En los datos de demostración hospitalarios de digna, el 22 de abril de 2026, el personal de enfermería de un grupo hospitalario administró 82 dosis de un medicamento nuevo. El informe de farmacia de ese día mostraba cero. Nada falló. Las dosis estaban registradas, pero el producto todavía no figuraba en el maestro de productos de farmacia, así que todos los informes que unían dosis con productos las descartaban. La integridad referencial en datos sanitarios significa que cada registro que apunta a otro, como una dosis a un producto, un resultado de laboratorio a una petición o un episodio a un paciente, apunta a una fila que realmente existe.

Este artículo sigue ese caso: cómo apareció el hueco, cómo lo detectó una comprobación de integridad referencial en digna y qué hizo el equipo a continuación. Después amplía el foco a las relaciones de datos hospitalarios y de aseguradoras que merecen la misma comprobación.

Para el concepto general de los registros huérfanos, consulte el artículo principal ¿Pueden sus datos seguir encontrando a sus padres? Entender la integridad referencial. Este se queda en el hospital.

Puntos clave

• Una dosis huérfana no es incorrecta, sino invisible: el inner join la elimina, de modo que los informes se quedan cortos sin generar ningún error.

• En la demostración de Danubia Kliniken, 82 de 4326 administraciones de medicamentos del 22 de abril hacían referencia a un producto que faltaba en el maestro de productos de farmacia.

• Una regla de integridad referencial en digna Data Validation son unos pocos campos y nada de SQL, y devuelve los registros fallidos con hospital, planta y código de producto.

• La corrección suele estar en los datos maestros: se da de alta el producto, se vuelve a ejecutar la inspección y el informe se corrige solo.

• Las comprobaciones se ejecutan dentro de la propia base de datos del hospital. Los datos de los pacientes nunca salen de su infraestructura.

Índice de contenidos

• ¿Qué ocurrió en Danubia Kliniken el 22 de abril?

• ¿Por qué no falló nada técnicamente?

• ¿Cómo detectó digna el producto que faltaba?

• ¿Qué hace el equipo a continuación?

• ¿Qué relaciones referenciales importan en los datos hospitalarios y de aseguradoras?

• ¿Por qué se rompe tan a menudo la integridad referencial en el sector sanitario?

• ¿Dónde se ejecutan las comprobaciones y salen los datos de los pacientes del hospital?

• ¿Cómo empezar?

¿Qué ocurrió en Danubia Kliniken el 22 de abril?

Un producto nuevo, Coavira 2.5 mg con el código de producto 3858646, llegó a las plantas antes que al maestro de productos de farmacia. El personal de enfermería documentó 82 administraciones el 22 de abril de 2026. Como el maestro no tenía ninguna fila coincidente, todos los informes que unían administraciones con productos contaban cero dosis de Coavira, mientras que los registros de administración de medicamentos mostraban 82.

Danubia Kliniken es un grupo hospitalario austriaco ficticio, y todas las cifras de este artículo proceden de los datos de demostración de digna. Las capturas de pantalla son pantallas reales de digna.

La secuencia es corriente. Un producto se pide, se entrega y se administra. El registro maestro que le da nombre y precio lo mantiene otro equipo, con otro calendario. En la demostración, la tabla de administraciones hospital_medication_administrations se carga desde los sistemas de planta, y el maestro de productos hospital_medications lo mantiene la farmacia. Durante un día o una semana, ambos no coinciden.

¿Quién se da cuenta? Normalmente no el equipo de datos. Una supervisora de planta compara un informe de consumo con lo que sabe que se administró, o un farmacéutico ve bajar el stock sin un consumo que lo explique. Para entonces, las cifras erróneas llevan días circulando.

¿Por qué no falló nada técnicamente?

No falló nada porque ninguna carga individual era incorrecta. Las administraciones se cargaron, el maestro se cargó y la consulta del informe se ejecutó. El fallo está en la relación entre dos tablas, y un inner join resuelve una relación rota eliminando la fila en silencio en lugar de generar un error.

Una versión simplificada del informe de consumo diario tiene este aspecto:

SELECT m.product_code,
       m.medication_name,
       COUNT(*) AS doses
FROM   hospital_medication_administrations a
JOIN   hospital_medications m
       ON m.product_code = a.product_code
GROUP  BY m.product_code,

SELECT m.product_code,
       m.medication_name,
       COUNT(*) AS doses
FROM   hospital_medication_administrations a
JOIN   hospital_medications m
       ON m.product_code = a.product_code
GROUP  BY m.product_code,

