Posts tagged ‘GxP’

En este artículo quiero mencionarles algunos problemas en la validación de los sistemas computarizados que es muy probable verlos una y otra vez.

Nuestro objetivo es que al abordar estos desafíos de validación, si Ud. los considera se ahorrará tiempo, dinero y dolores de cabeza.

Pero mencionemos algunos de ellos:

  1. Falta de información

Algunos documentos o registros omiten información fundamental o contenido que debería haber sido incluido.

  1. Inconsistencia

Algunos documentos contienen ciertas declaraciones inconsistentes con otras declaraciones acerca del mismo tema, en el mismo o en otro documento del paquete de validación.

  1. Falta de detalles necesarios

Esta deficiencia se aplica principalmente a los documentos de requerimientos. Los requerimientos del paquete de validación no describen adecuadamente las características de los datos, las interacciones de los usuarios con los procesos de negocio o los procesos claves internos del software.

A veces los requerimientos son compuestos, no son únicos, por ejemplo una declaración estipula 2 o más características del sistema. Esta deficiencia o falla frecuentemente trae aparejado problemas de trazabilidad.

También podes mencionar la falta de criterios de aceptación.

  1. Trazabilidad:

La matriz de trazabilidad está incompleta. Los detalles de los requisitos no se numeran explícitamente y se relacionan a las etapas de prueba asociadas

  1. Vaga redacción o texto ambiguo

Los documentos usan generalidades tales como “de acuerdo con un procedimiento aprobado” o “requisitos reglamentarios aplicables” o “todos los GxP y procesos de negocio asociados”. Además, los documentos utilizan palabras vagas como “puede”, “posiblemente”, “más o menos”, y “aproximadamente”.

A veces el texto puede ser interpretado de más de una manera, por lo que no estableció un requisito único y único. Las palabras “cualquiera” y “o” en el requisito son fuertes indicadores que el texto es ambiguo.

  1. Resultados de las pruebas no verificables

Los resultados esperados no son suficientemente descriptos para que un revisor independiente pueda comparar y verificar los resultados reales. El estándar IEEE para documentación de prueba de software, std. 829.1988, la cláusula 6.2.4 (1) establece “… proporcionar el valor exacto (con las tolerancias cuando sea apropiado) para cada salida o característica requerida”. Para los scripts ejecutados, los resultados reales no fueron registrados ni capturados de manera que permitiera a un revisor independiente compararlos con los resultados esperados. Por ejemplo, “OK” se anotó en la columna de resultados reales sin referencia a la captura de pantalla.

  1. Buena práctica de documentación (BPD)

Registros poco claros, a veces los datos que confirman un requisito específico son difíciles de encontrar en la evidencia proporcionada (por ej. Una planilla llena de datos pero no está clara la evidencia), fallas en la corrección de errores documentales.

Se hacen correcciones escritas a mano que cambian el sentido del requisito o el resultado esperado de la prueba, pero no se presenta informe de discrepancia o solicitud de cambio (ej. Cambio de un resultado esperado del indicador “Off” a “On”). En las BPD, se siguen las correcciones de la mano sin documentación adicional solo cuando se trata de un obvio error tipográfico, como letras que faltan o están transpuestas (ej. Corrección “mantenimeinto” a “mantenimiento”)

  1. Pruebas incompletas:

Los scripts de prueba no prueban completa o adecuadamente el requisito asociado.

  1. Requerimientos incompletos:

El análisis del sistema indica que el software tiene funcionalidades que fueron usadas pero NO han sido descriptas en el URS.

Análisis de impacto regulatorio y análisis de riesgo indican la necesidad de requerimientos que no están en el URS.

Un requerimiento implica otro requerimiento, posiblemente complementario, que necesita ser explicitado para asegurar su verificación.

  1. Falta de 1 proceso para resolver desvíos

Los documentos y registros más vulnerables:

  • Especificaciones (incluyendo el URS) las más frecuentes
  • Scripts de testeo
  • Plan de validación
  • Matriz de trazabilidad
  • Resultados de testeos

Menos problemas relacionados a CSV conducen a una inspección exitosa.

El doble chequeo es un aspecto crítico e importante de las GxP. El impacto de un error, mix-up, o una equivocación puede ser monumental. Cada uno conoce lo importante que el chequeo y doble chequeo puede ser.

Quiero darles un ejemplo, para hacerlo más entendible y mantener la conciencia en el más alto nivel.

