Dans les données de démonstration hospitalières de digna, le 22 avril 2026, le personnel infirmier d'un groupe hospitalier a administré 82 doses d'un nouveau médicament. Le rapport de la pharmacie pour ce jour-là affichait zéro. Rien n'a échoué. Les doses ont bien été enregistrées, mais le produit ne figurait pas encore dans le référentiel produits de la pharmacie, si bien que chaque rapport qui joignait les doses aux produits les écartait. L'intégrité référentielle des données de santé signifie que chaque enregistrement qui pointe vers un autre enregistrement, comme une dose vers un produit, un résultat de laboratoire vers une demande d'analyse ou une venue vers un patient, pointe vers une ligne qui existe réellement.

Cet article suit ce cas : comment l'écart est apparu, comment un contrôle d'intégrité référentielle dans digna l'a détecté, et ce que l'équipe a fait ensuite. Il s'élargit ensuite aux relations des données hospitalières et des organismes payeurs qui méritent le même contrôle.

Pour le concept général des enregistrements orphelins, consultez l'article de référence Vos données retrouvent-elles encore leurs parents ? Comprendre l'intégrité référentielle. Celui-ci reste à l'hôpital.

Points clés

• Une dose orpheline n'est pas fausse, mais invisible : la jointure interne la supprime, si bien que les rapports sous-comptent sans lever d'erreur.

• Dans la démo Danubia Kliniken, 82 des 4 326 administrations de médicaments du 22 avril référençaient un produit absent du référentiel produits de la pharmacie.

• Une règle d'intégrité référentielle dans digna Data Validation se résume à quelques champs, sans SQL, et renvoie les enregistrements en échec avec l'hôpital, le service et le code produit.

• La correction se trouve généralement dans les données de référence : ajouter le produit, relancer l'inspection, et le rapport se corrige de lui-même.

• Les contrôles s'exécutent dans la propre base de données de l'hôpital. Les données des patients ne quittent jamais son infrastructure.

Table des matières

• Que s'est-il passé chez Danubia Kliniken le 22 avril ?

• Pourquoi rien n'a-t-il échoué techniquement ?

• Comment digna a-t-il détecté le produit manquant ?

• Que fait l'équipe ensuite ?

• Quelles relations référentielles comptent dans les données hospitalières et des payeurs ?

• Pourquoi l'intégrité référentielle se rompt-elle si souvent dans la santé ?

• Où s'exécutent les contrôles, et les données des patients quittent-elles l'hôpital ?

• Comment démarrer ?

Que s'est-il passé chez Danubia Kliniken le 22 avril ?

Un nouveau produit, Coavira 2.5 mg, code produit 3858646, est arrivé dans les services avant d'arriver dans le référentiel produits de la pharmacie. Le personnel infirmier en a documenté 82 administrations le 22 avril 2026. Comme le référentiel ne contenait aucune ligne correspondante, chaque rapport qui joignait les administrations aux produits comptait zéro dose de Coavira, alors que les enregistrements d'administration des médicaments en indiquaient 82.

Danubia Kliniken est un groupe hospitalier autrichien fictif, et tous les chiffres de cet article proviennent des données de démonstration de digna. Les captures d'écran sont de vrais écrans de digna.

L'enchaînement est banal. Un produit est commandé, livré et administré. La fiche de référence qui le nomme et en fixe le prix est gérée par une autre équipe, selon un autre calendrier. Dans la démo, la table des administrations hospital_medication_administrations est chargée depuis les systèmes des services, et le référentiel produits hospital_medications est géré par la pharmacie. Pendant un jour ou une semaine, les deux ne concordent pas.

Qui s'en aperçoit ? Rarement l'équipe data. Une cadre de santé compare un rapport de consommation avec ce qu'elle sait avoir été administré, ou un pharmacien voit le stock baisser sans consommation correspondante. À ce stade, les chiffres faux circulent déjà depuis des jours.

Pourquoi rien n'a-t-il échoué techniquement ?

Rien n'a échoué parce qu'aucun chargement n'était faux en soi. Les administrations se sont chargées, le référentiel s'est chargé et la requête du rapport s'est exécutée. Le défaut se situe dans la relation entre deux tables, et une jointure interne règle une relation rompue en supprimant silencieusement la ligne au lieu de lever une erreur.

