validación de sistemas · pdf filetendencias nacionales e internacionales en el...

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

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



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



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.



Conclusiones

Ruegos y Preguntas

AGENDA

Ruegos y Preguntas

CONTACTO

validación de sistemas · pdf filetendencias nacionales e internacionales en el...

Documents