El Plan Maestro de Validación es uno de los documentos clave para los procesos de validación de sistemas informatizados. Describe la metodología a seguir en la validación de los sistemas informatizados de una compañía y todos los aspectos necesarios para llevar a cabo una validación. Incluye además el listado de los sistemas a validar. El alcance de un PMV suele ser a nivel de compañía, sin embargo, también puede definirse para un área de negocio, un grupo de sistemas o incluso para un sistema en concreto (muy utilizado para sistemas multi-site).

El pasado 9 de febrero de 2019 entraron en vigor las regulaciones de serialización descritas en la Directiva de Medicamentos Falsificados (Falsified Medicines Directive, FMD) y en el Reglamento Delegado de la Comisión Europea 2016/161. En ellas se describen las medidas de seguridad que debe tener implantadas el sector farmacéutico en el mercado europeo para evitar la entrada de medicamentos falsificados en la cadena de suministro legal: colocación de un dispositivo anti-manipulación y de un identificador único en el envase de determinados medicamentos para permitir su identificación y autenticación.

Los sistemas informáticos implementados para automatizar los procesos en la industria regulada (industria farmacéutica, biotecnológica, producto sanitario…) sufren constantemente cambios a lo largo de su ciclo de vida, ya sea en la fase de implementación como de uso en un entorno de producción. Un buen sistema de Gestión de Cambios, integrado en el Sistema de Gestión de la Calidad de la compañía tal como está descrito en el Anexo 11 de las GMP (sección 10), es necesario para garantizar que dichos cambios se introducen de manera controlada, coordinada y documentada.

La validación es la evidencia documentada de que un sistema funciona según el uso previsto. En el caso de sistemas de gestión documental, la validación se centra en evidenciar que ha sido diseñado y configurado para llevar a cabo las acciones y los flujos definidos para cada tipo de documento.

La validación de un sistema informatizado cubre la instalación del sistema sobre una infraestructura cualificada y la instalación de todos los complementos necesarios para que la aplicación funcione.

Ciclo de vida de un sistema informatizado - Mantenimiento del estado de la validación

Figura 1. Ciclo de vida de un sistema informatizado

 

Pero debe asegurarse que este estado de cumplimiento con todos los requerimientos, especialmente los regulatorios detallados en el Anexo 11 de las EU GMP, al que se ha llegado una vez finalizado el esfuerzo realizado durante la validación, se mantiene a lo largo de todo el ciclo de vida del sistema.

Debemos tener en cuenta que la mayor parte de este ciclo de vida la constituye la fase de funcionamiento/operación, es decir, su uso en el día a día, por lo que uno de los mayores retos con los que se encuentran las compañías es ¿Cómo asegurar que el estado validado del sistema se mantiene? Y tanto o más importante, ¿Cómo lo demuestro?

La fase de funcionamiento rutinario es el objetivo de todas las actividades de mantenimiento del estado de validación, ya que se trata de sistemas que evolucionan y es posible que tengan lugar cambios a lo largo del tiempo.

El sistema ya está validado, pero el esfuerzo realizado no sirve de nada si no se dispone de una metodología que permita mantenerlo bajo control, de manera que el resultado puede convertirse en obsoleto en un tiempo récord.

Y además, todas las actividades que se realicen deben estar documentadas y las evidencias de las mismas disponibles de forma que podamos demostrar la trazabilidad y adecuación de las mismas durante todo el tiempo que el sistema esté en uso.

Para ello, debe establecerse un marco de gestión de los sistemas informatizados robusto, de manera que permita asegurar el mantenimiento de su estado de validación durante todo el ciclo de vida del sistema. Este marco es el Sistema de Gestión de la Calidad, que debe asegurar que el sistema se utiliza por parte de personal formado, que se dispone de procedimientos de uso y control y que se dispone de un sistema de gestión de cambios e incidencias, entre otros.

