BLOG para cGMPdoc.com

La evaluación de los datos con respecto a la criticidad es esencial y, hasta cierto punto, no es una actividad trivial. Los datos deben evaluarse en particular con respecto a la seguridad del paciente y/o la calidad del producto.

El término “datos críticos” aparece en un solo lugar en las Directrices GMP de la UE:

“4.27 – Debería existir un sistema para indicar observaciones especiales y cualquier cambio en los datos críticos”.

El Anexo 11 de GMP de la UE también menciona datos críticos en un solo lugar.

“6. Chequeos de exactitud: para los datos críticos ingresados ​​manualmente, debe haber una verificación adicional sobre la precisión de los datos”.

Esto proporciona una base legal para revisar la entrada de datos críticos. Por lo tanto, una segunda persona debe verificarlo. Una alternativa sería un sistema computarizado validado.

Ejemplo:

La temperatura se mide en un tanque de agitación. Esta medición es parte del informe de lote y es relevante para la liberación. La temperatura se lee manualmente y se documenta manualmente. En este caso, se requiere una segunda persona para verificar la exactitud de los datos (principio de doble verificación).

O

La temperatura se registra electrónicamente a través de un sistema computarizado y se guarda electrónicamente. En este caso, habría que validar el sistema informático.

Volviendo a la evaluación de la criticidad de los datos: ni la sección 4.27 ni el Anexo 11 (sección 6) proporcionan mucha información sobre qué datos son críticos y cuáles no. No existe una definición legal de datos críticos en el entorno GMP. Si uno observa las diversas directrices y estándares en el área GMP, se puede encontrar una definición de datos críticos en VDI/VDE 3516 Parte 5 sobre “Validación en el entorno GxP – Tipos de datos crudos (raw data)”:

“Datos críticos:

Datos que tienen un impacto potencial en la seguridad del paciente, la calidad del producto y la integridad de los datos”.

Es decisión de la empresa (fabricante de productos medicinales) definir los datos a incluir.

La pregunta crucial es sin duda: ¿Existen datos relevantes para GMP que no sean críticos?

Esto no puede responderse unívocamente a partir del contenido de las bases legales vigentes. Sin embargo, la respuesta es “No”. Sin embargo, existen diferencias en la criticidad de los datos. La Figura 1 muestra un ejemplo correspondiente. Una clasificación de tres niveles tiene sentido:

Todos los datos son relevantes desde el punto de vista GMP, sin embargo varía la criticidad.

La criticidad es alta, media o baja.

PI 041 BUENAS PRÁCTICAS PARA LA GESTIÓN E INTEGRIDAD DE DATOS EN ENTORNOS REGULADOS GMP/GDP proporciona información sobre datos críticos, lo que también demuestra su importancia.

Ejemplo:

“5.4 Criticidad de los datos: por ejemplo: para una tableta oral, los datos del ensayo API generalmente tienen un mayor impacto en la calidad y seguridad del producto que los datos de friabilidad de la tableta”.

El documento destaca la importancia de los datos en términos de su influencia en decisiones como la liberación de lotes.

“5.4 Criticidad de los datos

5.4.1 La decisión en la que influyen los datos puede diferir en importancia y el impacto de los datos en una decisión también puede variar. Los puntos a considerar con respecto a la criticidad de los datos incluyen:

¿En qué decisión influyen los datos?

Por ejemplo: cuando se toma una decisión de liberación de un lote, los datos que determinan el cumplimiento de los atributos críticos de calidad son normalmente de mayor importancia que los registros de limpieza del almacén”.

Tomado de la News Letter de la ECA – 06.02.2019

El 15 de abril de 2020, la FDA emitió una Warning Letter (carta de advertencia) a la empresa india Shriram Institute for Industrial Research, basada en una inspección en octubre de 2019. Además de otros problemas, problemas con las pistas de auditoría en el laboratorio y su respuesta inadecuada llevaron a esta WL. Las WL de la FDA siempre se refieren a los capítulos correspondientes de 21 CFR Parte 211.

Su empresa no ejerció los controles apropiados sobre la computadora o los sistemas relacionados para garantizar que solo el personal autorizado instituya cambios en los registros maestros de producción y control u otros registros (21 CFR 211.68 (a))

Observación

La compañía sirve como un laboratorio de ensayos por contrato, que analiza los ingredientes activos y los productos farmacéuticos. Durante la inspección, el inspector de la FDA notó que el seguimiento de auditoría (Audit Trail) en las unidades de HPLC se activó solo unos días antes de la inspección. Esto fue confirmado por el empleado durante la inspección. El problema central aquí; es una observación repetida en esta empresa. Ya durante una inspección en 2016, ocurrió este punto, y la compañía se comprometió por escrito a instalar los Audit Trail.

