SIMPOSIO - Colegio Nacional de Químicos Farmacéuticos ... · (ej. en el Inventario de Sistemas...
Transcript of SIMPOSIO - Colegio Nacional de Químicos Farmacéuticos ... · (ej. en el Inventario de Sistemas...
SIMPOSIO PROPUESTA DE CAMBIO DE LA NOM-059
PUNTOS CRÍTICOS – VALIDACIÓN SISTEMAS COMPUTACIONALES
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 !!!
APROXIMACIÓN MÁS DETALLADA
DEL PUNTO
9.13 AL 9.15
ARMONIZACIÓN NORMATIVA
NOM-059-SSA1-2015: Buenas prácticas de fabricación de medicamentos.
Apartados
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.
(...)
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.
ALIN
EAM
ENTO
CO
N LA
S PR
INC
IPALES N
OR
MA
S Y
REFER
ENC
IAS IN
TERN
AC
ION
ALES
AD
QU
IRIR
CO
NO
CIM
IENTO
S EN TÉR
MIN
OS D
E EX
PEC
TATIV
A R
EGU
LATO
RIA
EL DATO – PIEDRA ANGULAR
INTEGRIDAD
DATO
VALIDACIÓN DE SISTEMAS COMPUTACIONALES – PARTE INTEGRANTE DE LA INTEGRIDAD DE DATOS
CSV
Integridad Datos
Reforzar Políticas de Seguridad
Revisión del Audit Trail
Validación Sistemas Computacionales Evaluación de Derechos
del Usuario Revisión de “Audit Trail”
INTEGRIDAD DE DATOS
VALIDACIÓN DE SISTEMAS COMPUTACIONALES
Implementación de Políticas de Seguridad
(Restricción a aplicaciones, Protección de carpetas,
Definición/Integración de Políticas de OS)
APROXIMACIÓN A LA VALIDACIÓN
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
enta
cio
n
APLICA
Basada en una Aproximación de GESTION de RIESGOS
INICIO & EVALUACIÓN DE ESFUERZO DE VALIDACIÓN
SISTEMA
INVENTARIO
EVALUACIÓN DEL IMPACTO
EVALUACIÓN DE RIESGOS BPx
ACTIVIDADES DE VALIDACIÓN
EVALUACIÓN DEL SISTEMA
CRITICIDAD
COMPLEJIDAD
EL ESFUERZO DE VALIDACIÓN
DEBE SER MÁXIMO PARA
SISTEMAS DE ALTA CRÍTICIDAD
Y COMPLEJIDAD, EL
ESFUERZO PODRÍA REDUCIRSE
A TRAVÉS DE AUDITORÍAS Y
DOCUMENTACIÓN DE
PROVEEDORES EN CASO DE
SW ESTÁNDARES CATEGORÍA
REGLA DE ORO
PROCESOS
DATOS
SISTEMA
ACTIVIDADES DE VALIDACIÓN
Reporte
TestingDefinición de Requerimientos y Especificaciones
Planeación
Construcción
del sistema
Protocolo de Calificación de
Instalación (IQP)
Protocolo de Calificación de
Desempeño (OQP)
En
Mar
cha
Evaluación
GxP Del sistema
Protocolo de Calificación de
Operación (OQP)
Requerimientos de Proceso
URS
Requerimientos Regulatorios
Especificaciones Funcional de
Diseño y Configuración
Requisitos Funcionales de
Automatización
Evaluación de
Riesgos
Análisis de Riesgos
Anexo 1: Procedimiento del
plan de pruebas.
Plan de Validación
Anexo 1: Matriz de trazabilidad
Reporte de
Validación
Reporte
TestingDefinición de Requerimientos y Especificaciones
Planeación
Construcción
del sistema
Protocolo de Calificación de
Instalación (IQP)
Protocolo de Calificación de
Desempeño (OQP)
En
Mar
cha
Evaluación
GxP Del sistema
Protocolo de Calificación de
Operación (OQP)
Requerimientos de Proceso
URS
Requerimientos Regulatorios
Especificaciones Funcional de
Diseño y Configuración
Requisitos Funcionales de
Automatización
Análisis de Riesgos
Anexo 1: Procedimiento del
plan de pruebas.
Plan de Validación
Matriz de trazabilidad
Reporte de
Validación
RESPONSABILIDAD DE LA INDUSTRIA FARMACÉUTICA
AUDIT TRAIL – SEGURIDAD EN LA INTEGRIDAD DE DATOS (1/4)
Si se considera necesario según su riesgo que un sistema disponga de Audit Trail y éste es incapaz de gestionar la auditoria de datos, deberán implementarse otras medidas (ej. Bitácora/Logbook) que permitan substituir su función. Se identificará que sistemas es necesario que tengan implementado el Audit Trail y que sistemas no cumplen con dicho requerimiento (ej. en el Inventario de Sistemas Computacionales).
Basado en un análisis de riesgo determinar la necesidad de que el sistema incluya un sistema de auditoría de datos.
Auditoria de Datos
El Audit Trail debe incluir cómo mínimo: • Identidad operador (User ID) • Fecha y Hora (hora de servidor, incluyendo zona horaria si está disponible) • Indicación inequivoca de que ha sido cambiado • Nuevo valor del dato (cambiado) • Razón (si es requerido por norma)
¿Qué debería incluir el Audit Trail?
AUDIT TRAIL – SEGURIDAD EN LA INTEGRIDAD DE DATOS (2/4)
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.
Auditoria de Datos
Audit Trail - Inalterable
Permite también el control de la Integridad, Fiabilidad y
Exactitud de los Datos generados en el pasado -
Retrospectiva
Audit Trail Identificación Reconstrucción
de los eventos
Característica Propósito Objetivo
AUDIT TRAIL – SEGURIDAD EN LA INTEGRIDAD DE DATOS (3/4)
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.
Auditoria de Datos
Enfoque en la Revisión de “Audit Trail” 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 BPF 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.
La revisión del Audit Trail puede tener gran impacto sobre los procesos de rutina
¡Adecuar la revisión de acuerdo al Riesgo!
Nivel de Riesgo
PROCESOS REGULADOS
REGISTROS RIESGO
ASOCIADO A REGISTROS
MÉTODO DE REVISIÓN DE
“AUDIT TRAIL”
Esfuerzo para la revisión de Audit Trail
AUDIT TRAIL – SEGURIDAD EN LA INTEGRIDAD DE DATOS (4/4)
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.
Auditoria de Datos
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
VALIDACIÓN MULTISITE (1/2)
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.
SISTEMA MULTISITE
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)
ELEMENTOS CLAVE FASE OPERACIONAL
• ¡Mantener el Sistema bajo control!
• ¡Asegurar la integridad de los registros!
SEGURIDAD
RESPALDO /RESTAURACIÓN
ARCHIVO
CONTROL ACCESO
LOGICA
TRAZABILIDAD
CONTROL DE CAMBIOS
GESTIÓN DE LA CONFIGURACIÓN
GESTIÓN INCIDENTE
MANTENIMIENTO
REVISIÓN PERIÓDICA
FORMACIÓN
FLUJOS INFORMATIVOS - ACTIVIDADES OPERACIONALES
Los Grupos de Procesos están relacionados
Vinculo de:Sistema entregado al
NegocioOperación del sistema
Comienzo de la vida de operación del sistema
Gestión de servicios y Monitoreo de
Desempeño
Programa de actividades de soporte/tarea de monitoreo de desempeño apropiada
Servicio o soporte requerido
Administración de la seguridad y del sistema
Proceso de Gestión de Cambios
Proceso de Gestión de Incidentes y CAPA
Proceso de Revisión y Auditoría
Proceso de Gestión de la Continuidad del Negocio
Administración de problemas de seguridad y requerimientos recibidos
Se requieren cambios al sistema
Ocurre un incidente
Incidente escalado
Acciones correctivas identificadas
Problemas resueltos;Requisición cumplida;Registros de seguridad y administración generados.
Cambio concluido y Registro de gestión de cambio generado
Incidente resuelto y acciones preventivas tomadas donde se requieran
Continuidad de uso del sistema
Registros de auditoría generados
Proceso de Gestión de Registros
Gestión de registro de las actividades/tareas apropiadas
Gestión de registro de las actividades/tareas apropiadas
Sistema sustituido o listo para ser reemplazado
Sistema sustituido o listo para ser reemplazado
Registros disponibles para auditoría y revisión
Registros disponibles para auditoría y revisión
Registro de servicios e información de desempeño general
Otros procesos de soporte: Procedimientos de usuario final de Gestión documental, Calibración, Formación, Mantenimiento.
Fuente: Figura 4.5, GAMP 5: Un enfoque basado en el riesgo para el cumplimiento de BPx de Sistemas Computarizados, © Copyright ISPE 2008. Todos los derechos reservados. www.ISPE.org
GESTIÓN DE CAMBIOS
Gestión de Cambios consiste en la gestión de procesos de control de cambios y configuración en una organización.
Fundamental para permitir al sistema evolucionar, mientras se mantiene su control.
Es el proceso que controla la evolución del desarrollo de los componentes del sistema garantizando que los cambios en los componentes son registrados, evaluados, autorizados y gestionados.
Gestión Configuración
Control de Cambios
GESTIÓN DEL CAMBIO
Configuración base (Baseline)
de Infraestructura
Configuración base (Baseline)
Funcional
¿El cambio impacta la
Configuración base (Baseline) del
Sistema?
No
Sí
Análisis
Aseguramiento
Calidad
Configuración base (Baseline)
del Sistema
¿El cambio impacta la
configuración base (Baseline)
funcional del Sistema?Sí
No
¿Impacto BPx?
Identificar el
cambio como
“Funcional”
Sí
Identificar el
cambio como “De
Configuración”
System Risk Analysis Baseline
Desarrollo del
ciclo de vida
del software
NoGestión de
cambios en la
infraestructura
TI
Gestión de la
liberación
Gestión de la
Configuración
Documentación de
Validación
• Solo los cambios que impactan las BPx funcionales requieren un análisis de Aseguramiento de Calidad; todos los cambios en infraestructura, núcleos, BPX no funcionales (ejem. cantidades) pueden ser de paso libre: solo se requiere que la configuración base (Baseline) sea actualizada.
APROXIMACIÓN AL CONTROL DE CAMBIOS
CONCLUSIONES Y BENEFICIOS
Aproximación regulatoria alineada con normatividad Internacional – Acceso a nuevos mercados
No enfocado solo al cumplimiento sino a la mejora continua
El conocimiento de los procesos es la base para la validación de sistemas
Control de los Flujos de Proceso Regulados por las BPM y gestionados por el sistema
Aproximación a la Validación impulsada por análisis de riesgos y integridad de datos
Ciclo de Vida de Validación, de la selección del proveedor al decomissioning del sistema – Asegurar la Integridad y exactitud de los datos.
PÍLDORA DE CUMPLIMIENTO
“Confiamos en Dios; todos los demás
tenemos que aportar datos..”
W. Edwards Deming (Become FDA Motto)
“Si no está Documentado es un rumor.”
Ron Tetzlaff
(former FDA Investigator)
“In this industry we make two products: drugs and data - unfortunately, the authorities are only interested in the data”
Richard Sykes, ex-CEO of Glaxo SmithKline
Ruegos y Preguntas
CONTACTO