Coverage — Couverture assurantielle

La ressource qui décrit le contrat d'assurance santé d'un patient. Pivot des flux financiers FHIR : pré-autorisation, facturation, remboursement.

Objet de la ressource

Coverage représente une couverture assurantielle : assurance santé privée, mutuelle / complémentaire, programme public (Medicare, Medicaid, Sécurité sociale, NHS), assurance accident du travail, assurance voyage. Une ressource Coverage correspond à une seule ligne de couverture ; un patient peut avoir plusieurs Coverage actives (primaire + secondaire + tertiaire).

Coverage est la pièce centrale des flux financiers FHIR. Elle est référencée par Claim (demande de remboursement), ClaimResponse, EligibilityRequest, ExplanationOfBenefit. C'est aussi elle qui porte la cost-sharing (co-payments, deductibles, out-of-pocket maximum) côté patient.

Champs clés

Coverage primaire vs secondaire

Un patient peut détenir plusieurs Coverage actives simultanément. Le champ order détermine l'ordre d'application :

• order=1 — couverture primaire. Reçoit la demande de remboursement en premier.
• order=2 — couverture secondaire (mutuelle / complémentaire en France, secondary insurance aux États-Unis). Comble le reste à charge après remboursement par la primaire.
• order=3+ — couvertures tertiaires (rare, mais existe pour des programmes spécifiques type CMU-C ou assurances voyage).

Dans un Claim, on ajoute une Claim.insurance par Coverage, avec focal=true pour la couverture sur laquelle on demande le paiement (typiquement la primaire). Le coordination of benefits (COB) entre primaire et secondaire est tracé via les ClaimResponse successifs.

Exemple JSON

Coverage primaire Aetna PPO 2026 pour Patient « example », auto-bénéficiaire, plan « ACME Group », co-pay 20 USD pour visite médecin généraliste :

{
  "resourceType": "Coverage",
  "id": "primary-aetna",
  "status": "active",
  "kind": "insurance",
  "type": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
      "code": "EHCPOL",
      "display": "extended healthcare"
    }]
  },
  "policyHolder": { "reference": "Patient/example" },
  "subscriber": { "reference": "Patient/example" },
  "subscriberId": [{
    "value": "W123456789"
  }],
  "beneficiary": { "reference": "Patient/example" },
  "dependent": "01",
  "relationship": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
      "code": "self"
    }]
  },
  "period": {
    "start": "2026-01-01",
    "end": "2026-12-31"
  },
  "insurer": { "reference": "Organization/aetna" },
  "class": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/coverage-class",
        "code": "group"
      }]
    },
    "value": "GRP-2026-ACME",
    "name": "ACME Group Plan"
  }, {
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/coverage-class",
        "code": "plan"
      }]
    },
    "value": "PLN-PPO-2026",
    "name": "Aetna PPO Standard 2026"
  }],
  "order": 1,
  "costToBeneficiary": [{
    "type": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/coverage-copay-type",
        "code": "gpvisit",
        "display": "GP Office Visit"
      }]
    },
    "valueQuantity": {
      "value": 20,
      "code": "USD",
      "system": "urn:iso:std:iso:4217"
    }
  }]
}

• kind=insurance — couverture commerciale (vs self-pay).
• type EHCPOL — extended healthcare policy.
• subscriber=beneficiary=policyHolder — le patient est titulaire, souscripteur et bénéficiaire (auto-couverture).
• relationship.code=self.
• class[] deux entrées : groupe (employeur ACME) + plan (Aetna PPO Standard 2026).
• order=1 — couverture primaire.
• costToBeneficiary[0] — co-pay de 20 USD pour les visites de médecin généraliste.

API REST

• GET /Coverage?beneficiary=Patient/example&status=active — couvertures actives d'un patient.
• GET /Coverage?beneficiary=Patient/example&_sort=order — couvertures triées par ordre d'application.
• POST /Coverage — créer une nouvelle couverture après vérification d'éligibilité.
• GET /Coverage/$eligibility-by-identifier — opération composite (selon profil) pour vérifier l'éligibilité en temps réel.
• GET /Coverage?subscriber-id=W123456789 — recherche par numéro de souscripteur.
• GET /Coverage?_include=Coverage:insurer — inclure l'Organization émettrice.

Profils nationaux

Pièges courants

• Confondre subscriber et beneficiary — le souscripteur peut être un parent qui couvre un enfant. beneficiary est obligatoirement le patient bénéficiaire actuel de l'acte.
• Pas de period.end — une Coverage sans date de fin paraît active indéfiniment ; gérer la fin de contrat par changement de status à cancelled + remplissage de period.end.
• order manquant — sans order, l'EHR ne peut pas déterminer quelle couverture envoyer en premier au moment de la facturation. Toujours le renseigner si plusieurs couvertures coexistent.
• class incohérent — les class[].type sont normés (group, plan, subgroup, subclass, subplan, class, sequence, rxbin, rxpcn, rxid…). Inventer un code propriétaire casse l'interopérabilité.
• Mauvais kind — Nouveau en R5. Avant R5, ce concept était porté par type. kind=self-pay est explicite pour les patients sans assurance, à ne pas omettre.
• Coverage active après fin de contrat — un nightly job de réconciliation doit basculer status à cancelled quand period.end est dépassé ; sinon, les pré-autorisations se basent sur une couverture périmée.

Ressources liées

• Claim — demande de remboursement référençant Coverage.
• ClaimResponse — réponse de l'assureur.
• ExplanationOfBenefit — relevé de prestations.
• CoverageEligibilityRequest / CoverageEligibilityResponse — vérification d'éligibilité en temps réel.
• Patient — bénéficiaire de la couverture.
• Organization — assureur.
• InsurancePlan — détails du plan d'assurance (mutualisation).
• HL7 v2 IN1 / IN2 / IN3 — équivalents legacy.