La integridad de los datos de laboratorio es crucial para la toma de decisiones sobre la calidad de los medicamentos. Es importante que la FDA mantenga un control estricto sobre los datos electrónicos de GMP para garantizar que todas las adiciones, eliminaciones y cambios a la información en los registros electrónicos estén autorizados y documentados.

Respuesta de la empresa

En la respuesta de la compañía, el único remedio era designar a un técnico de equipo para llevar a cabo inspecciones de rutina para garantizar el rendimiento adecuado del equipo. Esta respuesta no fue suficiente para la FDA. La FDA carecía de una descripción de los controles específicos que se implementarían para garantizar que los registros de auditoría permanecieran activos y que la integridad de los datos no se viera comprometida.

¿Qué espera la FDA al responder esta Warning Letter?

Se requiere una evaluación integral e independiente de las prácticas de laboratorio, procedimientos, métodos, equipos, documentación y competencia del analista. Sobre la base de esta evaluación, se debe establecer un plan detallado para la acción correctiva y la evaluación de la efectividad del sistema de laboratorio.

Fuente: News Letter de la ECA (13/5/2020).

Warning Letter al Instituto Shriram de Investigación Industrial

En más de una ocasión, sobre todo en los talleres de Validación de planillas Excel, suele aparecer la discusión sobre si las mismas son validables, hablamos de su inviolabilidad y generalmente llegamos a la conclusión que las planillas Excel, no son a prueba de balas, pero las necesitamos.

Diseñar e implementar una hoja de cálculo debería ser la última opción. La decisión final de encargar el desarrollo y la implementación de las hojas de cálculo debe basarse en una investigación elaborada con respecto a la disponibilidad de software “existente” y probado, que ya está destinado a ser utilizado dentro de las industrias sanitarias reguladas.
Se recomienda realizar cálculos en entornos seguros y validados con funciones para cumplir con las regulaciones aplicables, por ejemplo: sistemas de datos cromatográficos (CDS), sistemas de gestión de información de laboratorio (LIMS).
Existen en el mercado softwares que le dan a las planillas Excel la posibilidad de una mayor seguridad y funcionalidad de compliance, por ejemplo, Audit Trail, firmas electrónicas, gestión de usuarios, control de versiones.

Ahora nuestra realidad, es que tenemos muchas planillas Excel, las cuales utilizamos para calcular Atributos críticos de calidad, planillas con impacto sobre la calidad de nuestros productos y mientras esto sea así, tenemos que hacer todo lo posible para tener planillas Excel correctas y seguras, por eso tenemos que validarlas y luego implementar una excelente administración y seguimiento de las mismas.

Pero ojo, no debemos validar el software Excel (la aplicación), el cual ya esta probado por el uso y es confiable, pero si todo aquello que hemos configurado, todo lo que nosotros decidimos que la planilla hará.

En más de una oportunidad hemos hablado de la importancia del cumplimiento de las buenas prácticas de documentación (GDocP) para garantizar la precisión, integridad, consistencia y confiabilidad de los registros y datos a lo largo del ciclo de vida de los mismos.  Esto requiere que la documentación sea atribuible, legible, registrada al mismo tiempo, original y precisa (lo que llamamos ALCOA).

Hoy quiere focalizarme en la primera de las características: Atribuible, y pensar no solo en los sistemas electrónicos sino también en los registros en papel y además veamos algunos ejemplos. Veamos algunas conceptos de la WHO.

Atribuible: ¿Quién adquirió los datos o realizó una acción y cuándo?

La atribución de acciones en registros en papel debe ocurrir, según corresponda, mediante el uso de:

• Iniciales;
• Firma manuscrita completa;
• Fecha y, cuando sea necesario, hora.

La atribución de acciones en registros electrónicos debe ocurrir, según corresponda, mediante el uso de:

• Inicios de sesión de usuarios únicos que vinculen al usuario a acciones que crean, modifican o eliminan datos;
• Firmas electrónicas únicas (pueden ser biométricas o no biométricas);
• Un Audit Trail (Pista de auditoría) que debe capturar la identificación del usuario (ID), actividad y la fecha y hora;

Consideraciones especiales de administración de riesgos para los controles para garantizar que las acciones y los registros se atribuyan a una persona única:

