# Mappage HL7 v2 vers FHIR

> Mappage segment par segment et champ par champ de HL7 v2 ORU^R01 vers FHIR R4, les pièges qui brisent les intégrations, et un convertisseur que vous appelez via HTTPS.

Source: https://developers.anpheros.com/fr/guides/hl7-v2-to-fhir-mapping

**Mapper HL7 v2 vers FHIR signifie transformer chaque segment d'un message v2 délimité par des barres verticales en ressources FHIR R4 : PID en Patient, OBR en DiagnosticReport (ou ServiceRequest), chaque OBX en Observation, avec les codes, unités, plages et dates reportés champ par champ.** HL7 publie un [guide d'implémentation V2-to-FHIR](https://hl7.org/fhir/uv/v2mappings/) officiel avec des cartes conceptuelles pour les segments courants. Cette page présente le mappage pratique pour les résultats de laboratoire (ORU^R01), les pièges qui brisent les intégrations réelles, et un convertisseur que vous pouvez appeler via HTTPS : le connecteur de laboratoire Anpheros.

<!-- visual:v2map-flow -->

## Segment vers ressource

| Segment HL7 v2 | Ce qu'il transporte | Ressource FHIR R4 | Dans le connecteur de laboratoire Anpheros |
|---|---|---|---|
| MSH | Séparateurs, système d'envoi, type de message, ID de message | `MessageHeader` (ou provenance) | Séparateurs lus depuis MSH ; type vérifié pour ORU^R01 ; ID de message conservé pour la traçabilité |
| PID | Identifiants du patient, nom, date de naissance, sexe | `Patient` | Non utilisé : le patient est celui de l'URL de la requête, donc un message ne peut pas écrire dans le mauvais enregistrement |
| PV1 | Visite | `Encounter` | Non utilisé |
| ORC / OBR | Commande et rapport : ID du remplisseur/placeur, date | `ServiceRequest`, `DiagnosticReport` | OBR-3 (ou OBR-2) est l'ID du rapport, OBR-7 la date par défaut |
| OBX | Un résultat | `Observation` | Une Observation de laboratoire par OBX |
| NTE | Note en texte libre | `Observation.note` | Non utilisé |

## Champ OBX par champ

| Champ OBX | Élément FHIR Observation | Notes |
|---|---|---|
| OBX-2 type de valeur (NM, SN, ST, CWE) | choix de `value[x]` | NM et SN deviennent `valueQuantity` ; le texte reste du texte |
| OBX-3 identifiant `code^text^system` | `code.coding` | `LN` dans OBX-3.3 signifie LOINC ; les autres systèmes sont le code local du laboratoire |
| OBX-5 valeur, OBX-6 unité | `valueQuantity.value`, `.unit` / `.code` (UCUM) | `<5` et `6,4` doivent être analysés délibérément |
| OBX-7 plage de référence | `referenceRange.low` / `.high` | `3.5-5.1`, `<200`, `>40` |
| OBX-8 drapeau anormal | `interpretation` | H, L, HH, LL, A, N |
| OBX-11 statut du résultat | `status` | F → final, C → modifié, P → préliminaire, I → enregistré |
| OBX-14 heure de l'observation | `effectiveDateTime` | les heures v2 n'ont souvent pas de fuseau horaire ; FHIR en exige un |

## Convertir un message avec une requête

```bash
curl -X POST "https://platform.anpheros.com/v1/patients/$PID/labs/import" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: x-application/hl7-v2+er7" \
  -H "Idempotency-Key: $(uuidgen)" \
  --data-binary @oru_r01.hl7
```

La réponse liste le nombre d'Observations créées, le nombre ignorées car déjà importées, les marqueurs qui n'ont pas pu être mappés, et les nouvelles Observations avec leurs codes. Chacune reçoit un identifiant stable dérivé du rapport, du test, de l'heure et de la valeur, de sorte qu'un laboratoire qui renvoie le même message ne crée pas de doublons.

## Pièges qui brisent les intégrations réelles

1. **Fuseaux horaires.** `20261002074500` n'a pas de décalage ; décidez explicitement du fuseau horaire de l'expéditeur.
2. **Codes locaux.** Conservez le code propre au laboratoire lorsqu'il n'y a pas de LOINC ; ne le supprimez jamais.
3. **Réémissions.** Sans identifiant stable par résultat, les nouvelles tentatives deviennent des doublons.
4. **Corrections.** OBX-11 `C` est une correction ; décidez si elle remplace ou ajoute, et marquez l'ancien résultat.
5. **Valeurs non numériques.** `positive`, `<5`, `6,4` nécessitent des règles explicites, pas une supposition.

## Ce que le connecteur ne fait pas

Il accepte les résultats de laboratoire ORU^R01 via HTTPS. Il ne reçoit pas les messages ADT ou de commande, ne communique pas en MLLP sur TCP (un moteur d'interface en amont peut transférer), ne crée pas de DiagnosticReport et ne fait pas correspondre les patients à partir de PID.

## Questions fréquemment posées

### Comment mapper HL7 v2 à FHIR ?
Segment par segment : PID vers Patient, PV1 vers Encounter, ORC/OBR vers ServiceRequest et DiagnosticReport, OBX vers Observation, NTE vers notes. Le guide d'implémentation V2-to-FHIR de HL7 définit les mappages conceptuels au niveau des champs.

### Existe-t-il un convertisseur HL7 v2 vers FHIR ?
Oui. Les moteurs d'interface et les bibliothèques open-source convertissent les messages ; pour les résultats de laboratoire, le connecteur de laboratoire Anpheros convertit un message ORU^R01 en Observations FHIR R4 en une seule requête HTTPS et les stocke dans le dossier du patient.

### Quels types de messages HL7 v2 Anpheros accepte-t-il ?
ORU^R01 résultats de laboratoire. Un message d'un autre type génère un avertissement, et seuls ses segments OBX sont lus ; les messages ADT, d'ordonnance et autres ne sont pas pris en charge.

### Comment les indicateurs d'anomalie HL7 v2 sont-ils représentés dans FHIR ?
OBX-8 devient `Observation.interpretation` en utilisant les codes d'interprétation d'observation HL7 (H, L, HH, LL, A, N).

<!-- visual:cta-v2map -->

## Liens Utiles

- [API des résultats de laboratoire : HL7 v2, FHIR et LOINC](https://developers.anpheros.com/fr/guides/lab-results-api)
- [FHIR vs HL7 v2 : différences pratiques](https://developers.anpheros.com/fr/guides/fhir-vs-hl7-v2)
- [Comment importer des résultats de laboratoire dans un enregistrement FHIR](https://developers.anpheros.com/fr/guides/import-lab-results-fhir)
- [HL7 v2 et FHIR pour les tableaux de bord cliniques](https://developers.anpheros.com/fr/guides/clinical-dashboard-hl7-fhir)
- [Connecteur de laboratoire](https://developers.anpheros.com/fr/guides/lab-connector)