Messages de commande HL7 v2 ORM et OML expliqués

En HL7 v2, une demande (un test de laboratoire, un examen d'imagerie, un médicament) est envoyée sous forme de message ORM^O01 dans les versions jusqu'à 2.5.1, ou sous forme de message de demande de laboratoire OML^O21 à partir de la version 2.4. Les deux transportent le patient (PID), la visite (PV1), le segment ORC qui contrôle la demande (nouvelle, annulation, mise en attente, changement de statut, avec les numéros du placeur et du réalisateur) et le segment OBR qui indique ce qui a été demandé, par qui et pour quand. Le système réalisateur répond avec un ORR (ou ORL pour OML) et renvoie plus tard les résultats sous forme d'ORU. L'équivalent FHIR de ORC+OBR est une ServiceRequest.

Une demande de laboratoire, segment par segment

Un message de demande de laboratoire HL7 v2 (ORM^O01) est construit à partir de segments : MSH nomme le type de message et la version, PID identifie le patient, PV1 décrit la visite, ORC contient le code de contrôle de la demande, les numéros de demande du placeur et du réalisateur, la priorité et le fournisseur de la demande, OBR nomme le test demandé avec un code LOINC et l'heure de prélèvement, et DG1 donne le diagnostic justifiant la demande.

MSH|^~\&|EHR|GENHOSP|LIS|CENTRALLAB|20260314091200||ORM^O01^ORM_O01|MSG0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F|||12 High Street^^Leeds^^LS1 4AB^GB
PV1|1|O|CLINIC-3^^^GENHOSP||||42^SMITH^JOHN^^^Dr
ORC|NW|PLC-778812^EHR|||||^^^20260314093000^^R||20260314091200|42^SMITH^JOHN
OBR|1|PLC-778812^EHR||4548-4^Hemoglobin A1c/Hemoglobin.total in Blood^LN|||20260314093000||||||||42^SMITH^JOHN
DG1|1||E11.9^Type 2 diabetes mellitus without complications^I10

MSH-9 ORM^O01^ORM_O01 nomme le type de message, l'événement déclencheur et la structure. MSH-12 donne la version.
PID identifie le patient ; PID-3 contient l'identifiant avec son autorité d'attribution et son type (MR, numéro de dossier médical).
PV1 donne la visite : ambulatoire (O), le lieu, le clinicien traitant.
ORC-1 est le code de contrôle de la demande : NW nouvelle demande, CA demande d'annulation, OC demande annulée, HD mise en attente, RL libération, SC changement de statut, OK demande acceptée, UA impossible à accepter, XO modification de demande, DC arrêt. ORC-2 est le numéro de demande du placeur (attribué par le système demandeur), ORC-3 le numéro de demande du réalisateur (attribué par le laboratoire, vide jusqu'à sa réponse). ORC-7 contient le calendrier et la priorité (R routine, S stat, A asap). ORC-12 est le fournisseur de la demande.
OBR-4 est l'identifiant universel du service : ce qui a été demandé, codé (ici LOINC, LN). OBR-7 est la date et l'heure de l'observation ou de la collecte. OBR-16 répète le fournisseur de la demande. Dans les demandes de laboratoire, les détails de l'échantillon se trouvent dans OBR-15 dans les versions plus anciennes et dans un segment SPM dédié à partir de 2.5.
DG1 transporte le diagnostic qui justifie la demande.

La même demande avec plusieurs tests répète la paire ORC/OBR une fois par test, chacun avec son propre identifiant de jeu OBR-1.

ORM vs OML

ORM^O01 est le message de demande général HL7 v2, une structure souple pour les laboratoires, la radiologie, la pharmacie et les fournitures. OML, introduit dans la version 2.4, est le message de demande spécifique au laboratoire avec les déclencheurs O21, O33 et O35 et des segments SPM et SAC explicites pour les spécimens et les conteneurs. La plupart des interfaces hôpital-laboratoire utilisent encore ORM^O01 ; OML apparaît dans les systèmes de laboratoire plus récents et les profils IHE.

ORM^O01 est le message de demande général : une structure pour le laboratoire, la radiologie, la pharmacie, l'alimentation et les fournitures, ce qui le rendait peu précis. À partir de la version 2.4, HL7 a introduit OML (demande de laboratoire) avec plusieurs déclencheurs, O21 (demande par test), O33 (demande par échantillon) et O35 (demande par échantillon et conteneur), et une structure plus stricte avec les segments SPM et SAC pour les échantillons et les conteneurs. OMG (demande clinique générale), OMI (imagerie), OMP (pharmacie) ont suivi le même schéma. En pratique, la plupart des interfaces hôpital-laboratoire fonctionnent encore sur ORM^O01 en version 2.3.1 ou 2.5.1, et OML apparaît dans les systèmes de laboratoire plus récents et dans le profil IHE Laboratory Testing Workflow.

Réponses

Une demande HL7 v2 reçoit deux réponses. Un ACK immédiat (MSA-1 AA, AE ou AR) confirme que le message a été reçu et analysé. Ensuite, une réponse applicative, ORR^O02 pour ORM ou ORL^O22 pour OML, répète l'ORC avec OK ou UA et remplit l'ORC-3, le numéro de demande du réalisateur. Les résultats reviennent plus tard sous forme d'ORU^R01 portant les deux numéros de demande.

