Validar para confiar

01 / PERSPECTIVA Y APLICACIÓN

Una decisión estratégica de calidad

Una organización farmacéutica toma decisiones a partir de resultados, especificaciones, cálculos y aprobaciones. Cuando estos elementos pasan por un sistema computarizado, la calidad de la decisión depende también de su configuración, de sus interfaces y de las personas que lo operan. Mi punto de partida es identificar esa dependencia antes de hablar de formatos o de cantidad de pruebas.

Una hoja de cálculo puede transformar un resultado analítico; un sistema de laboratorio puede asociarlo a una muestra; una aplicación de producción puede presentar la información para una revisión. Un error de unidades, una fórmula modificada o una transferencia incompleta merecen atención por sus consecuencias, aunque la pantalla parezca funcionar correctamente.

Propongo evaluar la inversión en validación frente al trabajo que permite evitar: investigar resultados poco confiables, reconstruir registros, repetir actividades y gestionar interrupciones. No atribuyo a la validación un ahorro porcentual universal. Cada organización debe establecer su línea base y medir el efecto de los controles sobre sus propios incidentes y tiempos de recuperación.

El uso previsto debe poder explicarse en lenguaje del proceso: quién utiliza el sistema, para qué decisión, con qué datos y bajo qué condiciones. Esa definición permite asignar un dueño del proceso, un responsable técnico y una función de calidad con autoridad para aceptar o cuestionar la evidencia.

• Priorizar las funciones cuyo fallo pueda afectar al paciente, al producto o a un registro crítico.
• Acordar requisitos y criterios de aceptación antes de ejecutar las pruebas.
• Dar a calidad, usuarios y tecnología responsabilidades explícitas durante todo el proyecto.

02 / PERSPECTIVA Y APLICACIÓN

GAMP 5 y Parte 11: funciones distintas

GAMP 5, segunda edición, es una guía de buenas prácticas de ISPE para sistemas computarizados GxP. Su enfoque basado en riesgos y pensamiento crítico ayuda a adaptar el trabajo al uso previsto; no es una ley ni una certificación del software. La edición de 2022 contempla proveedores, desarrollo iterativo y tecnologías emergentes. [1]

21 CFR Parte 11 es una regulación de Estados Unidos sobre registros y firmas electrónicas dentro de su alcance. La evaluación comienza con los registros exigidos por normas FDA aplicables y con la forma en que se crean, conservan o presentan. Usar un computador, por sí solo, no establece que toda su información quede sometida a Parte 11. [2, 3]

Para sistemas cerrados, §11.10 recoge controles sobre validación, copias completas, conservación, acceso autorizado y pistas de auditoría, entre otros. Los apartados §11.50 y §11.70 tratan la manifestación de la firma y su vínculo con el registro; §§11.100, 11.200 y 11.300 añaden requisitos de firmas, identificación y contraseñas. Los sistemas abiertos requieren considerar también §11.30. [2]

La guía FDA de alcance y aplicación describe una interpretación acotada y discreción de aplicación para determinados requisitos de Parte 11. También señala que las obligaciones de las normas subyacentes siguen vigentes. Por eso recomiendo documentar la aplicabilidad y sus justificaciones con calidad y asuntos regulatorios, en vez de utilizar una lista universal de controles. [3]

• Guía de trabajo: definir cómo organizar el aseguramiento del sistema.
• Evaluación regulatoria: identificar qué registros, firmas y obligaciones aplican.
• Evidencia del proyecto: mostrar cómo se verifican los requisitos acordados.

03 / PERSPECTIVA Y APLICACIÓN

Del riesgo a una prueba que aporta valor

Propongo que cada prueba responda a una pregunta concreta del proceso. Considérese un ejemplo ilustrativo: una hoja de cálculo recibe concentraciones de laboratorio, aplica un factor de dilución y compara el resultado con una especificación. El propósito de la validación es demostrar que esa secuencia funciona bajo las condiciones autorizadas y que los fallos relevantes se detectan.

El equipo comienza por fijar las unidades, las reglas de redondeo, los límites y el origen de los datos. Después identifica fallos posibles: factor vacío, unidad incompatible, fórmula sobrescrita, valor exactamente en el límite o uso de una versión anterior. Para cada riesgo acuerda un control y una forma de comprobarlo, incluyendo resultados esperados calculados de manera independiente.

La protección de celdas es un control útil, pero no debe confundirse con una arquitectura completa de registros electrónicos. Si la hoja participa en un proceso sujeto a Parte 11, se necesita evaluar el entorno que conserva los archivos, administra identidades, registra cambios y controla aprobaciones. Las funciones disponibles y los procedimientos asociados se comprueban en conjunto.

En este ejemplo, un paquete de evidencia puede incluir requisitos aprobados, evaluación de riesgos, versión de la hoja, cálculos de referencia, resultados de pruebas, incidencias y decisión de aceptación. La trazabilidad debe permitir seguir una necesidad hasta su comprobación sin obligar al revisor a reconstruir el razonamiento del equipo.

El ejemplo describe una propuesta de trabajo, no resultados de un cliente. La selección definitiva de pruebas dependerá de la complejidad, el uso previsto, el entorno y las obligaciones identificadas.

• Probar valores normales, límites y entradas inválidas con criterios previos.
• Verificar roles, transferencias y recuperación donde el riesgo lo justifique.
• Investigar las desviaciones y registrar la justificación de la decisión final.

04 / PERSPECTIVA Y APLICACIÓN

Sostener la confianza después de la entrega

Mi recomendación es tratar la puesta en producción como una transición a la operación controlada. Antes de liberar el sistema, los responsables deberían conocer las limitaciones pendientes, disponer de procedimientos utilizables y haber practicado las tareas que sostienen la calidad de sus datos. La decisión de aceptación necesita un responsable y una justificación localizable.

Para iniciar un programa, propongo una secuencia en cuatro etapas. Primero, inventariar sistemas y registros, asignar propietarios y priorizar riesgos. Segundo, contrastar el estado actual con los requisitos acordados y definir qué evidencia existe. Tercero, cerrar brechas mediante controles y verificaciones. Cuarto, establecer revisiones y seguimiento. El calendario depende del alcance; estas etapas no presuponen una duración fija.

En operación, cada cambio debe evaluarse por su impacto: configuración, versión, interfaz, infraestructura, datos o procedimiento. La evaluación determina qué volver a comprobar y qué documentación actualizar. Las actualizaciones del proveedor merecen la misma atención cuando afectan al uso autorizado, incluso si se entregan como parte de un servicio en la nube.

Para la dirección propongo pocos indicadores con significado operativo: requisitos críticos con evidencia aceptada, desviaciones abiertas por impacto, cambios pendientes de evaluación y resultados de ejercicios de recuperación. Un porcentaje de pruebas ejecutadas, sin contexto de riesgo, puede ocultar brechas relevantes.

También conviene planear el retiro: qué registros se conservarán, cómo podrán leerse y quién responderá por ellos. Mi conclusión es que validar crea valor cuando une decisiones, responsabilidades y evidencia a lo largo de la vida del sistema. Esa disciplina permite incorporar nuevas tecnologías con un criterio de aceptación más claro.

• Designar responsables de cambios, incidencias, accesos y revisión periódica.
• Comprobar la recuperación de información; no limitarse a registrar que existe un respaldo.
• Usar indicadores para decidir acciones y prioridades, con seguimiento de su cierre.