Migration HL7 v2 vers FHIR dans les hôpitaux francophones
Inventaire d’interfaces pour un SIH francophone : ADT/ORM/ORU, HPRIM Santé, overlay INS, et le guide HL7 v2-to-FHIR 1.0.0 STU 1 comme contrat de mapping — pas un remplacement du v2.
Ala Ben Aicha
Réponse directe
Ne coupez pas le v2. Inventoriez ADT, ORM/ORU et, en France, HPRIM. Projetez PID vers Patient avec l'INS (OID 1.2.250.1.213.1.4.8). Le guide HL7 v2-to-FHIR 1.0.0 STU 1 est le contrat de départ, pas un remplacement.
Pas le playbook d'architecture, l'inventaire francophone
La page anglaise HL7 v2 to FHIR migration décrit l'architecture hybride (moteur d'intégration, ombre, bascule). Celle-ci est l'inventaire qu'un hôpital francophone doit poser avant cette architecture : quels protocoles parlent vraiment, quels identifiants franchissent le pare-feu, quel overlay national se colle sur le Patient projeté. Le détail A01/A04/A08/A03 (PID-3, PV1-19) est dans ADT → Patient / Encounter — je ne le réécris pas.
Contrat de mapping de départ : HL7 Version 2 to FHIR IG 1.0.0 STU 1 (généré le 7 octobre 2025). URL officielle : http://hl7.org/fhir/uv/v2mappings/ImplementationGuide/hl7.fhir.uv.v2mappings. Package : hl7.fhir.uv.v2mappings#1.0.0 sur FHIR R4. C'est une carte cumulative du standard, pas un IG national français.
Trois syntaxes qui ne sont pas un seul canal
En France, Interop'Santé maintient encore HPRIM (XML / HPRIM Santé) et PN13-IS, à côté de HL7 v2 et des volets CI-SIS. Un SIL de laboratoire peut émettre un ORU HL7 2.5.1, un ORU HPRIM Santé 2.4, ou les deux. Les traiter comme « du v2 » dans un seul canal Mirth, c'est mélanger les tables de codes et les identifiants.
| Source | Déclencheur typique | Cible FHIR (départ IG STU 1) | Overlay francophone |
|---|---|---|---|
| HL7 v2 ADT | A01, A04, A08, A03 | Patient + Encounter |
INS sur Patient.identifier ; IPP en plus, pas à la place |
| HL7 v2 ORM / OML | O01 / O21 | ServiceRequest |
Prescripteur = IDNatPS (urn:oid:1.2.250.1.71.4.2.1), pas un nom en ST |
| HL7 v2 ORU | R01 | DiagnosticReport + Observation |
Code LOINC si le volet l'exige ; le code HPRIM local ne suffit pas à l'EHDS |
| HPRIM Santé | ORM, ORA, ORU | Mêmes ressources, autre parseur | Table HPRIM 1 (contexte) et type de liaison (L/C/R) ≠ MSH-9 |
| PN13-IS | Pharmacie / prescriptions | MedicationRequest / dispense selon le volet |
Ce n'est pas un MedicationRequest EHDS MPD |
| CDA CI-SIS (transport HL7 v2) | MDM / document | DocumentReference / Binary |
Un CDA dans un MLLP n'est pas un Patient Summary EEHRxF |
HPRIM Santé 2.5 documente ORM (demandes), ORA (demandes + admin), ORU (résultats). Le champ de version / type de liaison n'est pas MSH-12. Si votre inventaire dit « tout le labo est en HL7 », ouvrez un fichier réel.
Identifiants : IPP, INS, et ce que PID-3 ne dit pas
PID-3 est une liste. En France, au moins trois autorités d'affectation se marchent dessus si vous n'en faites pas des identifier.system distincts :
| Identifiant | Système à pinner | Où il vit aujourd'hui | Piège à la projection FHIR |
|---|---|---|---|
| IPP | OID / URI de l'établissement | PID-3 local, HPRIM, DPI | L'upsert FHIR sur l'IPP seul crée des doublons trans-établissements |
| INS-NIR | urn:oid:1.2.250.1.213.1.4.8 |
Téléservice INSi, profil FR Core Patient INS | Recopier le NIR depuis une carte sans statut VALI |
| INS-NIA | urn:oid:1.2.250.1.213.1.4.9 |
Identité d'attente | Le fusionner avec le NIR dans le même slice |
| N° de séjour | OID local | PV1-19 (voir l'article ADT) | S'en servir comme Patient.identifier |
| RPPS / IDNatPS | urn:oid:1.2.250.1.71.4.2.1 |
PV1, ORC, HPRIM | Un code interne de prescripteur |
Le Patient projeté pour un usage national ou européen doit porter l'INS conforme FR Core, pas seulement l'IPP du SIH. L'INS ne s'invente pas dans le mapper : INSi, puis slice INS-NIR / INS-NIA. Les fixtures publiques utilisent les OID TEST/DEMO (1.2.250.1.213.1.4.10 / .4.11), jamais un NIR réel.
Exemple de-identifié (MSH tronqué, pas un message de production) :
MSH|^~\&|SIH|ETAB||DEST|20260917103000||ADT^A01|MSG-EXEMPLE|P|2.5
PID|||IPP-EXEMPLE^^^ETAB^PI||EXEMPLE^JEAN^^^^^D||19700101|M
PV1||I|||||||||||||||||SEJ-EXEMPLE|||||||||||||||||||||||||20260917103000
Le mapper : IPP-EXEMPLE + system établissement → Patient.identifier ; le séjour → Encounter.identifier (PV1-19), pas un second Patient. L'INS n'apparaît pas dans ce fragment : c'est volontaire. Sans INSi, vous n'avez pas d'identité VALI.
Ombre, bascule, rollback (rappel court)
- Inventaire : émetteur, version, volume, identifiants, dépendance clinique.
- Règles de mapping sur plusieurs messages réels de-identifiés (A08 de correction, ORU tardif, HPRIM et v2 pour le même examen).
- Phase ombre en lecture : réconcilier manquants, doublons, corrections tardives.
- Un seul chemin d'écriture ; prévention de boucle ; politique de replay.
- Rollback testé : couper le writer FHIR, restaurer le routage v2/HPRIM, rejouer sans dupliquer les ordres.
Les durées « 4–8 semaines » d'un spike sont illustratives, pas un devis. Le playbook anglais détaille l'architecture moteur ; ici, le livrable est la matrice source × identifiant × cible signée par le propriétaire d'interface.
Ce que cette page n'est pas
Ce n'est pas un rip-and-replace, pas une certification ANS, pas un mapping HPRIM officiel Interop'Santé, pas un avis juridique, pas un conseil clinique. Le guide STU 1 ne publie pas une ConceptMap dédiée pour chaque déclencheur français. Je ne « migre » pas votre SIH dans un article.
Si vous avez besoin du moteur et des maps (v2, HPRIM, FHIR, INS), c'est l'intégration HL7 / FHIR. Pour un spike borné, utilisez le contact avec intention projet.