# 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.

Auteur: Ala Ben Aicha

Page de référence: https://alabenaicha.me/fr/insights/migration-hl7v2-fhir-hopitaux

Mise à jour: 2026-09-17

## 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](https://alabenaicha.me/fr/insights/hl7v2-to-fhir-migration-strategy) 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](https://alabenaicha.me/fr/insights/hl7-adt-to-fhir-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](https://hl7.org/fhir/uv/v2mappings/) (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](https://esante.gouv.fr/doctrine/interoperabilite). 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](https://hl7.fr/ig/fhir/core/StructureDefinition-fr-core-patient-ins.html) | 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)

1. Inventaire : émetteur, version, volume, identifiants, dépendance clinique.
2. 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).
3. Phase ombre en lecture : réconcilier manquants, doublons, corrections tardives.
4. Un seul chemin d'écriture ; prévention de boucle ; politique de replay.
5. 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](https://alabenaicha.me/fr/services/hl7-fhir-integration). Pour un spike borné, utilisez le [contact avec intention projet](https://alabenaicha.me/fr/contact?intent=project).