Validación de eQMS: un enfoque basado en riesgos para equipos de calidad pequeños

Ha comprado, o está a punto de comprar, un sistema electrónico de gestión de calidad y alguien le ha pedido el plan de validación. El equipo de calidad está formado por tres personas. La última validación de un sistema informático que alguien de aquí vio fue una carpeta de anillas llena de capturas de pantalla de un instrumento de laboratorio, y nadie quiere repetirlo para un sistema que contendrá todos los PNT, CAPA y registros de formación que tienen. Este artículo presenta un enfoque proporcional para validar un eQMS: qué exigen realmente el Anexo 11 de las GMP de la UE y la cláusula 4.1.6 de ISO 13485, cómo GAMP 5 segunda edición y el enfoque de aseguramiento de software informático reducen el trabajo, hasta qué punto puede confiar en las pruebas del proveedor, qué diferencia supone la configuración frente a la personalización, qué debería probar por su cuenta y cómo mantener el sistema validado una vez que esté en funcionamiento.

Qué exigen realmente los requisitos

Para los fabricantes de productos sanitarios, la cláusula 4.1.6 de ISO 13485:2016 exige procedimientos documentados para validar las aplicaciones de software informático utilizadas en el sistema de gestión de la calidad. La validación se realiza antes del primer uso y, según corresponda, después de cambios en el software o en su aplicación; además, el enfoque debe ser proporcional al riesgo asociado al uso del software. Se conservan registros del trabajo. El informe técnico ISO/TR 80002-2:2017 ofrece orientación específica sobre la validación de software utilizado en sistemas de calidad de productos sanitarios y merece la pena consultarlo si desea un marco práctico.

Para los medicamentos, el Anexo 11 de las GMP de la UE se aplica a todos los sistemas informatizados utilizados en actividades reguladas por las GMP. La sección 1 exige una gestión de riesgos a lo largo del ciclo de vida del sistema, cuyo alcance de validación se base en una evaluación de riesgos justificada y documentada. La sección 4 trata la validación: requisitos de usuario basados en el riesgo y el impacto en las GMP, con trazabilidad a lo largo del ciclo de vida (4.4); evaluación del proveedor (4.5); y evidencia de métodos y escenarios de prueba adecuados (4.7). La sección 3 trata los acuerdos formales con los proveedores y la sección 11, la evaluación periódica. En 2025 se sometió a consulta pública una versión revisada del Anexo 11; en el momento de redactar este artículo, el texto de 2011 sigue siendo la versión publicada en la página EudraLex de la Comisión, así que planifique conforme a ella y esté atento a la nueva versión.

Ninguno de los dos textos le pide que pruebe todos los botones. Ambos le piden que comprenda qué hace el sistema en sus procesos, determine qué podría salir mal y concentre ahí sus esfuerzos. ICH Q9(R1) plantea lo mismo en términos generales: el esfuerzo, la formalidad y la documentación de la gestión de riesgos para la calidad deben corresponder al nivel de riesgo.

GAMP 5 segunda edición y aseguramiento de software informático en la práctica

ISPE publicó la segunda edición de GAMP 5 en julio de 2022. Sus categorías de software siguen siendo útiles: la mayoría de los productos eQMS son software configurado (categoría 4), y todo lo que se desarrolle específicamente para usted es software personalizado (categoría 5). Los cambios más importantes están en el énfasis. La segunda edición promueve el pensamiento crítico por parte de personas que entienden el proceso, espera que las empresas reguladas aprovechen plenamente los conocimientos, las pruebas y la documentación del proveedor, y respalda el desarrollo iterativo y los servicios en la nube.

