Validación de sistemas computarizados sin la espiral de papeleo

La validación tiene un problema de reputación en la manufactura, y en buena parte es merecido. Pregunte a un ingeniero qué es CSV en la práctica y a menudo recibirá la descripción de un conjunto de documentos, no de una actividad: protocolos escritos desde una plantilla, capturas de pantalla de cada campo, una hoja de firmas más gruesa que la prueba que certifica.

No es eso lo que pide la guía. GAMP 5 es explícito en que el esfuerzo debe ser proporcional al riesgo, la complejidad y la novedad — y en que es el pensamiento crítico, no el volumen, lo que hace defendible una validación. La distancia entre ese principio y la práctica habitual es donde está la mayor parte del costo.

Qué significa realmente "basado en riesgo"

Para cerrar esa distancia, el primer paso es definir de qué riesgo se habla. Riesgo aquí es riesgo para el paciente, para la calidad del producto y para la integridad de los datos — no riesgo de proyecto. Una función que calcula una cantidad de dispensación conlleva riesgo. Una función que permite al usuario cambiar el color de un gráfico, no. Probar ambas con la misma profundidad no es rigor; en la práctica es falta de priorización, y quita atención de las partes que importan.

Aplicado correctamente, esto cambia la forma del paquete. Las funciones de alto riesgo reciben especificación detallada, pruebas exhaustivas y trazabilidad explícita. Las de bajo riesgo reciben cobertura proporcional. El esfuerzo ahorrado va a las áreas que un inspector realmente va a sondear.

Un paquete de validación que trata cada función como igualmente crítica le dice al inspector que nadie evaluó cuáles lo eran.

Aproveche al proveedor en lugar de volver a probarlo

La evaluación de riesgo dice qué merece pruebas. La segunda pregunta es quién ya lo probó. Una de las mayores fuentes de desperdicio es volver a probar lo que el proveedor ya probó, y GAMP 5 lo anticipa: cuando un proveedor tiene un sistema de calidad maduro y puede evidenciar su propio desarrollo y pruebas, esa evidencia puede aprovecharse en lugar de duplicarse.

Ese aprovechamiento hay que ganarlo, no presuponerlo. Una evaluación de proveedor en la que se pueda confiar establece:

• si existe un ciclo de vida de desarrollo documentado, y evidencia de que se sigue
• cómo se controlan, prueban y liberan los cambios
• qué prueba el proveedor, y si esas pruebas se conservan y son auditables
• cómo se rastrean los defectos, y cómo se notifica a los clientes de los relevantes

Donde las respuestas sean buenas, sus pruebas se concentran en la configuración y en su propio proceso. Donde no lo sean, se prueba más — y ahora tiene una razón documentada para hacerlo, lo que ya es una posición más sólida que probarlo todo por defecto.

Pruebe el proceso, no el software

Con el alcance definido por el riesgo y por el proveedor, queda la pregunta de cómo probar lo que resta. Las pruebas de validación más útiles ejercitan el uso previsto, no la lista de funciones. Un protocolo que confirma que un campo acepta números dice poco. Un protocolo que hace pasar un lote representativo por el sistema — incluyendo un valor deliberadamente fuera de rango, una entrada corregida y una revisión de segunda persona — dice si el proceso se está imponiendo de verdad.

Es también aquí donde se nota la arquitectura. Si los valores en proceso llegan de un historiador de proceso con su marca de tiempo de origen, en lugar de teclearse, toda una clase de casos de prueba de transcripción deja de ser necesaria — el modo de falla se eliminó, no se probó.

Qué no exime el enfoque basado en riesgo

Nada de esto es licencia para aflojar donde importa. Un enfoque proporcional no es un enfoque ligero en las partes críticas, y algunas cosas siguen siendo innegociables, sea cual sea el resultado de la evaluación de riesgo:

1. Requisitos lo bastante específicos para ser probados. "El sistema debe ser amigable" no es verificable y no debería pasar la revisión.
2. Trazabilidad del requisito a la prueba, para que la cobertura sea demostrable y no afirmada.
3. Evidencia de que los controles de integridad de datos funcionan — registro de auditoría, firma electrónica, control de acceso — porque por ahí suele empezar una inspección.
4. Una justificación documentada del alcance elegido. La decisión de probar menos es defendible; una decisión no documentada de probar menos, no.

La validación no termina en el go-live

Incluso un paquete proporcional y bien justificado solo vale mientras el sistema se mantiene en el estado en que fue validado. El estado validado es una condición a mantener, no un hito a superar. La mayoría de los hallazgos en esta área no son sobre el paquete original — son sobre lo que ocurrió después: una configuración cambiada sin evaluación, un parche del proveedor aplicado sin pruebas de regresión, una revisión periódica programada y nunca realizada.

Aquí los sistemas ayudan de un modo que la documentación no puede. Un registro de auditoría encadenado por hash de los cambios de configuración convierte "controlamos los cambios" de una afirmación en un POE en algo que el inspector puede inspeccionar. Los permisos por rol hacen que la declaración de control de acceso sea verificable en lugar de aspiracional.

Por dónde empezar si el enfoque actual pesa demasiado

No empiece reescribiendo plantillas. Empiece con un sistema y una evaluación de riesgo honesta, y vea cuánto del paquete existente habría justificado esa evaluación. La respuesta suele ser incómoda, y es el argumento más persuasivo disponible para cambiar el enfoque.

A partir de ahí, la cuestión del alcance encaja naturalmente en las fases de una hoja de ruta de digitalización, y los sistemas más habitualmente en alcance — el registro electrónico de lote entre ellos — pertenecen a una postura más amplia de cumplimiento digital, no a un ejercicio de validación aislado.