Une version simplifiée du rapport de consommation quotidien ressemble à ceci :

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 n'apparaît pas du tout dans le résultat. Un tableau de bord filtré sur ce produit affiche 0. Les 82 lignes sont toujours dans la table des administrations, mais aucune requête passant par le référentiel ne les verra jamais.

Les contraintes de base de données le détectent rarement. Les systèmes cliniques sources peuvent appliquer leurs propres clés, mais dans un entrepôt de données hospitalier, l'extraction eMAR et le référentiel de la pharmacie proviennent généralement de systèmes différents, et les clés étrangères déclarées sont souvent non reprises ou non appliquées. Le contrôle doit donc s'exécuter sur les données au moment où elles arrivent. Trouver les orphelins à la main tient en une requête :

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 requête est simple. Le plus difficile est de l'exécuter pour chaque relation, à chaque chargement, et de voir le résultat avant que le rapport ne soit diffusé. L'article associé « Enregistrements orphelins : les trouver en SQL et les tenir à l'écart » détaille les modèles SQL, y compris les clés composites et la gestion des NULL.

Comment digna a-t-il détecté le produit manquant ?

Une règle d'intégrité référentielle sur la source de données des administrations vérifiait chaque product_code par rapport au référentiel produits de la pharmacie à chaque inspection. Le 22 avril, 4 244 lignes sur 4 326 ont réussi et 82 ont échoué : le statut de la règle est passé à Failed sur le tableau de bord, et les doses en échec n'étaient plus qu'à un clic.

La règle

La règle se trouve dans digna Data Validation, qui propose trois types de règles : Rule, Uniqueness et Referential Integrity. La configuration de celle-ci a pris six étapes :

1. Dans Configuration, sélectionnez la source de données hospital_medication_administrations, ouvrez l'onglet Data Validation et cliquez sur Add Rule. La boîte de dialogue Add Data Validation Rule s'ouvre.

2. Saisissez un Name (nom) et une Description : hc_product_in_master, « Chaque produit administré existe dans le référentiel produits de la pharmacie ».

3. Réglez Type sur Referential Integrity.

4. Sous Attributes (attributs), choisissez product_code sur cette source de données.

5. Sous must exist in (doit exister dans), choisissez la Data Source hospital_medications et ses Attributes product_code.

6. Réglez Threshold Mode (mode de seuil) sur Absolute, Info threshold 0 et Warn threshold 1, de sorte qu'une seule dose orpheline déclenche déjà un statut Uncertain et que deux ou plus font échouer le contrôle. Enregistrez.

La règle : product_code dans les administrations doit exister dans hospital_medications.product_code.

Aucun SQL à écrire. Dès lors, la règle s'exécute à chaque inspection de la source de données, planifiée ou à la demande. La vidéo L'intégrité référentielle dans digna : configuration en moins d'une minute montre la même configuration en temps réel, et l'article « Comment configurer un contrôle d'intégrité référentielle » détaille chaque champ, y compris les clés composites.

Le résultat

L'inspection du 22 avril a évalué 4 326 administrations. 4 244 ont trouvé leur produit dans le référentiel ; 82 non. Avec un Warn threshold de 1, cela donne un statut Failed sur le tableau de bord, à côté des autres contrôles du jour.

Le tableau de bord du 22 avril : hc_product_in_master, 4 244 sur 4 326 réussies, statut Failed.

Un comptage suffit pour savoir que quelque chose ne va pas. Il ne suffit pas pour savoir quoi faire. Pour cela, il vous faut les lignes.

Les enregistrements en échec

digna renvoie les enregistrements en échec eux-mêmes : le même contrôle avec la condition de réussite inversée, exécuté dans la base de données source. Dans la vue Invalid Records, filtrez sur Failed et choisissez le contrôle Full - hc_product_in_master. Chaque ligne est une dose qui ne pointe nulle part, avec l'hôpital, le service, le département, product_code 3858646 et medication_name Coavira 2.5 mg.

Invalid Records : chaque dose en échec avec l'hôpital, le service, le département et le code produit.

Cette liste répond aux questions qui, sinon, circulent par e-mail pendant une semaine : quel produit, quels services, combien de doses. Elle peut être exportée pour la personne chargée de la correction.

Que fait l'équipe ensuite ?

