La URS de un Environmental Monitoring System no es un documento burocrático para satisfacer a Calidad: es el contrato técnico que determina qué deberá demostrar el sistema, quién lo verificará y con qué evidencias. Una URS bien redactada hace que la cualificación resulte casi mecánica; una URS vaga convierte la OQ y la PQ en una negociación con el proveedor.
En la práctica, una URS de EMS eficaz hace cuatro cosas: define el intended use y el system boundary (dónde termina el EMS y dónde empiezan el BMS, la climatización o el laboratorio de microbiología); expresa los requisitos como resultado verificable en lugar de como solución técnica; asigna a cada requisito una justificación y un método de verificación; y cubre todo el ciclo de vida, no solo la puesta en marcha. La regla operativa más útil es esta: si un requisito no puede verificarse mediante un ensayo, una inspección documental o una demostración, no es un requisito — es una expectativa.
Este artículo aporta la estructura de referencia, la matriz de trazabilidad requisito–justificación–verificación, ejemplos de redacción correcta e incorrecta, y la checklist que conviene completar antes de emitir una RFP.
Por qué la URS decide el destino del proyecto EMS
Un Environmental Monitoring System es uno de los pocos sistemas de planta que se sitúa simultáneamente en tres planos: es instrumentación (contadores de partículas, muestreadores microbiológicos, sensores de presión diferencial, temperatura y humedad), es infraestructura (red, alimentación, servidores, integraciones) y es sistema computarizado GxP (registros electrónicos, audit trail, gestión de accesos). Cada uno de estos planos trae sus propias expectativas regulatorias y sus propios interlocutores.
El problema clásico surge cuando la URS la escribe una sola de estas funciones. Una URS redactada solo por Ingeniería describe bien sondas y conexiones pero ignora la revisión del audit trail. Una URS redactada solo por Calidad enumera principios de integridad de datos pero no define el comportamiento esperado ante una caída de red. Una URS copiada de la oferta de un proveedor ya no es una especificación: es la descripción de lo que ese proveedor ya vende, y hace imposible una evaluación técnica comparativa.
Las consecuencias aparecen tarde y salen caras: criterios de aceptación negociados durante la OQ, funciones que se descubren ausentes tras el SAT, datos históricos no migrables al cambiar de sistema, y alarmas para las que nadie definió quién debe reconocerlas ni en qué plazo.
Contexto regulatorio: qué exige realmente la normativa
Antes de redactar requisitos conviene aclarar la jerarquía de las fuentes, porque confundirlas es la forma más rápida de volver indefendible una URS.
Requisito regulatorio. El Annex 1 de las GMP europeas, plenamente aplicable desde el 25 de agosto de 2024, exige que la monitorización ambiental de las áreas de producción estéril se defina sobre la base de una evaluación formal del riesgo documentada, y que el programa de monitorización forme parte de la Contamination Control Strategy. El Annex 15, en vigor desde el 1 de octubre de 2015, establece que la especificación de equipos, instalaciones, utilities y sistemas se defina en una URS y/o especificación funcional, incorporando en esa fase los elementos esenciales de calidad y mitigando los riesgos GMP a un nivel aceptable. El Annex 11 — cuya versión aplicable sigue siendo la de enero de 2011 — se aplica al EMS en tanto que sistema computarizado usado en actividades GMP.
Requisito de norma. La serie ISO 14644 define la clasificación de salas limpias y los métodos asociados; es una norma técnica, no una regulación GMP, y las GMP la referencian para aspectos concretos. No todo lo que contiene la ISO 14644 es una obligación GMP, y no todo lo que exigen las GMP está cubierto por la ISO 14644.
Guidance y expectativa inspectora. Los documentos PIC/S, las guías FDA sobre proceso aséptico y las directrices ICH — en particular ICH Q9(R1) sobre Quality Risk Management — orientan las expectativas sin ser prescripciones puntuales.
Good engineering practice. Dimensionamiento del vacío, criterios de tendido, redundancia de alimentación: son decisiones de ingeniería correctas que deben documentarse, pero no derivan de una obligación regulatoria.
Recomendación GuideGxP. Todo lo que en este artículo se presenta como método de trabajo — estructura de la URS, matriz de trazabilidad, checklist — es práctica operativa recomendada, no un requisito regulatorio adicional.
Una URS madura declara explícitamente, para cada requisito, a cuál de estas categorías pertenece. Es la diferencia entre «lo hacemos porque lo exige la norma» y «lo hacemos porque hemos decidido que es la forma correcta», y en inspección la segunda afirmación es perfectamente aceptable siempre que esté justificada.
Si estás construyendo o revisando el sistema documental GMP de tu planta, The Pragmatic GMP es la newsletter semanal gratuita de GuideGxP: análisis operativos sobre normativa, cualificación e integridad de datos, sin teoría innecesaria.
Cómo se estructura una URS para un EMS
1. Business need e intended use
La sección inicial responde a dos preguntas distintas. El business need explica por qué existe el proyecto: nueva línea, ampliación de área, obsolescencia del sistema existente, brecha detectada en una inspección, necesidad de incorporar monitorización continua. El intended use describe el uso previsto en términos GxP: qué decisiones se tomarán con los datos que genera el sistema. Es el intended use, no la tecnología, lo que determina la profundidad de la cualificación y el alcance de los controles de integridad de datos.
Un EMS cuyos datos respaldan la liberación de lote tiene un intended use radicalmente distinto del de un sistema usado solo para trending de área, aunque el hardware sea el mismo.
2. System boundary e interfaces
La frontera del sistema debe trazarse antes que los requisitos funcionales. Sirve para establecer qué se incluye en el suministro, qué se excluye y dónde cambian las responsabilidades. Define explícitamente:
- qué puntos de monitorización, áreas y grados están en alcance;
- qué instrumentos se suministran, cuáles se reutilizan y cuáles se excluyen;
- dónde termina el EMS y empiezan el BMS, el SCADA de área o el historian de planta;
- quién posee la infraestructura IT y quién la red;
- qué datos se intercambian, en qué dirección, con qué protocolo y con qué criticidad GxP.
Una interfaz mal definida es la primera causa de litigio en el SAT. La pregunta no es «¿puede el sistema comunicarse con el BMS?» sino «qué datos circulan, quién es su record owner y qué ocurre si el enlace cae».
3. Stakeholders y responsabilidades
La URS de un EMS requiere al menos seis funciones en la mesa, cada una con una aportación indelegable: Calidad para intended use, criticidad GxP y requisitos documentales; Ingeniería para viabilidad, instalación e infraestructura; Microbiología para métodos viable, medios, incubación y manejo de muestras; Validación/CQV para estrategia de cualificación y entregables; IT/CSV para arquitectura, ciberseguridad, backup y gestión de accesos; Compras para contrato, SLA, repuestos y ciclo de vida comercial.
Recomendación operativa: asigna a cada sección de la URS un responsable nominal y haz firmar el documento por todas las funciones implicadas. Una URS aprobada solo por Calidad es formalmente válida y sustancialmente frágil.
4. Requisitos de monitorización
Aquí se describe qué debe monitorizarse, distinguiendo con rigor conceptos que a menudo se confunden:
- monitorización no viable (partículas) y viable (microbiológica), que responden a lógicas, tecnologías y tiempos distintos;
- monitorización continua y periódica, con sus implicaciones sobre alarmas, archivo y carga de gestión;
- clasificación de la sala limpia, cualificación de la sala limpia y monitorización ambiental de rutina: tres actividades distintas, con finalidades y criterios propios. Una URS que las trata como sinónimos propaga la confusión a toda la validación.
El número, tipo y posición de los puntos no se inventan en la URS: derivan de la evaluación de riesgos y de la estrategia de muestreo, que constituyen un ejercicio aparte — tratado en detalle en nuestro artículo sobre evaluación de riesgos y estrategia de muestreo en monitorización ambiental. La URS sí debe exigir que el sistema pueda soportar la estrategia definida, incluida su evolución futura.
5. Requisitos de prestaciones y disponibilidad
Son requisitos que el proveedor debe demostrar, no declarar. Exprésalos como resultado esperado y verificable: disponibilidad del sistema y comportamiento esperado ante indisponibilidad; continuidad de la adquisición durante mantenimiento o reinicio; capacidad de almacenamiento local del dato ante pérdida de comunicación; tiempos de respuesta de consultas e informes sobre volúmenes de datos realistas al final de la vida del sistema, no sobre una base vacía el día del FAT.
6. Alarmas y gestión de eventos
La gestión de alarmas es, junto con la integridad de datos, el área donde las URS resultan más incompletas. Define: tipos y niveles de alarma; propagación y notificación; requisitos de acknowledgement con identificación del operador; obligación de comentario o justificación; comportamiento de las alarmas durante actividades planificadas; registro inalterable de todo el ciclo de vida del evento; reglas de gestión de alarmas repetidas.
Cuidado con prescribir límites en la URS cuando estos provienen de otros documentos: la URS exige que el sistema sepa gestionar niveles configurables y trazables, mientras que los valores pertenecen al plan de monitorización y a las especificaciones de producto o proceso.
7. Datos, registros electrónicos e integridad de datos
Al tratarse de un sistema computarizado GxP, esta sección merece el mismo cuidado que el pliego técnico. Cubre: identificación de usuarios y user roles; segregation of duties entre quien configura, quien opera y quien revisa; audit trail completo, legible y revisable sin soporte del proveedor; contenido y conservación de los registros electrónicos y sus metadatos; backup, restore y disaster recovery con demostración periódica de eficacia; time synchronisation entre instrumentos, servidores y sistemas conectados; reporting y trending; requisitos de ciberseguridad, acceso remoto y gestión de parches; requisitos de data migration y legibilidad de los datos históricos en el tiempo.
La referencia regulatoria aplicable sigue siendo el Annex 11 en su versión de enero de 2011, complementada por los principios consolidados de integridad de datos. Si necesitas la base sobre principios ALCOA+ y audit readiness según el Annex 11, GuideGxP ya lo ha cubierto.
8. Requisitos de ciclo de vida
La sección más descuidada y la de mayor impacto económico: calibración y verificación periódica de los instrumentos con su accesibilidad física; mantenimiento preventivo y correctivo; documentación de suministro y de sistema; entregables de cualificación esperados y soporte a FAT, SAT, IQ, OQ y PQ; gestión de la configuración y del change control; política de actualización de software y soporte de versiones; obsolescencia declarada de hardware y software; continuidad operativa y estrategia de salida.
Exigir estos elementos en la URS significa poder evaluarlos en fase de licitación en lugar de descubrirlos en el tercer año de operación.
Requisitos bien formulados y requisitos que crean problemas
La diferencia entre una URS útil y una decorativa está en la redacción de cada requisito. Tres criterios: verificabilidad, neutralidad tecnológica, univocidad.
| Requisito mal formulado | Por qué es un problema | Reformulación |
|---|---|---|
| «El sistema debe ser fiable.» | No verificable: ningún ensayo puede demostrar o refutar la fiabilidad así expresada. | «El sistema debe garantizar una disponibilidad definida y medible en el periodo de referencia acordado, con evidencia del cálculo y registro de las indisponibilidades.» |
| «El sistema debe usar contadores de partículas modelo X conectados por fibra óptica.» | Prescribe la solución: excluye alternativas válidas e impide la comparación técnica entre ofertas. | «El sistema debe adquirir en continuo el dato de partículas en los puntos definidos por la estrategia de muestreo, garantizando la integridad del dato en toda la ruta de transmisión.» |
| «El sistema debe cumplir el Annex 11.» | No traducible a ensayo: delega en el proveedor la interpretación de lo que la empresa debe especificar. | «El sistema debe registrar en el audit trail la creación, modificación y eliminación de registros GxP con usuario, fecha, hora y motivo, y permitir su revisión por Calidad sin intervención del proveedor.» |
| «Las alarmas deben gestionarse correctamente.» | Ambiguo: no define quién, cuándo ni con qué evidencia. | «Cada alarma debe requerir acknowledgement con identificación unívoca del operador e introducción de un motivo, ambos registrados de forma inalterable.» |
| «El sistema debe permitir el backup de los datos.» | Cubre la mitad del problema: un backup sin restore verificado no protege nada. | «El sistema debe permitir backups automáticos con la frecuencia definida y la restauración verificable de datos y configuración, con procedimiento documentado y prueba periódica.» |
La matriz requisito → justificación → método de verificación
Es la herramienta que hace la URS inmediatamente utilizable en cualificación: cada requisito lleva consigo el motivo por el que existe y la forma en que se verificará. Construida así, la matriz de trazabilidad exigida en validación ya está escrita en gran parte.
| ID | Requisito (extracto) | Categoría | Justificación | Método de verificación |
|---|---|---|---|---|
| URS-001 | Adquisición continua del dato de partículas en los puntos críticos definidos por la estrategia de muestreo | Requisito regulatorio (Annex 1) | Monitorización de zonas críticas durante las operaciones | OQ – ensayo funcional en todos los puntos; PQ – adquisición en condiciones de operación |
| URS-014 | Almacenamiento local del dato ante pérdida de comunicación y recuperación automática sin pérdida de registros | Decisión basada en riesgo | Continuidad del registro durante fallos de red | OQ – simulación de interrupción y verificación de completitud |
| URS-022 | Audit trail revisable por Calidad sin soporte del proveedor | Requisito regulatorio (Annex 11, enero 2011) | Revisión periódica independiente de los registros GxP | OQ – revisión completa ejecutada por un usuario de Calidad |
| URS-031 | Sincronización horaria entre instrumentos, servidores y sistemas interfazados desde una fuente única | Requisito regulatorio (Annex 11, enero 2011) | Correlación fiable entre eventos y lotes | IQ – verificación de configuración; OQ – comparación de marcas de tiempo |
| URS-045 | Accesibilidad de las sondas para calibración y mantenimiento sin desmontajes estructurales | Good engineering practice | Sostenibilidad del plan de calibración en el tiempo | DQ – revisión de diseño; IQ – inspección en campo |
| URS-058 | Exportación de datos históricos en formato legible y no propietario durante todo el periodo de conservación | Recomendación GuideGxP | Protección frente al lock-in y continuidad ante sustitución del sistema | OQ – exportación de prueba y relectura independiente |
Checklist de completitud de la URS
Antes de emitir el documento, verifica que cada uno de estos elementos esté presente y no sea ambiguo:
- Business need e intended use GxP declarados y diferenciados.
- System boundary trazado, con inclusiones y exclusiones explícitas.
- Interfaces listadas con dirección del dato, protocolo y criticidad.
- Responsables nominales por sección y aprobación multifuncional.
- Distinción rigurosa entre viable y no viable, continuo y periódico.
- Distinción entre clasificación, cualificación y monitorización de rutina.
- Requisitos de prestaciones expresados de forma medible.
- Comportamiento esperado ante fallo de red, alimentación o servidor.
- Ciclo de vida completo de la alarma, incluido el acknowledgement.
- User roles y segregation of duties definidos antes de la configuración.
- Audit trail, backup, restore, disaster recovery y time synchronisation cubiertos.
- Requisitos de ciberseguridad y acceso remoto coherentes con la política IT de planta.
- Entregables de cualificación esperados y soporte a FAT, SAT, IQ, OQ, PQ especificados.
- Calibración, mantenimiento y accesibilidad física considerados en diseño.
- Data migration, conservación y legibilidad en el tiempo abordadas.
- Obsolescencia, soporte de software y estrategia de salida solicitados en la oferta.
- Cada requisito categorizado y dotado de método de verificación.
- Ningún requisito que prescriba una solución donde debería describir un resultado.
Escenario práctico
Un escenario realista y deliberadamente ficticio, útil para mostrar el razonamiento. Una planta farmacéutica debe dotar de EMS una nueva línea de llenado aséptico con aislador, manteniendo el sistema existente en dos áreas de Grado C.
El borrador inicial de URS, redactado por Ingeniería, enumera instrumentos, cantidades y conexiones. En la revisión multifuncional aparecen tres lagunas. Primera: el intended use no distingue entre datos que respaldan la liberación de lote y datos de trending de área, lo que habría llevado a cualificarlo todo con la misma profundidad y a un coste injustificado. Segunda: el system boundary no aclara quién posee el dato de presión diferencial, ya adquirido por el BMS — con el riesgo de dos fuentes divergentes sobre el mismo parámetro. Tercera: ningún requisito describe el comportamiento del sistema durante los ciclos de descontaminación del aislador, situación en la que las alarmas no gestionadas generan un ruido que erosiona la credibilidad de todo el sistema de alarmas.
La revisión de la URS añade un requisito de segregación entre datos críticos y datos de trending, asigna formalmente la titularidad del dato de presión a un único sistema con el otro en solo lectura, e introduce un requisito de gestión de estados operativos con registro trazable del cambio de estado. Ninguna de estas tres correcciones exige tecnología adicional: solo exigen haber sido pensadas antes de la licitación.
Errores frecuentes y señales de alarma
- URS copiada de la oferta del proveedor. Imposibilita la evaluación comparativa y cede al proveedor el control de los criterios de aceptación.
- Requisitos no verificables. «Robusto», «user friendly», «conforme»: ninguno de estos términos produce un ensayo.
- Límites y frecuencias incluidos en la URS. Pertenecen al plan de monitorización; en la URS rigidizan el sistema y generan desalineación en cada revisión del plan.
- Integridad de datos tratada como sección final. Si llega después de elegir la arquitectura, algunos requisitos resultan inimplementables.
- Ciclo de vida ausente. Calibración, obsolescencia y migración de datos no solicitadas en licitación se convierten en costes no negociables en operación.
- Confusión entre clasificación, cualificación y monitorización. Genera errores de alcance que se propagan hasta la PQ.
- Ningún requisito sobre el comportamiento en modo degradado. El sistema solo se prueba en funcionamiento nominal, es decir, en la condición menos interesante.
- Aprobación monofuncional. Una sola firma significa que las demás funciones descubrirán el documento cuando ya sea tarde para modificarlo.
Cómo documentar la decisión
La URS debe gestionarse como documento controlado, con versionado, aprobación multifuncional y change control para toda modificación posterior a su emisión. Cada requisito debería estar identificado de forma unívoca, categorizado por fuente y vinculado a su método de verificación; las decisiones tomadas en revisión deben registrarse con su justificación, especialmente cuando un requisito se excluye deliberadamente. En inspección, la pregunta más frecuente no es «¿tienen una URS?» sino «¿cómo decidieron esto y dónde está escrito?».
La URS aprobada se convierte después en la entrada de la estrategia de cualificación: cómo se verifican los requisitos mediante FAT, SAT, IQ, OQ y PQ de un Environmental Monitoring System se trata en el artículo dedicado.
Puntos clave
- La URS define el resultado esperado, no la solución técnica.
- Intended use y system boundary preceden a cualquier requisito funcional.
- Cada requisito tiene una categoría, una justificación y un método de verificación.
- Un requisito no verificable no es un requisito.
- El ciclo de vida se especifica en licitación, no se descubre en operación.
- La aprobación multifuncional es lo que hace sólida a la URS.
Preguntas frecuentes
¿Debe la URS indicar cuántos puntos de monitorización instalar?
No. Número y posición derivan de la evaluación de riesgos y de la estrategia de muestreo, que son documentos aparte. La URS debe exigir que el sistema soporte la estrategia definida y permita su evolución sin rediseño.
¿Quién debe aprobar la URS de un EMS?
La normativa no impone una composición. La práctica recomendada es la aprobación conjunta de Calidad, Ingeniería, Microbiología, Validación/CQV e IT/CSV, con Compras implicada en los aspectos contractuales y de ciclo de vida.
¿Hacen falta URS separadas para hardware y software?
No necesariamente. Muchas plantas gestionan una única URS con secciones diferenciadas, trazadas después hacia entregables de cualificación distintos. Lo importante es que la frontera entre las partes sea explícita y que ningún requisito quede sin método de verificación.
¿Cómo se trata el Annex 11 mientras hay una revisión en curso?
La versión aplicable debe identificarse en el momento de la redacción y citarse como tal. Un texto en consulta puede considerarse para orientar decisiones de diseño duraderas, pero nunca debe presentarse como requisito vigente ni usarse como criterio de aceptación en cualificación.
¿Se puede reutilizar la URS de un proyecto anterior?
Como base estructural sí, como contenido no. Intended use, system boundary, interfaces y condicionantes de planta cambian de un proyecto a otro: la reutilización acrítica es una de las causas más frecuentes de requisitos incoherentes.
¿Cuándo debe actualizarse la URS?
En cada cambio de alcance antes del congelamiento del diseño, y después mediante change control. Tras la liberación para uso, la URS sigue siendo la referencia frente a la que se evalúa el impacto de cualquier modificación del sistema.
Referencias regulatorias y técnicas
- EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (Comisión Europea): Annex 1 (aplicable desde el 25 de agosto de 2024), Annex 11 (revisión de enero de 2011), Annex 15 (en vigor desde el 1 de octubre de 2015).
- ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.
- ISO 14644-1 — Salas limpias y ambientes controlados asociados: clasificación de la limpieza del aire por concentración de partículas.
- PIC/S — Guides and Guidance Documents.
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.
- Siguiente paso natural: evaluación de riesgos y estrategia de muestreo.
- Decisión de arquitectura: EMS centralizado, standalone o híbrido.
- Verificación de los requisitos: FAT, SAT, IQ, OQ y PQ de un Environmental Monitoring System.
- Convertir la URS en licitación: cómo seleccionar un proveedor EMS.
- Fundamentos regulatorios GuideGxP: Contamination Control Strategy conforme al Annex 1 y plan de monitorización ambiental audit-ready.
