El software de un Environmental Monitoring System es la parte que produce el registro y, por tanto, aquella sobre la que se concentra la mayoría de las preguntas en inspección. Quién puede modificar un límite, quién puede invalidar un dato, cómo se demuestra que un valor no ha sido alterado, quién revisa el audit trail y con qué criterio, dónde están los datos de hace cinco años y quién puede leerlos todavía: son preguntas sobre la configuración y la gestión del software, no sobre la calidad de los equipos de medida.
La regla de fondo es que la integridad de datos se diseña, no se añade. Roles, permisos, trazabilidad y conservación se definen antes de la configuración: una vez el sistema está en operación, toda corrección estructural exige change control, re-verificación y a menudo intervenciones sobre datos ya producidos. La segunda regla es distinguir con precisión qué es un requisito regulatorio aplicable al propio contexto y qué es una decisión de empresa: confundir ambos planos lleva a gastar donde no hace falta y a descubrir lagunas donde sí habría hecho falta.
Por qué el software es el punto más expuesto del sistema
Un sistema de monitorización ambiental informatizado concentra tres funciones que, en papel, estarían separadas: adquiere el dato, lo procesa y lo conserva, y permite su revisión. Quien controla el software controla, potencialmente, las tres. Es esa concentración la que hace necesarios los controles sobre accesos, segregación de funciones y trazabilidad de las modificaciones.
La segunda razón es la duración. Los equipos se sustituyen; los datos permanecen durante todo el periodo de conservación aplicable y deben seguir siendo legibles y reconstruibles incluso cuando el sistema que los generó ya no existe. Las decisiones que se toman hoy sobre formatos, exportabilidad y archivo determinan si dentro de años será posible responder a una pregunta sobre un lote fabricado hoy.
El marco regulatorio: qué se aplica realmente
| Nivel | Qué establece respecto al software EMS |
|---|---|
| Requisito regulatorio (EudraLex Volume 4, Annex 11 — revisión de enero de 2011) | Es la versión aplicable. Se aplica a los sistemas informatizados empleados en actividades GMP y fija expectativas sobre validación, gestión de proveedores, seguridad y gestión de accesos, audit trail, control de cambios, backup y archivo, gestión de incidencias, continuidad y evaluación periódica. |
| Texto en consulta (revisión del Annex 11 en curso) | No es un requisito vigente. Puede tenerse en cuenta para orientar decisiones de diseño duraderas, siempre que se declare explícitamente como elemento prospectivo. Nunca debe usarse como criterio de aceptación en cualificación ni citarse como obligación. |
| Requisito regulatorio (21 CFR Part 11, FDA) | Se aplica a los registros y firmas electrónicos en el ámbito de los productos regulados por la FDA y sus predicate rules. Su aplicabilidad al propio sistema debe determinarse y documentarse: no es automática para una planta que no suministra al mercado estadounidense. |
| Requisito regulatorio (EudraLex Volume 4, Annex 15) | Define el marco de la cualificación y la validación, aplicable también al componente informatizado. |
| Expectativa / guidance (guidance PIC/S sobre integridad de datos, guidance de las autoridades, ICH Q9(R1)) | Aclaran las expectativas sobre completitud, atribuibilidad, legibilidad, contemporaneidad, originalidad y exactitud de los datos, y sobre el enfoque basado en el riesgo en su gestión. |
| Buena práctica del sector | Modelos de categorización del software y enfoques estructurados de validación de sistemas informatizados extendidos en el sector. Son metodologías reconocidas, no prescripciones regulatorias. |
| Recomendación operativa GuideGxP | Redactar una evaluación de aplicabilidad escrita — qué requisitos se aplican al sistema, por qué, y cuáles no — aprobada antes de la configuración. Es el documento que hace defendible cada decisión posterior. |
Guía técnica
Roles de usuario y segregation of duties
La matriz de roles se define antes de la configuración, no se hereda de los perfiles predeterminados del proveedor. Los principios:
- Identificación unívoca: cada usuario tiene credenciales personales y no compartidas; las cuentas genéricas de departamento están entre las observaciones más comunes.
- Mínimo privilegio: cada rol dispone solo de los permisos necesarios para su función.
- Separación de funciones: quien configura el sistema no debería ser la misma persona que revisa los registros producidos; quien opera no debería poder modificar los parámetros que gobiernan su propio trabajo.
- Administración del sistema: los privilegios administrativos se asignan a un número reducido de personas, preferiblemente ajenas a la función que usa operativamente el sistema, con actividad registrada.
- Ciclo de vida de las cuentas: creación, modificación, suspensión y desactivación siguen un proceso definido, ligado a los movimientos de personal.
- Accesos del proveedor: temporales, autorizados caso por caso, registrados y revocados al finalizar la intervención.
Audit trail: contenido y revisión
Un audit trail útil responde, para cada evento relevante, a cuatro preguntas: quién, qué, cuándo y por qué. A verificar en especificación y en cualificación:
- cobertura de los eventos relevantes: creación, modificación e invalidación de registros, cambios de configuración y de límites, gestión de alarmas, eventos de acceso;
- imposibilidad de desactivación o alteración por parte de los usuarios, administradores incluidos;
- presencia del motivo del cambio donde el cambio esté permitido;
- legibilidad en forma comprensible sin herramientas del proveedor;
- posibilidad de filtrar y revisar de forma eficiente: un audit trail técnicamente completo pero no revisable en la práctica no cumple su función;
- conservación durante todo el periodo exigido para los registros a los que se refiere.
La revisión del audit trail se planifica con enfoque basado en el riesgo: qué eventos se revisan, por quién, con qué frecuencia y con qué evidencia de la revisión. La frecuencia no deriva de una regla general sino de la criticidad de los datos y del proceso, y se justifica por escrito.
Registros electrónicos, firmas y gestión de datos
- Definición del dato bruto: establecer qué constituye el dato original y dónde reside es el presupuesto de todo control posterior.
- Metadatos: el registro no es solo el valor; incluye la información que permite interpretarlo y reconstruirlo.
- Firmas electrónicas: si se emplean, deben definirse las operaciones que las requieren, el significado de la firma y los controles asociados. Si el contexto no las exige, se documenta la decisión de no emplearlas.
- Gestión de datos anómalos: la posibilidad de excluir o anotar un dato debe regirse por procedimiento, con motivación registrada y trazabilidad completa. El borrado de datos brutos no es una función a configurar.
- Exportaciones e informes: deben verificarse como parte de la cualificación; un informe que presenta los datos de forma incompleta o engañosa es un problema de sistema, no de uso.
Configuración, personalización y validación
El esfuerzo de validación depende de cuánto se aparta el sistema del producto estándar. Un sistema configurado con parámetros previstos por el proveedor supone un esfuerzo distinto de uno con desarrollos específicos para el cliente. El criterio operativo: todo elemento configurado o desarrollado debe documentarse, justificarse y verificarse, y la documentación de configuración debe mantenerse actualizada como parte del sistema, no archivarse al cierre del proyecto.
La evaluación del proveedor — capacidad de desarrollo, gestión de versiones, soporte, documentación disponible — forma parte del marco y debe documentarse; su resultado influye legítimamente en la profundidad de las verificaciones propias.
Conservación, archivo y migración
- Periodo de conservación: definido en coherencia con los requisitos aplicables a los registros a los que se refieren los datos.
- Legibilidad en el tiempo: el formato de archivo debe seguir siendo interpretable incluso si el sistema se da de baja; la dependencia exclusiva de un formato propietario es un riesgo a evaluar explícitamente.
- Migración: toda transferencia de datos históricos requiere un plan, criterios de verificación de completitud y exactitud, y evidencia del resultado.
- Estrategia de salida: cómo se accede a los datos tras el fin del contrato o del soporte es una pregunta de la fase de licitación, no de la baja del sistema.
Revisión periódica del sistema informatizado
El sistema se revisa periódicamente para confirmar que sigue en estado de control: modificaciones habidas, incidencias registradas, desviaciones, resultado de las revisiones del audit trail, gestión de accesos, estado del soporte y de la obsolescencia, pruebas de restauración ejecutadas. La revisión periódica no es una repetición de la cualificación: es una verificación documentada de que las asunciones sobre las que se apoyaba la cualificación siguen siendo válidas.
Herramienta operativa: checklist de configuración orientada a integridad de datos
| Área | A definir antes de la configuración | Evidencia esperada |
|---|---|---|
| Accesos | Matriz roles-permisos aprobada | Documento aprobado y configuración correspondiente verificada |
| Accesos | Proceso de gestión del ciclo de vida de las cuentas | Procedimiento y registros |
| Audit trail | Lista de eventos registrados | Verificación en OQ de cada tipo de evento |
| Audit trail | Plan de revisión basado en el riesgo | Procedimiento con frecuencia justificada y registros de revisión |
| Datos | Definición de dato bruto y metadatos | Documento de sistema |
| Datos | Reglas de gestión de datos anómalos | Procedimiento y trazabilidad en el sistema |
| Límites y alarmas | Quién puede modificarlos y con qué autorización | Configuración de permisos y registro de las modificaciones |
| Informes | Informes previstos y su verificación | Verificación en OQ contra los datos fuente |
| Conservación | Periodo, formato y ubicación | Política documentada |
| Restauración | Prueba de restore en la configuración real | Informe de la prueba |
| Proveedor | Evaluación documentada | Informe de evaluación |
| Aplicabilidad | Qué requisitos se aplican y por qué | Evaluación de aplicabilidad aprobada |
Escenario práctico
En una planta que llamaremos Site Delta — realista pero ficticia — el equipo de proyecto configura el EMS usando los perfiles de usuario predeterminados propuestos por el proveedor, para no retrasar la puesta en marcha. El perfil destinado a los responsables de turno incluye, por comodidad operativa, la posibilidad de modificar los límites de alarma.
La cualificación se cierra sin hallazgos: el sistema hace exactamente aquello para lo que fue configurado. El problema aparece en la primera revisión periódica, cuando el audit trail muestra modificaciones de límites realizadas por personal operativo durante la producción. Ninguna de esas modificaciones era irregular según la configuración; todas eran incompatibles con el principio de separación entre quien opera y quien define los parámetros que gobiernan la operativa.
La corrección — redefinir la matriz de roles, reconfigurar los permisos, re-verificar, evaluar retrospectivamente las modificaciones ya ocurridas y documentar su impacto — exige un esfuerzo muy superior al que habría supuesto definir la matriz antes de configurar. Es el caso típico en el que el tiempo ahorrado al principio se devuelve con intereses.
Errores frecuentes y señales de alarma
- Adoptar los perfiles de usuario predeterminados del proveedor. Reflejan una hipótesis organizativa genérica, no la separación de funciones de la planta.
- Cuentas compartidas o genéricas. Hacen imposible la atribuibilidad, que es el primero de los principios de integridad de datos.
- Audit trail activo pero nunca revisado. El registro sin revisión no produce control; la ausencia de un plan de revisión justificado es un hallazgo frecuente.
- Citar el Annex 11 en revisión como requisito vigente. La versión aplicable sigue siendo la de enero de 2011; un texto en consulta no es una obligación.
- Asumir que la Part 11 se aplica siempre. La aplicabilidad debe determinarse y documentarse; asumirla sin análisis lleva a controles injustificados, negarla sin análisis lleva a lagunas.
- No definir el dato bruto. Sin esa definición, toda discusión sobre integridad y conservación queda ambigua.
- Configurar la posibilidad de borrar datos. La gestión de datos anómalos se hace con anotación trazada, no con eliminación.
- Descuidar la exportabilidad y la migración. Son los temas que encarecen o impiden la sustitución del sistema años después.
- Tratar la revisión periódica como una formalidad. Es el instrumento con el que se demuestra que el sistema sigue en estado de control.
Cómo documentar
- Evaluación de aplicabilidad: qué requisitos se aplican al sistema y por qué, cuáles no y con qué razonamiento.
- Matriz roles-permisos aprobada con el racional de la separación de funciones.
- Especificación de configuración mantenida como documento vivo.
- Plan de revisión del audit trail con frecuencia justificada y responsabilidades asignadas.
- Definición de dato bruto, metadatos y periodo de conservación.
- Evaluación del proveedor y su influencia en la estrategia de verificación.
- Informe de cualificación del componente informatizado, trazable a los requisitos.
- Registros de revisión periódica y acciones consecuentes.
Puntos clave
- La integridad de datos se diseña antes de configurar: después, cada corrección cuesta mucho más.
- La versión aplicable del Annex 11 es la de enero de 2011; un texto en consulta no es un requisito.
- La aplicabilidad de la Part 11 se determina y se documenta, no se asume.
- Un audit trail no revisable en la práctica no cumple su función.
- La separación de funciones es una decisión organizativa traducida en configuración, no al revés.
- Exportabilidad, archivo y estrategia de salida se negocian en la licitación, no en la baja del sistema.
Preguntas frecuentes
¿Qué versión del Annex 11 es aplicable?
La revisión de enero de 2011 sigue siendo la versión aplicable. Un texto en consulta puede tenerse en cuenta para orientar decisiones duraderas, pero debe declararse siempre como tal y no puede usarse como criterio de aceptación en cualificación.
¿Se aplica la 21 CFR Part 11 a nuestro EMS?
Depende del contexto: se aplica a los registros y firmas electrónicos en el ámbito de los productos regulados por la FDA y sus predicate rules. La determinación se hace caso por caso y se documenta en una evaluación de aplicabilidad aprobada.
¿Con qué frecuencia debe revisarse el audit trail?
No existe una frecuencia universal. Se define con enfoque basado en el riesgo, en función de la criticidad de los datos y del proceso, y se justifica por escrito junto con el alcance de la revisión y las responsabilidades.
¿Pueden usarse cuentas de departamento cuando se alternan varios operadores?
No, si los registros deben ser atribuibles a una persona. La atribuibilidad es uno de los principios fundamentales de integridad de datos; las necesidades operativas de rapidez se resuelven con soluciones técnicas de autenticación, no compartiendo credenciales.
¿Quién debería poder modificar los límites de alarma?
No quien opera bajo esos límites. La elección concreta depende de la organización, pero el principio de separación entre ejecución y definición de parámetros debe respetarse y documentarse en la matriz de roles.
¿Qué ocurre con los datos cuando se sustituye el sistema?
Deben seguir siendo legibles y reconstruibles durante todo el periodo de conservación. Las opciones — migración al nuevo sistema, archivo en formato independiente, mantenimiento en solo lectura del sistema antiguo — se evalúan con un plan documentado. El tema enlaza con la sustitución de sistemas existentes, tratada en el artículo sobre el retrofit de un EMS.
Referencias regulatorias y técnicas
- EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (Comisión Europea): Annex 11 (revisión de enero de 2011), Annex 15 (en vigor desde el 1 de octubre de 2015), Annex 1 (aplicable desde el 25 de agosto de 2024).
- 21 CFR Part 11 — Electronic Records; Electronic Signatures (eCFR).
- PIC/S — Guides and Guidance Documents, incluida la guidance sobre integridad de datos en entornos regulados.
- ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.
Continúa el recorrido del proyecto
Este artículo forma parte del recorrido Environmental Monitoring Systems de GuideGxP, que sigue el ciclo de vida de un proyecto EMS desde la definición de requisitos hasta la gestión en operación.
- Antes: la URS del sistema y la infraestructura de red y alimentación.
- Después: FAT, SAT, IQ, OQ y PQ del sistema y gestión en operación.
- Fundamentos regulatorios GuideGxP: integridad de datos, ALCOA+ y audit readiness según el Annex 11.
¿Quieres recibir análisis como este directamente por email? Suscríbete a The Pragmatic GMP, la newsletter de GuideGxP para quienes trabajan cada día con GMP, cualificación y data integrity.