El aseguramiento de software informático (CSA) impulsa el mismo enfoque. La FDA de EE. UU. lo presentó en unas directrices finalizadas en septiembre de 2025 y actualizadas en febrero de 2026. Aunque se trata de un documento estadounidense, sus cuatro pasos constituyen una estructura sólida para cualquier equipo pequeño. Identifique el uso previsto de cada función. Determine si un fallo de esa función supondría un riesgo elevado para el proceso. Elija actividades de aseguramiento acordes con el riesgo: pruebas con guiones detallados y resultados esperados cuando el riesgo sea alto, y métodos no guionizados, como pruebas exploratorias o basadas en la búsqueda de errores, cuando no lo sea. Conserve registros suficientes para demostrar que el trabajo se realizó, y nada más.

En conjunto, estos enfoques le permiten dejar de generar evidencias que nadie utiliza. No le permiten dejar de pensar.

Empiece por el uso previsto

Redacte una página que indique para qué se utiliza el eQMS en sus instalaciones. Qué procesos gestiona (control de documentos, formación, desviaciones, CAPA, auditorías internas), cuáles no (liberación de lotes, notificación de reclamaciones a las autoridades, por ejemplo), quién lo utiliza y qué registros que contiene son registros GMP o registros de ISO 13485. Añada el sistema a su inventario de sistemas informatizados, que el Anexo 11, apartado 4.3, espera que mantenga actualizado.

A continuación, redacte los requisitos de usuario en función de sus propios procesos y con sus propias palabras. «Una revisión de un PNT entra en vigor en su fecha de entrada en vigor y la revisión anterior se retira del uso en esa misma fecha» es un requisito que puede probar. «El sistema debe permitir el control de documentos» no lo es. En una empresa pequeña, unas pocas docenas de requisitos suelen bastar para cubrir un eQMS. Asigne un nivel de riesgo a cada uno: ¿podría un fallo afectar a la calidad del producto, la seguridad del paciente o la integridad de un registro GMP? La mayoría serán de riesgo bajo. Los que no lo sean, como la transición en la fecha de entrada en vigor, las firmas electrónicas, el registro de auditoría, los permisos por rol y la asignación de formación cuando se revisa un documento, son los que debe probar usted mismo.

Evaluar al proveedor y confiar en sus pruebas

El Anexo 11 establece que la competencia y fiabilidad de un proveedor son factores clave, que la necesidad de una auditoría debe basarse en el riesgo (3.2) y que la información sobre el sistema de calidad y las auditorías de los proveedores debe estar disponible para los inspectores cuando la soliciten (3.4). Para la mayoría de las empresas pequeñas que compran un sistema en la nube configurable, una evaluación remota basada en un cuestionario y documentos es proporcional; una auditoría presencial se justifica cuando las respuestas suscitan dudas.

Solicite una descripción de su ciclo de vida de desarrollo y sistema de calidad, sus procesos de lanzamiento y notificación de cambios, un resumen de sus propias pruebas de las funciones básicas, información sobre el funcionamiento del registro de auditoría y las firmas electrónicas, dónde se alojan los datos, cómo se prueban las copias de seguridad y las restauraciones, y cuál es su proceso de salida y exportación. Nuestra lista de comprobación para compradores de eQMS incluye la lista completa de preguntas.

Ahora, el límite. Las directrices de la MHRA sobre integridad de datos GxP (sección 6.19) establecen que no es aceptable aceptar datos de validación proporcionados por el proveedor sin considerar la configuración del sistema y el uso previsto por el usuario, ya que las pruebas del proveedor fuera de su proceso probablemente solo constituyan una verificación funcional. Las pruebas del proveedor pueden cubrir el producto básico: el motor del registro de auditoría registra los cambios, las firmas quedan vinculadas a los registros y los permisos se aplican según la configuración. Sus pruebas cubren su configuración dentro de sus procesos. Documente esta división en una breve declaración de confianza en las pruebas del proveedor, indicando los documentos del proveedor que revisó y las conclusiones a las que llegó.

Configuración frente a personalización

La configuración consiste en preparar el producto con las herramientas que ofrece: flujos de trabajo, rutas de aprobación, roles, esquemas de numeración, campos de formularios y reglas de formación. La personalización consiste en escribir o modificar código para usted. La diferencia tiene una gran repercusión en el esfuerzo de validación.

La configuración se prueba frente a sus requisitos. Si su ruta de aprobación de PNT tiene dos revisores y un aprobador de QA, pruebe esa ruta, incluido lo que ocurre cuando un revisor rechaza el documento. La personalización incorpora la categoría 5, con el diseño, la revisión del código y las pruebas que esto implica, y debe volver a probarse cada vez que el proveedor publica una nueva versión. Para un equipo pequeño, la estrategia de validación menos costosa consiste en configurar el sistema para adaptarlo a sus procesos y cambiar los procesos cuando entren en conflicto con el producto. Justifique por escrito cada solicitud de personalización.

Mantenga también bajo control la configuración. La sección 10 del Anexo 11 exige que los cambios en la configuración sigan un procedimiento definido, así que registre la configuración de referencia al poner el sistema en funcionamiento y gestione los cambios posteriores mediante el control de cambios con una evaluación del impacto.

Qué debe probar por su cuenta

Concentre las pruebas guionizadas en las funciones en las que un fallo podría dañar los registros o permitir que un documento incorrecto llegase a producción. Una distribución habitual para un eQMS sería la siguiente:

Las pruebas exploratorias también deben documentarse: quién las realizó, cuándo, en qué área, qué probó y qué encontró. Media página por sesión es suficiente. La migración de datos requiere una comprobación propia, ya que el apartado 4.8 del Anexo 11 exige que los datos migrados no cambien de valor ni de significado.

Finalice con un informe resumido de validación que enumere los requisitos, las evidencias de cada uno (sus pruebas, las evidencias del proveedor o ambas), las desviaciones detectadas durante las pruebas y cómo se resolvieron (Anexo 11, apartado 4.2), y una declaración clara de que el sistema es apto para el uso previsto.

Cómo mantener el sistema validado

Un eQMS en la nube cambia varias veces al año. Redacte un procedimiento breve para las versiones: cómo se entera de ellas, quién lee las notas de la versión, cómo se evalúa el impacto frente a sus requisitos y cuándo un cambio hace necesaria la repetición de pruebas. Un cambio en la lógica de firma o aprobación requiere una repetición específica de las pruebas. Un nuevo diseño de informe, no.

La sección 11 del Anexo 11 espera una evaluación periódica que confirme que el sistema permanece en un estado validado y que examine la funcionalidad, las desviaciones, los incidentes, el historial de actualizaciones, el rendimiento, la seguridad y el estado de validación. En una empresa pequeña, basta con una revisión anual de una o dos páginas: qué cambió, qué salió mal, si los accesos de los usuarios siguen siendo adecuados, si se comprobó la restauración de una copia de seguridad y si el paquete de validación sigue correspondiéndose con el uso del sistema. Aproveche también para revisar el registro de auditoría de una muestra de registros.

Mantener la proporcionalidad

Un paquete de validación de eQMS defendible para un fabricante pequeño cabe en una sola carpeta: uso previsto, requisitos con evaluación de riesgos, evaluación del proveedor y declaración de confianza en sus pruebas, configuración de referencia, sus guiones de prueba y registros de pruebas exploratorias, un informe resumido y un procedimiento para las versiones y la revisión periódica. Un inspector lo leerá en una hora. Si el suyo es mucho más extenso, pregúntese qué partes se utilizaron para tomar una decisión.

En resumen

Valide la configuración que creó para el proceso que lleva a cabo, confíe en el proveedor para el producto básico una vez que haya comprobado sus evidencias y mantenga el sistema validado mediante la evaluación de las versiones y una revisión anual.

Si ahora está definiendo el alcance de ese trabajo, la página de la plataforma InnoQualis describe los módulos de control de documentos, formación, desviaciones, CAPA y auditorías que validaría, con firmas electrónicas diseñadas para respaldar 21 CFR Part 11 y el Anexo 11 de las GMP de la UE, y un registro de auditoría de solo anexado.