L'équipe corrige les données de référence, pas les doses. Les administrations sont correctes : le personnel infirmier a administré du Coavira 2.5 mg et l'a documenté. Ce qui manquait, c'était la ligne produit ; le remède consiste donc à l'ajouter au référentiel produits de la pharmacie, à relancer l'inspection et à laisser les rapports reprendre les doses.

1. Lisez les enregistrements en échec et confirmez le schéma. Le même code produit, 3858646, sur chaque ligne en échec indique une entrée manquante dans le référentiel, et non une faute de frappe dans un système de service.

2. Prévenez l'équipe responsable du référentiel produits, ici la pharmacie, et joignez les enregistrements exportés.

3. La pharmacie ajoute Coavira 2.5 mg à hospital_medications.

4. Relancez à la demande l'inspection de la source de données des administrations. Dès que chaque code produit trouve sa correspondance, la règle réussit de nouveau et les doses apparaissent dans les rapports.

5. Actualisez le rapport de consommation. Les 82 doses apparaissent, attribuées aux bons hôpitaux et aux bons services.

Si les enregistrements en échec avaient montré des dizaines de codes différents dans un seul service, la cause aurait été différente, peut-être un problème de correspondance dans une interface, et le responsable aussi. Les enregistrements vous disent dans quel cas vous êtes. C'est la principale raison de regarder les lignes plutôt que les comptages.

Les équipes qui acceptent un court délai entre la première utilisation et la saisie dans le référentiel peuvent relever les seuils ou passer le Threshold Mode en Relative. Pour les données de médication, Danubia les garde stricts.

Quelles relations référentielles comptent dans les données hospitalières et des payeurs ?

Les relations à vérifier sont celles dont dépendent les rapports et la facturation : doses vers produits, venues vers patients, résultats de laboratoire vers demandes d'analyses et venues, occupation des lits vers services, et demandes de remboursement vers assureurs et contrats. Chacune, lorsqu'elle est rompue, supprime des lignes d'une jointure sans erreur, et chacune a un responsable différent.

Deux détails comptent dans les données hospitalières. D'abord, les clés composites : un code service n'est souvent unique qu'au sein d'un hôpital, l'occupation des lits doit donc être vérifiée sur l'hôpital et le service ensemble. Dans digna, vous choisissez plusieurs colonnes des deux côtés, dans le même ordre, et le contrôle porte sur la combinaison. Ensuite, les NULL : les contrôles référentiels ignorent les clés étrangères nulles, de sorte qu'une dose sans aucun code produit n'échoue pas. Si chaque administration doit porter un code produit, ajoutez une règle distincte de type Rule, product_code IS NOT NULL.

L'intégrité référentielle n'est qu'une couche de la validation des données cliniques. Les plages de valeurs, les contrôles de plausibilité et les règles de codage en sont une autre ; Validation des données de santé : règles cliniques et réglementaires à grande échelle les traite.

Pourquoi l'intégrité référentielle se rompt-elle si souvent dans la santé ?

L'intégrité référentielle se rompt souvent dans la santé parce que les enregistrements parents et enfants appartiennent à des services différents, résident dans des systèmes différents et se chargent selon des calendriers différents. La pharmacie gère les produits, le bureau des admissions les patients, le système de laboratoire les demandes d'analyses, les services techniques les unités de soins et la direction financière les assureurs. Chacun est correct dans son propre périmètre ; les jointures entre eux ne sont le travail de personne.

• Les données de référence ont de nombreux propriétaires. Un produit, un service ou un assureur est créé par le département qui s'en occupe, selon son propre processus. Les systèmes qui le référencent l'apprennent plus tard.

• Les systèmes se chargent selon des calendriers différents. La documentation des services peut arriver plusieurs fois par jour, alors qu'un référentiel est actualisé chaque nuit ou après une demande de modification. Tout écart entre les deux produit des orphelins, même si les deux côtés finissent par être corrects.

• Les codes changent. Des produits sont remplacés, des services fusionnés ou renommés, des assureurs changent de codes, des catalogues d'analyses sont révisés. Les enregistrements historiques portent toujours les anciens codes, et un référentiel qui ne conserve que les codes actuels les rend orphelins.

• Les sites fusionnent. Lorsqu'un groupe hospitalier intègre de nouveaux sites dans un reporting commun, des listes de codes qui n'ont jamais été conçues pour aller ensemble se retrouvent dans la même jointure.

