EHR integration MVP in 2026: what V1 needs and what can wait
TL;DR
An EHR integration MVP in 2026 is the smallest step that spares clinicians double entry on one workflow: usually structured data capture plus an export, with live interfaces later. Patient-facing reads have become standard and cheap. Writing into the chart has not.
- One YC-backed clinic startup called integration with larger EHRs "notoriously labor-intensive" and in 2025 prioritized more accessible clinics.
- In 2024, 70% of US hospitals let patients reach records through FHIR apps. Among hospitals letting apps write to the EHR in 2022, only 36% used standards-based APIs alone.
- Certified EHR modules were due on USCDI v3 and SMART App Launch v2 at the start of 2026.
- Epic holds 43.7% of the US acute care EHR market; connecting to it follows a customer.
- Price integration as its own line, per EHR and per site.
Why EHR integration stalls a first release
Two Hacker News threads from 2025 frame the problem from both ends. The team behind Cenote, a back-office automation startup for clinics, had talked to hospital networks on Epic and still wrote: "However, integrating with larger EHRs is notoriously labor-intensive, so for now, we're prioritizing more accessible clinics." In May, under WorkDone's launch, a commenter asked whether physicians had to leave the EHR to use it: "In my experience, that ends up being a non-starter/huge impediment to usage."
Too much integration and you never launch. Too little and clinicians never open the app.
The market explains the labor. Per KLAS data reported by Fierce Healthcare in May 2026, Epic holds 43.7% of the US acute care EHR market and 56.9% of hospital beds; Oracle Health has 21.9% of the market, MEDITECH 14.7%. HL7's product brief says over 95% of US healthcare organisations use its Version 2 messaging standard, so a hospital interface often means v2 messages routed by the hospital's own team, on its calendar.
HTI-1 deadlines passed in 2026, and they favor a small V1
The HTI-1 rule made USCDI version 3 the baseline for certified health IT as of January 1, 2026. SMART App Launch version 2 replaced version 1 after December 31, 2025. In November 2025, ASTP/ONC said it would not start enforcement before March 1, giving developers until the end of February. The updated criteria include the APIs for patient and population services.
HTI-5, proposed in December 2025, would remove 34 of 60 certification criteria and build future API requirements on FHIR. At its last update in March 2026, ASTP's page still listed it as a proposal.
For a V1 the lesson is narrow: standardized reads keep getting easier; writes still depend on each vendor and site.
How we built this guide
Regulatory facts come from ASTP/ONC documents, vendor facts from Epic's and athenahealth's pages, market shares from KLAS via the trade press, engineering examples from our published case studies. Groups in our own data with fewer than three data points are left out.
One disclosure: Mercury Development builds custom healthcare software, so we profit when integrations get built. The most useful guide we found, Nirmitee's founder timeline, gives durations; we add federal data, vendor terms and pricing.
Six levels of EHR integration at a glance
| Level | What it does | Who says yes | Standard | Release |
|---|---|---|---|---|
| 0. Capture | Fields that map to EHR data later | You | USCDI data classes | V1 |
| 1. Export | PDF or CSV the clinic files | Clinic staff | None required | V1 |
| 2. Patient-mediated read | Patient links their record to your app | The patient | FHIR R4, SMART standalone launch | V1 if patient-facing |
| 3. Provider read | Clinicians or your backend pull chart data | Each site | FHIR with SMART EHR or standalone launch, or Backend Services | V1 with a sponsor |
| 4. Write-back | Notes, results or orders into the chart | Each site and the vendor | Mostly vendor APIs or HL7 v2 | V2 |
| 5. Two-way sync | Both systems stay current | Everyone | Mixed | V3, if ever |
What V1 needs: structured capture and an export
Start with the two levels that need nobody's permission. Strictly, both are pre-integration: someone still files or imports the export, but nobody retypes the data.
Capture first. Design your tables around USCDI data classes, such as Medications or Vital Signs, and store values with units and timestamps instead of free text. A later FHIR mapping then becomes translation work, not archaeology.
Then give the clinic a way out: a PDF summary staff can file into the chart, or a CSV their systems can take. It sounds primitive. One of our longest-running systems started there.
The claims workflow we built for Precision Practice Management takes CSV snapshot reports from the four third-party practice management platforms Precision bills on, because building the workflow into those legacy programs was not feasible. Processing each snapshot took minutes instead of hours, which made daily imports possible. Since 2006 the system has reached its fourth major release, and an interface manager adds new practices.
Read-only FHIR access is the first real connection
When V1 needs EHR data, read it. Per ASTP Data Brief 79, 70% of US hospitals enabled patient access through FHIR apps in 2024, and 62% let patients submit data such as blood glucose or weight through apps. Hospitals on the largest EHR developer's system reached 83% FHIR app access, others 56%. Your first site's vendor matters.
Epic lists over 750 no-cost APIs and interfaces and says USCDI v3 support is free for developers. Its getting-started deck describes automatic distribution of qualifying patient-facing apps to US health systems with no involvement required: the patient decides whether the app is fit for use.
The SMART App Launch specification names two launch modes. Standalone launch starts in your app: the cheapest real connection for patient-facing products. EHR launch starts inside the chart, and in our experience each site has to enable it. Server-to-server reads use a separate Backend Services profile, with your client pre-authorized by each server.
WorkDone scoped its pilots the same way: read-only API access on Kipu and athenahealth, findings sent by email and a dashboard, in-EHR widgets later.
Write-back and two-way sync belong in V2
Writing is where standards thin out. In 2022, four in five hospitals let apps write to the EHR, per ASTP Data Brief 68, and most relied on non-standard APIs, alone or alongside standards-based ones. Only 36% of hospitals allowing app writes used standards-based APIs alone.
Nirmitee's published table puts numbers on the slope: 3-4 months for a read-only patient summary from one EHR, 5-7 for one-way write-back, 8-12 for two-way sync, 12-18 for Epic plus Oracle Health. Treat those as one firm's experience. The shape is the lesson: each step toward writing adds months.
If clinicians must leave the chart, remember the non-starter comment: give V1 a deep link and an export, and plan the EHR launch for V2.
When the EHR connection should follow a monitoring pilot is covered in our guide to remote patient monitoring app development.
When Epic and athenahealth are not V1 decisions
Epic is an enterprise sale before it is an API. It shut down App Orchard in late 2022 and unveiled Showroom in August 2023. Its own deck sets the order: a Showroom listing requires at least one live Epic connection and costs $500 per app per year.
athenahealth runs a Marketplace partner program that onboards each partner to integrate with its products. The same rule applies.
Put Epic or athenahealth into V1 only when all three hold:
- A signed first customer runs that EHR and will sponsor the connection.
- The workflow happens inside the chart, so an export would not be used.
- Read access covers the first release.
Otherwise do what Cenote did and start where integration is light. Pick one EHR: the one your first paying site runs.
Teams that build marketplace and direct EHR connections are ranked in our list of EHR/EMR development companies.
Price the integration as its own line
Folded into a feature estimate, integration hides in the total until it overruns. Split it out:
- Mapping per EHR: which data elements, which direction, how often.
- Build per connection: authorization, the FHIR client or v2 listener, error handling.
- Activation per site: security review, business associate agreement, test environment access.
- Vendor terms: Epic's $500 Showroom listing comes after go-live; marketplace programs set their own.
- Upkeep: standards move, as USCDI v3 and SMART App Launch v2 did in 2026.
Price each line per EHR and per site, so a budget review can cut a line and keep the product.
Typical EHR integration cost by product type sits in our guide to healthcare app development cost.
Which integration level fits your product
- Patient-facing app or remote monitoring companion: capture and export, plus patient-mediated read.
- Clinician tool sold to small practices: export first, then read access on the EHR your first practices share.
- Tool sold to hospitals: provider read through the sponsoring system's EHR, with activation priced per site.
- Clinical communication: the record exports covered in our clinician chat guide.
- Billing and back-office: file-based imports from practice management systems, as in the Precision case.
What our own requirement records show
Counted by hand in October 2026 across all our healthcare requirement records, veterinary requests excluded. Record counts stay unpublished under our client agreements; shares are rounded to five points.
- Around 15% named an EHR, EMR or practice management system, either in scope or in the existing stack.
- None of those named HL7 v2, FHIR or an API. They described workflows instead: basic data capture, schedule slots, a link to an existing portal, a later phase.
- Around 80% of those requests also framed the first release as deliberately small: an MVP, a prototype, a wrapper or a feature list to trim.
That is the collision this guide is about: the vaguest line in the scope lands in the smallest release.
Why we ship the export before the interface
Our opinion: on a V1 we would rather ship a correct data model with an export than a fragile live interface.
The reason is reversibility. A data model built on USCDI classes can feed FHIR, v2 or a file later. An interface built first locks you into one vendor's model and someone else's timeline.
The limit: when the work happens inside the chart and a customer sponsors the connection, start with read access through an EHR launch.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The requirement reviews behind this article, where incoming healthcare requests are read for existing systems, data flows and integration points, come from the engineering practice he works in.
Send us your EHR wish list and we will cut it to a V1
Tell us which systems your first customers run, what data you need from them and where your output has to land. We will map each item to an integration level, mark what the first release needs and what can wait, and show which lines to price separately.