Validación de sistemas computarizados.

1. Qué significa validar un sistema computarizado

Validar no es llenar un protocolo. Validar es reunir evidencia documentada de que un sistema hace lo que se espera que haga, de forma consistente, y de que seguirá haciéndolo mientras esté en uso. La palabra clave es evidencia: no basta con que el sistema funcione, hay que poder demostrarlo años después ante alguien que no estuvo ahí.

El segundo matiz importante es el alcance. No se valida un software, se valida un sistema computarizado: el programa, el equipo sobre el que corre, la interfaz con el proceso, los procedimientos que dicen cómo se usa y las personas que lo operan. Un sistema perfectamente probado con un procedimiento que nadie sigue no está validado, está probado.

Lo que convierte esto en obligación regulatoria es el impacto. Si el sistema decide, registra o influye en algo que afecta la calidad del producto, la seguridad del paciente o la integridad de un dato que soporta esa calidad, entra al alcance GxP. Si no lo hace, es un sistema de negocio y se gestiona con las buenas prácticas de informática de la casa, no con un paquete de validación.

Tres confusiones que cuestan tiempo

• Validación no es calificación. La calificación (IQ, OQ, PQ) es una parte de la validación, la que genera evidencia de pruebas. La validación es todo el ciclo, desde el requisito hasta el retiro.
• Que el proveedor haya probado no te exime. El proveedor prueba su producto en general; tú respondes por tu uso concreto, con tu configuración, tus datos y tu proceso.
• Validar no es probar todo. Probar todo es imposible y además es mala señal: significa que no se analizó el riesgo y se está gastando el esfuerzo donde no importa.

A lo largo del curso vamos a volver sobre la misma idea: el esfuerzo de validación se reparte según el riesgo, y cada decisión de alcance tiene que quedar justificada por escrito. Esa justificación es, en la práctica, lo primero que pide un auditor.

2. El marco normativo: quién exige qué

Pocas áreas tienen tantos documentos de referencia como esta, y casi ninguno es una norma de obligatorio cumplimiento por sí mismo. Conviene tener claro quién dice qué y con qué peso.

Referencia	Quién la emite	Qué aporta
Anexo 11, BPM europeas	Comisión Europea	Requisitos exigibles para sistemas computarizados en BPM: gestión de riesgo, proveedores, datos, auditoría, firmas, continuidad
Anexo 15, BPM europeas	Comisión Europea	Marco de calificación y validación en el que se encajan las etapas del sistema
21 CFR Parte 11	FDA	Condiciones para que un registro y una firma electrónicos sean aceptables
GAMP 5, segunda edición	ISPE	Guía de buenas prácticas: categorías, ciclo de vida, enfoque por riesgo, pruebas
Validación de software asegurada (CSA)	FDA	Reequilibra el esfuerzo hacia el pensamiento crítico y la prueba útil, menos papel por el papel
ICH Q9 revisada	ICH	Gestión de riesgo de calidad, base metodológica del análisis
Guías de integridad de datos	OMS, PIC/S, MHRA	Expectativas sobre ALCOA+, pista de auditoría y revisión de registros
Resolución 1160 de 2016	Invima, Colombia	Manual de BPM aplicable localmente, con el que hay que amarrar lo anterior

La trampa habitual es citar GAMP 5 como si fuera una norma. GAMP 5 es una guía de la industria, excelente, pero lo exigible en una inspección europea es el Anexo 11, y en una estadounidense la parte 11 junto con las secciones de BPM que apliquen. GAMP es el cómo; el anexo es el qué.

La segunda edición de GAMP 5, publicada en 2022, incorpora lo que ya era inevitable: sistemas en la nube, desarrollo ágil, entrega continua, herramientas de automatización y servicios de terceros. Si tu procedimiento interno todavía describe un mundo de instaladores en CD y servidores propios, estás escribiendo protocolos para una realidad que ya no es la tuya.

3. Inventario de sistemas y evaluación de impacto

Todo empieza por una lista. Si no sabes cuántos sistemas tienes, no puedes decir que los tienes bajo control, y esa lista es de las primeras cosas que se piden en una inspección.

El inventario no es un listado de licencias de informática. Es el registro de los sistemas que participan en actividades reguladas, con lo mínimo que permita decidir qué hacer con cada uno:

