HL7 v2 & FHIR EHR Integration in 2026: What It Takes

Updated October 2026: how to turn HL7 v2 feeds into a FHIR API and pick the engine for it, the HTI-5 proposed rule and the 2026 SVAP option (US Core 9.0.0 with USCDI v6), and Epic's 2026 developer numbers.

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

HL7 v2 EHR integration means exchanging pipe-delimited HL7 v2 messages — ADT for admissions and demographics, ORU for results, ORM or OMG for orders — with a hospital's electronic health record over MLLP, usually through an integration engine behind the hospital firewall. FHIR integration means calling the EHR's FHIR R4 REST API over HTTPS with SMART on FHIR authorization. In 2026 most telehealth products need both: FHIR for the app-facing reads and writes, HL7 v2 for the real-time feeds the hospital already publishes.

"We'll just integrate with the EHR" is the sentence that quietly adds three months to a telemedicine roadmap. The electronic health record — the system of record where a clinician's notes, diagnoses, medications, and results live — does not have one connector you flip on; it has two interoperability standards, several versions, a per-vendor approval process, and a federal rule that says which version is current. This article is written for the founder, product manager, or hospital IT lead who has heard "FHIR" and "HL7" in vendor calls and needs to understand what they actually are, which one to use when, and why the EHR connection is the part of a telemedicine build most likely to slip. Get the model right and you can scope it honestly; get it wrong and you discover the cost after you have promised a date. This piece is the deep-dive behind the single EHR link on the telemedicine integration map.

Two standards, one family

Here is the fact that confuses almost everyone the first time: HL7 v2 and FHIR are both made by the same organization, Health Level Seven International (HL7), a non-profit standards body. They are not rivals from competing camps. They are two generations of the same family's work, built thirty years apart for different worlds, and a real hospital runs both at once.

HL7 v2 is the elder. It was designed in the late 1980s to let one hospital department's computer send a message to another — admit this patient, here is a lab result, here is an order — over the local network. It is a messaging standard: systems fire structured text messages at each other and acknowledge receipt. FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is the modern standard, first drafted in 2011 and built for the web. It is an API standard: an app asks a server a question over HTTPS — "give me this patient's active medications" — and gets a structured JSON answer back, the same way any modern web or mobile app talks to any modern backend.

The reason both survive is simple economics. Hospitals spent three decades wiring HL7 v2 between their systems, and that plumbing works. FHIR did not replace it; it was added on top, mostly so external apps — patient portals, telemedicine front ends, analytics tools — could read and write the record through a clean web interface. So when a vendor says "we support FHIR," they usually mean "we put a FHIR API in front of a system that still speaks HL7 v2 internally." You will meet both, and you need to understand both.

HL7 v2: the language hospitals already speak

Open an HL7 v2 message and it looks like this — deliberately fake data, never put real patient data in a sample:

MSH|^~\&|LIS|LAB|EHR|HOSP|202606141015||ORU^R01|MSG00001|P|2.5.1
PID|1||100042^^^HOSP^MR||DOE^JANE||19850312|F
OBR|1||ORD789|2345-7^Glucose^LN|||202606141000
OBX|1|NM|2345-7^Glucose^LN||96|mg/dL|70-99|N|||F

Each line is a segment, named by its first three letters. MSH is the message header — who sent it, who receives it, what kind of message it is, and when. PID is patient identification — the medical-record number, name, date of birth, sex. OBR is an order, OBX is an observation (here, a glucose result of 96 mg/dL with a normal range and an "N" for normal). The pipe character | separates fields; the caret ^ separates components inside a field. That is the whole idea: a line per fact, delimiters between the pieces.

Messages come in types, and the three-letter codes are worth recognizing because vendors use them as shorthand. ADT (Admit, Discharge, Transfer) messages announce patient movement and demographics — the backbone feed most systems subscribe to. ORU carries observation results, like the lab result above. ORM and the newer OMG/OMP carry orders. SIU carries scheduling. Every message gets an ACK (acknowledgement) back so the sender knows it arrived. The transport underneath is usually MLLP (Minimal Lower Layer Protocol), a thin wrapper that frames each message over a raw TCP socket — not HTTPS, which is one reason HL7 v2 feeds live inside a hospital's network rather than on the open internet.

