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

Why this matters

The integration approach is an architecture decision you make early and live with for years, because reversing it means rebuilding the connection layer of your product. Pick "direct" when you should have used an aggregator and you spend six months onboarding vendors one at a time; pick "aggregator" when one direct integration would have done and you pay a recurring fee forever for a layer you did not need. This article is written for the founder, product manager, or technical lead who has scoped the pieces — the EHR standards, the vendor programs — and now has to commit to one shape. Get it right and the integration matches your customer list and your roadmap; get it wrong and it fights both. The goal here is to turn a vague "how should we integrate?" into a defensible decision you can put in front of a customer with a date attached.

The shared floor: why the data shape is not the decision

Start with what does not drive the choice, because it clears away a common confusion. Since a 2024 federal rule, every certified electronic health record in the United States — the system of record where a clinician's notes, medications, lab results, and diagnoses live — must expose the same kind of programmatic door. The rule is the Office of the National Coordinator's certification criterion § 170.315(g)(10), which requires a certified EHR to publish a FHIR R4 API (FHIR, "Fast Healthcare Interoperability Resources," is the modern web standard from the standards body HL7) for both single-patient and bulk access [1]. The information blocking rules of the 21st Century Cures Act make that door enforceable: a certified actor may not unreasonably interfere with access to electronic health information [2]. And because all certified systems profile FHIR R4 against US Core 6.1.0 / USCDI v3, the 2026 certified baseline, the data shape is shared across vendors [3].

So the standard is constant no matter which path you pick. A Patient resource looks the same coming from Epic or athenahealth. That is exactly why the integration decision is not about FHIR — the protocol is the floor everyone stands on. The decision is about delivery: how you reach those FHIR doors, who maintains the connections, and where your app physically runs. Four answers, below.

Path 1 — Direct: you build and own each connection

A direct integration is a point-to-point connection your team builds to each EHR vendor's FHIR API. You register in Epic's developer program, Oracle Health's Code Console, athenahealth's Developer Portal, and so on, and you maintain each one yourself. This is the path covered vendor-by-vendor in Integrating with Epic, Oracle Health, and athenahealth.

Direct gives the most control and the deepest access. You target the exact FHIR resources and scopes your workflow needs, you own the vendor relationship, and there is no third party between you and the record. The cost is that every vendor is a separate project: a sandbox, an app review, a marketplace listing, and a per-customer go-live, repeated per vendor. As shown in the vendor article, the FHIR code is roughly two of nine weeks per vendor; the other seven are process, and the process is what compounds when you add vendors. Direct is the right call when you serve one or two EHR vendors and want maximum control — common for a product built around a single large health-system customer.

Path 2 — Aggregator: someone else maintains the connections

An aggregator is a company that has already built and maintained the per-vendor connections and exposes a single normalized API to you. Redox is the best known: you call one Redox API, and Redox manages the connections to each EHR behind the scenes, translating the messy reality — HL7 v2, CDA documents, X12 billing files, FHIR — into one consistent JSON interface; it reports over 20 million transactions per day across roughly 10,000 organizations and 100-plus EHR vendors [4]. Health Gorilla plays a related role and is also a Qualified Health Information Network (QHIN) under TEFCA, the federal Trusted Exchange Framework, so beyond point-to-point connections it can query the national network for a patient's records across organizations [5].

The aggregator trade is simple: you pay a recurring fee (per-transaction or subscription) and accept a layer of indirection, and in return new EHRs arrive as configuration instead of new projects. You do one onboarding instead of N. This is the right call when your roadmap says "support every EHR our customers use" and that list has three or more vendors — because the per-vendor overhead is what an aggregator amortizes. One caution that teams miss: an aggregator does not remove a Business Associate Agreement, it adds one, because there is now an extra company touching patient data in the chain.

Decision tree for an EHR integration path: vendor count, where the user works, and read-versus-write needs Figure 1. The decision tree. Four questions — how many vendors, who the user is, read-or-write, and fee tolerance — route you to direct, aggregator, embedded, or standalone. Every leaf still requires a signed BAA.

