El proceso de retirada y desmantelamiento es la etapa final en la gestión del ciclo de vida de cualquier aplicación y supone la eliminación de ésta de las operaciones activas. Muchos factores diferentes pueden desencadenar este evento:
• Avance tecnológico.
• Nuevas adquisiciones.
• Obsolescencia del proceso de negocio controlado por la aplicación.
• Etc.
En entornos GxP, la retirada de los sistemas informatizados es parte del ciclo de vida de la validación y debe seguir procesos bien definidos y documentados (ver sección 4.1 del Anexo 11 de las GMP). Esto implica definir claramente los inputs, outputs, estándares, actividades y entregables.

Un MES, o Manufacturing Execution System, proporciona herramientas para gestionar los procesos de producción electrónicamente.
La implementación de este tipo de sistema en la industria farmacéutica supone la gestión de las guías de fabricación, o Batch Record (BR), de forma electrónica (eBR). Incluye el diseño, revisión y ejecución de las instrucciones de producción, la gestión de pesadas y dispensación, la gestión de equipos, entre otros.
Como consiguiente, se obtiene una reducción de errores y desviaciones causadas por los operarios al incorporar verificaciones y controles del sistema sobre operaciones críticas de producción, así como confirmaciones mediante firma electrónica.

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.