• Para firmas legalmente vinculantes, debe haber un vínculo seguro y verificable entre la firma de la persona única, identificable (real) y el evento de firma.
• Las firmas deben ejecutarse en el momento de la revisión o realización del evento o acción que se está registrando.
• El uso de imágenes digitales almacenadas de la firma manuscrita de una persona para firmar un documento no es aceptable. Esta práctica compromete la confianza en la autenticidad de estas firmas cuando estas imágenes almacenadas no se mantienen en un lugar seguro, cuyo acceso está limitado solo a la persona asignada. Correos electrónicos donde otros puedan copiarlos y reutilizarlos fácilmente.
• Se desaconseja el uso de sistemas híbridos, pero donde los sistemas heredados están a la espera de ser reemplazados, se deben implementar controles de mitigación. Se debe evitar el uso de contraseñas de inicio de sesión compartida y genérica para garantizar que las acciones documentadas en registros electrónicos puedan atribuirse a un individuo único. Cuando dichos controles técnicos no están disponibles o no son factibles, por ejemplo, en sistemas electrónicos heredados o donde el inicio de sesión terminaría una aplicación o detendría la ejecución del proceso, deberían usarse combinaciones de registros en papel y electrónicos para cumplir con los requisitos para atribuir acciones a los individuos involucrados.
• Es probable que el enfoque híbrido sea más riesgoso que un enfoque completamente electrónico; por lo tanto, se recomienda utilizar firmas electrónicas, siempre que estén disponibles. Por ejemplo, la ejecución y atribución de un registro electrónico mediante el adjunto de una firma manuscrita se puede realizar a través de un medio simple que crearía un formulario controlado de una sola página asociado con los procedimientos escritos para el uso del sistema y la revisión de datos. El documento debe enumerar el conjunto de datos electrónicos revisados y cualquier metadata sujeta a revisión, y proporcionará campos para el autor, el revisor y / o el aprobador del conjunto de datos para insertar una firma manuscrita. Este registro en papel con las firmas escritas a mano se debe vincular de forma segura y rastreable al conjunto de datos electrónico.
• La sustitución de sistemas híbridos debe ser una prioridad.
• El uso de un escriba para registrar una actividad en nombre de otro operador debe considerarse solo de manera excepcional. El registro de supervisión debe ser simultáneo con la tarea que se está realizando y debe identificar tanto a la persona que realiza la tarea observada como a la persona que completa el registro. La persona que realiza la tarea observada debe refrendar el registro siempre que sea posible, aunque se acepta que este paso de refrendación será retrospectivo.

El PIC/S está trabajando actualmente en la elaboración de la guía PI 041-1 “Buenas prácticas para la gestión de datos y la integridad de los datos en entornos regulados GMP / GDP”. El segundo borrador del documento se publicó originalmente el 10 de agosto de 2016 para su discusión. Los extensos comentarios internos han sido consolidados por el PIC/S y han resultado en un tercer borrador revisado. Este tercer borrador fue publicado el 30 de noviembre de 2018.

Para su información aquí están los contenidos y los principales cambios del tercer borrador de PIC / S PI 041-1:

Se ha mantenido la estructura básica del documento (compuesta por 14 capítulos).

             1. Historia del documento

             2. Introducción

             3. Propósito

             4. alcance

             5. Sistema de gobierno de datos.

             6. Influencias organizativas en la gestión exitosa de la integridad de los datos.

             7. Principios generales de integridad de datos y habilitadores.

             8. Consideraciones específicas de integridad de datos para sistemas basados ​​en papel.

             9. Consideraciones específicas de integridad de datos para sistemas computarizados.

            10. Consideraciones de integridad de datos para actividades subcontratadas.

            11. Acciones regulatorias en respuesta a los hallazgos de integridad de datos

            12. Remediación de problemas de integridad de datos

            13. definiciones

            14. Historial de revisiones

El subcapítulo 8.9 “Mantenimiento de registros” ha sido eliminado.

Se ha agregado un nuevo subcapítulo 9.8 “Gestión de sistemas híbridos”.

Se han realizado extensiones significativas y exhaustivas a los subcapítulos 9.3 “Seguridad del sistema para sistemas informáticos” y 9.4 “Pistas de auditoría para sistemas informatizados”.

A los interesados les sugiero darle un vistazo a este borrador, ya que tiene muchos conceptos que seguramente le serán útiles.

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 características detalladas en la tabla adjunta y utilizando el ciclo de vida de los datos (recolección, procesamiento, revisión y reporte de los datos).

Característica	Definició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é. Esto debería ser claro quien crea un registro y cuando. De todos modos, debería ser claro quien hace una enmienda en un registro, cuando y porqué.
Legible	Los datos deben ser registrados de forma permanente en una forma 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. Esto significa que la evidencia o los resultados de los tests son registrados como son observados, de esta forma permite la reconstrucción de los eventos alrededor de los datos.
Original	La información registrada deben ser datos originales (datos crudos) o una copia certificada del proceso. Los datos NO deben ser transcritos de u a fuente a otra sin justificación y control certificado del proceso in place.
Exacto	Sin errores o ediciones efectuadas sin enmiendas en los documentos. La información registrada es correcta.

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 la gente con el correcto conocimiento sea involucrada.

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 ejemplo):

• ¿Qué podría salir mal?
  • Datos han sido perdidos
  • Los sistemas fallan y no hay un plan de business continuity (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á encendido
  • El entrenamiento y la concientización del instrumento es inadecuado
  • Los passwords están siendo compartidos
  • Los resultados no son atribuibles, etc.
• ¿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.

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?

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.