Post on 06-Feb-2018
VALIDACIÓN DE SISTEMAS
COMPUTACIONALES
PhD. Francesco Amorosi 17, Sept. de 2015
Tendencias Nacionales e Internacionales en el ámbito de la Validación de Sistemas Computacionales
Elementos clave para la Validación de Sistemas Computacionales – PROY-NOM-059-SSA1-2015
Conclusiones
Ruegos y Preguntas
AGENDA
Tendencias Nacionales e Internacionales en el ámbito de la Validación de Sistemas Computacionales
Elementos clave para la Validación de Sistemas Computacionales – PROY-NOM-059-SSA1-2015
Conclusiones
Ruegos y Preguntas
AGENDA
LOS MEDICAMENTOS Y SU CALIDAD: UN PUNTO DE VISTA
OBJETIVO FINAL
Garantizar la Seguridad del Paciente dentro del Ciclo de Vida del Producto, desde la Investigación y Desarrollo (R&D) hasta su Distribución
“La Globalización ha alterado fundamentalmente los panoramas económicos y de seguridad requiriendo un cambio/esfuerzo mayor a Entes Regulatorios/Fabricantes, Distribuidores, Proveedores de Medicamentos para cumplir con su misión.”
5
Los nuevos retos son desencadenados por Procesos Globales en las Cadenas de Suministro
Algunas medidas regulatorias han sido definidas por las Entidades Regulatorias para mitigar los riesgos en la Calidad del Producto
Los inspectores están pidiendo cada vez más requerimientos de Integridad de Datos
El cumplimiento a las nuevas expectativas regulatorias se basa finalmente en la Integridad de Datos
Los servicios maquilados y las nuevas tecnologías (ejem. Cloud) pueden ser empleados por compañías reguladas tras una Calificación/Supervisión estricta del proveedor
LOS MEDICAMENTOS Y SU CALIDAD: CAMBIOS Y TENDENCIAS
La Tecnología Validada puede ser la única oportunidad que tenemos para enfrentar los retos actuales en la Industria Farmacéutica (globalización, reducción de costos, integridad de datos)…
RECIENTES CAMBIOS (RESUMEN)
Nuevo Anexo 11: 30 de Junio 2011
EFPIA, 2013
…
Guía sobre validación de proceso: vigente Julio 2014
Guía sobre validación de proceso 25 Enero 2011
… Food and
Drug Administration Safety and Innovation Act (FDASIA) 9 Julio 2012
NOM-059-SSA1-2013: En proceso de actualización Octubre 2015.
NOM-164-SSA1-2013: En proceso de actualización Octubre 2015
… Nuevo
Anexo 1 a las GMP de China sobre Validación de sistemas computacionales (Mayo 2015)
… GMP
Definición de integridad de datos y línea guía para la industria (Marzo 2015)
Los registros son confiables
Los Inspectores pueden acceder a los registros para tener evidencia de cumplimiento
Automáticamente se asegura la Cadena de Evidencia
Los registros pueden ser evaluados por el Ministerio de Salud en el caso de Investigaciones
QUÉ APORTA LA VERIFICACIÓN DE ESTAS NORMAS?
SI SATISFACES ESTAS NORMAS
LOS DATOS SON CONFIABLES
7
NOM-059-SSA1-2015
PROPUESTAS DE CAMBIOS (ÍNDICE): BUENAS PRÁCTICAS DE FABRICACIÓN DE MEDICAMENTOS
1. Objetivo y campo de aplicación.
2. Referencias.
3. Definiciones.
4. Símbolos y abreviaturas.
5. Documentación.
6. Sistema de gestión de calidad.
7. Personal.
8. Instalaciones y equipo.
9. Validación y calificación.
10. Sistemas de fabricación.
11. Devoluciones.
12. Liberación de producto terminado.
13. Control de calidad.
14. Retiro de producto del mercado.
15. Contratistas.
16. Destino final de residuos.
17. Concordancia con normas internacionales y mexicanas.
2 (Segunda Sección) DIARIO OFICIAL Lunes 22 de julio de 2013
18. Bibliografía.
19. Observancia.
20. Vigencia.
21. Apéndice A (Normativo). Áreas de fabricación.
1. Objetivo y campo de aplicación.
2. Referencias.
3. Definiciones.
4. Símbolos y abreviaturas.
5. Sistema de Gestión de Calidad
6. Gestión de Riesgos de Calidad
7. Personal
8. Instalaciones y equipo
9. Calificación y validación
10. Sistemas de fabricación
11. Laboratorio de Control de Calidad
12. Liberación de producto terminado
13. Retiro de Producto del Mercado
14. Actividades subcontratadas
15. Destino Final de residuos
16. Buenas Prácticas de Almacenamiento y Distribución
17. Concordancia con normas internacionales y mexicanas.
18. Bibliografía
19. Observancia
20. Vigencia.
21. Apéndices
21.1. Normativos.
Apéndice A. Clasificación de áreas de fabricación.
Apéndice B. Revisión Anual del Producto (RAP)
NOM-059-SSA1-2015: PROYECTO
NOM-059-SSA1-2013: VIGENTE
DETALLES NOVEDAD NUEVOS PUNTOS §9.13 --9.15 - NOM-059-SSA1-2015: PROYECTO
9.13 Validación de sistemas computacionales. 9.13.1 Los sistemas computacionales que impactan en la calidad del producto e integridad de datos, deben estar validados. 9.13.2 Deben contar con un inventario de todos los sistemas computacionales. 9.13.3 Los sistemas computacionales deben considerar componentes de software, instrumentos, equipos e infraestructura TI, entre otros. 9.13.3.1 Deben contar con un sistema de protección, integridad y respaldo de la información, los cuales deben determinarse basados en la documentación de evaluación de riesgos del sistema computacional. El acceso y legibilidad de los datos debe asegurarse durante todo el tiempo de retención. 9.13.3.2 El acceso a éstos debe ser controlado. 9.13.3.2.1 Se deben aplicar controles físicos y/o lógicos para restringir el acceso a usuarios con diferentes niveles de autorización. Los códigos de seguridad deben definirse de acuerdo a criterios predeterminados y ser modificados periódicamente. 9.13.3.2.2 El Sistema debe bloquear un usuario después de una cantidad definida de intentos de ingreso fallido. 9.13.3.3 Cuando un sistema computarizado genere registros electrónicos y/o emplee firmas electrónicas, éstos deben ser considerados en la validación: 9.13.3.3.1 Son considerados registros electrónicos los documentos y registros que son creados, modificados, mantenidos, archivados, recuperados y/o transmitidos a través de sistemas electrónicos. 9.13.3.3.2 En caso que se determine que un Sistema genera y mantiene datos electrónicos regulados, debe existir evidencia documental para asegurar su trazabilidad, fácil acceso e integridad de los mismos. 9.13.3.4 Si efectúan captura de datos críticos manualmente debe haber una revisión adicional en la exactitud de los datos que puede ser realizada por una segunda persona o a través de un medio electrónico validado. 9.13.3.5 Los datos deben ser protegidos por herramientas tales como copias de seguridad realizadas con las frecuencias definidas de acuerdo a un procedimiento. 9.13.3.6 La capacidad para restaurar los datos, así como la integridad y la exactitud para su respaldo, deberá ser verificada durante la validación y ser monitoreados en forma periódica. 9.13.3.7 Basado en un análisis de riesgo determinar la necesidad de que el sistema incluya un sistema de auditoría de datos, programada para registrar independientemente la fecha y hora de ingreso de los usuarios, así como las acciones de crear, modificar o eliminar registros electrónicos. 9.13.3.7.1 La auditoría de los datos (Audit trail) deberá prevenir su alteración y deberá estar disponible y convertible en un modo entendible, durante su periodo de retención, para permitir evidencia en la cadena de eventos.
9.13 Validación de sistemas computacionales. 9.13.1 Los sistemas computacionales que impactan en la calidad del producto deben estar validados. 9.13.2 Deben contar con un sistema de protección, integridad y respaldo de la información. 9.13.3 El acceso a éstos debe ser controlado. 9.13.4 Cuando un sistema computarizado genere registros electrónicos y/o emplee firmas electrónicas, éstos deben ser considerados en la validación: 9.13.4.1 Son considerados registros electrónicos los documentos y registros que son creados, modificados, mantenidos, archivados, recuperados y/o transmitidos a través de sistemas electrónicos.
NOM-059-SSA1-2015: PROYECTO NOM-059-SSA1-2013: VIGENTE
NUEVA NORMA COMPLETAMENTE REMODELADA !!!
10
NOM-059-SSA1-2015: Buenas prácticas de fabricación de medicamentos.
… Chapters ---
14. Actividades subcontratadas
15. Destino Final de residuos
17. Concordancia con normas internacionales y mexicanas Esta Norma es parcialmente equivalente a los estándares internacionales: (...) • EudraLex. Volume 4, Good manufacturing practice (GMP) Guidelines, Introduction, Part I, Part III and
Annexes 1, 2, 6, 8, 9, 11, 13, 14, 15 and 19. • Pharmaceutical Inspection Convention/Pharmaceutical Inspection Co-operation Scheme. Guide
to Good Manufacturing Practice for Medicinal Products Part I, II, III, Annexes. September 2009. • World Health Organization. Technical Report Series, No. 961, 2011 Annex 3, good
manufacturing practices for pharmaceutical products: main principles. Geneva, 2011. • U.S. Foods and Drug Administration. "Title 21, parts 11 & 211" Code of Federal Regulations,
Washington: Government Printing Office, 2012. (...)
DETALLES NOVEDAD NUEVOS PUNTOS §14--17 - NOM-059-SSA1-2015 : PROYECTO
ALINEAMENTO CON LAS PRINCIPALES NORMAS Y REFERENCIAS INTERNACIONALES
ADQUIRIR CONOCIMIENTOS EN TÉRMINOS DE EXPECTATIVA REGULATORIA
11
NOM-059-SSA1-2015: Buenas prácticas de fabricación de medicamentos.
… Chapters ---
18. Bibliografía (...) 18.21 ISPE. GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems. 2008. (...) 18.27 Anexo 20 “Buenas Prácticas de Fabricación de Medicamentos” PIC, Marzo 2014. 18.28 Guía de “Prácticas de Correcta Fabricación”, Ministerio de Salud de España “Gestión de Riesgo” 2008. 18.29 FDA (2004) Pharmaceutical CGMPS for the 21st century - A risk-based approach. Final report. 18.30 ICH (2005) “Quality risk management ICH Harmonised Tripartite Guideline Guideline Q9. 18.31 ICH (2008) Pharmaceutical quality system. ICH Harmonised Tripartite GuidelineQ10. 18.32 ICH (2009) Pharmaceutical development. ICH Harmonised Tripartite GuidelineQ8 (R2). 18.33 ICH (2011). Development and Manufacture of Drug Substances (Chemic al Entities and Biotechnological/Biological Entities). Draft Consensus Guideline Q11. 18.34 Vesper, J. L. (2006) Risk assessment and risk management in the pharmaceutical industry. Clear and simple. PDA/DHI. 18.35 CEI/IEC (1985) Techniques d’analyse de la fiabilité des systèmes. Procédured’analyse des modes de défaillance et de leurseffets (AMDE) / Analysis techniques for system reliability. Procedure for failure mode and effects analysis (FMEA). Norme international/International standard 608121985. 18.36 WHO (2003) Hazard and risk analysis in pharmaceutical products. Technical Report Series, No. 908. Annex 7
DETALLES NOVEDAD NUEVOS PUNTOS §18 - NOM-059-SSA1-2015 : PROYECTO
USO DE LAS LÍNEAS GUÍAS GAMP PARA CONOCER CÓMO CUMPLIR LOS REQUERIMIENTOS
Tendencias Nacionales e Internacionales en el ámbito de la Validación de Sistemas Computacionales
Elementos clave para la Validación de Sistemas Computacionales – PROY-NOM-059-SSA1-2015
Conclusiones
Ruegos y Preguntas
AGENDA
¿QUÉ IMPLICA EL NUEVO PROYECTO DE NORMA?
COMPRENDER CADA REQUERIMIENTO E IMPLEMENTAR MEDIDAS CORRECTIVAS PARA
CUMPLIR CON ELLOS
(y de dónde viene…)
ATTRIBUTOS DE CALIDAD DE LOS DATOS
¿QUÉ ES INTEGRIDAD DE DATOS?
14
QUE HACEN LOS DATOS APROPIADOS POR SU USO
EXACTITUD ACTUALIDAD PRECISION ENTEREZA
INTEGRIDAD: fuerza moral o ética, la calidad de ser honesto, y la
condición de estar libre de defectos o fallas y el estado de ser integro
INTEGRIDAD DEL DATO COMO PIEDRA ANGULAR DE LA REGULACIÓN
NECESIDAD FINAL
CONFIABILIDAD DEL DATO
REGLAS A CUMPLIR
NU
EVA
TEC
NO
LOG
ÍA
MA
YO
R C
ON
FIA
NZA
EN
P
RO
VEE
DO
RES
DE
SW/
PR
OC
ESO
S EX
TER
NO
S
15
CICLO DE VIDA VALIDACIÓN SISTEMAS COMPUTACIONALES
9.13.1 Los sistemas computacionales que impactan en la calidad del producto e integridad de datos, deben estar validados.
NUEVO PUNTO(S)
La Validación es un
PROCESO no un evento
Requerimientos
Selección del Sistema
Construcción Pruebas del Proveedor
Pruebas de Validación
Operación
Do
cum
en
taci
on
DEFINICIÓN SISTEMAS COMPUTACIONALES
9.13.3 Los sistemas computacionales deben considerar componentes de software, instrumentos, equipos e infraestructura TI, entre otros.
9.13.4.2 Los componentes de la infraestructura TI y cualquier instrumento o equipo relevante deben ser calificados.
De la definición PIC/S a la Integración de Conocimiento
Integración de conocimiento es el proceso de sintetizar múltiples modelos de conocimiento en un modelo común.
NUEVO PUNTO(S)
• Expectativas para el Ciclo de Vida de Validación
detallado
• Estrategia fuertemente basada PIC/S
• Requerimientos explícitos para la documentación
esperada
• Alineadas con las Buenas Prácticas IT
• Expectativas no prescriptivas. La Firma Regulada
deberá determinar cómo cumplir con los
requerimientos de la Norma establecida para
Validación.
• Referencia a la guía GAMP
• Guías relacionadas con Dispositivos Médicos
aplicadas como Buenas Prácticas también en
entorno Farma
ENFOQUE EN EL CICLO DE VIDA DE VALIDACIÓN
Anexo 11
CFR 21 Parte 11 PROY-NOM-059-SSA1-2015: • 9.13.4 El proceso de validación debe abarcar todas las fases
relevantes del ciclo de vida de acuerdo a la categoría y
arquitectura del sistema, para asegurar la exactitud, integridad y
consistencia en el desempeño previsto de los Sistemas
Computacionales.
• 9.13.4.1 La gestión de riesgos debe aplicarse al ciclo de
validación completo, incluyendo las fases de planeación,
especificaciones, pruebas, liberación del Sistema, mantenimiento
y retiro del sistema.
• 9.13.4.2 Los componentes de la infraestructura TI y cualquier
instrumento o equipo relevante deben ser calificados.
• 9.13.4.3 Para el proceso de validación, puede emplear las
pruebas ejecutadas por el proveedor, sin embargo la aceptación
de los registros de prueba entregados por el proveedor no deben
substituir las pruebas de validación efectuadas en sus
instalaciones, equipos y personal, tales como Plan de Validación,
Requerimientos de Usuario, Análisis de Riesgo, Calificación de
Desempeño, Reporte de Validación, entre otros.
• Estrategia fuertemente basada PIC/S
• Requerimientos explícitos para la documentación esperada
• Alineadas con las Buenas Prácticas IT
CICLO DE VIDA DE VALIDACIÓN – CICLO V
Construcción del Sistema
Relacionado con
Relacionado con
Relacionado con
Requerimientos de Usuario
(URS)
Calificación del Desempeño (PQ)
Especificaciones Funcionales
Calificación de Operación (OQ)
Calificación de Instalación (IQ)
Especificaciones de Diseño
ANÁLISIS DE RIESGOS SOBRE PROCESOS
ANÁLISIS DE RIESGOS SOBRE FUNCIONES
La DQ (Calificación del Diseño) para sistemas computacionales NO es requerido como documento en ninguna línea guía o estándar internacional relacionado a validación de sistemas computacionales.
FASES DEL CICLO DE VIDA
La mayoría de los sistemas cuentan con componentes de complejidad
variada, tales como sistema operativo, componentes no-configurados, y
componentes configurados o customizados. El esfuerzo se debe
concentrar como se define a continuación:
La categorización puede ayudar a enfocar los
esfuerzos donde el riesgo es mayor
CATEGORIAS GAMP Y ESFUERZO DE VALIDACION
Categoría 5
Customizado
Categoría 4
Configurados Categoría 3
No-
Configurados Categoría 1
Infraestructura
ESFUERZO
La selección del proveedor es crucial...
PERO
La Responsabilidad de la validación es
siempre del Cliente.
SELECCIÓN DEL PROVEEDOR
23
9.13.4.3 Para el proceso de validación, puede emplear las pruebas ejecutadas por el proveedor, sin embargo la aceptación de los registros de prueba entregados por el proveedor no deben substituir las pruebas de validación efectuadas en sus instalaciones, equipos y personal, tales como Plan de Validación, Requerimientos de Usuario, Análisis de Riesgo, Calificación de Desempeño, Reporte de Validación, entre otros.
NUEVO PUNTO(S)
UTILIZACIÓN DE LA DOCUMENTACIÓN DEL PROVEEDOR
Como está reportado en la guía de Integridad de Datos de MHRA, la aceptación de los datos de validación suministrado por el proveedor, en el aislamiento de la configuración del sistema y su uso previsto, no es aceptable
Utilice la documentación SOLO si está revisada y aprobada por Ustedes
EJEMPLOS DE PRUEBAS DEL PROVEEDOR
Unit Testing
• actividades deben realizarse con el fin de probar cada objeto de software respecto a su Unidad de Especificación de Diseño y verificar la correcta aplicación de cada función individuales de gestión de procesos.
Integration Test
Specification
• define aquellas pruebas que demuestran que todos los módulos de software se comunican entre sí correctamente y que el sistema cumple sus especificaciones de diseño. Para las soluciones basadas en el software configurable puede ser necesario en este punto integrar las pruebas para probar la configuración definida, según sea necesario, para cumplir con los URS
Site Acceptance
Testing
• Tienen que ser realizadas por el Proveedor con el fin de verificar:
• Funcionamento correcto del Sistema
• El cumplimento de los URS por parte del Sistema
• Correctas interfaz entre sistemas e instrumentos (si existen)
RELACIÓN Y VALIDACIÓN CLIENTE VS PROVEEDOR
Identificación del sistema
Definición de requerimientos de
usuario
Evaluación de Riesgo
Evaluación del proveedor
Planificación de la Validación
SISTEMA
Matriz de trazabilidad
Especificación de diseño
Especificación funcional
Calificación de Desempeño
Calificación de Instalación
Calificación de Operación
Reporte de resultados
Actividades de mantenimiento
Prueba de Módulo
Prueba de integración
Prueba de instalación
Prueba funcional
Act
ivid
ade
s d
el U
suar
ioA
ctiv
idad
es
de
l pro
vee
do
r
26
9.13.3.1 Deben contar con un sistema de protección, integridad y respaldo de la información, los cuales deben determinarse basados en la documentación de evaluación de riesgos del sistema computacional. El acceso y legibilidad de los datos debe asegurarse durante todo el tiempo de retención.
9.13.3.7 Basado en un análisis de riesgo determinar la necesidad de que el sistema incluya un sistema de auditoría de datos, programada para registrar independientemente la fecha y hora de ingreso de los usuarios, así como las acciones de crear, modificar o eliminar registros electrónicos.
9.13.4.1 La gestión de riesgos debe aplicarse al ciclo de validación completo, incluyendo las fases de planeación, especificaciones, pruebas, liberación del Sistema, mantenimiento y retiro del sistema.
NUEVO PUNTO(S)
GESTIÓN DE RIESGOS DURANTE TODO EL CICLO DE VIDA DEL SISTEMA
IMPLEMENTAR UNA APROXIMACIÓN BASADA SOBRE LOS RIESGOS PARA
DETERMINAR EL ESFUERZO DE VALIDACIÓN
ADECUADOS Y LAS MEDIDAS DE CONTROL NECESARIAS (i.e. AUDIT
TRAIL)
OBLIGATORIEDAD DE UN INVENTARIO PARA SISTEMAS COMPUTACIONALES
9.13.2 Deben contar con un inventario de todos los sistemas computacionales.
NUEVO PUNTO(S)
Actualizar
Inventario
Impacto
VALIDACIÓN DEL SISTEMA
COMPUTARIZADO
REVISIÓN PERIODICA
DE-COMMISSIONING
EVALUACIÓN DE IMPACTO
Commissioning
CONTROL DE CAMBIOS
NingunoIndirecto
Directo
Stop
SOLICITUD DE NUEVO
SISTEMA
CREAR EL INVENTARIOS OFICIAL DE TODOS LOS
SISTEMAS
IMPLEMENTAR UN PROCEDIMIENTO PARA
MANTENER EL INVENTARIO OFICIAL
ACTUALIZADO CON EL TIEMPO
INFRAESTRUCTURA IT
9.13.4.2 Los componentes de la infraestructura TI y cualquier instrumento o equipo relevante deben ser calificados.
NUEVO PUNTO(S)
29
9.13.4.4 Si se emplea un Sistema centralizado en múltiples sitios, el proceso de validación debe incluir la verificación de los procesos ejecutados a través del Sistema en cada sitio individual.
NUEVO PUNTO(S)
MÚLTIPLES SITES
DOCUMENTACIÓN CENTRALIZADA
DOCUMENTACIÓN LOCAL (SITE)
DOCUMENTACIÓN QUE
DEBE ENSEÑARSE A
LOS INSPECTORES
DOCUMENTACIÓN CENTRALIZADA
SÓLO LA DOCUMENTACIÓN CENTRAL NO PUEDE PROBAR QUE
EL PROCESO EJECUTADO EN EL SITIO ES CONFIABLE
VERIFICACIONES ADDICIONALES LOCALES (SITE)
30
9.13.5 Deben contar con una matriz de trazabilidad donde se documenten las múltiples etapas de especificaciones (incluyendo las revisiones) y las pruebas una vez que se han cumplido de manera satisfactoria.
NUEVO PUNTO(S)
MATRIZ DE TRAZABILIDAD
La Matriz de Trazabilidad hace referencia a las relaciones entre los Requerimiento de Usuarios versus las pruebas de test (IQ/OQ/PQ).
Documento que recoge los requerimientos definidos para la Calificación del Diseño. Este documento puede ser utilizado durante la evaluación del Control de Cambios para
identificar el impacto del cambio en el sistema y lo documentos de validación
User
Requirements
Functiona
Specifications
Design
Specification
Risk
Scenario
IQ/OQ
Test Scripts
PQ
Test Scripts
¿Cómo puedo encontrarlo en un tiempo razonable?
(1 minuto)
LA MATRIZ DE TRAZABILIDAD DURANTE LAS INSPECCIONES
CASO TÍPICO
1. El inspector está analizando el informe final 2. Él / Ella pregunta sobre una prueba específica
INPUT (INSPECTORES)
Desviaciones
Pruebas
Requerimientos
Función
Test
Requirement
Function
OUTPUT MATRIZ DE TRAZABILIDAD
Desviaciones
Requerimientos
Función
Pruebas
9.13.3.2.1 Se deben aplicar controles físicos y/o lógicos para restringir el acceso a usuarios con diferentes niveles de autorización. Los códigos de seguridad deben definirse de acuerdo a criterios predeterminados y ser modificados periódicamente.
9.13.3.2.2 El Sistema debe bloquear un usuario después de una cantidad definida de intentos de ingreso fallido.
NUEVO PUNTO(S)
SEGURIDAD
Authorised individuals
ACCESO
Activar una SOP para la Gestión de la Seguridad
Debe existir un documento que defina los criterios para asignar/revocar los privilegios de usuarios:
• Cuentas de usuarios con diferentes niveles o combinaciones de privilegios específicos
• Estaciones de trabajos desatendidas (Computadores) debe disponer de cierre automático de sesión (log-off) o protecciones físicas: Deben estar supervisados
Protección a través de un protector de pantalla con contraseña
CONTROL DE ACCESOS
Adoptar el principio de mínimos privilegios
33
Asignar a los usuarios el nivel mínimo de acceso que necesitan para desarrollar su trabajo durante el tiempo mínimo requerido.
Violaciones del principio de mínimos privilegios puede conllevar a:
• Perdida de la integridad de los datos
• Perdida de datos
Tipo de violaciones :
• Usuarios tiene demasiados accesos
• Usuario cambio el puesto de trabajo y mantiene los privilegios anteriores
• Usuario comparte credenciales de acceso (Login ID and Password)
ADOPTAR EL PRINCIPIO DE MÍNIMOS PRIVILEGIOS
34
ENFOQUE EN AUDITORÍA DE DATOS (AUDIT TRAIL) (1/2)
• Recomendamos que base su decisión en si aplica o no la auditoría de datos (Audit Trail), u otras medidas apropiadas, en la necesidad de cumplir con los requerimientos regulatorios, un análisis de riesgo justificado y documentado y en la determinación de los efectos potenciales en la calidad y seguridad del producto e integridad de datos.
• La Auditoría de Datos (Audit Trail) puede ser apropiada particularmente cuando se espera que los usuarios creen, modifiquen o borren registros regulados durante las operaciones normales.
• Se debe considerar, basados en un análisis de riesgo, la construcción dentro del sistema la creación de todos los registros relevantes a las BPF, cambios y eliminaciones.
• Para cambios o eliminación de datos relevantes a las BPF, la razón debe ser documentada.
• La Auditoría de datos (Audit trail) necesita estar disponible y ser convertible a un formato inteligible y que ser revisados periódicamente.
Anexo 11
Determine cómo revisar los registros de Auditorías de Datos (Audit Trail)
Guía Parte 11
PROY-NOM-059-SSA1-2015: 9.13.3.7 Basado en un análisis de riesgo determinar la necesidad de que el sistema incluya un sistema de auditoría de datos, programada para registrar independientemente la fecha y hora de ingreso de los usuarios, así como las acciones de crear, modificar o eliminar registros electrónicos. 9.13.3.7.1 La auditoría de los datos (Audit trail) deberá prevenir su alteración y deberá estar disponible y convertible en un modo entendible, durante su periodo de retención, para permitir evidencia en la cadena de eventos. 9.13.5.2 Deberán implementarse Procedimientos de control, que aseguren la revisión de la auditoría de datos de forma regular; la frecuencia y el método serán determinados, de acuerdo al riesgo. 9.13.5.3 Los sistemas con la funcionalidad de auditoría de datos deben emitir información que permita verificar si algún dato ha sido alterado desde su ingreso original.
AUDIT TRAIL - SUGERENCIAS
Ejemplo de acción que se controla a través de Audit Trail • Entrada de datos de proceso • Actualizaciones de registros clínicos • Cambios del estado de Materiales • Activación de una secuencia de fabricación • Desactivación de una alarma • Introducción/cambios de valores importantes/críticos por parte de un
operador (incluso dentro de los rangos validados) • Un comando para abrir/cerrar válvulas
Audit Trail debe activarse sólo para acciones humanas
La necesidad de Audit Trail no implica la necesidad de una firma (electrónica o manual)
37
Para los datos críticos ingresados manualmente, debe haber un control adicional sobre la exactitud de los datos. Esta verificación puede ser realizada por un segundo operador o por medios electrónicos validados. La criticidad y de las posibles consecuencias de los datos erróneos o incorrectamente introducidos a un sistema deben ser cubiertos por la gestión de riesgos.
9.13.3.4 Si efectúan captura de datos críticos manualmente debe haber una revisión adicional en la exactitud de los datos que puede ser realizada por una segunda persona o a través de un medio electrónico validado.
NUEVO PUNTO(S)
VERIFICACIÓN - EXACTITUD DE DATOS
Revisión Audit Trail
REVISIÓN DE AUDIT TRAIL
La decisión de integrar una Revisión de Audit Trail dentro del proceso de negocio necesita basarse en el riesgo y desempeñarse principalmente para los datos considerados de alto riesgo de acuerdo a un procedimiento definido, y solamente si los cambios de datos manuales son posibles en absoluto.
El Audit Trail debe demostrar que los datos relevantes están vinculados en la toma de decisiones. Un Audit Trail es básicamente lo mismo que una gestión de cambio al cumplimiento GMP de un registro en papel. Aplicar las mismas reglas para la revisión. En función de la criticidad del registro, debe haber una revisión de Audit Trail basada en riesgo.
REVISIÓN DE AUDIT TRAIL BASADO EN RIESGO
Manejo de Registros críticos
Es relevante para la liberación de los productos farmacéuticos
No hay pasos de liberación de calidad subsecuente
CONDICIONES
REVISIÓN CONTINUA La revisión de Audit Trail
(Verificación de la Integridad de datos) es mandatorio para los
datos completos que son utilizados por la Persona
Autorizada para desempeñar la actividad de liberación de lotes.
REVISIÓN PERIÓDICA (La revisión de Audit Trail para
garantizar que eventos no esperados hayan sido registrados)
REVISIÓN CONFORME AL EVENTO
(La revisión de Audit Trail para respaldar discrepancias,
auditorias internas o inspecciones)
SÍ NO
VERIFICACIÓN DE EXACTITUD (DOBLE VERIFICACIÓN)
La verificación por una segunda persona es requerida para pasos críticos, como el pesado y la adición de materias primas, porque se descubrió que históricamente son áreas problemáticas.
Una doble verificación GMP significa que una persona realiza el trabajo y la otra observa y hace sugerencias o correcciones .
En cuanto a datos manejados por un sistema computarizado sólo una parte de los registros críticos deben ser verificados con una doble verificación. REGISTROS ELECTRÓNICOS
REGISTROS
ELECTRÓNICOS
REGULADOSREGISTROS ELECTRÓNICOS
REGULADOS QUE NECESITAN
UNA DOBLE VERIFICACIÓN
ENFOQUE MIGRACIÓN DE DATOS
Docs FDA
WARNING LETTER
(…) la respuesta es inadecuada ya que carece de la evaluación retrospectiva de los datos de las unidades anteriores de HPLC. (…)
La FDA suele detallar los requerimientos a través de las Warning Letters (WL, Cartas de Advertencia)
Anexo 11
CFR 21 Parte 11
• (4.8) Si los datos son transferidos a otro formato de datos o sistema, la validación debe incluir la revisión de que los datos no sean alterados en valor y/o definición durante el proceso de migración.
PROY-NOM-059-SSA1-2015: 9.13.5.4 Si los datos son transferidos a otro formato de datos o sistema, la validación debe incluir la revisión de que los datos no sean alterados en valor y/o definición durante el proceso de migración
VERIFICACIÓN DE DATOS
La actividad de transporte de datos electrónicos de un
sistema a otro, o la transición de los datos de un estado a
otro:
• Conversión de Datos
• Actualización versión
mismo entorno
• Migración al mismo sistema
DATA
DB v. XX
APPLICATION v. AA
DATA
DB v. XX
APPLICATION v. BB
DATA
DB v. XX
DATA
DB v. YY
DATA DATA
SERVER 1
SERVER 2
VERIFICAR LA INTEGRIDAD DE LOS
DATOS EN CADA CASO
43
Cualquier cambio en un sistema computarizado incluyendo las configuraciones del
sistema, deben realizarse de una manera controlada, de acuerdo con un procedimiento
definido
9.13.5.1 Todo cambio a un Sistema computacional debe realizarse de acuerdo al sistema de control de cambios, incluyendo configuraciones de Sistema, deben aplicarse de acuerdo a un proceso predefinido y controlado que comprenda la definición del impacto del cambio y las actividades de verificación resultantes, incluyendo pruebas regresivas.
9.14.1 El mantenimiento de las instalaciones, equipos y servicios es otro aspecto importante para asegurar que el proceso se mantiene bajo control. Una vez que se ha logrado el estado calificado/validado debe mantenerse a través de monitoreo de rutina, mantenimiento, procedimientos y programas de calibración.
9.14.2.1 Si las instalaciones, servicios y equipos no han tenido cambios significativos, la evidencia documental de que estos cumplen los requisitos predefinidos es suficiente como evidencia de su mantenimiento del estado validado.
9.14.3 Cuando un cambio afecte la calidad o características del producto, o sus componentes y/o proceso, debe llevarse a cabo una nueva calificación y/o validación.
9.14.4 El mantenimiento del estado validado de los procesos de fabricación deben efectuarse de acuerdo a lo establecido en la verificación continua del proceso (etapa 3), véase el punto 9.9.2.3(*) de esta Norma.
NUEVO PUNTO(S)
CONTROLES DE CAMBIOS & GESTIÓN DE LA CONFIGURACIÓN
ENFOQUE: ALMACENAMIENTO DE DATOS
• 11.10 (c) Protección de datos para facilitar su recuperación precisa y en el momento a todo lo largo del periodo de retención de registros
• 7.1 Los datos deben asegurarse tanto por medios físicos como electrónicos contra daños. Los datos almacenados deben ser verificados en cuanto accesibilidad, legibilidad y precisión. El acceso a los datos debe asegurarse durante todo el periodo de retención.
• 7.2 Se deben hacer respaldos periódicamente de los datos relevantes. La integridad y precisión del respaldo de los datos y la habilidad de recuperación de los datos deben ser verificados durante la validación y ser monitoreados periódicamente.
Anexo 11
CFR 21 Parte 11
“El cómo” está definido en el Anexo 11
PROY-NOM-059-SSA1-2015: 9.13.3.3.2 En caso que se determine que un Sistema genera y mantiene datos electrónicos regulados, debe existir evidencia documental para asegurar su trazabilidad, fácil acceso e integridad de los mismos. 9.13.3.5 Los datos deben ser protegidos por herramientas tales como copias de seguridad realizadas con las frecuencias definidas de acuerdo a un procedimiento.
INTEGRIDAD
DE LOS DATOS
45
Los datos deben ser asegurados por medios físicos y
electrónicos contra posibles. Los datos almacenados se
deben revisar para la accesibilidad, legibilidad y precisión.
Acceso a los datos debe garantizarse durante todo el
período de retención.
Frecuentes respaldos de seguridad de todos los datos
relevantes. La integridad y la exactitud de los datos de
copia de seguridad y la capacidad de restaurar los datos
deben ser revisados durante la validación y monitoreados
periódicamente.
9.13.3.1 Deben contar con un sistema de protección, integridad y respaldo de la información, los cuales deben determinarse basados en la documentación de evaluación de riesgos del sistema computacional. El acceso y legibilidad de los datos debe asegurarse durante todo el tiempo de retención.
9.13.3.3.2 En caso que se determine que un Sistema genera y mantiene datos electrónicos regulados, debe existir evidencia documental para asegurar su trazabilidad, fácil acceso e integridad de los mismos.
9.13.3.5 Los datos deben ser protegidos por herramientas tales como copias de seguridad realizadas con las frecuencias definidas de acuerdo a un procedimiento.
9.13.3.6 La capacidad para restaurar los datos, así como la integridad y la exactitud para su respaldo, deberá ser verificada durante la validación y ser monitoreados en forma periódica.
NUEVO PUNTO(S)
ALMACENAMIENTO DE DATOS: RESPALDO-RESTAURACIÓN E INTEGRIDAD DE DATOS
9.14.2 Debe efectuarse una revisión periódica de las instalaciones, servicios y equipos, a fin de determinar si es necesario efectuar una nueva calificación. Ésta debe quedar documentada como parte del mantenimiento del estado validado.
NUEVO PUNTO(S)
REVISIÓN PERIÓDICA
Los Sistemas computacionales deben ser evaluados periódicamente para confirmar que se mantienen en un estado validado.
47
9.13.6.4 Las firmas electrónicas deberán estar enlazadas a sus respectivos registros electrónicos que aseguren que las firmas no han sido alteradas, copiadas o de alguna manera, transferidas a un registro electrónico para ser falsificadas por medios ordinarios.
9.13.6.5 En caso que la firma electrónica sea realizada mediante tokens o dispositivos biométricos, el sistema deberá asegurar que no puede emplearlo otra persona y que se han implementado medidas de control necesarias.
NUEVO PUNTO(S)
FIRMAS ELECTRÓNICAS
Los registros electrónicos podrán ser firmados electrónicamente. La firma electrónica debe tener las siguientes
características:
a. tener el mismo impacto que las firmas manuscritas dentro de la empresa,
b. estar permanentemente ligada a sus respectivos registros,
c. incluir la fecha y hora en que se firmó.
Registro Firmado
Firma
INMUTABLES e INTEGRAMENTE
UNIDOS
Tendencias Nacionales e Internacionales en el ámbito de la Validación de Sistemas Computacionales
Elementos clave para la Validación de Sistemas Computacionales – PROY-NOM-059-SSA1-2015
Conclusiones
Ruegos y Preguntas
AGENDA
INTEGRIDAD DE DATOS IMPACTO SOBRE VALIDACIÓN
FIABILIDAD
RESPONSABILIDAD
SECURIDAD
TRAZABILIDAD
REQUERIMIENTOS REGULATORIOS
REQUERIMIENTOS REGULATORIOS ESTABLECIDOS POR LAS BUENAS PRACTICAS DE FABRICACIÓN (NACIONAL E INTERNACIONAL) ESTÁN ORIENTADOS A GARANTIZAR LA INTEGRIDAD DE DATOS
INTEGRIDAD DE DATOS
SI LOS REQUERIMIENTOS REGULATORIOS SE CUMPLEN,
LA INTEGRIDAD DE DATOS ES GARANTIZADA
EVALUAR LOS SISTEMAS COMPUTARIZADOS vs REQUERIMIENTOS REGULATORIOS PARA EVALUAR
NIVEL ACTUAL DE INTEGRIDAD DE DATOS
¿HACIA DÓNDE NOS DIRIGIMOS?
Un sistema de calidad integrado es garantía que la calidad se construye dentro del producto
El conocimiento de los procesos es la base para la validación de sistemas
Aproximación a la Validación impulsada por análisis de riesgos y integridad de datos
ENFOQUE DE INSPECCIÓN DE LOS SEIS SISTEMAS
Guidance for Industry Quality Systems Approach to Pharmaceutical Current Good Manufacturing Practice Regulations, FDA, Sept 2002
Sistema de Producción
Sistema de instalaciones y
servicios
Sistema de Control del Laboratorio
Sistema de materiales
Sistema de acondicionado y
etiquetado Sistema
de
Calidad
TENDENCIAS CLAVE NUEVO PROYECTO NORMATIVO
Enfoque Proactivo
Mejora Continua
SME (Subject Matter Expert)
Basada en Riesgos y marcada tendencia prospectiva a la validación de Sistemas. Validar antes de Remediar.
Completo Ciclo de Vida de Validación. Detectar , evaluar/analizar y antes que suceda una falla resolver el problema
Armonización Normativa Globalización de los estándares y requerimientos de Validación
Gobernabilidad Integridad Datos La Validación de los Sistemas es parte de la aproximación a la Integridad y Seguridad de los Datos
La industria farmacéutica es tan especializada que requieres Expertos en cada materia. Evitar posibles Conflictos de Interés.
Tendencias Nacionales e Internacionales en el ámbito de la Validación de Sistemas Computacionales
Elementos clave para la Validación de Sistemas Computacionales – PROY-NOM-059-SSA1-2015
Conclusiones
Ruegos y Preguntas
AGENDA
Ruegos y Preguntas
CONTACTO