Le système récepteur répond deux fois. Immédiatement, avec un ACK (MSA-1 AA acceptation, AE erreur, AR rejet) qui confirme que le message a été reçu et analysé. Ensuite, en tant que réponse applicative, avec ORR^O02 (pour ORM) ou ORL^O22 (pour OML), répétant l'ORC avec OK ou UA et remplissant l'ORC-3, le numéro de demande du réalisateur, que les deux parties utilisent à partir de ce moment-là. Les résultats reviennent sous forme d'ORU^R01, avec les mêmes numéros de placeur et de réalisateur dans OBR-2 et OBR-3, ce qui permet à un résultat de retrouver sa demande. Voir Messages HL7 v2 expliqués : ADT et ORU.

Là où les demandes échouent

Les demandes HL7 v2 échouent le plus souvent en raison de numéros de placeur et de réalisateur non concordants lorsque l'ORR n'a pas été traité, de codes de test locaux dans OBR-4 sans code LOINC, d'annulations envoyées sans le numéro de placeur d'origine, de divergences de version telles qu'un segment SPM envoyé à un récepteur 2.3.1, et de priorités écrites dans un champ libre NTE au lieu de ORC-7 ou OBR-5.

Numéros qui ne correspondent pas : l'ORU revient avec un numéro de réalisateur que le DME n'a jamais vu, généralement parce que l'ORR n'a pas été traité.
Codes locaux dans OBR-4 : le code de test interne d'un laboratoire au lieu d'un code LOINC (ou sans celui-ci), de sorte que le dossier récepteur ne peut pas mapper le test. La solution est un code avec les deux : GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN.
Annulations sans les numéros d'origine : CA doit porter le numéro du placeur de la demande qu'il annule.
Incompatibilités de version : un segment SPM envoyé à un récepteur 2.3.1 est ignoré ou rejeté.
Priorité dans le mauvais champ : STAT dans un NTE texte libre au lieu de ORC-7 ou OBR-5.

La même demande en FHIR

Dans FHIR, les segments ORC et OBR d'une demande HL7 v2 sont regroupés en une seule ServiceRequest avec le statut, l'intention de demande, la priorité, un code LOINC, le sujet, la rencontre, le demandeur, la date/heure d'occurrence, le code de raison pour le diagnostic et les identifiants pour les numéros de placeur et de réalisateur. L'Observation et le DiagnosticReport résultants y font référence via basedOn, comme le guide d'implémentation HL7 v2 vers FHIR le cartographie.

En FHIR, ORC et OBR fusionnent en une seule ServiceRequest : status (active, on-hold, revoked, completed), intent (order), priority (routine, urgent, asap, stat), code (le test LOINC), subject, encounter, requester, occurrenceDateTime, reasonCode (le diagnostic ICD-10) et identifier pour les numéros du placeur et du réalisateur. L'Observation et le DiagnosticReport de résultat pointent en arrière avec basedOn. HL7 publie le mappage champ par champ dans le guide d'implémentation v2-to-FHIR.

La plateforme Anpheros prend en charge ServiceRequest, Observation et DiagnosticReport, et son connecteur de laboratoire accepte les résultats en HL7 v2 ORU, CSV ou JSON. Il n'envoie ni ne reçoit de demandes ; la commande reste dans les systèmes de l'hôpital ou du laboratoire, et le résultat final rejoint le dossier du patient.

Pages associées

Sources

Questions fréquentes

Quelle est la différence entre ORC et OBR ?

ORC concerne la demande en tant qu'objet administratif : qui l'a passée, ses numéros, son statut, sa priorité. OBR concerne le service demandé : quel test, sur quel échantillon, quand. Chaque OBR est précédé de son ORC.

Qu'est-ce qu'un placeur et un réalisateur ?

Le placeur est le système qui demande le service (le DME ou le système du médecin prescripteur) ; le réalisateur est le système qui l'exécute (le système de laboratoire ou de radiologie). Chacun attribue son propre numéro de demande, et les messages transportent les deux afin que l'une ou l'autre partie puisse trouver la demande.

Dois-je implémenter ORM ou OML pour une nouvelle interface de laboratoire ?

Si le partenaire prend en charge OML^O21 dans la version 2.5.1 ou ultérieure, privilégiez-le : la gestion des échantillons est explicite et les profils IHE sont basés dessus. Si le partenaire est un LIS plus ancien, ORM^O01 est ce qu'il parle, et vous vous adaptez.

Comment une demande HL7 v2 est-elle mappée à FHIR ?

ORC et OBR deviennent ensemble une ServiceRequest ; les numéros du placeur et du réalisateur deviennent des identifiants ; ORC-1 et ORC-5 sont mappés au statut ; OBR-4 au code ; DG1 à reasonCode ; le fournisseur de la demande à requester. Le guide HL7 v2-to-FHIR publie les tableaux détaillés.

Anpheros Platform

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.

Créer un sandbox gratuit Lire les guides développeurs →

Gratuit · 30 patients synthétiques · sans carte

Ce guide est informatif et ne remplace pas une consultation médicale. Pour toute décision concernant votre santé, parlez-en à votre médecin. En cas d’urgence, appelez le numéro d’urgence local (112 en Europe).

Rédigé par

L'équipe Anpheros

Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.

À propos d'Anpheros →