SELECT m.product_code,
       m.medication_name,
       COUNT(*) AS doses
FROM   hospital_medication_administrations a
JOIN   hospital_medications m
       ON m.product_code = a.product_code
GROUP  BY m.product_code,

Coavira 2.5 mg no aparece en absoluto en el resultado. Un cuadro de mando filtrado por este producto muestra 0. Las 82 filas siguen en la tabla de administraciones, pero ninguna consulta que pase por el maestro las verá nunca.

Las restricciones de la base de datos rara vez lo detectan. Los sistemas clínicos de origen pueden aplicar sus propias claves, pero en un almacén de datos (data warehouse) hospitalario el extracto del eMAR y el maestro de farmacia suelen venir de sistemas distintos, y las claves foráneas declaradas a menudo no se trasladan o no se aplican. Por eso la comprobación tiene que ejecutarse sobre los datos a medida que llegan. Encontrar los huérfanos a mano es una sola consulta:

SELECT a.hospital,
       a.ward,
       a.product_code,
       COUNT(*) AS orphaned_doses
FROM   hospital_medication_administrations a
LEFT   JOIN hospital_medications m
       ON m.product_code = a.product_code
WHERE  m.product_code IS NULL
  AND  a.product_code IS NOT NULL
GROUP  BY a.hospital, a.ward,

SELECT a.hospital,
       a.ward,
       a.product_code,
       COUNT(*) AS orphaned_doses
FROM   hospital_medication_administrations a
LEFT   JOIN hospital_medications m
       ON m.product_code = a.product_code
WHERE  m.product_code IS NULL
  AND  a.product_code IS NOT NULL
GROUP  BY a.hospital, a.ward,

SELECT a.hospital,
       a.ward,
       a.product_code,
       COUNT(*) AS orphaned_doses
FROM   hospital_medication_administrations a
LEFT   JOIN hospital_medications m
       ON m.product_code = a.product_code
WHERE  m.product_code IS NULL
  AND  a.product_code IS NOT NULL
GROUP  BY a.hospital, a.ward,

La consulta es fácil. Lo difícil es ejecutarla para cada relación, en cada carga, y ver el resultado antes de que salga el informe. El artículo relacionado Registros huérfanos: encuéntrelos con SQL y manténgalos fuera trata con más detalle los patrones SQL, incluidas las claves compuestas y el tratamiento de los NULL.

¿Cómo detectó digna el producto que faltaba?

Una regla de integridad referencial sobre la fuente de datos de administraciones comprobaba cada product_code contra el maestro de productos de farmacia en cada inspección. El 22 de abril, 4244 de 4326 filas superaron la comprobación y 82 fallaron, así que el estado de la regla pasó a Failed en el cuadro de mando, y las dosis fallidas estaban a un clic.

La regla

La regla se define en digna Data Validation, que tiene tres tipos de regla: Rule, Uniqueness y Referential Integrity. Configurar esta llevó seis pasos:

1. En Configuration, seleccione la fuente de datos hospital_medication_administrations, abra la pestaña Data Validation y haga clic en Add Rule. Se abre el cuadro de diálogo Add Data Validation Rule.

2. Introduzca un Name (nombre) y una Description (descripción): hc_product_in_master, "Todo producto administrado existe en el maestro de productos de farmacia".

3. Establezca Type (tipo) en Referential Integrity.

4. En Attributes (atributos), elija product_code en esta fuente de datos.

5. En must exist in (debe existir en), elija la Data Source (fuente de datos) hospital_medications y sus Attributes product_code.

6. Establezca Threshold Mode (modo de umbral) en Absolute, Info threshold en 0 y Warn threshold en 1, de modo que una sola dosis huérfana ya genere un estado Uncertain y dos o más hagan fallar la comprobación. Guarde.

La regla: product_code de las administraciones debe existir en hospital_medications.product_code.

Sin escribir SQL. A partir de ese momento, la regla se ejecuta con cada inspección de la fuente de datos, programada o bajo demanda. El vídeo Integridad referencial en digna: configuración en menos de un minuto muestra la misma configuración en tiempo real, y Cómo configurar una comprobación de integridad referencial recorre todos los campos, incluidas las claves compuestas.

El resultado

La inspección del 22 de abril evaluó 4326 administraciones. 4244 encontraron su producto en el maestro; 82 no. Con un Warn threshold de 1, eso supone un estado Failed en el cuadro de mando, junto a las demás comprobaciones del día.

El cuadro de mando del 22 de abril: hc_product_in_master, 4244 de 4326 superadas, estado Failed.

