Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

FHIR vs HL7 v2 : différences pratiques

Messages HL7 v2 et ressources FHIR comparés pour les développeurs : format, transport, le même résultat de laboratoire dans les deux, pièges de traduction, et où Anpheros accepte v2.

HL7 v2 est le format de message que les systèmes hospitaliers échangent depuis la fin des années 1980 — des événements délimités par des pipes tels que "patient admis" ou "résultat de laboratoire prêt" poussés entre les systèmes via une connexion réseau — tandis que HL7 FHIR est une norme d'API web où les applications lisent et écrivent des ressources telles que Patient et Observation sur HTTPS en JSON. Ce ne sont pas des alternatives que l'on choisit une fois pour toutes : la plupart des hôpitaux fonctionnent encore en interne avec v2, les nouvelles applications et les API orientées patient utilisent FHIR, et le travail d'intégration consiste souvent à traduire l'un dans l'autre. Cette page les compare sur les points importants lorsque vous écrivez du code, montre les mêmes données dans les deux formats, et explique où Anpheros accepte v2.

Côte à côte

	HL7 v2	HL7 FHIR R4
Style	Messages déclenchées par des événements (admission, commande, résultat)	Ressources que vous créez, lisez, mettez à jour, recherchez
Format	Segments de texte séparés par des sauts de ligne, champs par `\\|`, composants par `^`	JSON (ou XML)
Transport	Généralement MLLP sur TCP à l'intérieur du réseau hospitalier	HTTPS REST
Requête	Limitée ; les systèmes poussent principalement	Paramètres de recherche, `_include`, historique
Sécurité	Niveau réseau (VPN, liens privés)	OAuth 2.0 / SMART on FHIR, TLS, scopes
Flexibilité	Nombreux champs optionnels et segments Z locaux ; chaque interface est négociée	Ressources de base plus profils (US Core, IPS, IGs européens)
Utilisateurs typiques	EHR, systèmes de laboratoire, de radiologie, de facturation au sein d'un hôpital	Applications, APIs d'accès patient, échange inter-organisations, IA

Les messages v2 les plus courants :

Message	Signification	Ressources FHIR les plus proches
ADT^A01, A03, A08	Admission, sortie, mise à jour patient	`Patient`, `Encounter`
ORM / OML	Commander un test	`ServiceRequest`
ORU^R01	Résultat prêt	`Observation`, `DiagnosticReport`
SIU	Planification	`Appointment`
MDM	Document	`DocumentReference`

Le même résultat de laboratoire dans les deux

Une ligne de résultat ORU^R01 (segment OBX) :

OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500

Le même résultat en tant qu'Observation HL7 FHIR R4, tel qu'Anpheros le stocke après l'importation de ce message :

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
  "effectiveDateTime": "2026-10-02T07:45:00Z",
  "valueQuantity": {"value": 212.0, "unit": "mg/dL"},
  "interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
  "referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}

Champ par champ : OBX-3 devient code, OBX-5 et OBX-6 deviennent valueQuantity, OBX-7 referenceRange, OBX-8 interpretation, OBX-11 status, OBX-14 effectiveDateTime. HL7 publie un guide d'implémentation officiel HL7 Version 2 vers FHIR avec des mappages pour les segments, les types de données et les vocabulaires.

Là où les traductions échouent

Fuseaux horaires. Les horodatages v2 tels que 20261002074500 ne comportent souvent aucun décalage ; vous devez connaître le fuseau horaire de l'expéditeur. FHIR exige un fuseau horaire chaque fois qu'une heure est présente. (Anpheros interprète une heure v2 sans fuseau horaire comme UTC ; envoyez le décalage si vous le possédez.)
Codes locaux. De nombreux laboratoires placent leurs propres codes dans OBX-3 au lieu de LOINC. Une bonne traduction conserve le code local et le mappe à LOINC lorsque c'est possible, plutôt que de le supprimer.
Envois répétés. Les expéditeurs v2 retransmettent en cas de timeouts. Sans identifiant stable par résultat, un magasin FHIR se remplit de doublons.
Tout est optionnel. Le même champ peut être vide, répété ou utilisé différemment par deux expéditeurs. Validez le côté FHIR ; le validateur FHIR R4 montre ce qui manque à une ressource traduite.
Corrections. Le statut de résultat v2 C (corrigé) doit mettre à jour l'Observation existante et conserver son historique, et non en créer une seconde.