Los procesos principales que permiten asegurar este mantenimiento del estado de validación pueden incluirse en las siguientes categorías:

  • Gestión de altas, bajas y modificaciones de cuentas de usuario, con controles de seguridad lógica, acceso controlado, formación, roles, …
  • Gestión de cambios y configuración, tanto funcionales como asociados a infraestructura.
  • Gestión de incidencias.
  • Gestión de CAPA, como oportunidades de mejora.
  • Revisión periódica de los sistemas para confirmar que se mantienen en un estado válido y cumplen con las GMP.

Para más información en el tema, en CSV Experts impartimos un curso dedicado al Mantenimiento del estado de validación el día (13 de Noviembre) en Mataró (oficinas de CSV Experts). Información más detallada del curso en nuestra página web (www.csvexperts.com) o llamando al teléfono 93 169 65 98.

Los sistemas informatizados no están compuestos solamente por la aplicación y sus funcionalidades, sino que engloban también los usuarios y los procedimientos de uso aplicados al sistema. Los sistemas informatizados son, consecuentemente, sistemas vivos que pueden evolucionar y/o sufrir cambios después de su validación. Por este motivo y de acuerdo a la versión vigente del Anexo 11 de las EU GMP, éstos deben ser revisados periódicamente para garantizar que el estado de la validación y la integridad de los datos que gestiona se mantienen durante el período de tiempo transcurrido desde la validación o la última revisión realizada.
 
Revisión periódica

Figura 1. Revisión periódica

 

Las revisiones periódicas deben realizarse durante todo el ciclo de vida de un sistema informatizado. Para determinar qué sistemas están dentro del alcance y la frecuencia de la revisión periódica deberemos basarnos en una evaluación del riesgo del sistema que deberá poder justificarse cuando sea necesario frente a las autoridades.

El alcance de la revisión periódica debe incluir como mínimo los puntos listados a continuación desde la última validación o revisión realizada:

  • los registros de control de cambios
  • la resolución de desviaciones
  • la administración de cuentas de usuario
  • la formación de los usuarios
  • la gestión de las copias de seguridad de datos
  • cambios en la configuración crítica del sistema (Audit Trail, firma electrónica, contraseñas de usuarios…)
  • correcto funcionamiento del Audit Trail
  • documentación del sistema y documentación de validación
  • evaluación de los elementos de riesgo no mitigados totalmente durante la validación
  • …….

Los archivos de datos electrónicos que contienen datos GxP de sistemas retirados también deben estar sujetos a revisión periódica.

La revisión periódica de los sistemas debe realizarse de acuerdo con un procedimiento predefinido y se debe documentar incluyendo las acciones correctivas y su seguimiento (plan de acción) hasta su completa resolución.

La periodicidad de la revisión puede indicarse en el inventario de sistemas informatizados corporativo requerido por la norma que, entre otros datos, puede contener la siguiente información: funciones básicas del sistema, criticidad GxP, categoría GAMP, estado de la validación, frecuencia revisión periódica, responsabilidades sobre el sistema (system owner, process owner, data owner), usos de firma electrónica…

Para más información en el tema, en CSV Experts impartimos un curso dedicado al Mantenimiento del estado de validación el día (18 de Septiembre) en Madrid (Hotel AC Atocha) y el día (13 de Noviembre) en Mataró (oficinas de CSV Experts). Información más detallada del curso en nuestra página web (www.csvexperts.com) o llamando al teléfono 93 169 65 98.

La realización de un correcto análisis de riesgos en entornos GxP requiere de un equipo interdisciplinar que aporte el máximo conocimiento de sus áreas de experiencia.

Con diferencia, la parte más tediosa de las validaciones de sistemas informatizados, y la que más influye en disponer de un sistema bajo control, es la realización del Análisis de Riesgos. El Análisis de Riesgos se basa en los principios de ICH Q9 y la guía GAMP 5.

Un factor importante para abordar con éxito un análisis de riesgos es la elección de un equipo interdisciplinar, compuesto por expertos en las áreas involucradas, además de personal con conocimiento en riesgos regulatorios en entornos GxP. Sin el conocimiento de estos expertos, la valoración del riesgo o la identificación de qué podría ir mal, qué probabilidad hay que ocurra o cuáles son las consecuencias, será una tarea complicada, imprecisa y que puede conllevar la toma de decisiones erróneas.

