Posts tagged ‘propietario del sistema’

La nueva disposición de la ANMAT tiene establecidos requerimientos para los sistemas computarizados o informatizados en el Anexo 6 Sistemas Informatizados de la nueva Disposición.

Este Anexo aplica a todas las formas de sistemas informatizados usados como parte de las actividades reguladas por las BPF y se utilicen para crear, modificar, mantener,  archivar, obtener o distribuir registros electrónicos.

Además de Validar las aplicaciones, debemos calificar la Infraestructura  informatizada (IT).

La inclusión de un sistema informatizado en la manufactura no debe aumentar el riesgo total del proceso.

Estos lineamientos de la nueva GMP están basados en la GAMP5 (ISPE) A Risk-based Approach to Compliant GxP Computarized Systems.

Como parte del sistema de gestión de riesgos, las decisiones sobre la extensión de la validación y de los controles de la integridad de datos deben basarse en una evaluación de riesgos del sistema informatizado justificada y documentada.

La norma menciona diferentes figuras que deben existir, como: el propietario del proceso (process owner), el propietario del sistema (system owner), las Personas Calificadas e IT. Obviamente todo el personal debe estar calificado, con su nivel de acceso y definidas sus responsabilidades.

Los proveedores de sistemas informatizados deben estar evaluados y debe disponerse de acuerdos técnicos y acuerdos de confidencialidad (ppalmente. para acceso remoto). La necesidad de auditarlos debe estar basada en un análisis de riesgo del mismo.

Debe disponerse de un inventario de los sistemas computarizados del laboratorio.

La Validación debe ser proporcional al riesgo del sistema (clasificación del riesgo, por ejemplo Categoría GAMP5 y calificación del proveedor), a más riesgo más esfuerzos de validación.

La transferencia de datos debe ser efectuada de forma segura.

En cuanto a la Operación de los SC, debemos asegurar que los datos son guardados regularmente de forma integra durante el período de conservación de los mismos. Debe haber un Audit Trail y debe ser considerada la Gestión de cambios y configuración.

Los sistemas informatizados deben ser revisados periódicamente para verificar la validez de la validación. Esta revisión incluye por ejemplo documentos de operación, validación, cambios, eventos, accesos y manejo de back up, por ej.

También hace referencia a otros temas de importancia como el manejo de firmas electrónicas, plan de Disaster Recovery, etc.

Desde cGMPdoc les ofrecemos distintas alternativas como:

  1. Entrenamientos “In Company” para capacitar a su personal
  2. La implementación del proceso de CSV (Validación de Sistemas Computarizados), lo cual incluye la discusión del procesos internamente con el laboratorio, la confección de los SOPs necesarios, el entrenamiento del personal, la confección del PMV de sistemas computarizados y la ejecución de una validación a modo de ejemplo, de manera que Uds. puedan luego continuar con las actividades del Plan.
  3. La validación de un sistema computarizado
  4. Asesoramiento en la revisión de su proceso de CSV si lo necesita
  5. Pack de SOPs y documentos modelos sobre CSV

Espero que les resulte de utilidad.

La GAMP5 pone particular énfasis en dar lineamientos sobre un enfoque efectivo para compliance y para demostrar que el sistema es adecuado para sus propósitos de uso.

Por tal motivo da lineamientos sobre:

  • Un enfoque completo de ciclo de vida de los sistemas computarizados como parte de un sistema de gestión de calidad, desde la conceptualización del mismo hasta su retiro.
  • Un enfoque de escalado para alcanzar y mantener el cumplimiento GxP direccionado a la novedad, complejidad, riesgo al paciente, calidad del producto y de integridad de datos.
  • Clarificar el rol de la unidad de calidad y e introducir otros roles como Propietario del proceso, Propietario del sistema y SME (Subject Matter Expert).
  • En el entorno GMP, esfuerzos para disponer de claros requerimientos basados en el conocimiento del sistema y de los atributos críticos de calidad del proceso / producto, para facilitar la adopción de un enfoque de Quality by Design.
  • Aprovechar la documentación del proveedor y el conocimiento, si es posible, de forma de evitar duplicarlas de forma innecesaria.
  • Mejorar la eficiencia por medio de promover una interpretación práctica y efectiva de esta guía.
  • Maximizar el uso de documentación desde actividades, tales como desarrollo y commissioning, como evidencia de verificación.
  • La importancia de un seguimiento efectivo para alcanzar y mantener el cumplimiento.
  • Identificar oportunidades para mejorar de procesos y sistemas basados en la revisión periódica, análisis de causa raíz, y CAPA.

