Demandes de remboursement X12 837 vers FHIR Claim : boucles, segments et un mapping qui tient

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

Le standard HIPAA des demandes de remboursement figure au 45 CFR 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. 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 (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 :

Un 837P synthétique avec deux lignes de prestation (NPI fictif, identifiant d’adhérent fictif, aucun patient réel) :

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 exige status, type, use, patient, created, provider, priority et au moins un insurance. La plupart proviennent directement du 837.

La première ligne de l’exemple, en FHIR :

{
  "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 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 (2.2.0, publié en mars 2026, FHIR R4). Da Vinci 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 détaille les dates et les types de payeurs. Côté clinique, patients et pathologies doivent être conformes à US Core.

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