BLOG para cGMPdoc.com

Con frecuencia veo que los laboratorios, suelen tener procesos de Back Up para sus servidores, aunque a veces los mismos no están correctamente procedimentados, o no cuentan con ensayos de recuperación de la información. También he visto que los procedimientos de respaldo y recuperación se incluyen en el Disaster Recovery Plan (DRP), sin embargo, se recomienda tener un SOP de respaldo dedicado.

Ahora que pasa con los sistemas que están fuera de la red? los standalone. En general suelo ver que los laboratorios disponen de procedimientos para el uso de los mismos y con su personal entrenado, pero la administración de accesos y el back up y recuperación de los datos en muchos casos es una tarea pendiente.

Los registros de respaldo deben almacenarse en una ubicación segura especificada en los SOP. El almacenamiento generalmente se realiza fuera del sitio en un edificio separado de los registros originales.

Algunos elementos a tener en cuenta al escribir el SOP de Back up y recuperación son los siguientes:

• ¿Se ha descripto todo el proceso de copia de seguridad y restauración? Esto debe incluir la verificación exitosa de la copia de seguridad, los medios de copia de seguridad y la resolución de problemas
• ¿Es seguro el transporte y el almacenamiento del respaldo?
• ¿Cuál es el alcance de la copia de seguridad de datos (por ejemplo: todos los datos, datos de producción, fuente, datos de prueba, softwares)?
• ¿Cuál es la frecuencia de respaldo y la programación? una vez a la semana, ¿copia de seguridad completa y cambios incrementales, diferenciales o copia de seguridad diarios de los datos instantáneamente a otro servidor u otra ubicación? Esto dependerá de la criticidad de los datos.
• ¿Cuál es el cronograma de retención de respaldo y cómo se mantiene la calidad de los datos?
• ¿Se han archivado los datos de acuerdo con la estrategia de archivo? ¿Sigue siendo necesario mantener las cintas de respaldo?
• ¿Cómo se gestiona la restauración de datos? Esto incluye: frecuencia de las pruebas de restauración, qué se puede restaurar, ¿cuánto tiempo se conservarán los datos para solicitar la restauración?
• ¿Alguna vez ha probado la tarea de restauración (a partir de datos “antiguos”)?

Las empresas que dependen de sistemas electrónicos y en papel deberían determinar la medida en que los procedimientos de respaldo y recuperación son necesarios en función de la necesidad de cumplir con los requerimientos que le aplican, disponer de una evaluación de riesgos justificada y documentada, y una determinación del posible efecto sobre la calidad y el registro de los datos integridad.

Por otra parte la copia de seguridad también debe incluir documentos críticos de la compañía que no están cubiertos por las autoridades reguladoras.

Hace tiempo incluimos un Check de verificación del estatus de CSV (Validación de sistemas computarizados) y parte 11 (Firmas y registros electrónicos), acá les dejo el link.

Este check que estamos incluyendo en este artículo intenta ser una guía para auditar el cumplimiento de CSV en el laboratorio (o en su proveedor). Esperamos que le sirva de ayuda.

1. Desarrollo del Sistema
   • Proveedores

• Verificar si hay un método para aceptar el producto, incluyendo los requerimientos técnicos y de calidad del producto.
• Verificar como los requerimientos técnicos y de calidad son considerados por el proveedor y/o sub contratado. ¿Hay un proceso definido? ¿El mismo es cumplido?
• En el caso de sub contratar actividades, verificar la experiencia y calificación del mismo (por ej. verificar entrenamientos o certificaciones).
• Si la evaluación del proveedor involucró una auditoria, verificar el estatus de los hallazgos.
• ¿Dispone de un procedimiento para la evaluación de proveedores?, ¿dicho procedimiento es seguido?
• Si el Sistema es provisto por un proveedor, verificar si el mismo ha sido evaluado.
• Verificar si el Sistema fue elaborado “In House” o desarrollado por un proveedor.
  • Requerimientos
• Verificar que todos los requerimientos GMP del proceso, incluyendo la parte 11 (firmas y registros electrónicos) han sido incluidos.
• Verificar que los requerimientos son revisados y aprobados por los departamentos apropiados, incluyendo como mínimo responsable del proceso de negocios y al responsable de QA.
  • Diseño y codificación
• Verificar que existe un documento de diseño cubriendo todos los requerimientos del usuario y la trazabilidad entre los requerimientos y los elementos del diseño.
• Verificar que la especificación de diseño es revisada y aprobada por los departamentos apropiados.
• Confirmar que la especificación de diseño fue aprobada antes de que el codificado comience.
• Confirmar que existe un estándar de codificado (por ej. Java, etc.). En caso de no haberlo, debe haber una justificación adecuada.
• Verificar que la revision de código fue efectuada.
• Determinar si todo el código es revisado o si es revisado una muestra, en éste ultimo caso, determinar como fue seleccionada la muestra.
• Confirmar que los revisores de código son independientes y están adecuadamente calificados.
• Confirmar que los defectos encontrados durante la revisión son corregidos y las acciones correctivas tomadas para evitar su re ocurrencia.
  • Testeo