Un recuento basta para saber que algo va mal. No basta para saber qué hacer al respecto. Para eso necesita las filas.

Los registros fallidos

digna devuelve los propios registros fallidos: la misma comprobación con la condición de aprobación negada, ejecutada dentro de la base de datos de origen. En la vista Invalid Records (registros no válidos), filtre por Failed y elija la comprobación Full - hc_product_in_master. Cada fila es una dosis que no apunta a ninguna parte, con hospital, planta, servicio, product_code 3858646 y medication_name Coavira 2.5 mg.

Invalid Records: cada dosis fallida con hospital, planta, servicio y código de producto.

Esa lista responde a las preguntas que, de otro modo, circulan por correo durante una semana: qué producto, qué plantas, cuántas dosis. Se puede exportar para quien sea responsable de la corrección.

¿Qué hace el equipo a continuación?

El equipo corrige los datos maestros, no las dosis. Las administraciones son correctas: el personal de enfermería administró Coavira 2.5 mg y lo documentó. Lo que faltaba es la fila del producto, así que la solución es darlo de alta en el maestro de productos de farmacia, volver a ejecutar la inspección y dejar que los informes recojan las dosis.

1. Revise los registros fallidos y confirme el patrón. El mismo código de producto, 3858646, en todas las filas fallidas apunta a una entrada ausente en el maestro, no a una errata en un sistema de planta.

2. Notifique al equipo responsable del maestro de productos, en este caso la farmacia, y adjunte los registros exportados.

3. La farmacia da de alta Coavira 2.5 mg en hospital_medications.

4. Vuelva a ejecutar bajo demanda la inspección de la fuente de datos de administraciones. Cuando todos los códigos de producto se resuelven, la regla vuelve a superarse y las dosis aparecen en los informes.

5. Actualice el informe de consumo. Aparecen las 82 dosis, atribuidas a los hospitales y plantas correctos.

Si los registros fallidos hubieran mostrado decenas de códigos distintos en una sola planta, la causa sería otra, quizá un problema de mapeo en una interfaz, y también lo sería el responsable. Los registros le dicen en qué caso se encuentra. Esa es la razón principal para mirar filas y no recuentos.

Los equipos que aceptan un breve desfase entre el primer uso y el alta en el maestro pueden subir los umbrales o cambiar el Threshold Mode a Relative. Para los datos de medicación, Danubia los mantiene estrictos.

¿Qué relaciones referenciales importan en los datos hospitalarios y de aseguradoras?

Las relaciones que merece la pena comprobar son aquellas de las que dependen los informes y la facturación: dosis con productos, episodios con pacientes, resultados de laboratorio con peticiones y episodios, ocupación de camas con plantas, y reclamaciones con aseguradoras y pólizas. Cada una, cuando se rompe, elimina filas de un join sin ningún error, y cada una tiene un responsable distinto.

En los datos hospitalarios importan dos detalles. Primero, las claves compuestas: un código de planta a menudo solo es único dentro de un hospital, así que la ocupación de camas debe comprobarse sobre hospital y planta juntos. En digna se eligen varias columnas en ambos lados, en el mismo orden, y la comprobación se hace sobre la combinación. Segundo, los NULL: las comprobaciones referenciales omiten las claves foráneas nulas, así que una dosis sin ningún código de producto no falla. Si toda administración debe llevar un código de producto, añada una Rule independiente, product_code IS NOT NULL.

La integridad referencial es una capa de la validación de datos clínicos. Los rangos de valores, las comprobaciones de plausibilidad y las reglas de codificación son otra; Validación de datos sanitarios: reglas clínicas y regulatorias a escala trata esas.

¿Por qué se rompe tan a menudo la integridad referencial en el sector sanitario?

La integridad referencial se rompe a menudo en el sector sanitario porque los registros padre e hijo pertenecen a departamentos distintos, residen en sistemas distintos y se cargan con calendarios distintos. La farmacia mantiene los productos, admisión mantiene los pacientes, el sistema de laboratorio contiene las peticiones, servicios generales gestiona las plantas y finanzas gestiona las aseguradoras. Cada uno es correcto en sus propios términos; los joins entre ellos no son tarea de nadie.

• Los datos maestros tienen muchos responsables. Un producto, una planta o una aseguradora los crea el departamento al que le interesan, mediante su propio proceso. Los sistemas que los referencian se enteran más tarde.