Path 3 — Embedded (the iframe): your app runs inside the EHR

The third path is different in kind, not just in degree. Instead of your app calling the EHR from the outside, your app runs inside the EHR's own screen, in a frame embedded in the clinician's workflow. The clinician opens a patient's chart, clicks your tool, and it appears in a panel — typically an iframe, a web page embedded inside another — without leaving the record. In Epic, that frame lives inside its Hyperspace / Hyperdrive desktop; other vendors have equivalents [6].

The mechanism is a standard, not a vendor trick. SMART on FHIR — the healthcare login layer that sits on OAuth 2.0 — defines two launch styles. In a standalone launch, the user opens your app from outside the EHR (a home-screen icon, a patient portal link) and your app asks the EHR's authorization server for context. In an EHR launch, the EHR itself "opens a new browser instance (or iframe) pointing to the app's registered launch URL and passing some context" — so your app boots already knowing which patient and encounter the clinician is looking at [7]. EHR launch is the embedded, in-workflow pattern; standalone is the outside-the-EHR pattern. Both are part of the same SMART App Launch framework (currently v2.2.0) and both end in an OAuth access token your app uses to read and write FHIR [7].

Embedded is the right call when the user is a clinician working inside the EHR all day and context-switching to another tab is friction you cannot afford — an AI scribe panel, a specialist-consult widget, a decision-support tool. The cost is that you build to each vendor's embedding rules (Epic's framing requirements, the security headers an embedded page must send), and your UI lives inside someone else's application, with its sizing and styling constraints. You still need the per-vendor onboarding from Path 1; embedding is how the app appears, layered on top of a direct integration.

SMART on FHIR EHR launch opening an iframe with patient context vs a standalone launch, both ending in OAuth Figure 3. SMART on FHIR EHR launch versus standalone launch. The EHR opens an iframe with patient context on one lane; the user opens a standalone app on the other; both arrive at an OAuth token and FHIR read/write.

Path 4 — Standalone: skip live integration (for now)

The fourth option is the one teams forget to consider: do not integrate live at all, or not yet. A standalone telemedicine product runs its own scheduling, its own notes, and its own patient records, and exchanges data with the outside world through lighter-weight means — a patient-mediated download (the patient pulls their own record via a portal and uploads it), a manual export, or a document exchange — rather than a live API connection. SMART's standalone launch flow is the technical cousin here: the patient opens your app and authorizes it against an EHR only when they choose to [7].

Standalone is the right call early, for a direct-to-consumer product, or when your customers run no shared EHR. A behavioral-health startup seeing self-pay patients may need no EHR integration for its first year; a wellness product may never need one. The benefit is speed — you ship without waiting on any vendor's review queue. The cost is that data does not flow automatically, so clinicians retype, and at some scale the manual gaps become the bottleneck that pushes you toward Paths 1–3. Choosing standalone on purpose — and writing down the trigger that will move you off it — is a legitimate, often correct, decision.

The decision in four questions

Put the paths together and the choice reduces to four questions, in order.

First, how many EHR vendors must you reach? Zero today → standalone. One or two → direct. Three or more → price an aggregator. Second, who is the user and where do they work? A clinician living inside the EHR all day → embedded (EHR launch). A patient at home, or a clinician using your standalone app → standalone or direct/aggregator with a standalone launch. Third, do you need to write back, or only read? Read-only history from anywhere favors a TEFCA QHIN network query; structured write-back into the chart favors a direct or embedded integration with the specific write scopes confirmed. Fourth, what recurring cost can you carry? An aggregator converts a large one-time build into an ongoing fee; direct converts an ongoing fee into a larger one-time build plus your own maintenance. Most real products combine paths — for example, a direct, embedded Epic integration for the hospital customer that is 60% of revenue, plus an aggregator for the long tail of smaller systems.