Asimismo, se deberá identificar las medidas de control del riesgo que incorpora el sistema informatizado para poder reducir los riesgos a un nivel aceptable. Al intentar evaluar un concepto tan impreciso sin disponer del oportuno conocimiento y la implicación del equipo, la identificación, análisis y evaluación del riesgo supondrá un esfuerzo estéril.

Existen herramientas reconocidas y de gran utilidad para gestionar el riesgo, como por ejemplo las metodologías AMFE, AMFEC, AAF, APPCC, APO o APP. El riesgo se puede determinar evaluando la relación de la severidad y la probabilidad (clase de riesgo), y ésta relacionándola a su vez con la detectabilidad (prioridad del riesgo). La siguiente figura detalla un ejemplo de cómo realizar la evaluación del riesgo:

Análisis de Riesgos: Probabilidad y Detectabilidad

Source: Figure M3.5, GAMP 5: A Risk-Based Approach to Compliant GxP Computerized System, ®Copyright ISPE 2008. All rights reserved. www.ISPE.org.

Para abordar el Análisis de Riesgos, es primordial que el esfuerzo desempeñado sea proporcional a la criticidad del Sistema Informatizado dentro de la organización. Cabe destacar que, como toda actividad de gestión, es de vital importancia que sea dinámica dentro del proceso de calidad, debiéndose revisar y controlar periódicamente, por medio de procesos sistemáticos que permitan mejorar, sin dejar de tener en cuenta los nuevos conocimientos y experiencias adquiridas. La frecuencia de esta revisión siempre dependerá del nivel de riesgo del sistema Informatizado.

Para mayor profundidad en el tema, en CSV Experts impartimos un curso dedicado al Análisis de Riesgos el día 20 de Marzo en Mataró (oficinas de CSV Experts) y el día 22 de Mayo en Madrid (Hotel AC Atocha). Información más detallada del curso en nuestra página web: www.csvexperts.com o llamando al teléfono 93 169 65 98.

A menudo los conceptos de verificación y validación, o bien se confunden, o bien se interpretan diametralmente opuestos.

Desde la óptica de la 21 CFR 820 (Quality Systems Regulations for Medical Devices), se diferencian claramente, tal como sigue:

– Se explicita el término ‘verificación’ como la realización de pruebas específicas y evidenciadas, que demuestran que un determinado requerimiento de diseño es cubierto por el sistema.

– En este caso la ‘validación’ se entiende como la demostración evidenciada de que el sistema es capaz de cubrir el ‘intended use’ en el más amplio concepto del proceso en el que interviene.

En el ámbito de la validación de sistemas informáticos en entornos GxP, nos encontramos con diferentes escenarios que solo ayudan a aumentar la confusión, sobretodo si intentamos hacer encajar terminología que no tenemos muy clara con conceptos de ciclo de vida y metodologías de desarrollo (SCRUM, COBIT, AGILE…). De este modo, el equipo de desarrollo habla su idioma y desde el equipo de validación hablamos otro, que puede, o no, coincidir en los contenidos, pero lo que es seguro es que a nivel terminológico se genera una gran confusión.

>A todas luces, lo que es incuestionable es que se debe comprobar el funcionamiento del sistema informático antes de que éste entre en operación en las actividades del día a día, a través de diferentes etapas de test.

Independientemente de qué etapas de test definamos, de cómo las designemos  y el nivel de detalle de las pruebas que se realizan (siempre dependiendo de si se trata de un software de Categoría 4 o 5 de la guía GAMP), debemos tener en cuenta siempre unos principios básicos:

– El software desarrollado o configurado debe ser siempre testeado antes de ser entregado al cliente (se entiende ‘cliente’ como el ‘usuario’ del sistema). Estas pruebas serán completadas y adecuadamente evidenciadas, por el equipo de desarrollo/configuración del sistema. El objetivo es comprobar que toda la funcionalidad que se ha desarrollado o customizado es capaz de operar según se ha solicitado en los requerimientos y conforme se ha definido en la documentación funcional del sistema. En este sentido, desde la óptica del equipo de desarrollo/customización no se hará distinciones entre funciones GxP relevantes de las No-GxP relevantes, ya que su objetivo es ofrecer un software oficialmente probado, por lo que todos los escenarios de uso (use cases) deberían ser verificados adecuadamente.

– Una vez cubierta la etapa anterior, el sistema será entregado a los usuarios para que puedan realizar las pruebas que le correspondan, con el fin de comprobar que el uso previsto del sistema es cubierto adecuadamente por la funcionalidad recibida. Aquí el abanico de oportunidades y tipos de prueba a realizar se abre: desde la comprobación de todos los requerimientos, hasta la aproximación basada en los riesgos de las funciones y centrados en los aspectos que puedan comprometer de algún modo el cumplimiento de los principios GxP aplicables, con un esfuerzo considerable en forzar el sistema a situaciones límite.

Estos dos principios, que a priori parecen obvios y básicos, en ocasiones, por cuestiones de calendario y disponibilidad de recursos, se solapan y, sucede que a veces se aprovechan las pruebas de usuario para hacer comprobaciones que no ha podido completar el equipo de desarrollo: esta situación provoca que aparezcan errores que entorpecen la normal ejecución de las pruebas, los usuarios desconfían de la aplicación, se generan un gran número de desviaciones que obligan a corregir el programa y las pruebas de regresión se realizan de forma básica (o en ocasiones ni se realizan)… y al final se alcanza un nivel de validación con una documentación ciertamente difícil de presentar. Y a menudo preguntas tan básicas como ¿tras todas las correcciones realizadas se tiene certeza de que las pruebas realizadas son representativas? se quedan sin una respuesta clara e inequívoca… Y como conclusión final: el nivel de confianza sobre el sistema es muy bajo… contradiciendo el principio básico de la validación de ‘disponer de un nivel de confianza razonable’ de que el sistema es capaz de operar según su uso previsto.

 

Seguro que este escenario es reconocible por muchos de nosotros, por lo que, para evitar, o al menos minimizar estas situaciones, es necesario:

 

– Planificar las diferentes etapas de test desde el inicio del proyecto, estableciendo de forma clara qué pruebas realizará el equipo de proyecto y qué pruebas los usuarios, dándoles el tiempo necesario y adecuado para cada una de ellas.

– Definir las pruebas y nivel de documentación de cada etapa de test.

– Ser estrictos en no iniciar pruebas de usuario (UAT, OQ…) sin haber superado con éxito las pruebas del equipo de desarrollo y sin una revisión de dichas pruebas por la Unidad de Calidad.

Ya hace tiempo que se publicó la ICH Q9 que define la gestión de riesgos en la industria farmacéutica y la ICH Q8 acerca de la Quality by Design. Si preguntásemos a técnicos de Producción, Control de Calidad, Garantía de Calidad, Validaciones, Sistemas Informáticos, Logística… de la industria farmacéutica, tendrían claro que la ICH Q9 es aplicable a todos los ámbitos de la empresa, mientras que la ICH Q8 la centrarían mayormente en el desarrollo de API, medicamentos y su traspaso a escala productiva.

 

Tal vez a algunos pocos se les ocurriría pensar que el concepto de Quality by Design es aplicable a cualquier ámbito de la empresa, incluso a los Sistemas Informáticos que están utilizando en operaciones relevantes desde la óptica GMP. Así pues, haciendo una interpretación más sosegada del ánimo de la ICH Q8, podremos ver que los conceptos son aplicables (con matices, claro) a los sistemas informáticos y que el proceso a seguir desde la concepción del sistema a implantar a su posterior uso debe ir acompañado de un análisis detallado de los parámetros críticos del proceso sobre el que se implanta el software, así como de los parámetros críticos de la propia aplicación y una correcta definición de los elementos de control a implantar.

 