La guía intenta actualizarse a un entorno de cambio, además de buscar cumplir con las GxP vigentes y hacer foco en la Gestión de riesgos de Calidad.

 

  1. Hay una separación clara de responsabilidades y cooperación entre todo el personal relevante tal como propietario del proceso de negocios, propietario del sistema, una persona calificada de QA e IT?
  2. Hay un Análisis de riesgo documentado efectuado a lo largo del ciclo de vida del sistema computarizado, teniendo en cuenta la justificación para la validación, seguridad del paciente, integridad de datos y la calidad del producto?
  3. La documentación de validación incluye los registros de Controles de Cambios (si los hay) y los reportes sobre cualquier desvío observado durante el proceso de validación?
  4. Hay una URS para cada sistema, donde se describen las funciones esperadas por los usuarios y estas son trazables a lo largo del ciclo de vida de los documentos?
  5. Para la validación de SC customizados / categoría 5 GAMP5, hay un proceso “in place” para asegurar el análisis formal y el reporte de calidad y medidas de la performance para todas las etapas del ciclo de vida del SC?
  6. En el caso que sean transferidos datos a otro formato de datos o sistema. La validación incluye la verificación que los datos no han sido alterados en valor y/o significado durante el proceso de migración?
  7. En el caso que el SC intercambie datos electrónicamente con otros sistemas. Hay chequeos incorporados apropiados para verificar el correcto y seguro ingreso y proceso de los datos, de manera de minimizar los riesgos?
  8. En el caso que sean ingresados datos de forma manual. Hay una verificación adicional efectuada por una segunda persona o medio electrónico validado para asegurar la exactitud de los mismos? La criticidad y las consecuencias potenciales de potenciales errores o datos ingresados de forma incorrecta debería ser cubierta por la gestión de riesgo.
  9. Cómo es la seguridad de los datos frente al daño (tanto física como electrónica)? Los datos almacenados deberían ser chequeados para su accesibilidad, lectura y exactitud. El acceso a los datos debe ser asegurado a lo largo del período de retención.
  10. Es efectuado un back up de los datos de forma regular? La integridad y exactitud del back up de datos y la capacidad para recuperar datos debe ser verificada durante la validación y el monitoreo periódico.
  11. Es posible obtener copias impresas de datos almacenados electrónicamente de forma clara?
  12. Para registros que soportan la liberación del lote, es posible generar impresiones indicando si alguno de los datos ha sido cambiado desde la entrada original?
  13. Hay un “Audit Trail” diseñado dentro del sistema el cual registra todo cambio GMP relevante y las eliminaciones?
  14. Todos los cambios y eliminaciones de datos GMP relevantes son documentadas con una justificación?
  15. Los audit trails están disponibles y convertibles a un formulario comprensible?
  16. Los cambios a un SC son incluidos en un sistema de configuración hecho en una forma controlada de acuerdo a un procedimiento definido?
  17. Todos los SC son periódicamente evaluados para confirmar que ellos se mantienen en un estado validado y están en cumplimiento de las GMP? Las evaluaciones deberían incluir, si es apropiado, el rango actual de funcionalidad, el registro de los desvíos, incidentes, problemas, historial de las actualizaciones, performance, confiabilidad y reportes de estatus de validación.
  18. Hay controles físicos y lógicos, “In Place” para restringir el acceso a los SC a las personas autorizadas? Por ejemplo, uso de claves, tarjetas, código personal con contraseñas, biométricas, para restringir el acceso a áreas del equipamiento computarizado y almacenamiento de datos.
  19. Los sistemas de gestión de datos y documentos están diseñados para registrar la identidad de los operadores que ingresan, cambian, confirman o borran datos incluyendo la fecha y la hora?
  20. Cómo son reportados y evaluados los incidentes? La causa raíz del incidente debe ser identificada y debe ser la base de la acción correctiva (CAPA).
  21. Ha sido efectuada la evaluación de la parte 11 para los sistemas relevantes?
  22. Hay un procedimiento que confirma que la firma electrónica tiene el mismo impacto que las formas manuscritas dentro de los límites de la compañía?
  23. Las firmas electrónicas permanecen relacionadas a sus respectivos registros electrónicos?
  24. Cuando el sistema computarizado es usado para la certificación y liberación de lotes, el sistema permite solo personas calificadas para certificar la liberación de los lotes y claramente identificada y registra la persona que libera y certifica los lotes? Esto podría ser efectuado utilizando una firma electrónica.
  25. Los datos han sido chequeados para su accesibilidad, disponibilidad e integridad?

CSV

El proceso de Análisis de riesgos conducido como parte del ciclo de vida de validación de sistemas computarizados, nos permite poner el énfasis y la atención apropiada en aquellas partes del sistema que pueden tener potencial impacto sobre la seguridad al paciente, la calidad del producto y la integridad de datos.

mitigarriesgo1

Es recomendable conformar un equipo para el manejo de la validación de los sistemas computarizados inicialmente, y para el posterior manejo de los cambios que pudiera tener el sistema durante su uso productivo. Este equipo debe tener como mínimo de los siguientes roles:

  • Propietario del sistema (inicialmente este role puede ser llevado a cabo por el manager del proyecto)
  • Propietario de procesos del negocio
  • Proveedor (o representante técnico)
  • Representante de IT (con formación en Compliance)
  • Representante de Quality Assurance

