Hallazgos frecuentes en Inspecciones. Data Integrity: MHRA

Continuando con la serie de entradas relacionadas con Data Integrity (tenéis el listado al final de la entrada), y continuando con la anterior entrada sobre hallazgos frecuentes en Inspecciones Regulatorias, me centro en los resultados de inspección GCP en temas informáticos y de validación de sistemas.

En este caso, un inspector del MHRA comenta en el blog de la Agencia una serie de interesantes notas sobre validación de sistemas informáticos y hallazgos frecuentes en inspecciones bajo normativa GCP (enlace). La entrada del blog de la MHRA incluye una interesante explicación de un caso de validación de sistemas informáticos, que recomiendo la lectura.

Las conclusiones que podemos extraer de cara a mejorar nuestros sistemas o a estar preparados para auditorias o inspecciones son los siguientes:

Datos a tener en cuenta con respecto a los contratos/agreements:

El proveedor puede haber producido el software, pero la responsabilidad final es del usuario. Si se presupone o asume que un sistema o pieza de software está validado y no se verifica y esto causa problemas de data integrity / integridad de datos o problemas de seguridad del paciente, la responsabilidad final va a ser nuestra.

Por tanto, cobra vital importancia el contrato con el proveedor y añade algunos puntos clave que el usuario o sus departamentos legales y financieros deben conocer:

Los proveedores de sistemas electrónicos deben tener conocimientos especializados sobre los sistemas informáticos y, en ocasiones, sobre la legislación en materia de protección de datos, si procede, pero no necesariamente sobre los requisitos de buenas prácticas.
El contrato debe requerir que el suministrador trabaje según GxP. Si no lo hace, aumenta el riesgo de que no retengan suficiente documentación para reconstruir las actividades esenciales.
El contrato debe permitir al usuario el acceso a la documentación esencial no específica, como los documentos de validación del software/sistema, los procedimientos normalizados de trabajo de los proveedores, los registros de formación y los registros/resoluciones de problemas en el sistema Helpdesk/IT Ticket, o garantizar su conservación.
El contrato debe exigir que el proveedor informe de las infracciones graves al usuario o a las autoridades reguladoras pertinentes.
El contrato debe ser claro con respecto a la subcontratación por parte del proveedor, específicamente qué tareas pueden y no pueden ser subcontratadas y cómo el cliente mantendrá la supervisión.

Datos a tener en cuenta con respecto a los usuarios:

Comenta el inspector que la validación del sistema no se detiene con el desarrollo de los sistemas; también hay que pensar en los usuarios. Se puede tener un sistema muy fiable y totalmente validado, pero si los usuarios no son capaces de usarlo correctamente, es probable que se produzcan errores generados por el usuario que podrían llevar al incumplimiento de estándares.

Los hallazgos comunes relacionados con el aspecto de usuario de la validación incluyen:

El producto se entrega al cliente antes de que se haya desarrollado y publicado el material de formación (es decir, la guía del usuario).
Los usuarios tienen acceso al sistema sin formación.
A los usuarios se les da un acceso inapropiado (de nivel superior), como la posibilidad de realizar cambios en los datos.
El material del usuario no está siendo revisado o actualizado después del lanzamiento de una nueva versión con nuevas funcionalidades.
No se notifica a los usuarios de las actualizaciones del sistema que incluyen cambios en la funcionalidad.
No se siguen los procesos internos ni los procedimientos normalizados de trabajo (PNT/SOP) y, como resultado, no se completa la revisión formal y la aprobación de documentos clave como planes de validación, secuencias de comandos de prueba e informes.

Items a verificar en el caso de usar una validación de sistema informático externa:

Cuando se recibe un informe de validación, ¿se ha revisado y asegurado que corresponde a la versión del software que está utilizando?.
Si se detalla la funcionalidad del sistema, ¿se ha garantizado que toda la funcionalidad que está utilizando está cubierta en el informe?
Cuando se recibe un informe de validación, pero no se verifican los siguientes elementos:
- ¿muestra el sistema que va a ser validado con éxito, es decir, se ha probado y aprobado toda la funcionalidad que pretende utilizar?
- ¿Es evidente quién era el verificador y han firmado y fechado todo correctamente?
- ¿Es evidente cómo se han rectificado los errores de prueba?
- ¿Hay algo que pueda causarle preocupación, como la falta de una prueba de seguimiento después de una prueba fallida o indescifrable?
- ¿Son secuenciales las fechas?
- ¿Se completaron todas las pruebas antes de que se lanzara el producto?
- ¿Se acordaron y aprobaron todos los requisitos de especificación y los scripts de prueba antes de que se completara la construcción?
¿Se emitió el informe de validación antes de la liberación?
Si tienes alguna inquietud, ¿puedes resolverla? ¿Puedes autovalidarlos o mitigarlos de otra manera?
¿Se ha realizado una evaluación de riesgos formalizada, documentando los hallazgos y registrando cualquier acción paliativa que vaya a tomar?

Conclusiones:

Interesante entrada del blog de la MHRA, muy bien estructurada, haciendo un análisis concreto de un caso específico y extrapolando las conclusiones a cómo verificar los sistemas de calidad en entorno GCP. Recomiendo la lectura, por cultura general y específica.

Los tres niveles que he analizado a partir de la entrada me parecen importante. Por un lado, de la mano de la evaluación del proveedor ha de ir el contrato o quality agreement, definiendo claramente las responsabilidades.

Por otra parte, los usuarios deben conocer el sistema y estar formados. Y tenerlo en cuenta de cara a nuevas versiones.

Y por último, si decidimos no validar internamente y aceptamos la validación del fabricante, nos aporta una serie de parámetros a tener en cuenta. En este caso, hay una parte que seguramente no podremos convalidar, y es la integración con nuestros sistemas y trabajadores, que deberemos justificar de alguna manera.

Espero que haya sido de utilidad, y como siempre os agradeceré un me gusta, compartir el blog en redes sociales o clickar en alguna publicidad que os sea de interés para de esta manera apoyar el blog y permitirme llegar a más gente.

Un saludo y gracias.

Bonus track:

Os compilo a continuación el resto de entradas del monográfico sobre Data Integrity: