Heads up — on the roadmap. CoverageEligibilityRequest and CoverageEligibilityResponse are not exposed through the ESUS API today. This page describes the planned shape and the recommended interim pattern for eligibility checks.

Planned Shape (CoverageEligibilityRequest)

When the feature ships, the surface will follow standard FHIR. Expected request shape:

{
  "status": "active",
  "purpose": ["auth-requirements", "benefits"],
  "patientId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "coverage": {
    "reference": "Coverage/c1a2e3d4-5b6f-7890-abcd-ef1234567890"
  },
  "servicedPeriod": {
    "start": "2026-01-01",
    "end": "2026-12-31"
  }
}

Purpose Values

Interim Pattern (Today)

Until the resource is exposed, we recommend the following integration pattern:

1. Talk to the payer directly. Most payers expose their own eligibility API (270/271 X12, NCPDP, or a JSON adapter). Call it from your server and cache the response.
2. Persist the result in your own system keyed by patient + coverage + date range.
3. When creating a Claim, include insurance[].preAuthRef[] with any authorization numbers obtained from the payer.
4. Track failed adjudications in ClaimResponse.error[] and reprocess accordingly.

This pattern is the same integration your payer already supports and keeps you productive today. When the ESUS-side resource ships, migration will be a matter of writing the cached response through the new endpoint — the request body above will not change materially.

Common Eligibility Checks (for reference)

• Is the coverage active on the service date?
• Does the member require prior authorization for this procedure?
• What is the remaining deductible and out-of-pocket maximum?
• Are the requested providers in network?

We will publish the full endpoint contract when the feature enters private beta.