HEALTH COVERAGE DOCUMENT · EXPLANATION OF BENEFITS · TYPED
An EOB is not a bill. It is data your agent can read.
The Explanation of Benefits is the statement a health plan sends after it processes a claim: what was billed, what the plan allowed, what it paid, and what the patient may owe, line by line with remark codes. This door is the reference for the EOB as typed data, in the health revenue-cycle register. The schema below is free and keyless; the parse surface over it is roadmap, and labeled that way.
Early access. The reference and schema on this page are live and keyless today; everything callable is roadmap, and says so. The document at right is a specimen with fictional data. It is not a real plan document and it is not a bill.
PLAN Cascade Health Plan MEMBER J. Rivera · ID CHP-88214307 CLAIM 2026-183350021 PROVIDER Lakeview Family Medicine RECEIVED 2026-06-09 · PROCESSED 2026-06-24
DOS CODE SERVICE BILLED ALLOWED PAID PATIENT REMARK 2026-06-02 99214 OFFICE VISIT 240.00 132.40 107.40 25.00 CO-45 2026-06-02 80053 METAB PANEL 88.00 21.60 21.60 0.00 CO-45 2026-06-02 36415 BLOOD DRAW 24.00 0.00 0.00 0.00 CO-97
TOTALS 352.00 154.00 129.00 25.00 PATIENT RESPONSIBILITY 25.00 · OFFICE-VISIT COPAY · NOT A BILL
The statement that explains the claim.
After a provider bills a health plan, the plan processes the claim and reports the outcome to the member: service line by service line, billed against allowed, plan paid against patient responsibility, with a remark code on every reduction.
The first thing an EOB says about itself is what it is not: this is not a bill. Any actual bill comes from the provider, and the EOB is the document to check it against. The plan's allowed amount is the negotiated rate, the contract number rather than the sticker number, and the gap between billed and allowed is the first thing worth reading on every line.
The provider receives the same outcome in machine form as an electronic remittance advice, the X12 835. Member EOB and provider 835 describe one processing outcome, which is what makes the EOB parseable in the first place: under the letterhead it is already structured data.
Every reduction or non-payment carries a remark code from the industry code sets (CARC and RARC): CO-45 for a charge over the fee schedule, CO-97 for a service bundled into another. When the plan does not cover a line, the member can appeal; internal appeal windows are commonly 180 days from the decision, and the exact window varies by plan and state.
A register note, stated honestly: the EOB is a health coverage document, not property and casualty. This estate serves both registers with one design system: P&C claim documents like the loss run and the loss notice, and health revenue-cycle documents like the EOB. Same typed-schema discipline, different vocabulary, never blurred.
- Issued by
- The health plan, after it processes a claim the provider billed.
- Sent to
- The member. The provider receives the matching electronic remittance advice (X12 835).
- What it is not
- A bill. Any bill comes from the provider; the EOB is what you reconcile that bill against.
- Remark codes
- CARC and RARC codes on every reduction or non-payment: CO-45 over fee schedule, CO-97 bundled, PR-1 deductible.
- Appeal window
- Commonly 180 days from the processing decision for internal appeals. Varies by plan and state; the document states the plan's own deadline.
One statement, fourteen typed fields.
This is the shape a parsed EOB resolves to, whether it arrived as a member PDF or an 835 remittance. It is the reference an answer engine can quote and an agent can build against, and it stays free and keyless.
| Field | Type | Meaning | Source |
|---|---|---|---|
| payer | string | The health plan that processed the claim. | Plan |
| member_id | string | The member the claim was processed for. | Plan |
| claim_number | string | The plan's claim identifier. An appeal references it. | Plan |
| provider | string | Who rendered and billed the services. | Provider bill |
| date_processed | date | When the plan finished processing the claim. Appeal windows count from here. | Plan |
| lines[].date_of_service | date | When the service was rendered. | Provider bill |
| lines[].procedure_code | string | CPT or HCPCS code for the service line. | Provider bill |
| lines[].billed | money | What the provider charged. | Provider bill |
| lines[].allowed | money | The plan's negotiated rate: the contract number, not the sticker number. | Plan |
| lines[].plan_paid | money | What the plan paid the provider on this line. | Plan |
| lines[].patient_responsibility | money | Copay, coinsurance, or deductible: what the member may owe the provider. | Plan |
| lines[].remark_codes | string[] | CARC and RARC codes explaining every reduction or non-payment. | Plan |
| totals | object | Billed, allowed, plan paid, and patient responsibility across the lines. | Derived |
| appeal_window | object | The plan's appeal deadline and address, when the document states them. | Plan |
The full JSON Schema ships in /openapi.json under components.schemas.Eob. The spec is served today; the operations it documents are roadmap and tagged that way.
Four verbs over the statement.
Reading an EOB, reconciling it against a bill, and drafting an appeal for a human to send is open document work. This is the typed surface being built over it, labeled honestly: nothing below is callable yet.
| Verb | What it does | Status |
|---|---|---|
| parse | An EOB PDF or 835 remittance in, typed service lines out: billed, allowed, plan paid, patient responsibility, remark codes. | Roadmap |
| reconcile | Match the EOB against the provider's bill line by line, and flag anything billed beyond the allowed amounts. | Roadmap |
| explain | Turn a remark code (CO-45, CO-97, PR-1) into a plain-language sentence a member can act on. | Roadmap |
| draft | An appeal letter for a line the plan did not cover, with the plan's appeal deadline attached, for a human to review and send. | Roadmap |
None of these verbs decides a claim. The plan processes and decides the claim; this surface reads the paperwork that decision produces, and drafts are for a human to review and send. Nothing here is medical, legal, or billing advice. The P&C claims loop, with its own reserved acts, lives behind the reserved line at api.insure.
Built to be read by machines, honestly.
Every door in this estate ships a machine-readable kit. What is served today is served today; what is roadmap says Roadmap. Nothing on this list pretends to be callable before it is.
| Surface | What it is | Status |
|---|---|---|
| /llms.txt | This door in plain text for agents and answer engines: the definition, the schema, and the honest status of everything. | Served now |
| /openapi.json | OpenAPI 3.1 stub: the Eob schema as a typed read surface. The spec is served today; every operation in it is tagged x-status: roadmap and none is callable yet. | Served now |
| /mcp | Planned MCP endpoint. Planned tools: parse_eob, get_eob_schema, explain_remark_code. Documented before it exists so nobody mistakes a plan for a product. | Roadmap |
| /robots.txt | Allow-all. This door wants to be read, crawled, and quoted. | Served now |
The free tier is discoverability itself: this page, the schema above, /llms.txt, and /openapi.json stay free and keyless. No account is required to read anything on this door.
Read the schema now. Parse later.
Request early access and you are emailed the moment the EOB surface is callable. Early integrators shape the schema while it is still cheap to change: which plans, which formats, 835 or PDF first.
The honest fine print. eobs.claims is an early-access door of the api.insure estate, in the health revenue-cycle register. There is no live parser or API behind this page yet: every operation in /openapi.json is tagged roadmap, the MCP endpoint is roadmap, and the EOB above is a specimen with fictional data. It is not a real plan document and it is not a bill. Appeal windows vary by plan and state; the plan's own notice controls. Nothing on this page is medical, legal, or billing advice, and nothing here decides a claim: the plan processes and decides claims.