How to Read Patient Insurance Coverage from EHRs with
Your product can read a patient's insurance coverage (payer, plan, group number, member ID, policy holder and coverage dates) from AdvancedMD, athenahealth, CharmHealth, Epic, NextGen Healthcare, Oracle Health, PointClickCare, SMART on FHIR, TruBridge and Veradigm through one connection and one method call (as of 24 October 2026).
sdk.healthcare.listHealthcareCoverages returns the same Coverage object on all ten, so intake, eligibility and billing features read insurance the same way whichever EHR the practice runs. Every request is executed directly against the customer's EHR, so what you read is what's on file now.
Why insurance is the missing piece in most healthcare integrations
Eligibility checks, prior authorization, cost estimates, claims preparation and patient intake all start with the same question: what insurance does this patient have, and which plan comes first? The practice has already answered it during registration, inside the EHR.
Without that data, products ask patients to retype their insurance card, or staff to copy it between systems. Each EHR stores coverage differently: plan and group are nested classifications, the member ID may be a top-level field or an identifier, and the payer is a reference to an organization. Unified.to's Healthcare API maps all of it into a single Coverage object with plain fields.
What you are building
An insurance panel or intake pre-fill inside your product: the customer connects their EHR, and each patient's active coverage appears, ordered by priority.
- Authorize the customer's EHR and store one connection ID
- List a patient's coverage
- Pick the active plan in priority order
- Pass payer, plan, group and member numbers to your eligibility or billing workflow
Connect once and list a patient's coverage
import { UnifiedTo } from '@unified-api/typescript-sdk';
const sdk = new UnifiedTo({
security: { jwt: process.env.UNIFIED_API_KEY },
});
const coverages = await sdk.healthcare.listHealthcareCoverages({
connectionId,
patientId,
});
Each end-customer authorizes their own EHR through Unified.to's authorization component, which returns a connection ID. Store one per customer. On a patient-launch connection, leave out patientId and Unified.to uses the patient who authorized it.
What each field tells you
| Field | What it is | Typical use |
|---|---|---|
payer_name | The insurer | Route to the right clearinghouse or payer API |
plan_name | The plan, e.g. "Gold PPO" | Show the patient, match to fee schedules |
group_name / group_identifier | Employer or plan group and its number | Eligibility requests |
member_identifier | Member ID from the insurance card | Eligibility requests and claims |
subscriber_name | The policy holder | Dependent coverage |
relationship | SELF, SPOUSE, CHILD or OTHER | Whether the patient is the policy holder |
priority | 1 = primary, 2 = secondary … | Coordination of benefits |
status | ACTIVE, CANCELLED, DRAFT, ENTERED_IN_ERROR | Ignore anything not active |
start_at / end_at | Coverage period | Check the date of service falls inside it |
codes | The EHR's coverage-type codings (e.g. PPO, Medicare) | Product-type rules |
patient_id is the beneficiary, and references the same Patient object your product already reads. |
Pick the plan that applies
const dateOfService = new Date();
const applicable = coverages
.filter((c) => c.status === 'ACTIVE')
.filter((c) => !c.start_at || new Date(c.start_at) <= dateOfService)
.filter((c) => !c.end_at || new Date(c.end_at) >= dateOfService)
.sort((a, b) => (a.priority ?? 99) - (b.priority ?? 99));
const primary = applicable[0];
Treat a missing priority as unknown rather than primary when a patient has more than one plan.
Handling coverage that varies by EHR
Check support before you scope. Which fields each EHR returns is on the Supported Integrations page. MEDITECH's FHIR API doesn't include coverage, so it returns 501 Not Implemented (as of 24 October 2026).
Treat 501 as information, not failure. An empty list means the EHR has no insurance on file for the patient (self-pay, or not yet registered); a 501 means the EHR can't tell you. Fall back to asking the patient only in the second case.
Coverage is read-only. Insurance is entered at registration, in the EHR. Unified.to reads it; it doesn't write it.
Stay current
On SMART on FHIR and Veradigm (as of 24 October 2026), updatedGte returns only coverage changed since a timestamp, and [virtual webhooks](/blog/what_are_virtual_webhooks_how_they_differ_from_sync_based_webhooks) (object_type: "healthcare_coverage") deliver changes to your endpoint. On the other EHRs, read coverage when you need it, typically when a visit is booked or the patient checks in, since it changes rarely and the read is real time.
→ Start your 30-day free trial → Book a demo
Frequently asked questions
Does this check eligibility with the payer?
No. This reads the coverage the practice has on file. Pass payer_name, member_identifier and group_identifier to your eligibility service (a clearinghouse or payer API) to confirm benefits.
Is the patient's insurance data stored by Unified.to?
No. Every request runs against the customer's EHR in real time, and Unified.to keeps no patient records at rest. Unified.to is HIPAA compliant.