• Revisar la documentación de testeo asociada con el Sistema a auditar.
• Verificar que existe una estrategia de testeo explicando los testeos efectuados en cada etapa de desarrollo (ej. Testeos de módulo, testeo de integración, testeos de interface) y testeos de aceptación.
• Confirmar a través del proceso de testeo que los requerimientos funcionales críticos han sido testeados.
• Verificar que los testeos cubren condiciones límites, fallas y estrés, así como pruebas diseñadas para confirmar que el sistema funciona como se espera. Además, que incluye el control de seguridad de accesos lógicos.
• Verificar que los testeos sean efectuados por personal independiente y calificado (el desarrollador y el autor de los ensayos).
• Confirmar que los scripts de testeo están escritos, y que los mismos contienen claramente los criterios de aceptación.
• Verificar que los resultados de los ensayos han sido documentados y se dispone de la evidencia adecuada. Donde hay desvíos los mismos son documentados.
• Verificar que el test que falló ha sido evaluado respecto de la criticidad del requerimiento funcional.
• Verificar que cuando un test ha fallado la funcionalidad requerida no es crítica para el proceso ni para el cumplimiento GMP. Confirmar que existe una solución de procedimiento adecuada.
• Si es utilizada una herramienta automatizada para los testeos, verificar que la misma ha sido calificada para asegurar que funciona correctamente, que hay procedimientos para su uso, que las firmas de las aprobación de los scripts de testeos son registradas y que los cambios a la herramienta o scripts electrónicos son controlados y aprobados.
  • Entregables de Validación
• Verificar que hay un conjunto de documentos de validación consistente con una clara relación de los mismos a los requerimientos.
• Verificar que los entregables de validación son declarados en el plan de validación, han sido completados y están resumidos en el reporte de validación.
• Verificar que las excepciones (si aplica) del reporte de validación han sido registradas como acciones para su seguimiento.
  • Liberación
• Revisar como es liberado el Sistema para el uso.
• Verificar los controles y chequeos utilizados para asegurar que todas las actividades fueron completadas.
• Verificar que los roles y responsabilidades para la liberación están claras y se han cumplido.
• Verificar que todos los entregables requeridos fueron parte del paquete de liberación, por ej. un código de construcción del Sistema, certificado de liberación, manuales de uso, material de entrenamiento.

2. Gestión del sistema
   • General

• Establecer como es provisto el soporte al Sistema, confirmar que los roles y responsabilidades del hepdesk, de los administradores y soporte técnico están claramente definidas. Asegurar que el entrenamiento adecuado para cada rol fue suministrado.
• Verificar que el Sistema tiene un propietario que lo maneja con suficiente autoridad y con un presupuesto para su mantenimiento.
  • Manejo de problemas
• Confirmar que hay un procedimiento vigente para el reporte de problemas, con registro, investigación y resolución de los mismos.
• Verificar que las acciones correctivas y preventivas son implementadas.
• Verificar que hay una relación entre el reporte de incidentes y la gestión de cambios para el Sistema.
  • Gestión de cambio
• Asegurar que los procedimientos para iniciar, autorizar y documentar los cambios del Sistema están vigentes.
• Confirmar que los cambios son evaluados para asegurar que el impacto sobre las funcionalidades relacionadas es entendido.
• Asegurar que la gestión de los cambios incluye la actualización de la documentación del Sistema, instrucciones de uso, entrenamiento, datos maestros como la funcionalidad técnica.
• Asegurar que los testeos hechos como soporte de los cambios del Sistema confirman que las funciones relacionadas no son adversamente afectadas y además aseguran que los cambios requeridos son alcanzados.
  • Accesos y seguridad
• Revisar que las medidas de seguridad físicas están definidas para el Sistema y están en uso efectivo. Verificar como son controlados los accesos físicos al hardware.
• Revisar que las medidas de seguridad del software están definidas para el Sistema. Verificar como son controlados los accesos a las funcionalidades críticas son restringidas a los usuarios apropiados. Verificar que donde la capacidad de enmendar datos maestros ha sido restringida.
• Verificar la existencia de un procedimiento para otorgar y remover los accesos al Sistema de los usuarios. Verificar que los accesos son revisados periódicamente para asegurar que solo tengan acceso al Sistema los usuarios requeridos.
• Asegurar que los ambientes de desarrollo, de testeo y productivo son rutinariamente revisados en búsqueda de virus.
• Determinar si los elementos del Sistema tales como Sistema operativo, base de datos y aplicaciones del software son mantenidos con los últimos parches de seguridad disponibles.
  • Datos maestros
• Asegurar que existe un proceso para el mantenimiento de los datos maestros requeridos por el Sistema.
• Confirmar que los roles y responsabilidades están claras respecto a la gestión y aprobación de datos maestros.
• Verificar si los datos maestros son chequeados periódicamente para verificar su exactitud.
  • Planeamiento de Business Continuity /Disaster Recovery (incluyendo back up y recuperación)
