¿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.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *