BLOG para cGMPdoc.com

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.

2. 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.

3. 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.

4. 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

5. 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.

6. 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.

7. 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”)

8. Pruebas incompletas:

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

9. 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.

10. 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.

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?

Dentro de estos requerimientos básicos, les dejamos 10 tips claves, esenciales para asegurar la integridad de los datos dentro de los límites de un sistema de datos electrónicos:

1. Identidad única para cada usuario:

Para sistemas basados en papel, siguiendo las Buenas Prácticas de Documentación la identificación de cada analista puede ser alcanzada a través de que cada persona firme o coloque sus iniciales sobre una impresión o notebook de laboratorio. Con los sistemas electrónicos, este principio debe ser mantenido por medio de la identidad única del usuario.

Las cuentas de usuarios no deben ser compartidas, por ej. Una cuenta de usuario establecida para dos analistas para el acceso a un software de laboratorio de un sistema HPLC.

Las identidades de los usuarios no deben ser reusadas, si una persona deja el laboratorio o la compañía, esa identidad del usuario (ID) debe ser removida del uso y cualquier nuevo usuario debe ser habilitado con un nuevo y único número de cuenta de usuario.

2. Implementar controles de passwords adecuados:

Los passwords deben ser efectivos de manera que no puedan ser adivinados por otros, por ej. Su nombre / dirección / fecha de cumpleaños, etc. pero no lo demasiado complejos de manera que el usuario lo tiene que tener escrito para poder recordarlo.

Los passwords NO deben ser compartidos bajo ninguna circunstancia. Cuando las credenciales de registro son compartidas, los individuos específicos no pueden ser identificados a través de la actividad de registro y por consiguiente se pierde la integridad de datos.

3. Establecer diferentes tipos de usuarios con diferentes privilegios de acceso:

Los accesos a los sistemas o equipos deben ser limitados solo a individuos autorizados, por ej. Analistas, administradores.

Cada tipo de usuario debe ser asignado con diferentes privilegios de acceso de acuerdo al rol que efectuará en el sistema. Debe haber protocolos de seguridad de datos en los cuales se describe el rol del usuario y sus responsabilidades en términos de privilegios de acceso, cambio, modificación, creación y eliminación de proyectos y datos. Solo personal senior debe tener cuentas que le permiten administración completa del sistema, incluyendo la edición de los métodos y de los proyectos.

El rol del administrador del sistema debe asegurar que cualquier requerimiento de cambio, eliminación, etc. es cuidadosamente registrado, y atribuido a un individuo para asegurar que la trazabilidad es mantenida.

4. Establecer y mantener una lista de los usuarios actuales e históricos:

Una lista de los usuarios del sistema actuales y de los previos necesita ser establecida y mantenida, si un miembro del personal ha dejado de serlo, entonces la cuenta debe ser inmediatamente puesta como no disponible.

5. Control de cambios del sistema:

Relacionado con la asignación de privilegios de accesos está la capacidad de un usuario de hacer cambios. Los cambios deben ser solo efectuados por medio de los individuos autorizados, ej. Cambios de métodos, parámetros de integración y línea de base. Esto debe ser posible para identificar cuáles individuos hicieron los cambios para determinar si ellos tienen el apropiado entrenamiento, educación y experiencia.

6. Solamente personal entrenado debe operar el sistema:

Hay un requerimiento para que todo el personal tenga la combinación de educación, entrenamiento y experiencia para efectuar su trabajo. Una parte clave de cualquier programa de entrenamiento es que debe hacer foco sobre la generación de datos y que los cambios solo pueden ser hechos de acuerdo a procedimientos predefinidos para prevenir una acusación de falsificación o fraude.

Los usuarios de instrumentos o equipos deben poder demostrar su capacidad de uso frente a las agencias regulatorias cuando es requerido, dentro de su descripción de rol.

7. Registrar toda la información

Los registros de laboratorio deben incluir datos completos derivados de todos los ensayos necesario para asegurar el cumplimiento con las especificaciones y estándares establecidos. Esta es la clave para establecer la integridad de los datos en un sistema de captura de datos electrónicos, a pesar de las situaciones que nos pueden ocurrir, errores, mal funcionamiento de un equipo, etc.

Los datos crudos, “raw data”, (ej. Cromatogramas, pesadas del estándar y de muestras, cálculos, estándares, reactivos, información del instrumento) deben estar disponibles siguiendo la ejecución del trabajo para permitir que una investigación pueda ser llevada a cabo eficientemente y para confirmar la autenticidad y confiabilidad de los datos durante la inspección efectuada por la agencia regulatoria. Todos los datos deben ser registrados de manera que las actividades puedan ser cuidadosamente reconstruidas.

8. Definir y documentar registros electrónicos para el sistema

Para registros electrónicos los usuarios deben determinar cuáles datos serán definidos como “raw data”, como mínimo, todos los datos sobre los cuales se basa la toma de decisiones de calidad deben ser definidos como raw data.

Toda la documentación creada durante el análisis la cual incluye un registro es considerada como evidencia de una actividad, de este modo, los archivos de datos creados durante una corrida analítica son registros.

Muchos documentos (instrucciones y/o registros) pueden existir en formatos híbridos, por ej. Algunos elementos como electrónicos y otros en papel. No importa si un registro es generado en papel, existe con firmas manuscritas y le sigue una impresión de un registro electrónico (sistema híbrido) o si es mantenido completamente electrónico.

Controles apropiados deben están en uso para asegurar la integridad de los registros a lo largo del período de retención. Debe estar claramente definido cual registro está relacionado con cada actividad de ensayo y donde es localizado el registro. Controles de seguridad deben estar en uso para asegurar la integridad de los registros a lo largo del período de retención y validado cuando sea apropiado.

9. Revisión de las entradas al audit trail para cada lote

Parte de los datos completos de un sistema de datos cromatográfico en las corridas analíticas incluyen el audit trail, y hay un requerimiento bajo las cGMP para la firma o iniciales de una segunda persona para mostrar que el trabajo ha sido hecho correctamente y conforme a los estándares.

Los cambios no deben tapar los datos registrados previamente (sobre escritura).

10. Copia de seguridad del Sistema regular

Copias de seguridad (BackUp) regulares de toda la información relevante debe ser llevada a cabo. Típicamente esto se hace diariamente. La integridad y la exactitud de los datos de back up y la capacidad para recuperarlos datos debe ser verificada durante la validación y monitoreada periódicamente. Cuando el back up es efectuado, los registros del back up deben ser chequeados para ver cuando fue efectivo. El back up necesita ser validado, y periódicamente debe efectuarse una recuperación de los datos para ver que el hardware, por ej. CDs, son aún leíbles.