7 Hacks de Integridad de Datos para el Cumplimiento de GxP
¿Hubo un evento específico que impulsó la redacción de una nueva guía para asegurar la integridad de datos?
La integridad de los datos es un área emergente de preocupación para la FDA. En 2014 vimos 10 cartas de advertencia de la FDA con violaciones de integridad de datos; en 2017 vimos 56 cartas de este tipo.
Hubo una serie de eventos en distintos sitios en Asia que involucraron inadecuada calibración y manejo de datos «crudos» en equipos de HPLC. Estas fallas obvias en la integridad de datos galvanizaron el aumento en el escrutinio regulatorio. Estos eventos fueron tan similares en muchos sentidos que han dado lugar a una historia apócrifa en la que hubo un solo evento específico que lo inició todo. Pero todas las historias tienen en común ciertos elementos, como los sistemas computarizados de alta tecnología, las cadenas de suministro globalizadas y una cultura de calidad inmadura.
En uno de estos eventos reales, el laboratorio en cuestión tenía una «práctica incorrecta». En lugar de utilizar un estándar para calibrar el dispositivo, simplemente utilizaron la muestra del lote que estaban analizando. Si eso suena confuso, una simple analogía es útil; lo que hicieron fue como decidir que usted mide dos metros de altura tomando una cuerda que es tan larga como usted y rotular esa cuerda como de 2m de largo. Luego, mide la altura con la cuerda y llega a la conclusión de que en realidad tiene una altura de 2 metros. Razonamiento circular.
Nuevamente, en muchos de estos casos, las instalaciones involucradas fueron instalaciones relativamente nuevas con una cultura centrada en la calidad inmadura, con personal recién capacitado, presumiblemente bien intencionados que utilizan equipos computarizados de alta tecnología. Y, lo que es más importante, utilizaron esa tecnología de manera incorrecta, aunque de maneras que no eran obvias.
El Congreso de los Estados Unidos aprobó la Ley de Seguridad e Innovación de la FDA en 2012, que exige que la agencia inspeccione las instalaciones en países extranjeros que fabrican medicamentos o componentes de medicamentos para su distribución en los Estados Unidos. En 2014, la FDA envió cartas de advertencia a compañías con plantas en India, Australia, Austria , Canadá, China, Alemania, Japón, Irlanda y España. Las observaciones iban desde fallas en la integridad de los datos hasta ensayos de calidad inadecuadas y observaciones sobre contaminación.
Con respecto a los controles de acceso, ¿el hecho de que haya más administradores de sistemas será un problema que pueda generar una observación durante una inspección? ¿Cuál es un número aceptable? 3 a 4? 8 a 10?
En general, tener niveles no justificados de accesos administrativos es un problema. Pero no es realmente posible definir un número exacto sin saber más sobre qué tipo de sistema se está gestionando. ¿Qué hace el sistema? ¿Cuántos usuarios del sistema hay? El sistema se usa 24/7, o solo durante las horas de trabajo?
Como mínimo, tendrá 2 administradores para cualquier sistema. Un administrador es muy poco porque esa persona puede renunciar un día. 10 administradores…eso suena como mucho si solo tiene 20 usuarios en un sistema. Pero si tiene 2000 usuarios del sistema, 10 administradores pueden no ser suficientes. La clave es simplemente asegurarse de que las únicas personas con acceso administrativo sean aquellas que realmente lo necesitan para realizar su trabajo.
¿Qué constituye un «control adecuado» para evitar cambios o el acceso no autorizado a los datos?
El enfoque estándar es utilizar un sistema de autenticación de dos factores para limitar el acceso al sistema. En la mayoría de los softwares, esto se hace con nombres de usuario y contraseñas únicos. Esa es la forma en la que controlamos el acceso al sistema. Después decidimos qué usuarios pueden hacer cambios. Normalmente, esto se hace asignando perfil de usuario que tiene predefinidos determinados derechos. De esta manera de definen qué acciones puede realizar un usuario en particular en el sistema. Clásicamente, esto está definido por diferentes tipos de usuarios, tales como:
- Sólo vista
- Supervisor
- Gerente
- Administrador
La principal preocupación es asegurarse de que los permisos de cada clase de usuario coincidan con sus roles de trabajo. Dar a las personas acceso innecesario crea oportunidades de error.
¿Cómo proporcionamos controles para evitar la omisión / eliminación de datos?
Esto está muy cerca de la pregunta sobre cambios y acceso no autorizado. En el caso de omisiones / eliminaciones, el control estándar es el «audit trail» o registro de transacciones como preferimos definirlo en AKRIBIS. Un registro de transacciones del sistema adecuadamente diseñado capturará eventos que involucran la creación, modificación y eliminación de registros. Pero un registro de transacciones solamente es útil para nosotros si lo revisamos para detectar los momentos en que los datos se han modificado o eliminado. La omisión es más difícil de detectar, pero debe ser detectable ya sea a través de la revisión del registro, o simplemente a través de una revisión adecuada de los datos durante los procesos de reporte y asegurando que se adjunte el registro de datos original.
En nuestras instalaciones utilizamos un mismo un mismo usuario para nuestro sistema de monitoreo de variables críticas como temperatura, humedad y presiones diferenciales. ¿Eso puede ser una observación en inspección de la Agencia Reguladora o en una auditoría?
Definitivamente levantará una gran bandera roja. Cualquier inicio de sesión compartido se destacará porque crea una situación en la que los cambios o las acciones en el sistema no serán atribuibles a una persona específica. Recordemos los pilares de un sistema de datos íntegro:
ATRIBUIBLE: todos los datos generados deben identificarse con la persona que los generó y cuando lo hizo.
LEGIBLE: todos los registros deben ser legibles y permanentes (aun los eliminados).
CONTEMPORANEO: los resultados, mediciones o datos deben ser registrados en el momento en que son obtenidos. No es admisible el registro posterior.
ORIGINAL: los datos «crudos» en el medio en el que son registrados por primera vez. Ya sea el ticket de un impresora, el registro en una base de datos o el cuaderno del analista.
ACCURATE o EXACTO: para que los registros sean exactos deben ser libres de errores, completos, verdaderos y reflejar lo observado. Su edición no puede ser realizada sin una adecuada documentación de los cambios.
En el sistema ViewLinc de Vaisala que AKRIBIS implanta y califica para monitoreo de variables críticas con impacto GMP, podemos crear un usuario con acceso de solo lectura, que no puede realizar ningún cambio. Puede ser fácil pensar que tener una cuenta de solo vista compartida no crearía un problema de integridad de datos porque no se pueden hacer cambios, pero …
Como mínimo, va a captar la atención de un auditor y tendrá que explicarse. Usted realmente desea evitar tener que explicarle algo a un auditor porque nunca está garantizado que el auditor estará de acuerdo, y simplemente será el desencadenante de más preguntas que nunca se sabe dónde terminan. Los responsables de recibir auditorias saben que lo mejor es evitar dar motivos para que haya preguntas. Por lo tanto, usar usuarios compartidos siempre es una práctica peligrosa. Idealmente, cada usuario debiera disponer de una cuenta única no compartida. El control de acceso es el siguiente paso natural; el hecho de que un usuario no pueda cambiar los datos no significa que esté autorizado a verlos. La confidencialidad de la información es un factor extremadamente importante.
¿Cómo debemos manejar un caso en el que sospechamos que algunos datos pueden haber sido borrados accidentalmente?
Hay dos preguntas aquí:
Una es que Ud. crea que los datos han sido borrados. La otra es que Ud. crea que pueda haber ocurrido accidentalmente. Nuestro primer paso sería sugerirle que reviste el «audit trail» o «registro de transacciones». La parte 11 del capitulo 21 del Code of Federal Regulation de los EEUU, CFR 21 part 11, son una excelente guia para asegurar la integridad de sus datos. El mismo requiere que los registros de transacciones o audit trail capturen la creación, modificación y eliminación de registros. Entonces Ud. debería poder determinar si los datos fueron borrados. Si los datos se eliminaron (y desea que vuelvan a estar en el sistema), comenzará un proceso de desviación en el que recuperará los datos eliminados. Exactamente cómo puede recuperar los datos dependerá del sistema.
Ahora tratemos el hecho de que los datos se eliminaron accidentalmente. En este caso, podría haber un problema en el diseño de su flujo de trabajo, o quizás en el nivel de acceso del empleado. Entonces debería haber un CAPA, probablemente como parte del desvío iniciado, para evaluar esto. Como mínimo, deberá volver a capacitar al empleado, revisar los cambios de acceso y, posiblemente, reconfigurar sus flujos de trabajo.
Si copiamos datos «crudos» en un CD y borramos esos datos del disco duro, ¿cómo podemos asegurarnos de que todos los datos «crudos» se copiaron en el CD antes de eliminarlos permanentemente de la unidad?
Lo que está describiendo aquí es un proceso de migración de datos.
Debe crear algunos pasos de verificación para garantizar que todos los datos se hayan migrado y que los datos no se hayan modificado durante el proceso de migración. Podría hacer cosas como verificar que la cantidad de archivos fuera idéntica antes y después de la migración. Puede verificar que el tamaño de las carpetas de datos no haya cambiado antes y después. Si está realizando una migración de datos como esta regularmente, es posible que desee considerar validar el proceso.
