Integridad de datos y ALCOA+
Los nueve principios y qué revisa un inspector.
Leer artículo →
En el sector farmacéutico y de salud, un sistema informático no es solo una herramienta de trabajo: puede formar parte de la cadena que fabrica, almacena, distribuye o dispensa un medicamento. Cuando eso ocurre, ese sistema debe demostrar, con evidencia, que hace exactamente lo que se espera de él.
En este artículo
Una definición sin rodeos
La validación de sistemas computarizados (CSV, por sus siglas en inglés) es el proceso documentado que establece, mediante revisiones, pruebas y evidencia objetiva, que un sistema informático cumple de forma consistente con los requisitos para los que fue diseñado y con la regulación aplicable.
La palabra clave es evidencia. No basta con que el sistema «funcione»: hay que demostrarlo de manera que un tercero —típicamente un inspector de una agencia como el INVIMA, la FDA o la EMA— pueda revisar el rastro documental y llegar a la misma conclusión.
Validar no es probar el software una vez. Es construir y mantener un estado de confianza demostrable durante toda la vida del sistema.
¿Cuándo es obligatorio validar?
La CSV aplica a los sistemas que tienen impacto en las Buenas Prácticas (GxP): Buenas Prácticas de Manufactura (BPM/GMP), de Laboratorio (BPL/GLP) y de Distribución (BPD/GDP). En la práctica, hablamos de sistemas que:
- Controlan o registran procesos de fabricación (por ejemplo, sistemas SCADA o de control de equipos).
- Gestionan datos de calidad, resultados de laboratorio o liberación de lotes (LIMS, cromatografía, equipos de análisis).
- Soportan la trazabilidad, el almacenamiento o la distribución (ERP, WMS, sistemas de cadena de frío).
- Administran documentación y registros regulados (gestión documental, firmas electrónicas).
Un correo corporativo o una hoja de cálculo para gastos internos no requiere validación. Una hoja de cálculo que calcula la potencia de un principio activo, sí.
GAMP 5: el marco de referencia
La guía GAMP 5 (Good Automated Manufacturing Practice), publicada por la ISPE, es el estándar de facto para abordar la CSV. Su segunda edición reforzó dos ideas centrales: el enfoque basado en riesgo y el aprovechamiento del conocimiento del proveedor.
Las categorías de software GAMP
GAMP 5 clasifica el software según su complejidad y grado de personalización, porque no tiene sentido validar igual un sistema operativo que una aplicación hecha a la medida:
| Categoría | Tipo | Esfuerzo de validación |
|---|---|---|
| 1 | Infraestructura (SO, bases de datos) | Gestión, no validación formal |
| 3 | Producto no configurado | Bajo, centrado en el uso previsto |
| 4 | Producto configurado (LIMS, ERP) | Medio, según la configuración |
| 5 | Software a la medida | Alto, cubre todo el desarrollo |
El modelo en V
El ciclo de vida de la validación suele representarse con el modelo en V, que relaciona cada actividad de especificación con su verificación correspondiente:
- Especificación de requerimientos de usuario (URS): qué necesita el negocio y qué exige la regulación. Es el documento más importante; todo se traza hacia él.
- Especificaciones funcionales y de diseño: cómo el sistema cumplirá esos requisitos.
- Calificación de instalación (IQ): se verifica que el sistema esté instalado correctamente.
- Calificación operacional (OQ): se verifica que funciona como se diseñó, en todo su rango.
- Calificación de desempeño (PQ): se verifica que funciona de forma consistente en el entorno real.
El hilo que conecta ambos lados de la V es la matriz de trazabilidad: un requerimiento sin prueba, o una prueba sin requerimiento, es una señal de alerta para cualquier auditor.
El enfoque basado en riesgo
Validar cuesta tiempo y dinero, y no todos los sistemas —ni todas sus funciones— tienen el mismo impacto. Por eso GAMP 5 propone concentrar el esfuerzo donde el riesgo lo justifica: en las funciones que afectan la calidad del producto, la seguridad del paciente y la integridad de los datos.
Un análisis de riesgo bien hecho responde a tres preguntas: ¿qué puede fallar?, ¿qué tan grave sería?, ¿qué tan probable es que ocurra y que se detecte a tiempo? Con esas respuestas se decide la profundidad de las pruebas para cada función.
Validar «todo por igual» deja cientos de páginas sobre funciones triviales y poca profundidad justo donde el riesgo es alto.
Mantener el estado validado
La validación no termina cuando se firma el informe. Un sistema entra en estado validado y debe permanecer así mientras esté en uso. Esto exige un control de cambios formal: toda modificación —una actualización, un nuevo módulo, un cambio de configuración— se evalúa por su impacto y, si corresponde, se revalida la parte afectada.
Aquí es donde muchos sistemas «pierden» su validación sin que nadie lo note: se actualizan sin evaluar el impacto, y en la siguiente inspección la evidencia ya no refleja el sistema real. Un punto que la CSV tradicional a veces trata de forma superficial es la seguridad: un sistema puede estar perfectamente validado y, al mismo tiempo, ser vulnerable. Por eso tiene sentido abordar validación y ciberseguridad como dos caras de la misma moneda.
¿Necesitas validar un sistema o revisar si sigue en estado validado?
En SystemVal integramos validación GxP y ciberseguridad para que tus sistemas críticos sean confiables y auditables.
Agenda un diagnóstico