Epic offers record exchange, patient-directed APIs, and partner access—but those routes are not interchangeable

Start with the use case before choosing the connection

Epic's current interoperability page presents a portfolio of routes rather than one universal connection. It describes Care Everywhere for exchange across electronic health records, FHIR-based APIs for patient-directed sharing with third-party apps, Community Link for community users, direct connections with government partners, health-plan data exchange, electronic referrals, Share Everywhere for one-time patient-driven access, and publicly available API and interface specifications. Each route can be appropriate within its own operating context.

The labels cannot be treated as synonyms. A clinician querying for outside records, a patient authorizing an app, a community partner viewing a chart, an agency requesting information, a payer sending claims data, and a referral team transmitting an order involve different purposes, parties, credentials, identity rules, payloads, consent or authority, response expectations, and downstream work. A connection that works for one actor may be unavailable or inappropriate for another even when both touch the same patient record.

Build a route-by-use-case acceptance matrix

For each production use case, teams should retain the initiating actor, permitted purpose, legal and organizational authority, sending and receiving organizations, patient and provider identity process, endpoint and transport, standard and version, implementation guide or interface specification, requested and returned data, time horizon, provenance, consent or segmentation behavior, authentication, user workflow, exception path, monitoring, support owner, and retention rule. The record should distinguish access, query, push, referral, application API, portal view, and one-time share.

Acceptance criteria should match that route. A query-based exchange may require patient discovery, document retrieval, duplicate handling, and reconciliation. A patient-facing API needs authorization, app registration, revocation, scope, and response tests. Community access needs user provisioning and audit controls. A referral needs order, attachment, acknowledgment, scheduling, status, and closure behavior. Reusing the same connected flag across these cases obscures missing functions and gives buyers no way to explain who can do what.

Test one patient story across several paths

A representative evaluation should use one synthetic patient with records at multiple organizations and test a clinician exchange, a patient-directed app request, a community-user view, and an electronic referral. The team should introduce a near-match identity, missing document, revoked authorization, unsupported element, delayed acknowledgment, corrected result, and unavailable endpoint. Reviewers should see different expected outcomes by route, trace the source and transformation of returned data, identify who owns each exception, and avoid declaring all interoperability unavailable when only one path fails.

Epic's official page supports the described record-exchange, patient-directed API, partner-access, referral, government, payer, one-time sharing, and standards-based connection positioning, but no customer configuration, identity rule, API, interface, consent flow, data set, exchange, security control, implementation, or outcome was independently tested here. Providers, patients, exchange partners, developers, privacy and security teams, clinical owners, and legal and compliance leaders must define the production route. Published interoperability options do not certify route availability, complete records, semantic fitness, lawful disclosure, or clinical use.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.