• Nombre, versión y proveedor.
• Proceso al que sirve y área responsable.
• Dueño del sistema y dueño del proceso, con nombre y cargo.
• Si tiene impacto GxP, y por qué.
• Categoría GAMP asignada.
• Si genera, modifica o conserva registros electrónicos.
• Si usa firmas electrónicas.
• Estado de validación y fecha de la última revisión.

La evaluación de impacto

Para cada sistema se responde, por escrito y con firma, una pregunta sencilla de enunciar y difícil de contestar a la ligera: ¿una falla de este sistema puede afectar la calidad del producto, la seguridad del paciente o la integridad de un dato que sustenta esa calidad? Si la respuesta es sí, el sistema es GxP.

Hay casos de frontera que conviene resolver siempre igual, y dejarlo escrito en el procedimiento: un sistema de nómina no es GxP; uno de gestión de mantenimiento que registra la calibración de instrumentos críticos sí lo es; una hoja de cálculo que hace el cálculo de un resultado de liberación también, y es la que más veces se queda fuera del inventario.

Las hojas de cálculo merecen párrafo aparte porque son el punto ciego clásico. Si calcula, decide o conserva algo regulado, es un sistema computarizado y necesita su propio paquete, proporcional pero real: protección de fórmulas, control de versiones, verificación del cálculo y control de acceso.

4. Las categorías GAMP y el esfuerzo que implican

La clasificación por categorías sirve para una cosa: ajustar el esfuerzo al riesgo que trae el software en sí mismo. No es una etiqueta burocrática, es la primera decisión de alcance.

Categoría	Qué es	Ejemplos	Enfoque típico
1	Software de infraestructura	Sistema operativo, gestor de base de datos, antivirus	Se gestiona por calificación de la infraestructura, no por validación propia
3	Producto comercial usado tal como viene	Registrador de temperatura sin configuración, balanza con firmware fijo	Verificación del uso previsto contra la URS
4	Producto comercial configurado	Gestor documental, sistema de laboratorio, control de proceso parametrizado	Evaluación de proveedor y pruebas centradas en la configuración y los flujos propios
5	Desarrollo a la medida	Módulo propio, macro, interfaz programada, informe a medida	Ciclo completo con revisión de diseño y pruebas de todo lo desarrollado

La categoría 2 desapareció en la versión 5 de la guía; si la ves en un documento, ese documento viene de una edición anterior y probablemente arrastra otras cosas desactualizadas.

Un sistema real casi nunca es de una sola categoría. Un gestor de laboratorio es categoría 4 en su núcleo, pero el informe que alguien programó a la medida para liberar un lote es categoría 5 y se prueba como tal. Lo correcto es clasificar por componentes y dejarlo escrito en el plan, no forzar el sistema entero a una casilla.

Dicho esto, la categoría por sí sola no define el alcance de las pruebas. Define el punto de partida. Lo que termina de definirlo es el análisis de riesgo del capítulo seis.

5. El ciclo de vida: del concepto al retiro

El modelo en V sigue siendo la forma más clara de explicar la lógica de la validación: cada cosa que se especifica a la izquierda tiene a la derecha algo que la verifica. No es una metodología de proyecto, es una relación de trazabilidad.

Lo que cambió en los últimos años no es esa relación, sino la forma de recorrerla. Un proyecto ágil no baja la V una sola vez de arriba abajo: la recorre en ciclos cortos, por incrementos. La trazabilidad entre requisito y evidencia se mantiene igual de exigente; lo que cambia es el momento en que se produce.

Las etapas, con lo que entrega cada una

Etapa	Qué se hace	Qué queda
Concepto	Se define la necesidad y se evalúa si hay impacto GxP	Evaluación de impacto, caso de uso
Planificación	Se decide el alcance, el enfoque y quién responde por qué	Plan de validación
Especificación	Se escribe qué debe hacer el sistema y cómo lo hará	URS, especificación funcional y de configuración
Riesgo	Se identifican funciones críticas y se define el alcance de prueba	Análisis de riesgo con controles
Configuración	Se instala, configura o desarrolla	Registros de configuración, revisión de código si aplica
Verificación	Se ejecutan las pruebas planificadas	Protocolos ejecutados con evidencia
Informe y liberación	Se concluye y se autoriza el uso	Informe de validación firmado
Operación	Se mantiene el estado validado	Cambios, revisiones periódicas, respaldos
Retiro	Se saca de servicio conservando los datos	Plan de retiro y de migración o archivo

