Réponse courte : une interface de laboratoire a deux directions. Les commandes vont du DME au système d'information de laboratoire (LIS) sous forme de messages HL7 v2 ORM^O01 ou OML^O21 (ou en FHIR ServiceRequest), et le LIS répond avec ORR/ORL et plus tard avec les résultats sous forme de ORU^R01 (ou FHIR DiagnosticReport avec Observations). Les difficultés ne résident pas dans les messages eux-mêmes, mais dans les détails qu'ils contiennent : les numéros de placeur et de remplisseur qui lient les résultats aux commandes, le statut du résultat (préliminaire, final, corrigé), les indicateurs d'anomalie, les unités et les valeurs de référence, les informations sur le spécimen, la microbiologie avec ses résultats multipartites, et le mappage des codes vers LOINC. Bien réalisés, chaque résultat arrive sur le bon patient, la bonne commande et au bon endroit dans le dossier, avec son sens intact.
Étape 1 : accord sur les flux
La première étape de l'intégration d'un système d'information de laboratoire avec un DPI consiste à convenir avec le laboratoire des flux existants : commandes sortantes, mises à jour du statut des commandes, résultats entrants, corrections, annulations, tests supplémentaires et réflexes, ainsi qu'un flux de données démographiques ADT vers le SIL. Les parties fixent également la version HL7, généralement 2.3.1 ou 2.5.1, et le transport, typiquement MLLP avec accusés de réception.
Décidez avec le laboratoire quels flux existent : commandes sortantes (ou le laboratoire reçoit-il du papier et s'enregistre-t-il lui-même ?), mises à jour du statut des commandes, résultats entrants, corrections, annulations, tests additionnels, tests réflexes, et données démographiques (flux ADT vers le LIS pour qu'il connaisse le patient avant l'arrivée du spécimen). Dessinez la séquence pour un résultat normal, un résultat corrigé et une commande annulée. Décidez de la version HL7 (2.3.1 et 2.5.1 sont les plus courantes) et du transport (MLLP avec ACKs ; parfois des fichiers). Voir Messages de commande HL7 v2.
Étape 2 : le message de résultat, champ par champ
Un résultat de laboratoire arrive au DPI sous forme de message HL7 v2 ORU^R01 : MSH identifie l'expéditeur et le destinataire, PID le patient, PV1 la visite, ORC et OBR portent les numéros de commande du placeur et du remplisseur, le panel commandé et le statut du rapport, et chaque OBX contient un analyte avec son code LOINC, sa valeur, ses unités, sa plage de référence, son indicateur d'anomalie et son statut de résultat.
MSH|^~\&|LIS|CENTRALLAB|EHR|GENHOSP|20260314130500||ORU^R01^ORU_R01|RES0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F
PV1|1|O|CLINIC-3^^^GENHOSP
ORC|RE|PLC-778812^EHR|FIL-556701^LIS|||||||||42^SMITH^JOHN
OBR|1|PLC-778812^EHR|FIL-556701^LIS|58410-2^CBC panel - Blood by Automated count^LN|||20260314084000|||||||||42^SMITH^JOHN||||||20260314130000|||F
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||10.9|g/dL|12.0-15.5|L|||F|||20260314125800
OBX|2|NM|6690-2^Leukocytes [#/volume] in Blood by Automated count^LN||6.4|10*3/uL|4.0-10.0|N|||F|||20260314125800
OBX|3|NM|777-3^Platelets [#/volume] in Blood by Automated count^LN||230|10*3/uL|150-400|N|||F|||20260314125800
NTE|1||Mild normocytic anaemia; suggest iron studies if clinically indicated.
- ORC-2 / OBR-2 numéro de placeur et ORC-3 / OBR-3 numéro de remplisseur : le lien vers la commande. OBR-4 : le panel, codé (LOINC
LN). OBR-7 : heure de collecte du spécimen. OBR-22 : heure du rapport de résultats. OBR-25 : statut du résultat pour toute la commande (Ppréliminaire,Ffinal,Ccorrigé,Xannulé). - OBX-2 : type de valeur (
NMnumérique,STchaîne,TXtexte,CE/CWEcodé,SNnumérique structuré tel que<^5). OBX-3 : l'analyte, codé. OBX-5 : la valeur. OBX-6 : unités, idéalement UCUM (10*3/uL, pasK/µL). OBX-7 : plage de référence sous forme de texte. OBX-8 : indicateurs d'anomalie (L,H,LL,HH,A,N). OBX-11 : statut du résultat par analyte (P,F,C,X,Dsupprimé). OBX-14 : heure d'observation. OBX-19 : heure d'analyse. - NTE : commentaires, attachés à l'OBR ou à un OBX spécifique par position.
- SPM (2.5+) : type de spécimen (SNOMED CT), heure de collecte, heure de réception, condition.
Étape 3 : les cas spéciaux
Les cas spéciaux qu'une interface de laboratoire doit gérer sont les résultats corrigés (statut C avec les numéros de commande d'origine, remplaçant et alertant plutôt que supprimant), les résultats préliminaires puis finaux, la microbiologie avec les organismes et les susceptibilités liés par un sous-ID, les résultats textuels et les PDF intégrés, les tests réflexes et supplémentaires, les annulations, ainsi que les unités et les plages de référence qui changent lorsque le laboratoire change d'analyseur.
- Corrections : un nouvel ORU avec
Cdans OBR-25 et OBX-11 et les mêmes numéros de placeur/remplisseur ; le DME doit remplacer, signaler le changement et alerter le clinicien. Ne jamais supprimer l'original silencieusement. - Préliminaire puis final : résultats
P(une coloration de Gram) suivis deF(la culture) ; le dossier doit afficher le statut. - Microbiologie : un OBX pour l'organisme identifié (codé, SNOMED CT), puis les résultats de sensibilité en tant qu'OBX par antibiotique avec l'organisme comme sous-ID (OBX-4), souvent sur plusieurs messages. C'est là que se cachent la plupart des bugs d'interface.
- Résultats textuels et PDF : la pathologie et certains commentaires de chimie arrivent sous forme de lignes TX ou de PDF intégré (OBX-2
ED) ; le dossier a besoin à la fois du texte et du fichier. - Tests réflexes et additionnels : nouveaux OBR sous la commande d'origine, ou une nouvelle commande créée par le laboratoire ; convenir de leur numérotation.
- Annulations : statut
X, avec les numéros d'origine. - Unités et plages par analyseur : le même test peut changer d'unités lorsque le laboratoire change d'analyseur ; l'interface doit transporter la plage avec chaque résultat, sans la supposer.
Étape 4 : codes
Le mappage des codes dans une interface de laboratoire signifie traduire les codes de test locaux du laboratoire en LOINC une seule fois, dans une table maintenue, et envoyer à la fois le code local et le code LOINC dans OBX-3, normaliser les unités en UCUM, et coder les types de spécimens et les organismes en SNOMED CT. Sans ce mappage, les résultats ne peuvent pas être suivis entre les laboratoires ni lus par des systèmes externes.
Mappez les codes de test du laboratoire à LOINC une fois, dans une table maintenue, et envoyez les codes locaux et LOINC dans OBX-3 (GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN). Normalisez les unités en UCUM. Types de spécimens et organismes en SNOMED CT. La méthode est décrite dans Comment mapper les codes de laboratoire locaux à LOINC ; sans cela, les résultats ne peuvent pas être suivis sur plusieurs laboratoires ni lus par un système externe.
Étape 5 : l'alternative FHIR
L'alternative FHIR à une interface de laboratoire HL7 v2 utilise un ServiceRequest pour la commande, un Observation par analyte avec un code LOINC, une quantité UCUM, une plage de référence et une interprétation, et un DiagnosticReport qui les regroupe avec le statut, le performeur, l'heure d'émission, la conclusion et le PDF. La livraison se fait par écrit REST, un Bundle de transaction par rapport, ou des Abonnements FHIR.
Avec FHIR, la commande est une ServiceRequest, les résultats sont des Observations (une par analyte, code LOINC, quantité UCUM, referenceRange, interpretation) regroupées par un DiagnosticReport qui porte le statut, le performeur, l'heure d'émission, la conclusion et le PDF, avec basedOn pointant vers la ServiceRequest. Les corrections sont des versions des mêmes ressources avec le statut amended ou corrected. La livraison se fait par écritures REST sur le serveur FHIR du DME, un Bundle de transaction par rapport, ou des Subscriptions. Le guide HL7 v2-vers-FHIR mappe chaque champ ci-dessus ; de nombreux laboratoires proposent désormais les deux. Voir DiagnosticReport FHIR expliqué et Observation FHIR expliquée.
Étape 6 : tests et mise en production
Tester une interface de laboratoire avant la mise en service signifie exécuter des patients synthétiques à travers chaque cas spécial, comparer une journée de résultats parallèles entre le rapport du laboratoire et le dossier du DPI, vérifier les fuseaux horaires et les transitions d'heure d'été, vérifier la gestion des accusés de réception et la relecture après une panne, et convenir d'une procédure d'astreinte pour les messages échoués, en utilisant le profil IHE Laboratory Testing Workflow comme référence.
Testez avec des patients synthétiques à travers chaque cas de l'étape 3 ; comparez une journée de résultats parallèles entre le rapport papier ou PDF et le dossier ; vérifiez les fuseaux horaires et les transitions d'heure d'été/hiver ; vérifiez la gestion des ACKs et la relecture après une panne ; convenez d'une procédure d'astreinte pour les messages échoués. Le profil Laboratory Testing Workflow de l'IHE et les suites de conformité nationales fournissent une base testée.
Échecs à anticiper
Les échecs contre lesquels une interface de laboratoire doit être conçue sont les résultats déposés dans une rencontre précédente, les fusions de patients non appliquées au SIL, les changements d'unités après une mise à niveau d'analyseur décalant les tendances, les résultats corrigés écrasant sans alerte, les susceptibilités de microbiologie attachées au mauvais organisme, et les résultats de tests pour lesquels le DPI n'a pas de code disparaissant dans une file d'attente d'erreurs.
Résultats classés dans une rencontre précédente car PV1 était obsolète ; une fusion (ADT A40) non appliquée au LIS ; un changement d'unité après une mise à niveau d'analyseur décalant silencieusement les tendances ; des résultats corrigés écrasant sans alerte ; des sensibilités de microbiologie attachées au mauvais organisme ; un laboratoire envoyant des résultats pour un test pour lequel le DME n'a pas de code, qui disparaissent alors dans une file d'erreurs.
Dans Anpheros
Le connecteur de laboratoire Anpheros accepte ORU^R01, CSV et JSON et produit des Observations sous un DiagnosticReport avec LOINC et UCUM, en conservant les codes locaux et le fichier d'origine ; le guide développeur sur l'importation des résultats de laboratoire en détaille le fonctionnement avec la sandbox gratuite.
Pages associées
- Messages de commande HL7 v2 ORM et OML
- Messages HL7 v2 expliqués : ADT et ORU
- Comment mapper les codes de laboratoire locaux à LOINC
- DiagnosticReport FHIR expliqué
- Connecteur de laboratoire : HL7 v2, CSV ou JSON vers FHIR
- Moteurs d'interface expliqués
- Importer les résultats de laboratoire dans FHIR (site développeur)
Sources
- Référence HL7 v2.5.1 ORU_R01 (Caristix)
- Segment HL7 v2.5.1 OBX (Caristix)
- Cadre technique IHE Laboratoire (LTW)
- Guide d'implémentation HL7 v2 vers FHIR
- HL7 FHIR R4 : DiagnosticReport
Questions fréquentes
Quelle version HL7 une nouvelle interface de laboratoire devrait-elle utiliser ?
2.5.1 si les deux parties le prennent en charge : il dispose de SPM pour les spécimens et d'une gestion plus claire du statut. De nombreux laboratoires utilisent encore la version 2.3.1, et l'interface s'adapte au côté le plus ancien.
Comment les résultats sont-ils associés aux commandes ?
Par le numéro de commande du placeur (attribué par le DME) et le numéro de commande du remplisseur (attribué par le LIS), transportés dans ORC-2/3 et OBR-2/3 de la réponse de commande et du résultat. Si le DME n'a jamais enregistré le numéro du remplisseur, l'association se rabat sur le numéro du placeur.
Que faire si le laboratoire ne peut pas envoyer de codes LOINC ?
Mappez leurs codes locaux à LOINC de votre côté, dans le moteur ou le connecteur, et conservez les deux. Insistez pour que le système de codes local soit stable et que les nouveaux tests soient annoncés.
FHIR est-il prêt pour les interfaces de laboratoire ?
Oui pour les nouvelles connexions, surtout en dehors de l'hôpital : ServiceRequest, Observation et DiagnosticReport couvrent entièrement les commandes et les résultats, et les guides nationaux les décrivent. À l'intérieur de l'hôpital, le LIS et les analyseurs parleront HL7 v2 pendant des années.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte

