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