Para la determinación de los parámetros y atributos críticos del sistema informático, nos basaremos en un profundo conocimiento del proceso que gestionaremos con el sistema informático. A partir de este conocimiento (aportado principalmente por los usuarios y personal técnico que conoce con detalle el proceso), podremos efectuar el análisis de riesgos (siguiendo ICH Q9) que nos permitirá:

  • Evaluar los posibles riesgos que puede conllevar un funcionamiento incorrecto del sistema,
  • definir controles que deberá incorporar el propio sistema y, si es posible,
  • rediseñar la operativa del sistema para evitar que se produzcan dichos fallos.

En muchas organizaciones, la gestión de riesgos se limita a la preparación del Análisis de Riesgos. Éste ya está integrado como parte del proceso de Validación del Sistema Informático, pero en la mayoría de los casos se limita en obtener una tabla que clasifica las funciones del sistema en base a su impacto y probabilidad del fallo y, a partir de ahí, se definen las pruebas de validación a realizar. Pero en un enfoque más holístico del proceso de gestión de riesgos, se debe considerar el Análisis de Riesgos en las fases iniciales de la concepción y diseño del sistema informático y dotar, de forma objetiva, de argumentos que permitan redefinir el sistema para minimizar los riesgos. De este modo, estaremos alineados con los fundamentos de la ICH Q8.

Previamente a la aprobación de la norma de Good Distribution Practices (GDP) en marzo de 2013 y posteriormente modificada en noviembre del mismo año, la validación de sistemas informáticos que gestionan las diferentes actividades de almacenamiento y distribución de los medicamentos quedaba muy limitada a lo que eran los fabricantes de medicamentos, y se extendía a mayoristas y distribuidores por requisito expreso de los laboratorios farmacéuticos.

 

Con la aprobación de las GDP, no cabe duda de que la Validación de los Sistemas Informáticos es un requisito básico que deben cumplir todos los distribuidores de medicamentos para estar alineados con la norma y conseguir la correspondiente autorización de distribución de medicamentos por la agencia reguladora correspondiente.

 

Puesta esta necesidad sobre la mesa, se hace manifiesta la situación de muchos sistemas informáticos de gestión logística que han sido desarrollados específicamente para el distribuidor (ya sea internamente por el departamento de informática del distribuidor, como por empresas especializadas en el sector de la distribución) o adquiridos en el mercado, que tienen como su objetivo principal una buena gestión logística, pero que en su definición no contemplaron los requisitos que se derivan del sector farmacéutico.

Ante este escenario, es altamente recomendable, antes de iniciar cualquier proceso de validación, efectuar una primera ‘auditoría’ del software, con el fin de identificar cuanto antes aquellas carencias relacionadas con los aspectos básicos de las EU GMP Annex 11, a saber:

  • Acceso controlado a la aplicación y definición de las responsabilidades sobre el sistema informático y las funciones que se realizan con él.
  • Trazabilidad de las modificaciones de datos, de los movimientos de stock y de todo el historial del medicamento desde que se recibe hasta que se distribuye.
  • Realización de backup del sistema informático y de los datos, comprobando la capacidad de restaurar el sistema en caso de necesidad. Estos procesos se deben monitorizar periódicamente.
  • Control de las condiciones de distribución de medicamentos.
  • Disponibilidad de procedimientos de control de cambios, gestión de la configuración, gestión de la seguridad, uso del sistema…

A todo ello, cabe también analizar como se garantizan los principios de Data Integrity, mediante sistemas informáticos cuyo diseño no fue inicialmente concebido para un entorno regulado al estilo del sector farmacéutico.

La realización de una auditoría de cumplimiento de GDP, EU GMP Annex 11 y Data Integrity, permitirá disponer de una visión inicial muy valiosa que permitirá a las compañías de distribución de medicamentos dirimir si son necesarios esfuerzos previos de modificación/adaptación del software para adaptarlo a los requisitos necesarios, previo al proceso de validación del sistema informático de gestión logística.