La etapa que más se descuida es la última. Un sistema se retira y nadie se preguntó dónde quedan los registros que, por norma, hay que conservar años. Eso se planifica antes de apagar el servidor, no después.

6. Análisis de riesgo: decidir dónde se prueba

Este es el capítulo que separa una validación útil de una pila de papel. El análisis de riesgo no está para justificar lo que ya decidiste: está para decidir.

El recorrido es siempre el mismo. Se parte de las funciones del sistema, no de sus módulos. Para cada función se pregunta si su falla puede afectar al producto, al dato o al paciente. Las que sí pueden se evalúan por severidad, probabilidad y detección, y de ahí sale el nivel de riesgo que define cómo se prueba y con qué evidencia.

Cómo se traduce el riesgo en prueba

Nivel	Tipo de verificación	Evidencia
Alto	Prueba con guión detallado, paso a paso, con resultado esperado escrito antes	Capturas, impresiones, registro firmado y fechado, revisión independiente
Medio	Prueba con guión resumido, centrada en el resultado	Registro del resultado y de las desviaciones
Bajo	Prueba exploratoria o verificación de uso	Anotación del responsable, sin captura por cada clic

Esta tabla es, en esencia, el aporte práctico del enfoque CSA: no aplicar el mismo rigor a todo. Capturar pantalla de cada campo de una función de bajo riesgo no agrega seguridad, agrega horas y un archivo que nadie vuelve a abrir.

Tres errores que se repiten:

• Analizar riesgo por módulo en vez de por función. El módulo no falla, falla lo que hace.
• Puntuar sin criterio definido. Si la escala de severidad no está descrita en el procedimiento, cada analista puntuará distinto y el resultado no es defendible.
• Terminar el análisis y no conectarlo con nada. El riesgo alto debe aparecer después en un caso de prueba concreto; si no aparece, el análisis fue decorativo.

El control que mitiga un riesgo no siempre es una prueba. Puede ser un perfil de acceso, una alarma, una verificación por segunda persona o un paso del procedimiento. Lo que no puede es quedarse sin registrar.

7. La URS: el documento del que cuelga todo

Si la URS está mal escrita, el resto del paquete hereda el problema. No hay análisis de riesgo que arregle un requisito ambiguo, ni protocolo que pueda verificar algo que no se definió.

Un requisito sirve si cumple cuatro condiciones: es verificable, es atribuible a alguien, es único y está escrito en términos de necesidad, no de solución. Comparemos:

Así no	Así sí
El sistema debe ser seguro	El sistema debe exigir usuario y contraseña individuales, bloquear la cuenta tras cinco intentos fallidos y cerrar la sesión por inactividad a los 15 minutos
El sistema debe tener trazabilidad	El sistema debe registrar en una pista de auditoría no editable el valor anterior, el valor nuevo, el usuario, la fecha y hora y el motivo de cada cambio sobre un dato liberado
El sistema debe generar reportes	El sistema debe generar un reporte de lote con los parámetros críticos registrados, exportable a PDF, con sello de fecha y hora de generación
Debe usar base de datos Oracle	El sistema debe conservar los registros durante al menos diez años y permitir su consulta íntegra durante ese periodo

Ese último par ilustra el error más común: meter la solución técnica en el requisito. La URS dice qué necesita el usuario; cómo se resuelve es asunto de la especificación funcional y del proveedor.

Qué debe cubrir

• Funciones del proceso que el sistema debe soportar.
• Datos que registra, calcula o conserva, con sus unidades y rangos.
• Requisitos de integridad de datos: pista de auditoría, firmas, perfiles, respaldo.
• Interfaces con otros sistemas y con equipos.
• Desempeño: volúmenes, tiempos de respuesta, usuarios concurrentes.
• Entorno: infraestructura, disponibilidad, recuperación ante fallas.
• Requisitos regulatorios aplicables, citados por su fuente.
• Requisitos de documentación, soporte y formación.

Cada requisito lleva un identificador único. Ese identificador es el que después viaja a la matriz de trazabilidad y permite demostrar, en una sola tabla, que todo lo que se pidió se verificó.

8. Proveedores: qué evaluar y qué aprovechar

El Anexo 11 lo pide explícitamente: hay que evaluar al proveedor en función del riesgo. Lo que no dice es que haya que auditar a todos en sitio, y ahí es donde se desperdicia esfuerzo.

