Data Integrity Risk Assessment (DIRA) (III)

Como parte del monográfico de análisis de la guía de integridad de los datos de la MHRA (parte I, parte II), antes de completar el análisis de la guía con las últimas definiciones, hago un inciso para profundizar en un tema que he recibido alguna consulta al respecto. Es el análisis de riesgos de la integridad de los datos, o DIRA, por sus siglas en inglés.

Análisis de las guías. ¿Hay que realizar análisis de riesgos para Data Integrity?

Esto es lo que dicen las principales guías de data integrity sobre la necesidad de realizar análisis de riesgos:

MHRA – Sí – El esfuerzo y los recursos aplicados para asegurar la validez e integridad de los datos deben ser proporcionales al riesgo y al impacto de un error en la integridad de los datos para el paciente o el proceso.
OMS/WHO – Sí – El esfuerzo y los recursos asignados a la gestión de datos y registros deben ser proporcionales al riesgo para la calidad del producto. El enfoque basado en el riesgo para la gestión de registros y datos debería garantizar que se asignan los recursos adecuados y que las estrategias de control para garantizar la integridad de los datos de GxP son proporcionales a su impacto potencial en la calidad del producto y en el paciente, en la seguridad y toma de decisiones relacionadas.
EMA – Sí -El esfuerzo y los recursos asignados a la gestión de datos deben ser proporcionales al riesgo para la calidad del producto, y también deben equilibrarse con otras demandas de recursos de calidad.
FDA – Sí- La FDA espera que los datos sean fiables y exactos. La regulación permite estrategias flexibles y basadas en el riesgo para prevenir y detectar cuestiones de integridad de datos.
PIC/s – Sí – El esfuerzo y los recursos asignados a la gestión de datos deben ser proporcionales al riesgo para la calidad del producto, y también deben equilibrarse con otras demandas de recursos de calidad.
FDA China – Sí – Se tomarán las medidas pertinentes en función de los riesgos en la generación de datos, registro, almacenamiento y uso del proceso de gestión de datos para garantizar la integridad de los mismos.

Como vemos, es un requerimiento en todas las normativas por lo que si no hemos hecho un análisis de riesgos de la integridad de datos, recomiendo incluirlo ya como requerimiento interno para este año y trazar un plan viable de cumplimiento. Pero para hacerlo con criterio y en consonancia a lo que indica la normativa, ahí van algunas lineas maestras.

Definiciones:

En primer lugar, vamos a ver qué dice del análisis de riesgos una de las principales guías de referencia sobre Data Integrity, la guía PIC/s (enlace):

Las evaluaciones de riesgos deben centrarse en un proceso operativo (por ejemplo, producción, control de calidad), evaluar los flujos de datos y los métodos de generación de datos, y no sólo considerar la funcionalidad o complejidad del sistema de IT. Los factores a considerar incluyen:

Complejidad del proceso;
Métodos de generación, almacenamiento y retirada de datos y su capacidad para garantizar la exactitud, legibilidad e indelibilidad de los datos;
Consistencia del proceso y grado de automatización / interacción humana;

En el caso de los sistemas informatizados, deben tenerse en cuenta las interfaces manuales con los sistemas informáticos en el proceso de evaluación de riesgos. La validación de un sistema informatizado por sí sola no puede dar lugar a un bajo riesgo para la integridad de los datos, en particular cuando el usuario puede influir en la transmisión de los datos del sistema validado.

Se entiende por tanto que en primer lugar deberemos, por procesos y empezando por los más críticos, analizar cada uno de los flujos de datos que se producen. De esta manera, se podría definir la criticidad de los datos, enfocado en la seguridad del paciente, como:

De riesgo alto: Datos directamente asociados con el producto / proceso, desde la recepción a la liberación, con alto impacto en la calidad, seguridad o trazabilidad. Por ejemplo, sistemas de control de lotes, sistemas de análisis en laboratorio, sistemas de monitorización críticos para la conservación del producto, etc.
De riesgo medio: Datos de soporte en la producción o servicio, que ayudan y tienen impacto durante el proceso, pero no son la fuente primaria de toma de decisión. Por ejemplo, sistemas de gestión de desviaciones, sistemas de control documental, etc.
De riesgo bajo: Datos de soporte a procesos GMP pero que no tienen impacto en la calidad, seguridad o trazabilidad.

Estrategia:

Por tanto, en primer lugar debemos definir los procesos críticos dentro de nuestro sistema, y, empezando por los de mayor criticidad, dentro de cada elemento definir los flujos de datos y la criticidad de cada componente.

Por ejemplo, será mejor comenzar por el sistema de liberación de lotes o producto antes que por un sistema de control de uso de equipos de protección individual. Ambos tienen impacto en GxP, pero obviamente el impacto del primero es mayor por lo que será interesante comenzar por éste.

