# Demandes de remboursement X12 837 vers FHIR Claim : boucles, segments et un mapping qui tient > Comment est structurée une demande de remboursement X12 837 professionnelle ou institutionnelle, comment ses boucles et segments se projettent sur une ressource FHIR R4 Claim, où intervient ExplanationOfBenefit, et les pièges qui cassent les flux de facturation. Auteur: Ala Ben Aicha Page de référence: https://alabenaicha.me/fr/insights/x12-837-to-fhir-claim Mise à jour: 2026-10-06 ## Réponse directe Le X12 837 est la demande de remboursement électronique imposée par HIPAA aux États-Unis, en version 005010 : 837P pour les actes professionnels, 837I pour les établissements, 837D pour le dentaire. Les données de la demande se trouvent dans la boucle 2300 (`CLM`, `HI`) et les lignes de prestation dans la boucle 2400 (`SV1` ou `SV2`, `DTP`). Chacun de ces éléments se projette proprement sur une ressource FHIR R4 Claim : `CLM02` vers `Claim.total`, `HI` vers `Claim.diagnosis`, chaque ligne 2400 vers `Claim.item`, et les pointeurs `SV107` vers `Claim.item.diagnosisSequence`. Le résultat de la liquidation (ce que rapporte un avis de paiement 835) relève de ClaimResponse ou d’ExplanationOfBenefit, pas de Claim. ## Quel 837, quelle version | Transaction | Guide d’implémentation dans `GS08` / `ST03` | Émetteur typique | Segment de ligne | | ----------------------- | ------------------------------------------- | ----------------------------------------------- | ------------------------------- | | **837P** Professionnel | `005010X222A1` | Cabinets médicaux, laboratoires, ambulances | `SV1` (HCPCS/CPT) | | **837I** Institutionnel | `005010X223A2` | Hôpitaux, établissements de soins de suite, HAD | `SV2` (code de recette + HCPCS) | | **837D** Dentaire | `005010X224A2` | Cabinets dentaires | `SV3` (CDT) | Le standard HIPAA des demandes de remboursement figure au [45 CFR 162.1102](https://www.law.cornell.edu/cfr/text/45/162.1102). Le texte cite les rapports techniques de mai 2006 et leurs errata de 2007. Les guides compagnons des payeurs et de Medicare attendent les identifiants des errata ultérieurs de juin 2010 indiqués ci-dessus : c’est donc ce qui figure dans l’enveloppe. Une version plus récente arrive-t-elle ? En 2022, X12 a demandé au NCVHS d’examiner les guides 008020 (837P `008020X323`, 837I `008020X324`). En juin 2023, le NCVHS a recommandé au HHS de ne pas engager de réglementation pour les demandes de remboursement et les avis de paiement, et [X12 a publiquement exprimé son désaccord](https://x12.org/news-and-events/news/ncvhs-response-letter). En octobre 2026, aucune règle ne remplace la 005010 pour le 837. L’article a été modifié en décembre 2024 et en août 2025 pour faire passer les demandes de pharmacie de ville à NCPDP F6 ; les références X12 837 n’ont pas bougé. Par ailleurs, [CMS-0053-F](https://www.cms.gov/files/document/nsg-attachments-final-rule-fact-sheet.pdf) (mars 2026) a adopté les X12 275/277 version 6020 pour les pièces jointes aux demandes, avec une mise en conformité au 26 mai 2028. ## Anatomie d’un 837P Trois enveloppes entourent chaque lot de demandes : * **ISA / IEA** : l’interchange. `ISA` est à largeur fixe (106 caractères, terminateur compris) ; `ISA13` doit être égal à `IEA02`. * **GS / GE** : le groupe fonctionnel. `GS01` vaut `HC` pour les demandes ; `GS06` doit être égal à `GE02`. * **ST / SE** : le jeu de transactions. `SE01` est le nombre de segments de `ST` à `SE` inclus. À l’intérieur, des boucles hiérarchiques (`HL`) portent les acteurs : | Boucle | Contenu | Segments clés | | --------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | En-tête | Finalité du lot | `BHT` (`BHT06` = `CH` facturable, `RP` déclaration/rencontre) | | **1000A** | Émetteur | `NM1*41`, `PER` | | **1000B** | Destinataire | `NM1*40` | | **2000A** | Niveau du prestataire facturant | `HL` code de niveau 20, `PRV` taxonomie | | 2010AA | Nom, NPI, adresse et identifiant fiscal du prestataire facturant | `NM1*85` avec le qualifiant `XX`, `N3`, `N4`, `REF*EI` | | **2000B** | Niveau de l’assuré | `HL` code de niveau 22, `SBR` (rang du payeur, lien, indicateur de type de couverture) | | 2010BA / 2010BB | Assuré et payeur | `NM1*IL`, `DMG` ; `NM1*PR` | | 2000C | Patient, uniquement s’il n’est pas l’assuré | `PAT`, `NM1*QC` | | **2300** | Demande | `CLM`, `HI`, `REF`, `DTP` | | 2310x | Prestataires au niveau de la demande (adressant, exécutant, structure) | `NM1`, `PRV` | | **2400** | Ligne de prestation | `LX`, `SV1` ou `SV2`, `DTP*472` | Un 837P synthétique avec deux lignes de prestation (NPI fictif, identifiant d’adhérent fictif, aucun patient réel) : ```text ISA*00* *00* *ZZ*SUBMITTERID *ZZ*RECEIVERID *261005*1200*^*00501*000000101*1*T*:~ GS*HC*SUBMITTERID*RECEIVERID*20261005*1200*101*X*005010X222A1~ ST*837*0001*005010X222A1~ BHT*0019*00*BATCH0001*20261005*1200*CH~ NM1*41*2*EXAMPLE BILLING SERVICE*****46*SUB12345~ PER*IC*EDI DESK*TE*5555550100~ NM1*40*2*EXAMPLE PAYER*****46*PAYER01~ HL*1**20*1~ PRV*BI*PXC*207Q00000X~ NM1*85*2*EXAMPLE FAMILY CLINIC*****XX*1234567893~ N3*100 MAIN ST~ N4*ANYTOWN*NY*123451234~ REF*EI*123456789~ HL*2*1*22*0~ SBR*P*18*******CI~ NM1*IL*1*DOE*JANE****MI*XYZ123456789~ N3*1 TEST LANE~ N4*ANYTOWN*NY*12345~ DMG*D8*19800101*F~ NM1*PR*2*EXAMPLE PAYER*****PI*PAYER01~ CLM*PCN-0001*175***11:B:1*Y*A*Y*Y~ HI*ABK:E119*ABF:I10~ LX*1~ SV1*HC:99213*125*UN*1***1:2~ DTP*472*D8*20261001~ LX*2~ SV1*HC:83036*50*UN*1***1~ DTP*472*D8*20261001~ SE*27*0001~ GE*1*101~ IEA*1*000000101~ ``` Lecture de la demande : `SBR02` = `18` signifie que le patient est l’assuré, donc pas de boucle 2000C. `CLM05` = `11:B:1` donne le lieu de prestation 11 (cabinet), le qualifiant B et la fréquence 1 (demande initiale). `HI` porte des codes CIM-10-CM sans le point décimal : `ABK` est le diagnostic principal, `ABF` un diagnostic associé. `SV107` = `1:2` rattache la première ligne aux deux diagnostics. Le 837I diffère précisément là où ça fait mal : `CLM05` porte le type de structure et la fréquence (le type de facture) au lieu du lieu de prestation, `CL1` ajoute les informations d’admission, `SV2` place le code de recette en premier, et il n’existe pas de pointeur de diagnostic au niveau de la ligne. ## Mapping vers FHIR R4 Claim [FHIR R4 Claim](https://hl7.org/fhir/R4/claim.html) exige `status`, `type`, `use`, `patient`, `created`, `provider`, `priority` et au moins un `insurance`. La plupart proviennent directement du 837. | Source 837 | Élément FHIR R4 Claim | Remarques | | --------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | `ST03` (X222A1 / X223A2 / X224A2) | `Claim.type` | `professional` / `institutional` / `oral` du système de codes claim-type | | `BHT06` = `CH` | `Claim.use` = `claim` | Les déclarations de rencontre `RP` n’ont pas de valeur `use` exacte ; traitez-les dans un flux séparé | | `BHT04` / `BHT05` | `Claim.created` | | | `CLM01` | `Claim.identifier` | Numéro de contrôle patient ; votre clé d’idempotence | | `CLM02` | `Claim.total` | Doit égaler la somme des montants des lignes | | `CLM05-3` = 7 ou 8, `REF*F8` | `Claim.related` | Remplacement ou annulation d’une demande antérieure du payeur | | `HI` positions 1..12 | `Claim.diagnosis.sequence` + `diagnosisCodeableConcept` | Rétablissez le point CIM-10-CM : `E119` devient `E11.9` | | 2010BA / 2000C | `Claim.patient` | Assuré ou ayant droit, selon `SBR02` et la boucle 2000C | | `SBR`, 2010BB `NM1*PR` | `Claim.insurance.coverage` vers Coverage | `focal` = true pour le payeur concerné par la demande | | 2010AA `NM109` (`XX`) | `Claim.provider` | NPI facturant en tant qu’identifiant | | 2310B exécutant, `PRV03` | `Claim.careTeam`, `careTeam.qualification` | La taxonomie va dans qualification, jamais dans le champ NPI | | `LX01` | `Claim.item.sequence` | | | `SV101` (+ modificateurs) | `item.productOrService`, `item.modifier` | CPT/HCPCS | | `SV201` (837I) | `item.revenue` | Code de recette NUBC | | `SV102` / `SV203` | `item.net` | Montant de la ligne | | `SV103` + `SV104` | `item.quantity` | Conservez l’unité : `UN` unités ou `MJ` minutes | | `CLM05-1`, remplacé par `SV105` | `item.locationCodeableConcept` | Codes de lieu de prestation CMS | | `SV107` | `item.diagnosisSequence` | Les valeurs sont des positions dans `HI` | | `DTP*472` | `item.servicedDate` ou `servicedPeriod` | `D8` date unique, `RD8` période | | (aucune) | `Claim.priority` | Valeur `normal` ; le 837 n’a pas d’équivalent | La première ligne de l’exemple, en FHIR : ```json { "resourceType": "Claim", "id": "example-837p-pcn-0001", "identifier": [{ "system": "urn:example:patient-control-number", "value": "PCN-0001" }], "status": "active", "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/claim-type", "code": "professional" }] }, "use": "claim", "patient": { "reference": "Patient/example-jane-doe" }, "created": "2026-10-05T12:00:00Z", "provider": { "identifier": { "system": "http://hl7.org/fhir/sid/us-npi", "value": "1234567893" } }, "priority": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/processpriority", "code": "normal" }] }, "diagnosis": [ { "sequence": 1, "diagnosisCodeableConcept": { "coding": [{ "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "E11.9" }] } }, { "sequence": 2, "diagnosisCodeableConcept": { "coding": [{ "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "I10" }] } } ], "insurance": [ { "sequence": 1, "focal": true, "coverage": { "reference": "Coverage/example-xyz123456789" } } ], "item": [ { "sequence": 1, "diagnosisSequence": [1, 2], "productOrService": { "coding": [{ "system": "http://www.ama-assn.org/go/cpt", "code": "99213" }] }, "servicedDate": "2026-10-01", "locationCodeableConcept": { "coding": [ { "system": "https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set", "code": "11" } ] }, "quantity": { "value": 1 }, "net": { "value": 125.0, "currency": "USD" } } ], "total": { "value": 175.0, "currency": "USD" } } ``` La seconde ligne (`83036`, 50,00, pointeur 1) suit la même forme. L’URI du système de lieux de prestation est celle à laquelle se lie le guide CARIN ; utilisez-la pour que les profils EOB en aval valident. ## Claim, ClaimResponse ou ExplanationOfBenefit ? * **Claim** est la demande : ce que le prestataire a facturé. Il se construit à partir du 837. * **ClaimResponse** est la réponse du payeur à une ressource FHIR Claim. L’autorisation préalable dans [Da Vinci PAS](https://alabenaicha.me/fr/insights/da-vinci-prior-authorization-fhir) utilise ce couple. * **ExplanationOfBenefit (EOB)** est la demande liquidée telle que le payeur l’a enregistrée : montant admis, payé, reste à charge, motifs d’ajustement. Sa source est le système de liquidation du payeur, les mêmes données que celles envoyées dans un avis de paiement 835 (`005010X221A1`). Pour les API des payeurs américains, les EOB destinés aux patients suivent le [guide CARIN Blue Button](https://hl7.org/fhir/us/carin-bb/) (2.2.0, publié en mars 2026, FHIR R4). [Da Vinci PDex](https://hl7.org/fhir/us/davinci-pdex/) (2.2.0, août 2026) couvre les informations issues des demandes sans les montants, plus les données cliniques, pour l’accès des prestataires et l’échange entre payeurs. CMS-0057-F impose en général les nouvelles API Provider Access et Payer-to-Payer à partir du 1er janvier 2027 ; l’[article sur l’autorisation préalable Da Vinci](https://alabenaicha.me/fr/insights/da-vinci-prior-authorization-fhir) détaille les dates et les types de payeurs. Côté clinique, patients et pathologies doivent être conformes à [US Core](https://alabenaicha.me/fr/insights/fhir-us-core-tefca-implementation). Règle pratique : si vous êtes une intégration côté prestataire qui convertit des 837 sortants, produisez des Claim. Si vous êtes un payeur qui expose un historique, produisez des EOB à partir des données liquidées. N’essayez pas de construire un EOB à partir du seul 837 : il ne contient aucun montant payé. ## Les pièges qui cassent les flux de facturation **NPI ou taxonomie.** Le NPI du prestataire facturant est `NM109` avec le qualifiant `XX` ; le code de taxonomie est `PRV03`. Ce sont deux identifiants aux rôles différents. Un NPI de type 2 (organisation) en 2010AA avec un NPI de type 1 pour l’exécutant en 2310B est normal. Mappez les NPI vers des identifiants et la taxonomie vers `careTeam.qualification` ou la spécialité d’un PractitionerRole. **Pointeurs de diagnostic.** `SV107` pointe vers des positions du segment `HI` (jusqu’à 12 codes sur un 837P, jusqu’à quatre pointeurs par ligne). Triez, dédoublonnez ou fusionnez les diagnostics et chaque pointeur devient faux sans le moindre message d’erreur. X12 confirme que [tous les codes HI n’ont pas à être pointés](https://x12.org/resources/requests-for-interpretation/rfi-1417-2400-loop-sv107-2-5010). Conservez l’ordre d’origine et reportez-le dans `diagnosis.sequence`. **Points décimaux.** X12 transporte la CIM-10-CM sans le point, la terminologie FHIR l’attend. Convertir dans un seul sens produit des codes rejetés de l’autre côté. **Lieu de prestation.** `CLM05-1` est la valeur par défaut de la demande ; `SV105` la remplace pour une ligne. Déterminez la valeur effective par ligne avant le mapping. **Unités.** `SV103` `UN` (unités) et `MJ` (minutes, fréquent en anesthésie) se ressemblent une fois réduits à un nombre. Gardez l’unité. **Règles d’adresse.** En 5010, l’adresse du prestataire facturant en 2010AA exige une adresse postale réelle et un code ZIP à neuf chiffres. Les sources qui stockent des ZIP à cinq chiffres échouent au niveau du clearinghouse. **Numéros de contrôle des enveloppes.** `ISA13`, `GS06` et `ST02` doivent être uniques selon votre accord avec le partenaire d’échange et correspondre à leurs segments de fin. Les régénérer lors d’une nouvelle tentative peut créer une demande en double ; les réutiliser peut faire rejeter un fichier comme doublon. Fixez la règle avec le clearinghouse et journalisez les numéros de contrôle avec `CLM01`. **Les accusés de réception sont empilés.** Un `TA1` répond sur l’enveloppe d’interchange, un 999 (`005010X231A1`) sur la syntaxe et la conformité au guide d’implémentation, et un 277CA (`005010X214`) accepte ou rejette chaque demande. Un 999 accepté ne signifie pas que la demande l’est. Le paiement arrive plus tard, dans le 835. Rattachez chaque accusé à sa demande et remontez les rejets 277CA à l’équipe de facturation. **Des données de santé partout.** Un 837 contient des PHI de bout en bout, journaux et files de messages en échec compris. Les garde-fous décrits dans [HIPAA pour l’intégration santé](https://alabenaicha.me/fr/insights/hipaa-compliance-healthcare-integration) s’appliquent au circuit EDI autant qu’aux API FHIR. Si votre équipe traite aussi des flux cliniques, les réflexes segment/champ acquis avec les [messages HL7 v2 d’exemple](https://alabenaicha.me/fr/insights/hl7-message-types-sample-messages) se transposent, mais les règles de délimiteurs et d’enveloppes X12 sont plus strictes. ## Liste de contrôle de réalisation 1. Fixez le guide d’implémentation par partenaire d’échange (`005010X222A1` ou `005010X223A2`) et chargez le guide compagnon du payeur. 2. Analysez les enveloppes, validez le nombre de segments et les numéros de contrôle avant tout mapping. 3. Projetez 2300 et 2400 sur Claim avec le tableau ci-dessus ; rétablissez les points CIM-10-CM et conservez l’ordre de `HI`. 4. Validez la ressource Claim contre votre profil cible, pas seulement contre R4 de base. 5. Branchez le traitement des `TA1`, 999 et 277CA, puis le rapprochement des 835 si vous portez le cycle de facturation. 6. Laissez la génération des EOB côté payeur, à partir des données liquidées. Si vous avez besoin d’un flux 837, d’un mapping vers FHIR Claim, ou de faire cohabiter EDI et FHIR dans une intégration de DPI, voyez l’accompagnement en [intégration EHR et EMR](https://alabenaicha.me/fr/services/ehr-emr-integration).