Situación	Profundidad razonable
Software de infraestructura, categoría 1	Ninguna evaluación formal; se gestiona por la calificación de infraestructura
Producto estándar, bajo impacto	Cuestionario y revisión documental
Producto configurado, alto impacto	Cuestionario, revisión del sistema de calidad del proveedor y, según resultado, auditoría remota
Desarrollo a la medida o servicio en la nube crítico	Auditoría, acuerdo técnico y revisión periódica

La pregunta práctica es qué se puede aprovechar de lo que el proveedor ya hizo. La respuesta corta: bastante, si su documentación es rastreable y su sistema de calidad resiste la revisión. Las pruebas de fabricación del proveedor pueden sustituir parte de la calificación de instalación y operación cuando la evaluación lo respalda, la decisión queda documentada y las pruebas cubren realmente tu configuración.

Lo que no se puede delegar nunca: la verificación de que el sistema cumple tu URS en tu entorno. El proveedor no conoce tu proceso, tus perfiles de usuario ni tus interfaces.

Lo específico de la nube

Con un servicio en la nube cambian tres cosas: no controlas la infraestructura, no controlas el calendario de actualizaciones y los datos están en manos de un tercero. Eso se compensa con acuerdo técnico escrito, derecho de auditoría, notificación previa de cambios, compromisos de disponibilidad y una salida clara: cómo recuperas tus datos, en qué formato, si decides irte.

9. Calificación y pruebas en el enfoque actual

IQ, OQ y PQ siguen siendo la estructura más usada y la que entiende cualquier auditor. Lo que cambió es cómo se llenan.

Etapa	Qué demuestra	Ejemplos de prueba
Instalación	Que el sistema está instalado como se especificó, en el entorno correcto	Versión instalada, componentes, parámetros de servidor, conexiones, documentación recibida
Operacional	Que las funciones se comportan como dice la especificación, incluidos los casos límite	Perfiles y permisos, cálculos, alarmas, pista de auditoría, rangos y valores fuera de rango, recuperación tras corte
Desempeño	Que en uso real, con los procedimientos y las personas de la planta, el sistema cumple su propósito	Flujo completo de un lote, carga de usuarios, tiempos de respuesta, interfaz con el equipo

Cómo se escribe un caso de prueba

Un caso de prueba útil tiene siempre las mismas partes: identificador, requisito que verifica, precondiciones, pasos numerados, resultado esperado escrito antes de ejecutar, espacio para el resultado obtenido, veredicto y firma con fecha. El resultado esperado escrito después no es una prueba, es una descripción.

Sobre las desviaciones durante la ejecución: aparecen, es normal, y esconderlas es lo único que no se puede hacer. Se registran con su número, se clasifica el impacto, se resuelve, se vuelve a probar lo afectado y se cierra en el informe. Un paquete de validación sin una sola desviación levanta más sospecha que uno con quince bien gestionadas.

Qué aporta el enfoque CSA

La propuesta de la FDA no es probar menos, es pensar más antes de probar. Empuja a dedicar el esfuerzo a las funciones que afectan al paciente y al producto, a aceptar pruebas no guionizadas y exploratorias donde el riesgo es bajo, a aprovechar lo que hizo el proveedor y a reducir la evidencia ritual: la captura de pantalla que no demuestra nada que el registro ya no demuestre.

10. Integridad de datos, Anexo 11 y parte 11

Un sistema puede estar impecablemente probado y fallar en lo que hoy más se inspecciona: si sus datos son confiables.

ALCOA+ resume las propiedades que debe tener un registro regulado: atribuible, legible, contemporáneo, original y exacto; y además completo, consistente, perdurable y disponible. Cada una de esas palabras se traduce en una función concreta del sistema, y esa función se verifica.

Propiedad	Qué se revisa en el sistema
Atribuible	Usuarios individuales, sin cuentas compartidas ni genéricas
Legible	Registros consultables sin herramientas propietarias obsoletas
Contemporáneo	Fecha y hora del sistema sincronizadas y no modificables por el usuario
Original	El dato primario se conserva; si se trabaja con copia, está declarada como copia verdadera
Exacto	Cálculos verificados, sin transcripciones manuales evitables
Completo	Los reprocesos y los datos descartados también quedan, con su motivo
Consistente	Secuencia de eventos coherente, sin huecos
Perdurable	Respaldo probado con restauración, no solo programado
Disponible	Recuperable durante todo el periodo de retención