HL7 v2's strength is that it is everywhere and it is stable: a result feed wired in 2008 still runs. Its weakness is that it is loose. The standard has optional fields and "Z-segments" (custom local extensions), so two hospitals can send "the same" ORU message with different fields populated, and your integration has to handle each site's dialect. That per-site variability, not the format itself, is what makes HL7 v2 work labor-intensive. For a telemedicine product, HL7 v2 is how you most often receive a real-time ADT feed (to know a patient was admitted) or a lab result feed (to pull results into the consult), server-to-server, behind the hospital firewall.

FHIR: the web API for clinical data

FHIR takes a different mental model. Instead of messages flying between systems, FHIR models healthcare as a set of resources — discrete, named objects you can read and write through a REST API. A Patient resource. An Observation resource (a lab result, a vital sign). A MedicationRequest (a prescription). An Appointment, an Encounter, a Condition (a diagnosis), a DocumentReference (a clinical note). FHIR R4 defines roughly 145 resource types; a telemedicine app typically touches a dozen.

Reading data is an ordinary HTTPS request. To get a patient's record you call GET [base]/Patient/100042; to find their active medications you call GET [base]/MedicationRequest?patient=100042&status=active. The server returns JSON. Here is a trimmed, fake Observation — the same glucose result as the HL7 v2 example, in FHIR's shape:

{
  "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "2345-7", "display": "Glucose" }] },
  "subject": { "reference": "Patient/100042" },
  "valueQuantity": { "value": 96, "unit": "mg/dL" },
  "referenceRange": [{ "low": { "value": 70 }, "high": { "value": 99 } }]
}

Two things make FHIR practical for an app team. First, it is self-describing JSON over HTTPS — any engineer who has built a web app can read it without learning a clinical message grammar. Second, it carries the codes inline: that loinc.org / 2345-7 says "this is a glucose measurement" in a universal vocabulary, so you are not guessing what a number means. FHIR is how a telemedicine app reads patient context before a visit and writes the visit back to the chart afterward, through the API the EHR vendor publishes.

FHIR's limitation is the mirror of HL7 v2's. Because it is newer and exposed to the outside world, it is governed tightly — and the governing version is set by federal rule, which is the next section. It is also still filling in: not every workflow a hospital runs internally has a mature FHIR equivalent, which is exactly why the legacy HL7 v2 paths persist.

Figure 1. HL7 v2 versus FHIR. Two standards from the same body, thirty years apart. Most hospitals run both: FHIR for app-facing reads and writes, HL7 v2 for legacy server-to-server feeds.

The version that matters in 2026

"We support FHIR" is not a specification, because FHIR has versions and US health IT is locked to a specific one. Three numbers define the 2026 baseline, and they are dated.

The base standard is FHIR Release 4 (R4), published in 2019. R4 is the version with normative content — parts the authors have promised will not break — which is why regulators built on it. Two newer releases exist: R4B (December 2022), a small transitional update, and R5 (March 2023), a larger release that is "trial use" and introduced breaking changes, so production health IT has not moved to it. R6 has been through two normative ballots — the first in the January 2026 cycle, the second published as 6.0.0-ballot5 in July 2026 — and is not final; the official current release is still R5 [8]. For an EHR integration in 2026 you target R4, full stop.

R4 alone is not enough, because R4 is a global standard and the U.S. needs to pin down exactly which fields a certified record must support. That job belongs to US Core, a U.S.-specific FHIR implementation guide (a profile that says "in the U.S., a Patient resource must include these elements, bound to these code systems"). US Core is keyed to USCDI — the United States Core Data for Interoperability — the government's list of clinical data classes every certified record must exchange.