Durante algunos años trabajé en una Planta farmacéutico en el sector de producción y muchas veces cuando volvía de regreso a casa, conduciendo mi auto, pasaban unos cuantos km hasta que tomaba conciencia de que estaba manejando. Alguna vez les ha pasado esto?  Supongo que a muchos de Uds. Es más en ese momento pensaba, “que suerte que mi coche conoce el camino”.

El tema es que, conducir el auto es una habilidad que tenemos bastante fácilmente dominada, y para la mayoría de nosotros, una habilidad que hemos aprendido y dominado hace largo tiempo. Conducir el auto es una actividad de rutina, repetitiva, una tarea redundante, realmente no requiere mucho pensamiento. La mayoría de nosotros realiza su camino a través del tráfico de la ciudad cada día sin realmente prestar mucha atención a lo que estamos haciendo.

doble-check-azul

Entonces, me pregunto, cuantas tareas o trabajos en la compañía pueden ser caracterizadas como bastantes rutinarias, repetitivas y redundantes. La respuesta es la mayoría de ellas. Estas tareas o trabajos son caldo de cultivo para la complacencia. Así como muchos accidentes de tránsito son el resultado de complacencia, muchos mix-ups y errores en nuestras operaciones son el resultado de complacencia.

El doble chequeo es una efectiva herramienta para protegerse de la complacencia. Un efectivo doble chequeo requiere disciplina. Muchos lugares en nuestros documentos requieren una segunda firma. Esto significa una verificación independiente, No solo una segunda firma. La segunda firma es el doble check. La persona que efectúa el doble check (verificación independiente), debe entender la importancia de su role y las consecuencias si ella no efectúa la tarea exactamente y de manera completa.

Démosle valor a la firma.

Tomado de David Markovitz (GMP Training Systems).

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.

La validación es mandatoria para los sistemas GxP.

El nivel de la validación dependerá de la configuración del software y de cómo el proveedor diseñó, desarrolló y testeó el sistema computarizado (hardware y software).

La evaluación del proveedor y la categoría del software (de acuerdo a la GAMP5) son claves en el proceso de análisis de riesgo e influenciarán en la determinación de cuanto esfuerzo será requerido para la validación del sistema computarizado.

Les dejo los flujogramas propuestos para las actividades de validación de las categorías 3, 4 y 5, de acuerdo a la GAMP5 (2008).

Flujograma para un sistema de categoría 3.

Vmodel_cat3

Flujograma para un sistema de categoría 4 (adaptado).

Vmodel_cat4

 

Flujograma para un sistema de Categoría 5 (a medida).

Vmodel_Cat5

 

¿Qué tipos de sistemas computarizados debemos considerar?

En principio los relacionados a las actividades de controles del proceso, los relacionados al laboratorio, las aplicaciones de IT y lo relacionado a infraestructura.

Espero que les haya resultado interesante.

 

 

Cuando hablamos de Sistemas Computarizados en entornos GxP, la guía  seguida internacionalmente como referencia para validar y mantener a los sistemas, es la GAMP 5 (Good Automated Manufacturing Practice versión 5) confeccionada por el ISPE.

Planilla Excel cálculo MKT

Esta guía divide a los sistemas en 4 categorías de software, siendo la 1era la más sencilla y la 5ta la más compleja (la categoría 2 desapareció en esta versión).  A medida que aumenta la categoría, se debe ir incrementando la complejidad de los ensayos durante la etapa de validación, respondiendo a softwares más complejos y con más posibilidades de fallas.

Básicamente la división obedece a:

  • Categoría 1: softwares de infraestructura no configurables
  • Categoría 3: se pueden modificar algunos parámetros pero el software tampoco es configurable
  • Categoría 4: Softwares usualmente complejos, cuyos parámetros pueden ser configurados por el usuario de acuerdo a sus necesidades.
  • Categoría 5: Softwares customizados, no se fabrican en serie, sino a medida del

En que categorías coloca la GAMP 5 a nuestras planillas de cálculo?

Sorpresa!!,  en la categoría 4ta, y en la 5ta cuando tiene funciones macro.

Definitivamente nuestras planillas de cálculo son muy vulnerables, razón por la cual deben estar sólidamente diseñadas y protegidas y el proceso de validación debe reflejar consistentemente la robustez de lo hecho.

Si te faltan recursos … te ayudamos.