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 vive la mayor parte del coste.
Qué significa realmente "basado en riesgo"
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; es falta de priorización, y desvía la 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 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
Una de las mayores fuentes de desperdicio es volver a probar lo que el proveedor ya probó. 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 los relevantes
Donde las respuestas sean buenas, sus pruebas se concentran en la configuración y en su propio proceso. Donde no lo sean, 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
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 fallo se ha eliminado, no probado.
Qué no exime el enfoque basado en riesgo
Un enfoque proporcional no es un enfoque ligero donde importa. Algunas cosas siguen siendo innegociables, sea cual sea el resultado de la evaluación de riesgo:
- Requisitos lo bastante específicos para ser probados. "El sistema debe ser amigable" no es verificable y no debería sobrevivir a la revisión.
- Trazabilidad del requisito a la prueba, para que la cobertura sea demostrable y no afirmada.
- Evidencia de que los controles de integridad de datos funcionan — pista de auditoría, firma electrónica, control de acceso — porque por ahí suele empezar una inspección.
- 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
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. Una pista de auditoría encadenada por hash de los cambios de configuración convierte "controlamos los cambios" de una afirmación en un PNT 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.
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.
