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

Why this matters

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

Side-by-side comparison of HL7 v2 and FHIR across format, transport, model, typical use, and learning curve 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 is in balloting — its first normative ballot was scheduled for January 2026 — and is not expected to be final before 2027. 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 — 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.

Timeline of FHIR R4, R4B, R5, and R6 with the US Core and USCDI versions, marking the 2026 certified baseline 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. 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 current published version is SMART App Launch 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."

SMART on FHIR EHR-launch sequence: EHR launch, OAuth2 authorization with PKCE, access token and patient context, then FHIR reads and writes 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.

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 retired and replaced in early 2024 by Showroom, 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. Epic publishes one of the largest FHIR footprints of any vendor: on the order of 450 FHIR API endpoints across roughly 55 R4 resources. 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. 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.

Decision tree comparing four EHR-access paths: direct FHIR, aggregator, embedded SMART app, and HL7 v2 feed, by speed, control, and cost 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.

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) rather than "latest," 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.

What to read next

Download the FHIR & HL7 v2 EHR Integration Cheat Sheet (PDF)

Call to action

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/index.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 in ballot, not expected final before 2027. The basis for "target R4 in 2026." 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://loinc.org/
  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, successor to App Orchard, launched early 2024), 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/

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. Eight of ten sources are tier-1 primary standards/regulatory documents (80%), well above the 40% threshold for a compliance-touching article.