• Verificar que el Sistema tiene un plan de continuidad del negocio (BC), y que el mismo tiene en cuenta la criticidad del sistema.
• Verificar que el Sistema tiene un plan de disaster recovery (DR), y que el mismo tiene en cuenta la criticidad del sistema.
• Verificar que existe un régimen de back up y recuperación para el Sistema y que el mismo está documentado, mantenido y testeado. Verificar si el mismo tiene en cuenta la criticidad del Sistema.

3. Revisión periódica

• Verificar que el Sistema es sujeto a revisiones periódicas para determinar que actividades tienen que ser efectuadas para mantener el estado validado.
• Confirmar que los resultados de la revisión son registrados y cualquier acción es seguida hasta que se complete.

Cualquier evaluación de integridad de datos dentro de una operación de laboratorio manual o electrónica debe basarse sobre un análisis de riesgo vs las siguientes características detalladas a continuación:

Atribuible

¿Quién adquirió los datos o realizó una acción y cuándo? Si un registro es modificado por quién y porqué.

Legible

Los datos deben ser registrados de forma permanente (duradera) y fácil de leer.

Contemporáneo

Los datos deben ser registrados al mismo tiempo que el trabajo es efectuado con marca de fecha y hora.

Original

La información registrada deben ser datos originales (datos crudos) o una copia certificada del proceso. Los datos NO deben ser transcritos de una fuente a otra sin justificación y sin control certificado del proceso.

Exacto       

Sin errores o ediciones efectuadas, sin enmiendas en los documentos. La información registrada es correcta.

Basado sobre estas características (atributos de integridad de datos) los laboratorios deben asegurar que los procesos analíticos están definidos, mapeados y con los riesgos evaluados para cumplir con la integridad de datos a lo largo del ciclo de vida de los datos. Todos los datos del sistema procesado deben ser incluidos.

El uso de análisis de riesgo y la generación de proceso de mapeo permite una mayor visibilidad de donde la integridad de datos es crítico y además da soporte a las autoinspecciones de tales sistemas.

Dentro de estos requerimientos básicos, las siguientes 10 áreas claves son esenciales para asegurar la integridad de los datos dentro de los límites de un sistema de datos electrónicos, esto está detallado en el siguiente artículo del blog: http://wp.me/p1Hn5Y-tA

Análisis de riesgo:

El análisis de riesgo es el proceso de identificar los peligros y los modos de falla y evaluar las consecuencias potenciales de esos peligros. Esto es críticamente dependiente de que sea involucrado personal con conocimiento.

Los análisis de riesgos de calidad comienzan con una descripción bien definida del problema, una pregunta de riesgo o un análisis de un área de riesgo particular. En el caso de integridad de datos el proceso de laboratorio individual debe ser mapeado en detalle, comenzando por la preparación de la muestra, a través de los resultados de verificación / aprobación y finalizando con el archivo y recuperación de los datos.

Una vez que el proceso fue analizado para las áreas de riesgo crítico de integridad de datos, por ej. Cuál es el riesgo y que impacto podría tener sobre la calidad del producto y la seguridad del paciente, entonces pueden ser asignadas etapas de mitigación.

El proceso de análisis debe seguir las siguientes preguntas, por ej:

• ¿Qué podría salir mal?
  • Datos han sido perdidos
  • Los sistemas fallan y no hay un plan de continuidad del negocio in place
  • Los datos no están siendo registrados
  • Los datos no están siendo verificados
  • El audit trail no está siendo revisado
  • El audit trail no está funcionando
  • El entrenamiento y la concientización del equipo/instrumento es inadecuado
  • Los passwords están siendo compartidos
  • Los resultados no son atribuibles
• ¿Cuál es la probabilidad de que esto salga mal?
• ¿Cuáles son las consecuencias (severidad) para la calidad del producto o la seguridad del paciente?
• La falla ¿Será detectada? ¿Cómo?

Hay muchas herramientas y técnicas que pueden ser usadas para ayudar a identificar peligros y /o modos de fallas y evaluar los riesgos. No hay una sola herramienta o técnica que cumpla con todos los requerimientos, en otro momento ampliaremos sobre las mismas.

Espero que les resulte útil.

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.

Les dejo 5 preguntas para autoevaluarse respecto de integridad de datos:

1. Todo su personal entiende que una pobre integridad de los datos, genera pérdida de confianza regulatoria?
2. Tiene back up y archivo de sus datos?
3. Rutinariamente revisa y comprueba la integridad de los datos?
4. Rutinariamente desafía todas las transacciones (audit trail)?
5. Tiene validados sus sistemas de manejo de datos?

Si alguna de las respuestas no fue del todo satisfactoria, Ud. ha detectado  una oportunidad de mejora sobre la integridad de datos, asegúrese tener un plan de acciones de remediación, también desde cGMPdoc podemos proponerle una solución o le dejamos a mano la posibilidad de un taller “In Company” teórico-práctico de 4 hs de duración.