Quand utiliser quoi

À l'intérieur d'un hôpital, entre systèmes existants : v2 est généralement ce que les systèmes utilisent. Un moteur d'intégration route et transforme les messages.
Développement d'une application, d'une API d'accès patient ou de tout ce qui traverse les organisations : FHIR, avec OAuth et consentement.
Alimentation de l'IA ou de l'analytique : FHIR, car il est interrogeable, codé et versionné.
Les deux : le schéma courant dans le monde réel — recevoir v2 du laboratoire ou du DME, stocker FHIR, servir FHIR aux applications.

Où Anpheros s'intègre

Anpheros stocke les dossiers patients au format FHIR R4 et accepte un type de message HL7 v2 : ORU^R01 résultats de laboratoire, envoyé via HTTPS au connecteur de laboratoire (POST /v1/patients/{id}/labs/import avec Content-Type: x-application/hl7-v2+er7). Chaque OBX devient une Observation de laboratoire avec un code LOINC, une plage de référence et une interprétation ; l'identifiant du rapport est conservé dans la provenance et les rapports renvoyés sont ignorés. Un résultat corrigé (OBX-11 = C) avec une nouvelle valeur est stocké comme une nouvelle Observation avec le statut amended ; l'original reste tel quel, donc si votre source envoie des corrections, marquez l'Observation précédente entered-in-error ou mettez-la à jour via l'API FHIR. Un exemple concret est API de résultats de laboratoire.

Il n'accepte pas d'autres messages v2 (ADT, commandes, planification), n'écoute pas sur MLLP et n'envoie pas de v2. Pour ceux-ci, un moteur d'intégration devant Anpheros traduit en FHIR et écrit via l'API.

Foire aux questions

FHIR remplace-t-il HL7 v2 ?

Pas bientôt. v2 reste l'épine dorsale de la plupart des hôpitaux car il fonctionne et est intégré dans les systèmes existants. FHIR se développe autour de lui — dans les applications, l'accès patient et l'échange entre organisations — et les deux coexistent, souvent avec une traduction entre eux.

Qu'est-ce que MLLP ?

Le Minimal Lower Layer Protocol : une manière simple de cadrer les messages v2 sur une connexion TCP, avec des caractères de début et de fin autour de chaque message et un accusé de réception (ACK) en retour. FHIR utilise HTTPS à la place.

Puis-je convertir automatiquement les messages HL7 v2 en FHIR ?

En grande partie. Le guide d'implémentation v2-vers-FHIR de HL7 donne des mappages standard, et les moteurs d'intégration les implémentent. Attendez-vous à un travail manuel pour les codes locaux, les segments Z, les fuseaux horaires et la manière dont chaque expéditeur utilise les champs optionnels.

Anpheros accepte-t-il HL7 v2 ?

Oui, pour les résultats de laboratoire : les messages ORU^R01 publiés via HTTPS vers le connecteur de laboratoire deviennent des Observations FHIR. Les autres types de messages v2 et les connexions MLLP ne sont pas pris en charge.

Liens connexes

Mappage HL7 v2 vers FHIR : mappage segment et champ, et un convertisseur
API des résultats de laboratoire : HL7 v2, FHIR et LOINC
Comment importer des résultats de laboratoire dans un enregistrement FHIR
Interopérabilité des données de santé
DICOM vs FHIR : données d'imagerie et données cliniques
Plateforme FHIR

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card