Validación de sistemas informatizados en entornos GxP

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.

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 o 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án 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).

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.

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.

Como puedes ver, el proceso de validación de sistemas informáticos en entornos GxP es una tarea compleja y exhaustiva que requiere la asesoría de consultores expertos en la materia. 

AMBIT BST 

En Ambit ayudamos a nuestros clientes a validar y optimizar sus sistemas informatizados. Somos expertos desde hace más de 15 años en el desarrollo de estrategias y soluciones IT para tu compañía. Somos consultores e integradores en múltiples ámbitos. Por eso, si necesitas ayuda, no dudes en ponerte en contacto con nosotros. 

Si quieres conocer más sobre las soluciones que te podemos ofrecer para implantar la informatización en los procesos de tu organización, validar sistemas informatizados, garantizar la integridad de la información o implantar programas en proyectos GxP, te recomendamos este ebook.