Under the U.S. Office of the National Coordinator's HTI-1 Final Rule, certified health IT must support US Core 6.1.0 against USCDI v3, with SMART App Launch for authorization, as the baseline — with a compliance date of January 1, 2026 [1][2][3]. On that same date the older versions retired: USCDI v1, US Core 3.1.1, and SMART App Launch 1.0.0 are no longer the certification floor [3]. Vendors may voluntarily go higher through ONC's Standards Version Advancement Process (SVAP) — US Core 7.0.0 maps to USCDI v4, US Core 8.0.1 to USCDI v5, and the 2026 SVAP list, usable from August 29, 2026, adds US Core 9.0.0 with USCDI v6 [11] — but the floor you can rely on in 2026 is R4 / US Core 6.1.0 / USCDI v3 [1][2]. Write that string into your integration spec.

The rule that forces all of this to exist is worth naming, because it is why you can demand a FHIR API at all. ONC's certification program includes a criterion, § 170.315(g)(10), "Standardized API for patient and population services," that requires certified EHRs to expose a FHIR R4 API supporting both single-patient access (via SMART on FHIR) and multi-patient bulk access [4]. Paired with the information blocking rules, which prohibit a certified actor from unreasonably interfering with access to electronic health information, the effect is that a hospital's certified EHR is required to offer you a standards-based FHIR door. You still have to go through the vendor's process to use it — but the door has to be there.

What changed in 2026, and what is still proposed

Three developments since January matter for anyone scoping EHR work now. First, the HTI-5 proposed rule (published in the Federal Register on December 29, 2025; comments closed February 27, 2026) would remove 34 and revise 7 of the 60 certification criteria and keep the FHIR API criteria, (g)(10) among them, at the center of what is tested [12]. It would also state that "access" and "use" of health data under the information blocking rules include automated means, including autonomous AI systems [12]. As of October 2026 ONC lists it as a proposed rule, so the HTI-1 baseline above still governs; check its status before you sign a spec. Second, the CMS Interoperability Framework asks networks that want to be shown as CMS Aligned Networks to offer FHIR APIs on US Core with USCDI v3 or later, with those API requirements in effect from July 4, 2026 [13]. Third, TEFCA, the national network-of-networks, had moved 464 million documents by the end of 2025, according to ONC, and HHS reported passing 1 billion exchanged records in June 2026 [14]. The direction is the same in all three: FHIR as the default door, HL7 v2 kept for what already runs.

Figure 2. The version ladder. FHIR R4 is the certified baseline, profiled by US Core 6.1.0 against USCDI v3 as of January 1, 2026 under HTI-1; since August 29, 2026, SVAP also allows US Core 9.0.0 with USCDI v6. R5 is trial-use; R6 is still in ballot. Target R4.

SMART on FHIR: launching your app inside the EHR

A FHIR API answers "how do I read the data?" SMART on FHIR answers the question that comes first: "how does the app prove who is asking, and get permission?" SMART (Substitutable Medical Applications, Reusable Technologies) is a thin, healthcare-specific layer on top of OAuth 2.0, the same authorization framework that powers "Sign in with Google." The certification floor since January 1, 2026 is SMART App Launch 2.0.0 (granular scopes, PKCE); the latest published version is 2.2.0, built on FHIR R4 [3].

In plain terms, SMART solves a login-and-context problem. Imagine a clinician clicks your telemedicine tool from a button inside their EHR. You do not want them to log in again, and you want your app to know which patient's chart is open right now. SMART's EHR launch does both: the EHR redirects to your app with a launch token, your app completes an OAuth2 handshake (using PKCE, a proof step that stops an intercepted code from being reused), and the EHR hands back an access token plus launch context — the authorized user and the current patient — so your app opens already pointed at the right chart. There is also a standalone launch, for when a patient opens your app directly and authorizes it to pull their record from the hospital's portal.

Permissions are expressed as scopes, a compact vocabulary borrowed straight from FHIR. A scope like patient/Observation.rs means "read and search this one patient's observations." user/Appointment.rs means "the appointments this logged-in user may see." system/Patient.rs is for a backend service with no human present. The pattern is [context]/[Resource].[permissions], and it lets a hospital grant your app exactly the data it needs and nothing more — the minimum-necessary principle of HIPAA, enforced in the authorization layer. For a telemedicine product, SMART on FHIR is the difference between "log in twice and copy the patient's name across" and "the consult opens already wired to the chart."

