What data can you actually get out of the EHR? Two routes, not one

Being a clinician does not entitle you to your institution's data, and a certified, "FHIR-enabled" EHR does not mean the app you build can reach it. Access runs through two genuinely different routes, and most of the frustration clinicians report comes from picking the wrong one, or mistaking a technical capability for a legal or operational one.

HTI-5, the rule that would clarify how information-blocking law treats automated and AI-driven access, is not law yet. A final draft has sat under OIRA review since 28 July 2026, with no conclusion date published as of 14 September 2026; everything below describes what is actually in force today, not what a still-pending rule might become.

A request for data has to clear six layers, not one, and a project fails wherever the first one does:

Changelog

• Epic2026-09-14 · Initial publication, checked directly against open.epic.com and vendorservices.epic.com.
• Oracle Health2026-09-14 · Initial publication; one previously reported pricing tier confirmed directly, two others omitted as unverified.
• eClinicalWorks2026-09-14 · Initial publication, checked directly against eclinicalworks.com; no public sandbox URL located, marked unverified rather than assumed.

The two routes

Two routes reach real data, and they answer different questions.

Patient right-of-access. HIPAA gives a patient, or their authorised representative, access to their own designated record set, not only the standardised subset a certified API exposes, usually within 30 days and often faster through a portal export or a patient-authorised SMART app. This route needs no institutional sponsor; a patient can request it directly, or a properly authorised app can retrieve it on their behalf. It is scoped to one patient at a time, and to what that patient's providers actually hold.

Developer program. Registering with a vendor unlocks a free sandbox in every case checked above, but production access still runs through the institution: it decides which apps connect, what scopes they get, and whether the stated purpose is treatment, operations or something else. This route supports cohorts and embedded clinical workflows; it is also the slower one, since it depends on someone else's security and change-management queue rather than a vendor's sandbox speed.

The decision rule is simple: one patient wants their own record, start with the patient route; a clinician wants workflow, a cohort, or anything written into the chart, start with the institution, and budget for its calendar, not the vendor's.

Real examples

Two people already verified on this directory prove both routes work, in opposite directions. Josh Mandel, SMART Health IT's chief architect, built mychart-takeout, a browser tool that exports a patient's own record from Epic MyChart and keeps it local; the project documents testing against several production Epic instances, most recently a parity check on 13 August 2026. Chukwuma Onyeije MD went the institutional route and wrote up what it actually took, in his own words: a free Epic sandbox, then "an application review process, security documentation, and... a data use agreement" before anything touched production.

Two further examples, neither a directory member yet, show the ceiling on each route once fully built out. The University of Utah's Bili App, a SMART on FHIR tool embedded in Epic for neonatal bilirubin management, was used 20,516 times for 91.84% of eligible newborns in its published evaluation, saving a median 66 seconds per task; that is the institutional route once deployed and evaluated, not merely approved. COSRI, the University of Washington's SMART on FHIR opioid-prescribing tool, is the same pattern for a different specialty. On the patient side, Mere Medical (Christopher Fu, internal medicine) is a local-first personal record built entirely on patient-authorised SMART connections: no institutional sponsor required, and no institutional ceiling either.

The 3am nurse test for live data

The site's own bar for a finished tool, the 3am nurse test, applies just as hard to a data connection as to the tool built on top of it. Before treating any live feed as ready:

• Is this the right patient, at the right organisation?
• When was this pulled, and what does a blank field mean: no data, not asked, or a failed query?
• Can every displayed value be traced back to its source record?
• What does a clinician still need to verify inside the EHR itself before acting on this?
• Who owns the problem the day this connection breaks?

An API returning 200 OK answers none of these. A synthetic-data sandbox answers none of them either; production data carries duplicates, corrections, external records and gaps a test patient never will.

What this doesn't cover

Write-back capability is deliberately not a column in the table above: it varies operation by operation even within one vendor, and folding a vendor's read access together with its usually separate, usually narrower write access would be exactly the kind of imprecision this guide is trying to avoid. Even if HTI-5 finalises largely as proposed, it would remove one exception vendors used to refuse third-party write requests; it would not create a duty to expose a writable endpoint. This guide is also US-only: HIPAA, the Cures Act and information-blocking law stop at the US border, and a clinician elsewhere is working under an entirely different framework. Payer-side APIs (CMS-0057-F, due January 2027 for Medicare Advantage, Medicaid, CHIP and federal exchange plans) are a related but separate system, out of scope here.

Corrections

Every card above has a "Suggest a correction" link. Vendor pricing and process change without much notice, and the table's own honesty depends on catching that fast, not on getting it right once and assuming it stays right. See the open data endpoint for the machine-readable version of everything above, CC BY 4.0 licensed.