🔒 Health Data Portability Interoperability (FHIR) Simulator

Proprietary EHR Silos and the Cost of Non-Interoperability

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."

• 96%: Hospitals with certified EHR (ONC/ASTP national data, 2021)
• 62%: Hospitals doing all 4 interop domains (send + receive + find + integrate)
• ~75%: Clinical communication still by fax (industry estimates, US ambulatory care)
• $155M: eClinicalWorks settlement (DOJ False Claims Act, 2017)

How Meaningful Use built silos, not bridges

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."

The measurable cost of fragmentation

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.

HL7 FHIR R4 — Decomposing the Chart into Modular, RESTful Resources

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.

• Oct 2019: FHIR R4 normative release (HL7 International)
• 145+: Resource types defined in R4 (Patient, Observation, Condition...)
• 2011: FHIR development began (led by Grahame Grieve)
• USCDI v3: Current mandated data set (compliance from Jan 1, 2026)

Resource-oriented, REST-native architecture

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.

USCDI — the mandatory minimum data set

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.

Core clinical FHIR resources exchanged in a typical record

SMART on FHIR — Patient-Mediated, Scoped Authorization

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.

• Boston Children's: Origin institution (SMART launched circa 2010)
• OAuth 2.0: Underlying protocol (+ OpenID Connect)
• 800+: Health systems via Apple Health Records (SMART on FHIR, by ~2023)
• §170.315(g)(10): ONC certification criterion (mandates SMART App Launch support)

The SMART App Launch flow, step by step

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.

Granular scopes and the CMS Patient Access mandate

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.

From Single Queries to Population-Scale Bulk FHIR Pipelines

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.

• 2018: CommonWell–Carequality bridge (connected the two largest US networks)
• NDJSON: Bulk export file format (HL7 Bulk Data Access IG, $export op)
• Feb 2024: TEFCA go-live (first QHINs begin live exchange)
• ~$15B: CMS prior-auth API savings est. (over 10 years, CMS-0057-F)

Synchronous REST queries in practice

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.

Bulk FHIR ($export) for population health

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).

The networks stitching it together

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 Information Blocking Rule — Penalties, Exceptions, and What Actually Moves the Needle

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.

• Dec 13, 2016: Cures Act signed into law (directed the info-blocking rule)
• Apr 5, 2021: Info-blocking compliance start (initial USCDI v1 scope)
• Oct 6, 2022: Scope expanded to all EHI (no more USCDI-only carve-out)
• $1,000,000: Max penalty per violation (developers/HINs/HIEs, HHS OIG rule, 2023)

Eight recognized exceptions to information blocking

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.

Two separate penalty tracks

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.

Failure modes that persist even without deliberate blocking

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.