Figure 3. The SMART on FHIR EHR-launch flow. The EHR hands your app the logged-in user, the open patient, and a scoped access token, so the clinician never logs in twice and the app reads only what it was granted.

The three ways data actually moves

Once you hold a token, clinical data reaches your platform through three patterns, and choosing the right one per use case is most of the integration design.

The first is user-facing SMART on FHIR reads and writes — one patient at a time, in the moment. A clinician opens the consult, your app pulls this patient's problems, medications, and recent results through the FHIR API, and writes the visit note back as a DocumentReference. This is the pattern for the live consult.

The second is bulk data export, for when you need many patients at once — populating a registry, running quality reporting, training an analytics model. FHIR's Bulk Data Access specification (nicknamed "Flat FHIR") defines a $export operation that returns large datasets as NDJSON — newline-delimited JSON, one resource per line — at the system, group, or patient level [5]. Because no human is present, it authenticates with SMART Backend Services: your server signs a JWT with a private key instead of a user logging in [5]. Bulk export is how you move a population, not a person.

The third is HL7 v2 messaging, the legacy real-time feed described earlier — an ADT stream to know who was admitted, an ORU stream to receive results — server-to-server over MLLP, behind the firewall. New telemedicine integrations lean on FHIR, but many production deployments still take their real-time event feeds over HL7 v2 because that is what the hospital already publishes.

A practical rule: use SMART on FHIR for the live, single-patient consult; Bulk Data for population reads; and HL7 v2 for the real-time event feeds the hospital already runs. Most clinical products end up using all three.

Turning HL7 v2 feeds into a FHIR API: picking the platform

To expose legacy HL7 v2 messages as RESTful APIs for a telehealth app, you put a translation layer between the hospital and your product: it listens for HL7 v2 over MLLP, acknowledges each message, maps segments to FHIR R4 resources, validates them against US Core, and stores or forwards them so your app reads plain FHIR. The mapping itself has a standard now: HL7's V2-to-FHIR implementation guide, version 1.0.0 (STU 1), maps v2 segments and data types to FHIR R4 [15]. What you choose is where that layer runs and who maintains it.

Three facts change the math in 2026. Mirth Connect, which many teams adopted because it was open source, moved to a single commercial license with version 4.6 in March 2025; 4.5.2 is its last open-source release [17]. Microsoft says its default conversion templates are samples, not supported for production, so you host and test your own copy [16]. And no tool removes per-site work: every hospital's Z-segments and optional fields still need a mapping and a test set of real-shaped messages. Choose on four questions: does it speak MLLP with ACKs inside the hospital network, does it validate output against US Core, can one engineer change a site's mapping in a day, and will the vendor sign a BAA.

If the EHR has no public API, check certification first: a certified EHR must offer the (g)(10) FHIR API [4]. If it is not certified, ask the vendor for an HL7 v2 interface, or reach it through an aggregator that already has a connection. Screen scraping and browser automation are a last resort for production clinical data: they break on every UI release and still need a BAA.

What "integrate with Epic" actually involves

Here is where the standards meet reality. FHIR R4, US Core, and SMART are the common language; each EHR vendor wraps that language in its own developer program, sandbox, review, and go-live process. "Integrate with Epic" is a project, not a setting, and the standard does not save you from the vendor's gate.