Los principios de evaluación y gestión de riesgos son aplicados desde que se introduce un sistema informático a la planta, y además durante el control de cambios, la revisión periódica y el decomiso del mismo.

Como parte de la implementación inicial del sistema computarizado, se evalúan los riesgos del proyecto, por ejemplo: restricciones de recursos, falta de conocimiento técnico, financiación, estabilidad del proveedor, etc. Estos riesgos del proyecto pueden ser manejados por el Propietario de procesos del negocio o Project Manager.

Registro del sistema y determinación del impacto regulatorio

Se trata de la primera etapa de análisis de riesgos del sistema, donde se efectúa una evaluación regulatoria (por ej. si el sistema tiene impacto GxP), o es crítico para el negocio, SOx, Finanzas, Privacidad de datos, eDiscovery. Luego de esta evaluación, se toma y se registra la decisión sobre si el sistema será validado.

Clasificación de riesgo del sistema

Si un sistema computarizado debe validarse entonces debe llevarse a cabo una clasificación de riesgo del sistema para ayudar a determinar el nivel y el alcance de las actividades de validación requeridas. Los resultados de la clasificación de riesgos deben ser registrados.

La clasificación de riesgos del sistema asigna un score que puede ser Alto, Medio o Bajo basado en:

  • El status GxP del sistema
  • El status de evaluación del proveedor (Rojo, Amarillo o Verde)
  • La categoría GAMP5 del sistema
  • Si el sistema almacena registros GxP
  • Si el sistema tiene una red de conectividad.

Estos factores son registrados en el sistema de registro.

Esta clasificación de riesgo pretende reflejar el potencial nivel de riesgo que el sistema tiene para el proceso de negocio, por ej. Si el sistema fue desarrollado a medida, de acuerdo a las GAMP es categoría 5, o el proveedor tiene un sistema de gestión de calidad que NO es lo suficientemente maduro, la clasificación de riesgo del sistema establecida será mayor para asegurar que se aplican controles más exhaustivos durante el ejercicio de validación del sistema.

Para cada sistema, los entregables requeridos son descriptos en el Plan de Validación del sistema computarizado. El nivel de las actividades de validación dependerá de la clasificación del sistema, bajo, medio o alto, el paquete de testeos y su ejecución podría ser efectuado por el proveedor en el caso de un sistema de bajo riesgo, aunque en el caso de un sistema de alto riesgo, el paquete suele ser desarrollado en conjunto (proveedor + laboratorio) y la ejecución puede ser efectuada por el proveedor con la aprobación final del laboratorio o efectuada por el laboratorio.

Análisis de riesgo funcional

Si es requerido, un análisis de riesgo funcional es llevado a cabo. Esto se puede hacer a un nivel alto y / o un nivel funcional. El factor clave para llevar a cabo una evaluación de riesgos funcional es en los casos donde los escenarios de riesgo y la probabilidad y controles de mitigación no pueden determinarse sólo por hacer una evaluación de alto nivel y donde se requiere más detalle. Evaluación del riesgo sólo puede llevarse a cabo una vez que el diseño del sistema se ha acordado y aprobado. Los sistemas de bajo riesgo no necesitan someterse a una Evaluación de Riesgos. Los sistemas clasificados como de medio y alto riesgo deben someterse a una evaluación de riesgos en un nivel alto como mínimo. Una evaluación de riesgo alto nivel considera requisitos en grupos.

  • La primera etapa es para clasificar los requerimientos. Dentro del URS, para cada requerimiento:
    • Establecer el impacto GxP
    • Establecer la criticidad para el negocio
    • Establecer cualquier otra área sujeta a regulación, ej. SOx, Financiera, Privacidad de datos, eDiscovery.
  • La segunda etapa implica la realización del análisis de riesgo para cada requerimiento

El foco de la evaluación está en la interacción del sistema con el proceso de negocio.

El análisis de riesgo debe considerar, para cada requerimiento:

  • Qué podría salir mal (modos de fallas);
  • Probabilidad
  • Impacto
  • Detectabilidad

Luego se lleva adelante un sistema de score de riesgos basados en la probabilidad de ocurrencia, el impacto o severidad del evento y la detectabilidad del mismo (según el enfoque de la GAMP5), el foco debe estar en aquellos ítems donde la clasificación final del riesgo del sistema es medio o alto.

A modo de ejemplo podemos utilizar los siguientes valores:

Probabilidad (1-3)

Severidad (1-3)

Detectabilidad (1-5)

De acuerdo a estos valores, el score mínimo es 1 y el máximo a obtener es 45 y podemos valorar los riesgos de la siguiente manera:

Bajo riesgo (1-4)

Riesgo medio (5-10)

Alto riesgo (>10)

  • La tercera etapa en el proceso es para identificar los controles de mitigación para cada requerimiento. Los controles incluyen testeos técnicos y de negocios, SOPs, requerimientos de entrenamiento, etc.
  • El reporte de la Evaluación de Riesgos funcional, puede ser elaborado utilizando un modelo o template adecuado, y el mismo debe ser aprobado por QA.