Comparison of direct, aggregator, embedded, and standalone EHR integration paths: control, time, cost, and BAA Figure 2. The four paths side by side. Control falls and speed rises as you move from direct to standalone; the recurring fee appears only with an aggregator; the BAA is required on every path that touches real patient data.

A worked example: the cost math

Numbers keep the decision honest. Take a telemedicine product that must read a patient's chart before a visit and write the note back after, against three EHR vendors, and price the two realistic paths.

Direct, three vendors. Each vendor is about nine engineering-weeks — two of code, seven of process (sandbox, mapping, app review, first go-live). The code is largely shared across vendors; the process is not, because each vendor gates you separately:

3 vendors × ~7 process-weeks   = ~21 process-weeks
+ ~3 shared code-weeks          = ~24 engineering-weeks  (≈ 6 months)
+ your team maintains 3 connections, ongoing

Aggregator, one connection. One onboarding — call it the same ~9 weeks for the first connection — and then vendors two and three arrive as configuration, not projects:

~9 weeks to first go-live
+ new EHRs = configuration (days, not weeks)
+ recurring per-transaction / subscription fee, ongoing

The aggregator saves roughly 15 process-weeks of build and the ongoing burden of maintaining three connections, in exchange for a fee that scales with use. The crossover is the rule of thumb from the vendor article, generalized: one or two vendors, integrate directly; three or more, price the aggregator — because the per-vendor overhead compounds while the code does not. Embedding adds a UI layer on whichever path you pick; standalone removes the vendor wait entirely at the cost of automatic data flow. Plug in your own vendor count and the aggregator's quoted fee; the shape holds.

The compliance rule that applies to every path

One rule survives every branch of the tree, and it is the quiet one. Every party that touches Protected Health Information (PHI) — any health data tied to an identifiable person — sits inside your HIPAA compliance boundary and needs a signed Business Associate Agreement (BAA) before a single real field flows. That contract is what makes it lawful for an outside company to handle patient data on your behalf. On the direct path, that means a BAA with each EHR vendor. On the aggregator path, a BAA with the aggregator and with the EHRs behind it — the aggregator adds a business associate, it does not remove one. On the embedded path, the same per-vendor BAAs apply, because your app is still reading and writing real PHI even though it renders inside the EHR's frame. Only the standalone, synthetic-data, or fully patient-mediated case can sometimes avoid an added BAA — and only while no PHI passes through a third party you control.

The line to memorize: a sandbox uses synthetic data and needs no BAA; production uses real data and always does. Encryption does not change this. A connection can be perfectly encrypted and still be a HIPAA violation without the signed BAA, because "encrypted" and "compliant" are two different claims and you need both. The contract itself is covered in Business Associate Agreements; the rule behind it in HIPAA in plain English for product teams.

A common mistake to avoid

The most expensive mistake is choosing the integration path from a slide instead of from the customer list. Teams pick "aggregator" because it sounds modern and pay a recurring fee for years to reach the one EHR a direct integration would have covered in nine weeks; or they pick "direct" because it sounds cheaper and then drown onboarding the eighth vendor by hand. Let the four questions — vendor count, user, read-or-write, fee tolerance — pick the path, and re-ask them when the customer list changes, because the right answer at three customers can be the wrong answer at thirty.

A close second mistake is treating "embedded" and "integrated" as the same thing. Embedding (the iframe / EHR launch) is where your app appears; integration is how data moves. You can be embedded in Epic and still have shallow read-only access, or standalone and write deeply through a direct API. Decide the data path and the UI path separately, confirm the exact write scopes your workflow needs against the vendor spec, and confirm the BAA path early — discovering at go-live that a contract does not cover your use is the launch-day surprise no team wants.

Where Fora Soft fits in

Fora Soft has built real-time video and clinical software since 2005, and we treat the integration path as an architecture decision made against the customer list, not a default. The requirement comes before the feature: a signed BAA on every EHR vendor and any aggregator before real patient data moves, the FHIR version pinned to the 2026 certified baseline (R4 / US Core 6.1.0) rather than "latest," and the path chosen on purpose — direct for one or two vendors, an aggregator or a TEFCA QHIN when the list is long, an embedded SMART-on-FHIR launch when the clinician lives inside the EHR, and an honest standalone start when no shared EHR exists yet. Then the capability follows: a compliant video consult that reads the chart before the visit and writes the note back after, on the path that matches who your customers are and how many there will be.