Epic runs the largest such program. Its app marketplace, launched in 2016 as App Orchard, was wound down at the end of 2022, and in August 2023 Epic unveiled Showroom in its place [10], organized in tiers: a Connection Hub listing (a paid annual listing so health systems can find your product), a Toolbox of recommended integration patterns, and a Workshop tier for deep co-development. Production access to Epic's APIs runs through its Vendor Services program — the successor to App Orchard — plus the open fhir.epic.com developer sandbox for building against test data first. The scale in 2026: Epic reports more than 1,000 apps listed in Showroom, about 3.7 billion patient-directed data exchanges a month through its APIs, and more than 50 new APIs for payer and prior-authorization exchange [18]; its public directory listed 478 production FHIR R4 endpoints on October 19, 2026 [19]. Epic also publishes its HL7 v2 interface specifications on open.epic.com. The point for scoping is that you build against the sandbox, then pass Epic's review and a per-customer go-live before a single real patient's data flows.

Oracle Health (the former Cerner, acquired by Oracle in 2022) exposes its Millennium platform through its own FHIR R4 APIs and a code/console developer program with the same shape: sandbox, registration, then production. In August 2025 Oracle launched a new AI-centered EHR on Oracle Cloud Infrastructure, first for U.S. ambulatory practices, with acute care planned for 2026 [20]; Millennium is still the installed base most integrations meet. athenahealth runs its marketplace and developer portal the same way. Each of the long tail — eClinicalWorks, MEDITECH, and the rest — has its own front door. The standards are shared; the onboarding is not, and that is the part that takes weeks per vendor.

This is why many teams reach for an aggregator instead of integrating each EHR directly. Companies like Redox and Health Gorilla maintain the per-vendor connections and expose one normalized API to you, trading a direct relationship (and per-transaction cost) for a single integration surface and a faster start. When to integrate directly, when to use an aggregator, and when to embed inside the EHR is the trade-off weighed in the integration decision guide; the vendor-by-vendor specifics are in integrating with Epic, Oracle Health (Cerner), and athenahealth. The takeaway here: a FHIR API being "standard" does not make access instant, because the standard governs the data shape, not the vendor's admission process.

Figure 4. Four paths to the record. Direct FHIR gives the most control and the slowest start; an aggregator trades per-transaction cost for one integration surface; embedding via SMART suits in-EHR workflows; HL7 v2 remains the legacy real-time feed.

A worked example: the timeline math

Numbers keep the scope honest. Suppose you scope a telemedicine product's EHR work as "read the patient's chart before the visit and write the note back after." Against a single, cooperative vendor, the FHIR read-and-write code itself is small — call it two engineering-weeks once you have access.

Now add the parts the standard does not remove. Sandbox setup and learning the vendor's quirks: one week. Mapping your data model to US Core profiles and the terminology codes: one week. Vendor app review and security questionnaire: two to four weeks of mostly waiting, not coding. A per-customer go-live with the hospital's own IT team: one to three weeks. So a first EHR integration against one vendor runs, conservatively:

2 (code) + 1 (sandbox) + 1 (mapping) + 3 (review, midpoint) + 2 (go-live, midpoint) = 9 engineering-weeks, of which only two are the FHIR code.

Now multiply. Supporting Epic and Oracle Health and athenahealth is not 3× the code — the FHIR calls are similar — but it is roughly 3× the review, sandbox, and go-live overhead, because each vendor gates you separately. That overhead, not the API, is why "integrate with the EHR" stretches a roadmap, and why an aggregator that collapses three onboardings into one can be worth its per-transaction fee. Fill in your own vendors; the shape holds.

The terminology layer underneath

One more piece sits under both standards: the code systems that give clinical data shared meaning. A FHIR Observation or an HL7 v2 OBX is only useful if "glucose" means the same thing everywhere, so healthcare uses standard vocabularies. LOINC (Logical Observation Identifiers Names and Codes) names lab tests and measurements — the 2345-7 for glucose in the examples above. SNOMED CT names clinical findings and conditions. RxNorm names medications. ICD-10-CM names diagnoses for billing. US Core binds specific FHIR fields to specific vocabularies, so "support US Core" includes "send the right codes." You do not invent these; you map your data to them. The labs deep-dive covers LOINC in practice in lab orders and results.

A common mistake to avoid

