From proprietary EHR silos to SMART-on-FHIR APIs — simulating health data portability under the 21st Century Cures Act
Two decades of federal EHR incentive spending produced near-universal digitization without producing interoperability. Certified electronic health record adoption is nearly ubiquitous, yet most hospitals still cannot fluidly send, receive, find, and integrate outside patient data — the gap between "digitized" and "connected."
The HITECH Act (2009) funded the "Meaningful Use" program with roughly $35 billion in incentive payments to hospitals and physicians who adopted certified EHR technology. It worked as an adoption engine — but certification criteria of that era rewarded documentation and billing capability, not standardized external data exchange.
Each major vendor built its own internal data model: Epic's Chronicles is a hierarchical MUMPS (M) database; Oracle Health's (formerly Cerner) Millennium platform is relational but uses its own proprietary schema and identifiers; MEDITECH, athenahealth, Veradigm and NextGen each differ again. Interfacing between any two systems required custom point-to-point HL7 v2 messaging — ADT (admit-discharge-transfer) and ORU (observation result) message types hand-built and mapped system by system.
Because switching or connecting vendors was expensive and slow, some vendors had a direct commercial incentive to keep it that way — a dynamic regulators would later name "information blocking."
A single custom HL7 v2 interface between two health systems has historically cost anywhere from $50,000 to $250,000 to build and maintain, with no reuse across other vendor pairs — the classic "N-squared" integration problem.
Clinically, fragmentation shows up as duplicate imaging and lab tests when prior results are inaccessible, incomplete medication reconciliation at transitions of care, and specialist referrals that stall because the referring note never arrives in a usable form. Absent a national patient identifier in the US, matching "John A. Smith, DOB 3/4/1980" across two unconnected systems is itself unreliable — duplicate or mismatched patient records are estimated to occur in a meaningful share of cross-system encounters even inside a single health system's own facilities.
Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") was started by Grahame Grieve at HL7 in 2011 to replace brittle HL7 v2 messages and the seldom-implemented v3/RIM model with small, self-contained, web-native resources. FHIR Release 4 became the first normative version in October 2019 and is now the API layer every ONC-certified EHR must expose.
Each FHIR resource is a small JSON (or XML) object with a fixed schema, a unique id, and its own RESTful URL: [base]/Patient/123, [base]/Observation/456. Resources reference each other rather than nesting everything into one giant document — an Observation.subject points at a Patient; a MedicationRequest.subject does the same.
Standard verbs apply directly: GET reads a resource or a search Bundle, POST creates, PUT updates. Search parameters are standardized per resource (Observation?patient=123&category=laboratory&date=ge2025-01-01), so any FHIR-conformant client can query any FHIR-conformant server without bespoke integration code — the opposite of the HL7 v2 point-to-point model.
The United States Core Data for Interoperability (USCDI) defines the specific data classes every certified EHR must be able to expose via FHIR: patient demographics, problems, medications, laboratory results, clinical notes, allergies and intolerances, immunizations, vital signs, procedures, and care team members, among others.
USCDI is versioned and expands over time: v1 took effect with the 2020 Cures Act Final Rule; v3 was finalized in July 2023 and adds classes such as social determinants of health (SDOH) screening and assessment data; under the ASTP/ONC HTI-1 final rule, USCDI v3 compliance becomes mandatory for certified health IT starting January 1, 2026. The US Core Implementation Guide constrains base FHIR resources into US-specific profiles (for example, requiring the race/ethnicity extension on Patient) so that "conformant" actually means "usable" across vendors.
| Product | Indication | Trial Design | Key Result |
|---|---|---|---|
| Patient | Demographics, identifiers, contact info | Root resource — nearly everything else references it via .subject | One addressable identity ties the whole chart together |
| Observation | Labs, vitals, social history | LOINC-coded value[x] + effectiveDateTime + status | Same shape models a blood-pressure reading and a PCR result |
| Condition | Diagnoses, problems | SNOMED CT / ICD-10-CM coded, clinicalStatus flag | Keeps the problem list continuous across referrals |
| MedicationRequest | Prescriptions, orders | RxNorm-coded, structured dosageInstruction | Enables real-time interaction checks across prescribers |
| AllergyIntolerance | Allergies, adverse reactions | Criticality + coded reaction.manifestation | Cuts a leading cause of preventable adverse drug events |
SMART (Substitutable Medical Applications, Reusable Technologies) was created around 2010 at Boston Children's Hospital's Computational Health Informatics Program under Josh Mandel and Kenneth Mandl. Built on OAuth 2.0 and OpenID Connect, it lets a patient — not the EHR vendor — decide which third-party app may read which categories of their FHIR data, for how long.
1. App registration: the app is pre-registered with the EHR's authorization server and receives a client_id. 2. Launch: either "EHR launch" (clinician opens the app from inside the chart) or "standalone launch" (patient opens the app directly and selects their health system). 3. Authorization request: the app redirects to the authorization endpoint requesting specific scopes, e.g. patient/Observation.rs, patient/MedicationRequest.read. 4. Patient login and consent: the patient authenticates directly with the EHR (the app never sees the password) and reviews a consent screen listing exactly what is being shared. 5. Authorization code returned, then exchanged server-side for an access token — typically short-lived (around one hour) plus a longer-lived refresh token. 6. The app calls the FHIR API with an Authorization: Bearer <token> header; the server checks the token's scopes on every request.
SMART v1 scopes were resource-type-level (patient/Observation.read = all observations, full stop). SMART v2 (2022) introduced granular scopes that can restrict by category or code — patient/Observation.rs?category=laboratory grants only lab results, not mental-health or social-history observations, addressing a major privacy gap in the original design.
The CMS Interoperability and Patient Access Final Rule (CMS-9115-F), effective July 1, 2021, forces the other half of the equation: Medicare Advantage, Medicaid, CHIP, and Qualified Health Plan issuers must expose a Patient Access API using FHIR and SMART so patients can pull their own claims and clinical data into any app of their choosing, at no cost.
Once authorized, exchange happens two ways: small, synchronous REST calls for one patient at a time, and asynchronous Bulk FHIR jobs that export entire populations as newline-delimited JSON. Query-based networks like Carequality and CommonWell now bridge most of the country, and the federally chartered TEFCA network went live in 2024 to connect the networks to each other.
A typical single-patient lookup: GET [base]/Patient?identifier=SSN|123-45-6789 to resolve the FHIR id, then GET [base]/Observation?patient=123&category=laboratory&_sort=-date to pull recent labs. Results return as a searchset Bundle with pagination links (next/previous) rather than one unbounded payload.
Production FHIR endpoints typically enforce rate limits (commonly on the order of tens to low hundreds of requests per minute per client) and require the OAuth bearer token on every call — an app with no valid, sufficiently scoped token receives a 401 or 403 rather than data.
The HL7 Bulk Data Access Implementation Guide defines a $export operation: the client kicks off an asynchronous job with a Prefer: respond-async header, polls a status endpoint, and eventually receives links to NDJSON files (one resource type per file) staged in cloud storage. This is how accountable care organizations pull thousands of patients' worth of data for quality-measure reporting, and how payer-to-payer data exchange is being phased in under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F, finalized January 2024, with API provisions phasing in through 2026–2027).
Carequality (query-based exchange framework, est. 2014) and CommonWell Health Alliance (est. 2013) connected their networks to each other in 2018, together reaching a large majority of US hospitals and ambulatory practices for record lookup. TEFCA — the Trusted Exchange Framework and Common Agreement mandated by the Cures Act — designated its first Qualified Health Information Networks (QHINs) in December 2023, with live production exchange beginning in early 2024, aiming to make any-to-any query possible without every network having to bilaterally connect to every other one.
The 21st Century Cures Act, signed December 13, 2016, directed ONC to define "information blocking" and prohibit it. The Final Rule (45 CFR Part 171) took effect April 5, 2021 for USCDI v1 data and expanded to cover all electronic health information (EHI) on October 6, 2022 — with real financial teeth that only fully arrived years later.
Not every access delay or denial counts as blocking. ONC recognizes eight exceptions when specific conditions are met: Preventing Harm, Privacy, Security, Infeasibility, Health IT Performance (brief planned downtime), Content and Manner (how the data is delivered), Fees (reasonable, cost-based), and Licensing (reasonable terms for interoperability elements). A practice that doesn't cleanly fit an exception, and that interferes with access, exchange, or use of EHI, is presumptively information blocking if the actor knew (or should have known) it would have that effect.
Health IT developers, health information exchanges, and health information networks face civil monetary penalties of up to $1,000,000 per violation, enforced by the HHS Office of Inspector General under a rule finalized in July 2023 and effective that September. Providers instead face "appropriate disincentives" administered by CMS rather than direct fines — reduced or eliminated Promoting Interoperability incentive payments and other Medicare payment adjustments, phased in starting with reporting periods in 2024.
Semantic interoperability gaps remain common: two vendor instances can both use the correct LOINC or SNOMED code yet map local values to it inconsistently, so a "positive" result renders differently downstream. Patient matching is still probabilistic in the absence of a US national patient identifier, producing duplicate or split records at rates that vary widely by health system. And technically "compliant" APIs can still be de facto unusable — slow rate limits, undocumented fields, or fees calibrated just under the threshold that would trigger scrutiny — a pattern regulators have described as compliance in form but not in substance.