How to Read Patient Insurance Coverage from EHRs with Unified.to's Healthcare API
·
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 each of them, 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 read insurance coverage from the EHR?
The practice already recorded each patient's insurance during registration, inside the EHR, so reading it there answers the question that eligibility checks, prior authorization, cost estimates, claims preparation and patient intake all start with: what insurance does this patient have, and which plan comes first?
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 payer, plan, group and member ID into a single Coverage object with plain fields.
What are the steps to show a patient's insurance?
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 service
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.
What does each Coverage field mean?
| 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 | Employer or plan group | Eligibility requests |
group_identifier | The group's 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 | Coverage start | Check the date of service is on or after it |
end_at | Coverage end | Check the date of service is on or before 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 (see How to Find and Register Patients). |
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.
What if an EHR doesn't return insurance coverage?
Check support before you scope. Which fields each EHR returns is on the Supported Integrations page. MEDITECH has no coverage object in Unified.to's Healthcare API, so a coverage call returns 501 (as of 26 October 2026).
Handle 501 separately from an empty list. 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.
How do I know when a patient's coverage changes?
On SMART on FHIR and Veradigm (as of 24 October 2026), updatedGte returns only coverage changed since a timestamp, and Unified.to's [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 each read goes directly to the EHR.
→ 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 directly against the customer's EHR. Unified.to keeps no customer records at rest; connection credentials and operational metadata are encrypted at rest. A HIPAA BAA is available on the Scale plan.