The most expensive misconception is treating the EHR connection as one undifferentiated task — "add EHR integration" as a single backlog ticket. It is at least four decisions: which standard per data flow (FHIR vs HL7 v2), which version (R4 / US Core 6.1.0 in 2026, not "latest"), which access pattern (live SMART read, bulk export, or v2 feed), and which path per vendor (direct, aggregator, or embedded). Collapse those into one ticket and you will scope the two weeks of FHIR code and miss the seven weeks of versioning, mapping, review, and go-live around it.

A close second mistake is on compliance, and it is quiet. The EHR, any integration engine, and any aggregator in the path all handle Protected Health Information — any health data tied to an identifiable person — so every one of them sits inside your HIPAA boundary and needs a signed Business Associate Agreement (BAA), the contract that makes it lawful for a vendor to handle patient data, before a single field flows. A FHIR sandbox uses synthetic test data and needs no BAA; the moment you point at real patient data in production, the BAA must already be in place. The contract is covered in Business Associate Agreements; the rule behind it in HIPAA in plain English for product teams.

Quick answers

What is HL7 v2 EHR integration?

It is exchanging HL7 v2 messages — ADT, ORU, ORM — with a hospital's EHR over MLLP, usually through an integration engine inside the hospital network. A telehealth product uses it to receive admissions, results and orders in real time.

How do I pick a platform that turns HL7 v2 messages into REST APIs?

Pick one that listens on MLLP with ACKs, maps to FHIR R4 using the HL7 V2-to-FHIR guide, validates against US Core 6.1.0, and signs a BAA. A self-hosted engine fits many site-specific feeds; Azure or Google Cloud fits a backend already on that cloud; an aggregator fits many EHRs at once.

How do I integrate with an EHR that has no public API?

A certified EHR must expose a FHIR R4 API under ONC criterion (g)(10). For an uncertified system, buy an HL7 v2 interface from the vendor or go through an aggregator; keep screen scraping out of production.

How do I build telehealth software that integrates with existing EHRs?

Use SMART on FHIR to launch the consult from the chart and read context, write the visit note back as a FHIR DocumentReference, and take ADT and result feeds over HL7 v2 where the hospital already publishes them. Plan the vendor review and per-customer go-live as their own milestones.

How do I connect patient-flow software to hospital systems?

Subscribe to the hospital's HL7 v2 ADT feed for admissions, transfers and discharges, and use FHIR Encounter and Location reads where the EHR exposes them. The ADT feed is the event source; FHIR fills in detail on demand.

How long does a first EHR integration take?

About 9 engineering-weeks against one cooperative vendor in our worked example, of which only 2 are FHIR code; the rest is sandbox, mapping, vendor review and go-live. Each extra vendor repeats most of that overhead.

Where Fora Soft fits in