• Los sistemas se cargan con calendarios distintos. La documentación de planta puede llegar varias veces al día, mientras que un maestro se actualiza cada noche o tras una solicitud de cambio. Cualquier desfase entre ambos genera huérfanos, aunque los dos lados acaben siendo correctos.

• Los códigos cambian. Los productos se sustituyen, las plantas se fusionan o se renombran, las aseguradoras cambian de código, los catálogos de laboratorio se revisan. Los registros históricos siguen llevando los códigos antiguos, y un maestro que solo conserva los códigos vigentes los deja huérfanos.

• Los centros se fusionan. Cuando un grupo hospitalario incorpora nuevos centros a un reporting compartido, listas de códigos que nunca se diseñaron para encajar se encuentran en el mismo join.

• El padre está en otra base de datos. El maestro de productos puede estar en el sistema de farmacia y las administraciones en el almacén de datos clínico. Desde Release 2026.01, digna comprueba la integridad referencial entre distintas conexiones de base de datos del mismo proyecto, sin replicar ninguna de las dos tablas.

Nada de esto indica un hospital mal gestionado. Es el estado normal de un almacén de datos hospitalario alimentado por muchos sistemas. La diferencia está en si encuentra el hueco el día en que se abre o la semana en que alguien se queja.

¿Dónde se ejecutan las comprobaciones y salen los datos de los pacientes del hospital?

Las comprobaciones se ejecutan dentro de la propia base de datos del hospital, y los datos de los pacientes nunca salen de su infraestructura. digna se ejecuta on-premises o en la nube privada del hospital. Envía SQL al origen, recibe recuentos y obtiene las filas fallidas solo cuando usted las solicita. No se copia ninguna tabla fuera, y el equipo de digna nunca ve sus datos.

Para los datos clínicos, eso es una condición previa, no un detalle. Los datos de medicación, laboratorio y episodios permanecen donde sus equipos de seguridad y protección de datos ya los gobiernan.

Desde Release 2026.06, las reglas también pueden gestionarse como código: el SDK de Python (pip install digna-sdk) gestiona proyectos, inspecciones y reglas desde CI/CD, y las reglas de validación pueden exportarse desde pruebas e importarse en producción.

¿Cómo empezar?

Elija la relación cuyo fallo más daño haría, normalmente dosis con productos o reclamaciones con aseguradoras, y añada una regla de integridad referencial para ella. Son unos pocos campos. Después, añada la siguiente. Tras unas cuantas inspecciones sabrá en cuáles de sus joins puede confiar y cuáles pierden filas en silencio.

Si quiere ver en funcionamiento las comprobaciones de Danubia Kliniken y hablar sobre los datos de su propio hospital o aseguradora, reserve una demostración con el equipo de digna.

Preguntas frecuentes

¿Qué es la integridad referencial en datos sanitarios?

Significa que cada registro que hace referencia a otro apunta a una fila que existe: una dosis a un producto del maestro de farmacia, un resultado de laboratorio a su petición, un episodio a un paciente. Cuando falta el padre, los joins descartan la fila hija y los informes se quedan cortos sin ningún error.

¿Por qué desaparecen dosis de medicamentos de los informes hospitalarios?

Normalmente porque el producto falta en el maestro de productos de farmacia. Los informes unen administraciones con productos, y un inner join elimina en silencio las dosis sin producto coincidente. En la demostración de Danubia Kliniken, 82 dosis de un producto nuevo aparecían como cero en todos los informes que pasaban por el maestro.

¿Cómo se comprueban los datos del eMAR contra el maestro de productos de farmacia?

Añada una regla Referential Integrity sobre la fuente de datos de administraciones en digna Data Validation: elija product_code como atributo y, en must exist in, seleccione el maestro de productos y su product_code. Cada inspección informa de las filas superadas y fallidas y lista cada dosis huérfana.

¿Salen los datos de los pacientes del hospital cuando digna ejecuta estas comprobaciones?

No. digna se ejecuta on-premises o en la nube privada del hospital, y cada comprobación se ejecuta dentro de la base de datos de origen. digna envía SQL y recibe recuentos, más las filas fallidas cuando usted las abre. No se copia ninguna tabla fuera, y el equipo de digna nunca ve sus datos.

¿Qué tablas de un almacén de datos hospitalario necesitan comprobaciones de integridad referencial?

Empiece por los joins de los que dependen los informes y la facturación: administraciones de medicamentos con el maestro de productos, episodios con pacientes, resultados de laboratorio con peticiones y episodios, ocupación de camas con plantas por hospital y código de planta, y reclamaciones con aseguradoras y pólizas. Cada uno tiene un responsable distinto al que notificar.