Dentro de cada proceso (por ejemplo, gestión de los datos para la liberación de producto por Dirección Técnica), se debería:

Detallar los requerimientos para los controles de seguridad y documentación de los datos.
Documentar los controles técnicos o de procedimiento establecidos para cada requerimiento.
Documentar si se cumple el requerimiento o si hay una laguna.
En caso de tener que implementar algún cambio o mejora, realizar la CAPA o control de cambios pertinente, dependiendo del enfoque.
Garantizar mediante los elementos disponibles en el sistema de calidad el correcto seguimiento hasta la implementación y evaluación de eficiencia del elemento en cuestión.
Reevaluar el riesgo una vez implementada la mejora.

Hay que tener en cuenta que dependiendo de la acción a realizar, puede ser que se requiera un tiempo elevado para su implementación. No es lo mismo modificar los permisos de usuario que implementar una auditoría de datos o que validar completamente un complejo sistema informático.

Ejemplo:

Hay múltiples herramientas para analizar los riesgos de un proceso. En alguna otra ocasión he hablado de los diagramas de espina de pez o de la herramienta del análisis modal de fallos y efectos (AMFE). Como ejemplo, podemos tomar el flujo de datos asociado a la validación de los resultados de un analizador que permita liberar el producto. Se podría describir como un analizador automático que envía directamente los resultados a un programa informático que permite al Director Técnico liberar el producto si no hay resultados de análisis positivos.

En este caso, es fácil intuir que la criticidad es alta, por tanto es un sistema de riesgo alto dentro de un proceso crítico. Además, incluye interfase con otro sistema, que también se debería analizar.

Pero, ¿qué deberíamos comprobar en el análisis de riesgos de este componente informático? Voy a poner alguno de los elementos (no todos) que comprobaría en el AMFE.

Flujo de datos. Deberíamos comprobar que el flujo de datos es conocido y está definido en la validación (que es un pre-requisito) y en un procedimiento operativo SOP o similar. Además, deberemos garantizar la definición de los datos ALCOA+ en general y para este elemento en concreto. Con respecto a los datos primarios, el sistema deberá emitirlos y registrar cualquier cambio en ellos (audit trail).
Configuración del sistema: Elementos críticos de configuración del sistema han de estar definidos y validados. Además, no debe ser posible modificar parámetros como fecha y hora.
Permisos y usuarios: Es una parte importante del sistema, tanto para validar como para analizar los riesgos. Los diferentes niveles de acceso, permisos y usuarios han de estar definidos en un documento de especificaciones. Por ejemplo, un técnico de laboratorio no debería poder dar un apto de producto (es decir, ni tener acceso) y, ojo, un responsable de mantenimiento del software poder modificar parámetros en entorno real. Los usuarios genéricos no se deben permitir. Se deberían realizar controles periódicos de usuarios, por ejemplo, para eliminar permisos de bajas o en movilidades dentro de la empresa.
Procedimientos y contratos: Otro elemento clave es la firma de un acuerdo de calidad con el proveedor del software, implementador de mejoras y/o responsable del mantenimiento del mismo. Deberemos tener un SOP que defina la gestión del software, su mantenimiento, se indique la periodicidad y metodología para las copias de seguridad, etc.

Éstos son solo algunos de los elementos que deberemos analizar en el AMFE de riesgos para este elemento crítico. Pueden haber otros dependiendo del tipo de sistema, la fase de implementación o la criticidad del mismo.

Todo riesgo resultante no aceptable deberá ser tratado con medidas destinadas a reducir dicho riesgo a niveles considerados aceptables. Todo ha de quedar documentado, y el riesgo revisarse de manera periódica acorde a procedimientos escritos.

Es recomendable realizar los análisis conjuntamente entre el técnico informático, un miembro de calidad y responsable del proceso. Creo que de esta manera, el resultado va a ser más preciso y se va a poder justificar mejor a posteriori, evitándose análisis sesgados o parciales.

Conclusiones:

Como hemos visto, realizar análisis de riesgos de los diferentes elementos de la integridad de datos dentro de la organización es un requerimiento normativo esperado. Estos análisis deben realizarse como parte del análisis de riesgos de los sistemas de calidad, y tener mayor nivel de detalle cuanto más riesgo asociado resultante se defina.

Se han de analizar los principales elementos críticos de cada subsistema, enfocado en la calidad, seguridad y trazabilidad del proceso o producto y su impacto tanto en siguientes fases de la cadena de suministro como en la salud del paciente final.
Espero haya sido de interés, y espero vuestros comentarios y experiencias. Saludos y gracias.