# Terminologie HL7 v2 vers FHIR : OBX vers Observation avec LOINC et SNOMED

> Mappez un fragment ORU/OBX anonymisé sur Observation.code et value[x] à l'aide de HL7 v2-to-FHIR 1.0.0. LOINC lie les observations ; SNOMED relie les problèmes et les allergies au fur et à mesure que l'IG les cartographie. Les codes locaux échouent en premier, pas le PID.

Auteur: Ala Ben Aicha

Page de référence: https://alabenaicha.me/fr/insights/hl7v2-fhir-loinc-snomed-mapping

Mise à jour: 2026-09-19

## Réponse directe

Mappez OBX à Observation à l'aide de la version v2 vers FHIR IG 1.0.0 : OBX-3 devient Observation.code, OBX-5 devient valeur \[x]. Lier LOINC sur les observations et SNOMED sur les problèmes et allergies. Les codes locaux, et non le PID, sont l'échec habituel.

## Fixez la version dus cartes publiées, puis les reliures

Utilisez une version identifiée de la publication [HL7 version 2 vers FHIR IG 1.0.0 (STU 1)](https://hl7.org/fhir/uv/v2mappings/) (généré le 7 octobre 2025, package `hl7.fhir.uv.v2mappings#1.0.0` sur FHIR R4). Préférez ce package à la version CI. Le modèle de moteur hybride est le [Manuel de migration v2 vers FHIR](https://alabenaicha.me/fr/insights/hl7v2-to-fhir-migration-strategy); la chorégraphie ordre/résultat est la [flux de travail en radiologie et en laboratoire](https://alabenaicha.me/fr/insights/radiology-lab-workflow-integration). **Cette page est le contrat de terminologie à l'intérieur de ce moteur.**

La carte de segment à épingler est [OBX → Observation](https://hl7.org/fhir/uv/v2mappings/ConceptMap-segment-obx-to-observation.html). Les problèmes et les allergies ne sont pas OBX : les cartes IG [AL1 → AllergieIntolérance](https://hl7.org/fhir/uv/v2mappings/ConceptMap-segment-al1-to-allergyintolerance.html) (`AL1-3` → `AllergyIntolerance.code`) et [DG1 → Etat](https://hl7.org/fhir/uv/v2mappings/ConceptMap-segment-dg1-to-condition.html) (`DG1-3` → `Condition.code`), également via EpisodeOfCare.diagnosis.

| champ v2                                | Chemin FHIR                | Carte de reliure/type                                                                  | Échec habituel                                                                                      |
| --------------------------------------- | -------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **OBX-3** Identifiant Observation (CWE) | `Observation.code`         | [LOINC](https://loinc.org/) `http://loinc.org` lorsque CWE.3 est `LN`                  | Mnémonique local (`HGB^^^L`) sans système                                                           |
| **OBX-2** + **OBX-5**                   | `value[x]`                 | NM → `valueQuantity`; ST/FT/TX → `valueString`; CWE/CE/CNE/CF → `valueCodeableConcept` | Le type de valeur et la valeur\[x] ne sont pas d'accord                                             |
| **OBX-6** Unités                        | `valueQuantity` unité/code | UCUM lorsque l'expéditeur l'envoie réellement                                          | Unité sur la chaîne, pas sur la quantité                                                            |
| **OBX-11** Statut du résultat           | `Observation.status`       | Tableau 0085 → statut (`F` → `final`)                                                  | Traiter `C` (corrigé) comme nouveau Observation                                                     |
| **AL1-3** Allergène                     | `AllergyIntolerance.code`  | [SNOMED CT](http://snomed.info/sct) lorsque CWE.3 est `SCT`                            | Allergène en texte libre sans système de code                                                       |
| **DG1-3** Diagnostic                    | `Condition.code`           | SNOMED CT (ou le système national de diagnostic les noms CWE) comme les cartes IG CWE  | En supposant que chaque DG1 est une condition de liste de problèmes sans lire la carte des messages |

LOINC et SNOMED sont **reliures**. Il ne s'agit pas d'une licence que je vends, ni d'un système de code que j'héberge, et non impliqués par un document FHIR JSON valide. L'IG v2 vers FHIR mappe CWE → CodeableConcept ; il ne traduit pas une table locale en LOINC ou SNOMED pour vous.

Sources primaires : [v2 vers FHIR 1.0.0](https://hl7.org/fhir/uv/v2mappings/), [OBX → Carte conceptuelle Observation](https://hl7.org/fhir/uv/v2mappings/ConceptMap-segment-obx-to-observation.html), [LOINC](https://loinc.org/).

## Identifiant sur l'observation : OBX-3, pas PID

PID devient toujours Patient — c'est le [Article sur l'ADT](https://alabenaicha.me/fr/insights/hl7-adt-to-fhir-patient-encounter). Les échecs terminologiques apparaissent lorsque **OBX-3 n'a pas de système de codage d'attribution**. Un deuxième Patient n'est pas la bonne solution.

Fragment ORU/OBX anonymisé (élément de spécification, pas une personne) :

```
MSH|^~\&|LIS|LAB-A|FHIR-BRIDGE|HOSP-A|20260919120000||ORU^R01^ORU_R01|MSG0007|P|2.5
PID|1||HOSP-MRN-0001^^^HOSP-A^MR||EXAMPLE^JANE^Q
OBR|1||FILL-2026-0042|58410-2^CBC panel - Blood by Automated count^LN
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||13.2|g/dL|12.0-16.0|N|||F
```

Observation projeté (tronqué) :

```json
{
  "resourceType": "Observation",
  "status": "final",
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "718-7",
        "display": "Hemoglobin [Mass/volume] in Blood"
      }
    ]
  },
  "valueQuantity": {
    "value": 13.2,
    "unit": "g/dL",
    "system": "http://unitsofmeasure.org",
    "code": "g/dL"
  }
}
```

La variante du code local `OBX|1|NM|HGB^Hemoglobin^^L||13.2|g/dL` analyse comme v2 et comme FHIR et échoue toujours à chaque vérification sémantique attendue par LOINC. C’est le défaut de production habituel – pas un PID-3 manquant.

## Que mettre en œuvre en premier

1. Inventaire des systèmes de codage OBX-3 sur **véritable anonymisé** messages (LN, SCT, messages locaux) `L`, vide). Comptez combien de valeurs Observation.code n'auraient pas `system`.
2. Fixez la version de `hl7.fhir.uv.v2mappings#1.0.0`. Implémenter OBX → Observation, y compris la branche OBX-2 → valeur\[x] ; ne pas coder en dur `valueQuantity` pour chaque OBX.
3. Lier **LOINC** sur les observations de laboratoire/cliniques et **SNOMED CT** sur AL1/DG1 car l'IG cartographie ces segments. Conserver les systèmes de codes nationaux comme complément `coding` entrées; ne les laissez pas tomber.
4. Corrections d'essais (`OBX-11 = C`) et annule non seulement le chemin heureux `F`. Le contexte du rapport nécessite toujours DiagnosticReport où le [guide de radiologie/laboratoire](https://alabenaicha.me/fr/insights/radiology-lab-workflow-integration) le dit.

## Ce que ce n'est pas

Cet article n'est pas une licence LOINC ou SNOMED CT, ni un abonnement UMLS, ni un comparateur d'identité de patient, ni un conseil clinique. Le mappage d'un OBX dans un laboratoire ne certifie pas une interface. Je ne vends pas de licences terminologiques. Les incompatibilités PID appartiennent aux pages ADT/MPI. Les valeurs ci-dessus correspondent à des jeux de données de test et non à une personne.

## Lecture connexe

* [Migration de HL7 v2 vers FHIR](https://alabenaicha.me/fr/insights/hl7v2-to-fhir-migration-strategy)
* [Flux de travail en radiologie et en laboratoire](https://alabenaicha.me/fr/insights/radiology-lab-workflow-integration)
* [HL7 ADT à Patient et Encounter](https://alabenaicha.me/fr/insights/hl7-adt-to-fhir-patient-encounter)

Pour le travail sur le moteur qui préserve les systèmes OBX-3 dans Observation.code, utilisez [Intégration HL7 FHIR](https://alabenaicha.me/fr/services/hl7-fhir-integration) ou [démarrer un projet](https://alabenaicha.me/fr/contact?intent=project).