Heads up — limited surface today. A standalone Coverage FHIR resource is on the roadmap. Until it ships, coverage information is represented inline inside two existing resources: as Claim.insurance[].coverage when you submit a claim, and as Account.coverage[].coverage when you aggregate charges into an account. This page describes the current pattern.

Representing Coverage on a Claim

Every claim carries an insurance[] array with one entry per coverage that should adjudicate the claim. Exactly one entry should have focal: true (the primary coverage).

{
  "resourceType": "Claim",
  "insurance": [
    {
      "sequence": 1,
      "focal": true,
      "coverage": {
        "reference": "Coverage/3fa85f64-5717-4562-b3fc-2c963f66afa6",
        "display": "Blue Cross Blue Shield — HMO Gold"
      },
      "preAuthRef": ["PA-2026-12345"]
    }
  ]
}

When the full Coverage resource is not yet exposed through the API, store the coverage identity externally (in your own system or with the payer) and reference it by Coverage/<uuid> in the claim. ESUS persists the reference and forwards it to downstream adjudication workflows.

Representing Coverage on an Account

The Account resource accumulates charges for a patient and can list the coverages that back it:

curl -X POST https://api.esus.health/fhir/Account \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/fhir+json" \
  -d '{
    "status": "active",
    "name": "Inpatient stay — January 2026",
    "subjectId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "coverage": [
      {
        "coverage": {
          "reference": "Coverage/c1a2e3d4-5b6f-7890-abcd-ef1234567890"
        },
        "priority": 1
      }
    ]
  }'

Minimum Data to Record Per Coverage

When integrating with a payer, the minimum information you will typically need to hand to ESUS (on Claim or Account) is:

• Payer identity — Organization reference or identifier.
• Subscriber identifier — the member id used by the payer.
• Plan code / name — for internal tracking.
• Relationship — self, spouse, child, other.
• Period — effective dates.

We recommend storing these fields in your own system today and mapping to the standalone Coverage resource once it ships; the transition will be backward-compatible through the Coverage/<uuid> reference already used in Claim and Account.