What to read next

Download the EHR Integration Decision Worksheet (PDF)

Call to action

References

  1. ONC § 170.315(g)(10) — Standardized API for Patient and Population Services (ONC Health IT Certification Program API Resource Guide) — 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 "every certified EHR offers the same FHIR door." Tier 1. https://onc-healthit.github.io/api-resource-guide/g10-criterion/
  2. Information Blocking and Application Programming Interfaces (21st Century Cures Act, Cures Act Final Rule) — ASTP/ONC (HealthIT.gov). Prohibits certified actors from unreasonably interfering with access, exchange, or use of electronic health information; makes the mandated FHIR API enforceable. Tier 1. https://www.healthit.gov/condition-ccg/application-programming-interfaces
  3. HL7 FHIR US Core Implementation Guide STU 6.1.0 (against USCDI v3) and the HTI-1 2026 baseline — HL7 / ASTP/ONC. US Core 6.1.0 / USCDI v3 with SMART App Launch is the 2026 certified baseline (compliance date 2026-01-01); the shared data shape across all certified EHRs. Tier 1. https://hl7.org/fhir/us/core/
  4. Redox healthcare data integration platform — Redox. Hub-and-spoke aggregator translating HL7 v2 / CDA / X12 / DICOM / FHIR into one JSON API; reports 20M+ transactions/day, ~10,000 organizations, 100+ EHR vendors. Vendor documentation; metrics are vendor-reported — re-verify before publish. Tier 4. https://redoxengine.com/
  5. Health Gorilla Qualified Health Information Network (QHIN) under TEFCA — Health Gorilla / ASTP (TEFCA program). Designated a QHIN in late 2023, live early 2024; enables national-network record query under the Trusted Exchange Framework and Common Agreement, distinct from point-to-point aggregation. QHIN designation is an ASTP/TEFCA status; reach metrics are vendor-reported. Tier 4 (vendor) / Tier 1 (TEFCA program). https://www.healthgorilla.com/home/company/qhin
  6. Epic on FHIR developer program (fhir.epic.com) and Hyperdrive/Hyperspace embedding (open.epic) — Epic Systems. Provider-facing apps embed in Epic's Hyperspace/Hyperdrive desktop via the SMART on FHIR EHR-launch flow, rendering in an in-workflow frame; free FHIR R4 sandbox (May 2026 build). Vendor documentation, used to describe the embedded pattern — re-verify before publish. Tier 4. https://fhir.epic.com/
  7. SMART App Launch Implementation Guide v2.2.0 (STU 2.2) — App Launch: Launch and Authorization — HL7. Defines the EHR-launch flow ("the EHR initiates a launch sequence by opening a new browser instance or iframe pointing to the app's registered launch URL and passing some context") versus the standalone-launch flow, both on OAuth 2.0; the standard behind the embedded (iframe) and standalone paths. Tier 1 (standards). https://hl7.org/fhir/smart-app-launch/app-launch.html

Per the source hierarchy, the certified-API mandate, information-blocking rule, 2026 version baseline, and the SMART launch flows are cited to ASTP/ONC and HL7 (refs 1–3, 7 — tier 1 / standards); the aggregator and embedding mechanics to the providers and Epic's own developer documentation (refs 4–6, tier 4), used to describe delivery options and cost, never to assert regulation. Where vendor marketing equates "embedded" with "integrated," the article follows the SMART spec's precise EHR-launch-versus-standalone distinction and separates the UI path from the data path. Four of seven sources are tier-1 primary regulatory/standards documents (57%), and 100% of the regulatory and standards claims are sourced to tier-1 primaries; vendor and aggregator rows are explicitly labelled tier 4 and used only for non-regulatory delivery and cost context.