Fora Soft has built real-time video and clinical software since 2005, and in telemedicine the EHR connection is where the schedule risk concentrates, so we scope it as its own project from day one. The requirement comes before the feature: a BAA on the EHR vendor and any aggregator before real data flows, the version pinned to the certified baseline (FHIR R4 / US Core 6.1.0 / USCDI v3 in 2026, with US Core 9.0.0 only where the customer's EHR has adopted it) rather than "latest," HL7 v2 feeds translated to FHIR in one engine the team can change per site, and each access pattern chosen on purpose — SMART on FHIR for the live consult, Bulk Data for population reads, HL7 v2 for the real-time feeds the hospital already publishes. Then the capability follows: a video consult that reads the chart before the visit and writes the note back after, without leaking a field of patient data or surprising the timeline. Our AI telehealth video platform builds ship that FHIR R4 integration with Epic and Oracle Health, and our telemedicine software development team scopes the EHR leg as its own milestone.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume handbook that takes the whole video stack apart, from the pixel to production — encoding, delivery, audio, and AI — across 9,000+ pages. A telemedicine platform stands on that stack: volume 7 covers real-time pipelines, serving, cost, and the regulatory ground a clinical product has to hold; volume 3 covers WebRTC and the delivery layer the consult itself runs over; volume 1 covers the encoding underneath both. Work through them and you can design and build the system this article scopes. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. HTI-1 Final Rule — Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing — Office of the National Coordinator for Health IT (ASTP/ONC), final rule 2024; certified health IT must adopt USCDI v3 with US Core 6.1.0 and SMART App Launch, compliance date 2026-01-01. Tier 1. https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program
2. United States Core Data for Interoperability (USCDI) v3 and HL7 FHIR US Core Implementation Guide STU 6.1.0 — ASTP/ONC and HL7. USCDI v3 with US Core 6.1.0 is the 2026 certified baseline; SVAP allows voluntary US Core 7.0.0 (USCDI v4) / 8.0.1 (USCDI v5). Tier 1. https://hl7.org/fhir/us/core/
3. SMART App Launch Implementation Guide 2.2.0 (SMART on FHIR), OAuth 2.0 EHR and standalone launch, scopes — HL7 / SMART Health IT. Defines EHR launch, standalone launch, OAuth2 with PKCE, launch context, and the scope vocabulary; older SMART App Launch 1.0.0 retired as the certification floor on 2026-01-01. Tier 1 (standard). https://hl7.org/fhir/smart-app-launch/
4. ONC § 170.315(g)(10) — Standardized API for Patient and Population Services (ONC Health IT Certification Program) — ASTP/ONC. Requires certified EHRs to expose a FHIR R4 API supporting single-patient (SMART on FHIR) and multi-patient (bulk) access; the basis for "a certified EHR must offer a FHIR door." Tier 1. https://onc-healthit.github.io/api-resource-guide/g10-criterion/
5. HL7 FHIR Bulk Data Access (Flat FHIR) Implementation Guide and SMART Backend Services — HL7. Defines the $export operation (system / group / patient level), NDJSON output, and JWT-based backend-service authorization for moving large FHIR datasets without a user present. Tier 1 (standard). https://hl7.org/fhir/uv/bulkdata/export.html
6. HL7 FHIR Release 4 (R4) specification — Health Level Seven International. The normative, certified base version of FHIR profiled by US Core; defines the resource model (Patient, Observation, MedicationRequest, etc.) and REST API used for app-facing reads and writes. Tier 1 (standard). https://hl7.org/fhir/R4/
7. HL7 Version 2 Messaging Standard (product brief) — Health Level Seven International. The legacy pipe-delimited messaging standard (MSH/PID/OBR/OBX segments; ADT, ORU, ORM message types) still used for most hospital server-to-server clinical data exchange. Tier 1 (standard). https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
8. FHIR Releases and Versioning (R4B, R5, R6 status) — Health Level Seven International. R4 (2019) normative; R4B (Dec 2022) transitional; R5 (Mar 2023) trial use; R6 through its second normative ballot (6.0.0-ballot5, July 2026) and not final; R5 is the current official release. The basis for "target R4 in 2026." See also https://hl7.org/fhir/6.0.0-ballot5/codesystem-FHIR-version.html. Tier 1 (standard). https://hl7.org/fhir/directory.html
9. LOINC, SNOMED CT, RxNorm, and ICD-10-CM as the terminology layer bound by US Core — Regenstrief (LOINC), SNOMED International, NLM (RxNorm), CDC/CMS (ICD-10-CM). The code systems US Core binds FHIR fields to, so that "glucose" means the same thing across systems. Tier 1 (standards/terminology authorities). https://www.nlm.nih.gov/research/umls/sourcereleasedocs/current/LNC/index.html
10. Epic on FHIR developer program (fhir.epic.com), Showroom, and Vendor Services — Epic Systems. The vendor's FHIR R4 API sandbox, app marketplace (Showroom, unveiled August 2023 after App Orchard was wound down in late 2022; Fierce Healthcare, 2023-08-23), and production-access program; illustrates that standards-based access still passes a per-vendor sandbox, review, and go-live gate. Tier 4 (vendor developer documentation). https://fhir.epic.com/
11. Advancements in Health IT: ONC's 2026 Approved SVAP Standards — ASTP/ONC, June 30, 2026. USCDI v6 and US Core 9.0.0 approved for voluntary use from 2026-08-29. Tier 1. https://healthit.gov/blog/standards/advancements-in-health-it-oncs-2026-approved-svap-standards/
12. HTI-5 Proposed Rule — ASTP/ONC; Federal Register 2025-12-29, comments closed 2026-02-27, listed as proposed (page updated 2026-03-31). Removal of 34 and revision of 7 of 60 criteria and the "automated means" clarification as summarized by Reed Smith, 2026-01-12. Tier 1. https://healthit.gov/regulations/hti-rules/hti-5-proposed-rule/
13. CMS Interoperability Framework — Centers for Medicare & Medicaid Services (page modified 2026-08-06). CMS Aligned Networks: FHIR APIs on US Core with USCDI v3 or later, in effect from 2026-07-04. Tier 1. https://www.cms.gov/interoperability
14. Data Liquidity, Affordability, and Access: The History & Growth of TEFCA — ASTP/ONC, February 11, 2026 (updated 2026-06-05): 464 million documents exchanged by the end of 2025. Tier 1. https://healthit.gov/resources/data-liquidity-affordability-and-access-the-history-growth-of-tefca/. The 1-billion-records milestone (HHS, June 2026) as reported by MarketScale: https://www.marketscale.com/industries/healthcare/onc-marks-universal-ehr-adoption-and-one-billion-tefca-health-records-exchanged-in-inaugural-coordinators-quarterly
15. HL7 Version 2 to FHIR Implementation Guide 1.0.0 (STU 1) — HL7 International. Maps v2 messages, segments and data types to FHIR R4. Tier 1 (standard). https://hl7.org/fhir/uv/v2mappings/
16. Overview of $convert-data — Microsoft Learn (updated 2026-08-24). HL7 v2, C-CDA, JSON and STU3 to FHIR R4 via Liquid templates; default templates not for production. Tier 2 (vendor documentation). https://learn.microsoft.com/en-in/azure/healthcare-apis/fhir/convert-data-overview
17. A new era for Mirth Connect by NextGen Healthcare — NextGen Healthcare, March 19, 2025. Version 4.6 moves to a single commercial license; 4.5.2 is the last open-source version. Tier 2 (vendor). https://www.nextgen.com/blog/industry-news/a-new-era-for-mirth-connect-by-nextgen-healthcare
18. Open@Epic to return in 2026 as healthcare data sharing accelerates — Epic Systems, 2026. 1,000+ Showroom apps, ~3.7 billion patient-directed exchanges a month, 50+ new payer and prior-authorization APIs. Tier 2 (vendor). https://www.epic.com/epic/post/openepic-to-return-in-2026-as-healthcare-data-sharing-accelerates
19. Epic R4 production endpoint directory — open.epic.com; Bundle total 478, timestamp 2026-10-19. Tier 2 (vendor). https://open.epic.com/Endpoints/R4
20. Oracle ushers in new era of AI-driven electronic health records — Oracle, August 13, 2025. New EHR on OCI, U.S. ambulatory first, acute care planned for 2026. Tier 2 (vendor). https://www.oracle.com/news/announcement/oracle-ushers-in-new-era-of-ai-driven-electronic-health-records-2025-08-13/

Per the source hierarchy, standard and rule facts follow the issuing bodies (ONC/ASTP and HL7) over vendor summaries: the R4 / US Core 6.1.0 / USCDI v3 baseline and 2026-01-01 compliance date are cited to ONC and HL7 (refs 1–3), the (g)(10) API mandate to ONC (ref 4), and the SMART, Bulk Data, FHIR R4, and HL7 v2 mechanics to HL7 (refs 3, 5–8). The Epic program details (ref 10) are vendor documentation, used only to illustrate the per-vendor onboarding reality, not as a regulatory source. The October 2026 additions cite ONC and CMS for rule status (refs 11–13), HL7 for the v2-to-FHIR mapping (ref 15), and vendor pages only for vendor facts (refs 16–20). Fourteen of twenty sources are tier-1 standards or regulatory documents (70%), above the 40% threshold for a compliance-touching article.