Validación de LIMS y CDS: riesgo, pruebas y autorización de uso

El proveedor entrega un paquete de pruebas completo, pero el laboratorio ha modificado el flujo de aprobación y conectado un instrumento nuevo. ¿Qué evidencias siguen siendo válidas? La respuesta exige comparar uso previsto, configuración real y cobertura de pruebas. La validación de LIMS y CDS debe apoyar una decisión documentada sobre la idoneidad del sistema del laboratorio para su uso.

1. Delimitar el sistema y las decisiones que apoya

Empieza por el proceso: recepción de muestras, adquisición, tratamiento, transferencia, revisión, aprobación y conservación. Identifica registros y metadatos, usuarios, instrumentos, interfaces y servicios necesarios. La distinción entre LIMS, CDS, ELN y SDMS ayuda a distribuir responsabilidades sin dejar pasos sin cubrir.

Registra versiones y configuraciones, módulos, reglas locales y dependencias de infraestructura. Define quién es responsable del proceso, mantiene el sistema, presta soporte técnico y aprueba evidencias según el sistema de calidad. Validar el software no sustituye la cualificación del instrumento ni la validación del método analítico: son actividades relacionadas, con objetos y pruebas diferentes.

Evalúa la aplicabilidad normativa según productos, actividades, registros y mercados. El Annex 11 se refiere a sistemas informatizados utilizados en actividades GMP; los requisitos estadounidenses aplicables no nacen de la mera presencia de un ordenador. La guía final FDA CSA de febrero de 2026 trata el software de producción y del sistema de gestión de calidad de dispositivos médicos: no elimina la CSV farmacéutica ni extiende automáticamente su ámbito a todos los LIMS.

2. Relacionar requisitos, riesgos y pruebas del proveedor

Redacta requisitos verificables: resultado o comportamiento necesario, condiciones y criterio de aceptación. Evalúa las consecuencias de resultados incorrectos, datos incompletos, aprobaciones no autorizadas o registros irrecuperables. La prioridad deriva del riesgo para producto, paciente e integridad de datos, no del número de pantallas.

Examina competencia y sistema de calidad del proveedor, documentación disponible, versiones probadas, entorno, cobertura y defectos conocidos. Para reutilizar una prueba, identifica el requisito cubierto, por qué la evidencia es fiable y si la configuración o dependencias locales pueden cambiar el resultado. Un certificado genérico o una declaración de conformidad no demuestra el flujo concreto del laboratorio.

Documenta qué puede aceptarse, complementarse o necesita verificación local. No es necesario repetir sin motivo cada prueba fiable; tampoco está justificado heredar un resultado porque coincida el nombre de la función. Configuraciones, código personalizado, interfaces y controles operativos pueden requerir comprobaciones distintas.

3. Construir una matriz que llegue a la decisión

Esta matriz original es un ejemplo adaptable al alcance. Cada prueba tiene datos y criterios predefinidos; compara el resultado real con el esperado, conserva las evidencias y gestiona diferencias. Las actividades se ejecutan en entornos autorizados con datos de prueba identificables.

No pruebes solo la ruta favorable. Comprueba errores, interrupciones y combinaciones plausibles que puedan causar una decisión incorrecta. En las interfaces, la comprobación debe alcanzar el significado de los datos en el destino: el mapeo y conciliación instrumentos–LIMS desarrolla este punto.

4. Resolver desviaciones y autorizar el uso

Registra las pruebas ejecutadas con requisito, versión, entorno, datos, ejecutante, resultado y referencia a evidencias. El volumen de capturas no mide la cobertura. Deben poder reconstruirse el comportamiento verificado y la razón por la que respalda la aceptación; las herramientas y el entorno de prueba también requieren evaluación de idoneidad.

Un incumplimiento del criterio no se vuelve aceptable al borrar la prueba o cambiar retrospectivamente lo esperado sin justificación. Documenta desviación, causa evaluada, impacto, corrección y comprobaciones posteriores. Vincula una repetición favorable al fallo inicial, sin eliminarlo.

Antes de autorizar el uso, revisa cobertura de requisitos, desviaciones y riesgos residuales, configuración final, procedimientos, formación, soporte, accesos y recuperación. La función autorizada identifica alcance aprobado, posibles restricciones y responsabilidades. Autorizar condicionalmente una fase posterior no permite automáticamente el uso rutinario de una función crítica no demostrada.

5. Caso simulado: el flujo personalizado cambia la cobertura

El paquete del proveedor demuestra que un revisor puede aprobar un resultado completo en el flujo estándar. El laboratorio añade una importación instrumental y un estado «pendiente de verificación». Durante una prueba local, un mensaje incompleto deja la unidad vacía, pero permite pasar al estado aprobado.

La prueba estándar sigue siendo útil para lo que demuestra; no cubre esta combinación. El equipo registra la desviación, comprueba reglas del nuevo estado e interfaz, corrige el comportamiento y prueba mensajes completos, incompletos y repetidos con los roles previstos. También comprueba que eventos, versión y decisiones sigan siendo reconstruibles. La autorización depende del resultado documentado, no del volumen del expediente del proveedor.

Durante la operación, cambios de configuración, versiones, interfaces, roles y uso previsto requieren evaluación de impacto y controles pertinentes. La evaluación periódica considera también incidentes, rendimiento, seguridad y recuperabilidad. Deben justificarse frecuencia y profundidad: la validación inicial no mantiene por sí sola el estado validado.

6. Fuentes y aplicabilidad

Fuentes verificadas el 2 de octubre de 2026. Contexto GMP de medicamentos de uso humano; matriz y escenario originales, sin pruebas sobre sistemas productivos.

• Comisión Europea — GMP Annex 11, revisión 1, enero de 2011, aplicable desde el 30 de junio de 2011, principio y §§1–4, 7, 9–14: validación, proveedores, pruebas y estado de control.
• Comisión Europea — GMP Annex 15, revisión de marzo de 2015, aplicable desde el 1 de octubre de 2015, principio y §§1–2: planificación, pruebas externas, desviaciones y autorizaciones; remite al Annex 11 para sistemas informatizados.
• FDA — Data Integrity and Compliance With Drug CGMP, versión final de diciembre de 2018, Q2–Q3: controles proporcionados y funciones validadas para el uso pertinente; guía no vinculante.
• FDA — Computer Software Assurance for Production and Quality Management System Software, versión final del 3 de febrero de 2026, secciones I y III: dispositivos médicos y 21 CFR Part 820; sustituye la versión de septiembre de 2025, no los requisitos GMP de medicamentos.