• Le parent se trouve dans une autre base de données. Le référentiel produits peut résider dans le système de la pharmacie et les administrations dans l'entrepôt de données cliniques. Depuis la Release 2026.01, digna vérifie l'intégrité référentielle entre différentes connexions de base de données d'un même projet, sans répliquer l'une ou l'autre table.

Rien de tout cela ne signale un hôpital mal géré. C'est l'état normal d'un entrepôt de données hospitalier alimenté par de nombreux systèmes. La différence, c'est de trouver l'écart le jour où il s'ouvre ou la semaine où quelqu'un se plaint.

Où s'exécutent les contrôles, et les données des patients quittent-elles l'hôpital ?

Les contrôles s'exécutent dans la propre base de données de l'hôpital, et les données des patients ne quittent jamais son infrastructure. digna fonctionne sur site ou dans le cloud privé de l'hôpital. Il envoie du SQL à la source, reçoit des comptages et ne récupère les lignes en échec que lorsque vous les demandez. Aucune table n'est copiée à l'extérieur, et l'équipe digna ne voit jamais vos données.

Pour des données cliniques, c'est une condition préalable, pas un détail. Les données de médication, de laboratoire et de venues restent là où vos équipes sécurité et protection des données les encadrent déjà.

Depuis la Release 2026.06, les règles peuvent aussi être gérées sous forme de code : le SDK Python (pip install digna-sdk) gère les projets, les inspections et les règles depuis la CI/CD, et les règles de validation peuvent être exportées de l'environnement de test et importées en production.

Comment démarrer ?

Choisissez la relation dont la défaillance ferait le plus de dégâts, en général doses vers produits ou demandes de remboursement vers assureurs, et ajoutez-lui une règle d'intégrité référentielle. Cela prend quelques champs. Ajoutez ensuite la suivante. Après quelques inspections, vous savez à quelles jointures vous pouvez vous fier et lesquelles perdent des lignes sans bruit.

Si vous souhaitez voir les contrôles de Danubia Kliniken en action et discuter de vos propres données hospitalières ou de payeur, réservez une démo avec l'équipe digna.

Questions fréquentes

Qu'est-ce que l'intégrité référentielle des données de santé ?

Cela signifie que chaque enregistrement qui fait référence à un autre enregistrement pointe vers une ligne qui existe : une dose vers un produit du référentiel de la pharmacie, un résultat de laboratoire vers sa demande d'analyse, une venue vers un patient. Lorsque le parent manque, les jointures écartent la ligne enfant et les rapports sous-comptent sans aucune erreur.

Pourquoi des doses de médicaments disparaissent-elles des rapports hospitaliers ?

Généralement parce que le produit est absent du référentiel produits de la pharmacie. Les rapports joignent les administrations aux produits, et une jointure interne supprime silencieusement les doses sans produit correspondant. Dans la démo Danubia Kliniken, 82 doses d'un nouveau produit apparaissaient comme zéro dans chaque rapport passant par le référentiel.

Comment vérifier les données eMAR par rapport au référentiel produits de la pharmacie ?

Ajoutez une règle Referential Integrity sur la source de données des administrations dans digna Data Validation : choisissez product_code comme attribut, puis sous must exist in, sélectionnez le référentiel produits et son product_code. Chaque inspection indique les lignes réussies et en échec et liste chaque dose orpheline.

Les données des patients quittent-elles l'hôpital lorsque digna exécute ces contrôles ?

Non. digna fonctionne sur site ou dans le cloud privé de l'hôpital, et chaque contrôle s'exécute dans la base de données source. digna envoie du SQL et reçoit des comptages, ainsi que les lignes en échec lorsque vous les ouvrez. Aucune table n'est copiée à l'extérieur, et l'équipe digna ne voit jamais vos données.

Quelles tables d'un entrepôt de données hospitalier nécessitent des contrôles d'intégrité référentielle ?

Commencez par les jointures dont dépendent les rapports et la facturation : administrations de médicaments vers le référentiel produits, venues vers patients, résultats de laboratoire vers demandes d'analyses et venues, occupation des lits vers services sur le code hôpital et le code service, et demandes de remboursement vers assureurs et contrats. Chacune a un responsable différent à prévenir.