Pista de auditoría

Tiene que ser automática, no desactivable por el usuario, y debe registrar quién, qué, cuándo, valor anterior, valor nuevo y motivo cuando aplique. Y hay una parte que casi nunca está resuelta: la revisión de esa pista. Tener el registro no basta; alguien debe revisarlo con una frecuencia definida, dejando constancia de que lo hizo. Si no hay procedimiento que diga quién, cada cuánto y qué busca, la pista es un archivo que nadie abre.

Firmas electrónicas

Para que una firma electrónica sea aceptable debe estar vinculada de forma inseparable a su registro, identificar inequívocamente al firmante, mostrar el significado de la firma (revisado, aprobado, ejecutado) con su fecha y hora, y no poder transferirse a otra persona. Además se necesita el soporte alrededor: política de contraseñas, formación registrada y, donde lo exija la parte 11, la declaración ante la autoridad de que la firma electrónica equivale a la manuscrita.

11. Informe, trazabilidad y liberación

El informe de validación es el documento que alguien va a leer dentro de tres años para entender qué se hizo. Escríbelo pensando en esa persona, no en cerrar el proyecto.

Debe contener, como mínimo: qué se validó y con qué alcance, qué se ejecutó y con qué resultado, las desviaciones con su tratamiento y cierre, las limitaciones y restricciones de uso que quedan vigentes, las acciones pendientes con responsable y fecha, y la conclusión sobre si el sistema es apto para el uso previsto, firmada por quien tiene la autoridad para decirlo.

La matriz de trazabilidad

Es la tabla que conecta cada requisito de la URS con la especificación que lo desarrolla, el riesgo asociado y el caso de prueba que lo verificó, con su resultado. Suele ser lo primero que pide un auditor porque en una sola hoja se ve si el paquete es coherente o si hay requisitos que nadie verificó.

Requisito	Especificación	Riesgo	Prueba	Resultado
URS-014 Pista de auditoría no editable	FS-008	Alto	OQ-021	Conforme
URS-015 Bloqueo tras cinco intentos	FS-009	Medio	OQ-022	Conforme
URS-031 Exportación del reporte de lote	FS-017	Medio	PQ-006	Conforme con desviación DV-03 cerrada

La liberación para uso es un acto formal y con fecha: antes de ella el sistema no se usa para actividades reguladas. Y debe venir acompañada de lo que hace que el sistema funcione de verdad: procedimientos operativos aprobados, personal formado con registro, y respaldo y recuperación probados.

12. Mantener el estado validado

La validación no termina con la firma del informe. Empieza ahí la parte larga, que es conservar esa condición mientras el sistema esté en uso.

Control de cambios

Todo cambio sobre un sistema validado pasa por evaluación previa: una actualización de versión, un parámetro de configuración, un perfil nuevo, un informe modificado, un cambio en la infraestructura que lo soporta. La evaluación determina el impacto y, con él, qué hay que volver a probar. Rara vez es todo; casi nunca es nada.

Tipo de cambio	Verificación habitual
Parche de seguridad sin cambio funcional	Verificación de instalación y prueba de regresión reducida
Cambio de configuración de una función crítica	Prueba de la función afectada y de sus interfaces
Actualización mayor de versión	Evaluación de impacto completa y recalificación parcial o total
Nuevo informe a la medida	Verificación del informe contra el dato de origen

Revisión periódica

Con una frecuencia definida según el riesgo, se revisa que el sistema siga en control: cambios del periodo, incidencias, desviaciones, estado de respaldos y restauraciones, vigencia de usuarios y perfiles, versiones soportadas por el proveedor y vigencia de la documentación. El resultado se firma y, si aparecen hallazgos, se abren acciones con responsable y fecha.

Continuidad y retiro

El plan de continuidad describe cómo sigue operando el proceso si el sistema cae, y esa alternativa manual tiene que estar probada, no solo escrita. El retiro, por su parte, se planifica: qué datos se conservan, dónde, en qué formato legible, por cuánto tiempo y cómo se verifica que la migración no alteró nada. Una migración de datos es, por sí sola, una actividad que se valida.

Con esto cierra el recorrido: inventario, marco, riesgo, especificación, prueba, datos, informe y mantenimiento. Si el examen te sale bien, es porque estos doce capítulos quedaron conectados entre sí, que es justamente como funcionan en una planta.