¿Aprovechar la verificación como parte de la OQ en la validación de sistemas informáticos?

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.

El Análisis de Riesgos como base del Quality by Design en Sistemas Informáticos

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.

Validación de Sistemas Informáticos en entornos GDP

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.

 

Aprovechar las pruebas del proveedor

Hace tiempo me enseñaron unas pruebas que había realizado el implantador del software acerca del funcionamiento del sistema y me dijeron que eso era la validación. Mi primera reacción fue de incredulidad y sorpresa. A continuación empecé a revisarlas, manteniendo el mismo nivel de desconfianza. La cara me iba cambiando poco a poco… había un nivel de detalle al que yo nunca habría llegado. Y no sabía muy bien qué hacer con ellas.

Mi aplicación dogmática de la metodología de la validación me ponía en cuestión lo que estaba viendo. Eran pruebas que estaban muy bien hechas, se probaba todo o casi todo (si había cosas que no se probaban tampoco lo tenía objetivamente claro). Sabía que era una osadía el pensar que aquellas pruebas eran toda la validación del sistema informático. ¿Pero cómo desaprovechar todo aquel ingente trabajo? ¿Cómo le iba a decir a QA que aquello no era la validación y que tenía que hacer más cosas? ¿Y cómo le iba a decir que, a pesar de tener las pruebas, son muchas las actividades que no recogían aquel legajo de verificaciones? Presentía que me estaba metiendo en un jardín del que era difícil salir indemne.

Desde entonces ha llovido mucho, y nadie cuestiona hoy en día que las pruebas realizadas por el implantador/suministrador son de gran valor. Pero cuidado, no son el todo, tan solo son una parte de la validación.

¿Puedo instalar un sistema de control sin la documentación de cualificación?

Las empresas integradoras de sistemas de control y automatización de procesos se encuentran a menudo con una barrera que parece infranqueable: si quiero trabajar para la industria farmacéutica, me piden un conjunto de pruebas que no sé muy bien en qué consisten y no sé si yo las puedo hacer. ¡Me piden documentación de cualificación!

A menudo la sensación general es que el sector farmacéutico está envuelto de una áurea de misticismo que lo hace inaccesible para las empresas que no tienen experiencia previa en el sector.

Hace poco hablaba con un ingeniero de una empresa integradora de sistemas de control y entendía que si quería desarrollar proyectos en la industria farmacéutica, tenía que dar un paso adelante, y afrontar con profesionalidad y rigor (y con cierto temor la primera vez) los retos que les plantea el sector: preparación de protocolos de IQ, OQ, FAT, SAT… elaboración de una documentación detallada de toda la implantación y funciones, verificar la instalación y su funcionamiento  y documentar adecuadamente todas las tareas realizadas.

Aquellos integradores que hace tiempo que han entrado en el sector y cumplen con estos requisitos, han aprendido que este método de trabajo han aportado calidad a sus productos y los tiempos de implantación quedan mejor acotados y la dedicación requerida inicialmente ha sido fácilmente amortizada.

¿Mis sistemas informáticos pueden guardar los datos el tiempo requerido por las leyes?

El entorno farmacéutico se encuentra con unas exigencias muy claras en cuanto a la necesidad de almacenar datos de los productos que fabrica.

  • Desde los 5 años mínimos para la documentación relacionadas con la fabricación de lotes de producto acabado.
  • Hasta los 30 años exigibles para la obtención de productos y derivados del plasma o la sangre humanos.

La complejidad de sistemas informatizados que actualmente hay en el mercado, así como los cambios de versiones, bases de datos… junto que la gran cantidad de información que somos capaces de generar en la actualidad, implica disponer de unas políticas muy claras de data retention, a la vez que estrategias tecnológicas adecuadas para satisfacer las necesidades de almacenamiento de los datos durante dicho periodo. Y lo que es más importante, garantizar que se puedan recuperar los datos en el momento que se necesiten (que para eso se almacenan).

Hoy en día existe una gran variedad de medios tecnológicos que nos van a permitir implantar estrategias robustas para almacenar gran cantidad de información, pero el talón de Aquiles lo encontramos en procesos de migración de datos entre sistemas. No siempre la información es compatible entre sistemas y se tiene que acabar haciendo cribado de datos… Frente a esta situación, es crucial discriminar qué información es obligatorio mantener y cuál es prescindible. Y la que mantengo ¿puede estar en un formato electrónico inteligible?