To integrate with an EHR like Epic or Cerner in 2026, you connect through standardized FHIR R4 APIs using SMART on FHIR (OAuth 2.0) authorization, build first against a free vendor sandbox, then complete each health system's app review and go-live. Most startups move faster with an aggregator (Redox, Health Gorilla, Particle Health) that normalizes many EHRs behind one API. Expect 2-4 weeks for a prototype and 2-4 months per production site.
EHR integration is where most healthtech MVPs either get traction or get stuck. The technology is more standardized than ever, but the process, the per-site authorizations, security reviews, and clinical sign-off, is what actually controls your timeline. This guide walks through the standards, the vendor paths, the sandboxes, the real pitfalls, and what to budget, so you can scope integration before it scopes you. For the bigger picture on shipping a clinical product, start with our pillar guide to healthtech MVP development.
EHR vs EMR: a quick definition
People use EHR and EMR interchangeably, and for integration purposes the distinction rarely matters. An EMR (electronic medical record) is the digital chart within one practice or organization. An EHR (electronic health record) is the broader, shareable patient record designed to move between organizations. The major systems you will integrate with, Epic, Oracle Health (Cerner), MEDITECH, athenahealth, eClinicalWorks, are usually called EHRs.
What matters to you is which system your pilot customer runs, which version, and whether they have enabled the FHIR APIs you need. Two clinics on "the same EHR" can have very different configurations, app catalogs, and approval processes.
The standards: HL7 v2, FHIR, and US Core
There are two interoperability worlds you will encounter. Legacy HL7 v2 is a pipe-delimited messaging format (ADT, ORM, ORU) that still moves enormous volumes of data through interface engines for admissions, orders, and results. It is reliable but brittle, point-to-point, and unfriendly to web developers.
FHIR (Fast Healthcare Interoperability Resources) is the modern standard, and it is what you should target. FHIR exposes clinical data as RESTful JSON resources, Patient, Observation, Condition, MedicationRequest, DocumentReference, and supports the read/write patterns web teams already know. In the US, certified EHRs are required to expose standardized FHIR R4 APIs constrained by the US Core implementation guide, which defines the minimum resource profiles you can rely on.
For a deeper treatment of the standard itself, profiles, bulk export, and interoperability strategy, see our companion piece on healthcare data interoperability with FHIR. This article stays focused on the integration engineering.
| Approach | Best for | Tradeoff |
|---|---|---|
| FHIR R4 (SMART on FHIR) | Modern apps reading/writing structured clinical data | Coverage varies by EHR version and enabled scopes |
| HL7 v2 via interface engine | High-volume ADT/orders/results, legacy sites | Brittle, custom mappings, slower to stand up |
| Aggregator API (Redox, Health Gorilla, Particle) | Startups needing many EHRs fast, one contract | Platform fees; abstraction can hide edge cases |
| Flat file / CSV exports | Early pilots, batch analytics, no live writes | Not real-time, manual, no patient-facing workflows |
SMART on FHIR: how authorization actually works
SMART on FHIR is the OAuth 2.0-based framework that defines how your app gets permission to access an EHR's FHIR API. There are two patterns you need to know.
SMART App Launch (user-facing). A clinician or patient launches your app from within or alongside the EHR, authenticates, and consents to specific scopes (for example, patient/Observation.read). This is the pattern for apps that live inside the clinical workflow, such as a chart-side assistant or an AI medical scribe that writes notes back to the encounter.
SMART Backend Services (system-to-system). Your backend authenticates with a signed JWT and client credentials, no human in the loop, to pull data in bulk or sync on a schedule. This is what powers analytics pipelines and population-level features.
Scopes are the heart of it. You request the minimum resources and actions you need, and the health system grants or denies them. Asking for broad write access you do not need will slow your security review. Design for least privilege from day one, the same discipline that underpins HIPAA-compliant app development.
Vendor paths: Epic, Oracle Health (Cerner), and the rest
Epic
Epic publishes its developer program at fhir.epic.com and its app marketplace, historically called App Orchard and now part of "Connection Hub" and "Showroom." You register your app, choose client types (public vs confidential, user vs backend), build against Epic's open FHIR R4 sandbox, and then pursue go-live at a specific Epic customer. Epic also offers patient-facing access via MyChart-connected apps. The technical work is well documented; the gating step is the individual health system agreeing to enable your app.
Oracle Health (Cerner)
Oracle Health (formerly Cerner) runs its developer experience through code.cerner.com / the Oracle Health developer console, with a public FHIR R4 sandbox and SMART support. The flow mirrors Epic: register, build against the sandbox, request scopes, then coordinate a production tenant with the customer. Resource availability and write support vary by the customer's licensed modules.
Everyone else
MEDITECH, athenahealth, eClinicalWorks, NextGen, and others each publish FHIR endpoints with their own developer portals and quirks. If your roadmap requires more than one or two EHRs, the per-vendor overhead compounds quickly, which is exactly the problem aggregators solve.
Build direct or use an aggregator?
This is the most consequential early decision. Building direct gives you control, no middle layer, and no per-transaction platform fees, but you absorb the full cost of each EHR's quirks, sandboxes, and approvals. Aggregators (Redox, Health Gorilla, Particle Health, 1up Health, Metriport) normalize many EHRs behind a single API and often handle parts of the connection plumbing for you.
| Factor | Direct integration | Aggregator |
|---|---|---|
| Time to first connection | Slower per EHR | Faster, one API surface |
| Cost model | Engineering-heavy upfront | Platform + usage fees ongoing |
| Control & edge cases | Full visibility | Abstraction can hide details |
| Scaling to many EHRs | Linear effort | Designed for breadth |
| Negotiating leverage | You own every contract | Vendor handles some terms |
A common pattern that works: start with an aggregator to win your first few customers and validate the product, then add direct integrations later for your highest-volume EHR where the fees no longer make sense. At SpeedMVPs we frequently ship the first version on an aggregator so founders can demo a live integration in weeks, not quarters, while keeping the option to go direct open. If you are still shaping the build, our guide to scoping an AI MVP before you build helps you decide what to defer.
Working with sandboxes
Every major EHR offers a free FHIR sandbox with synthetic patient data, and you should live in it before you ever touch real PHI. A realistic sandbox sequence looks like this:
- Register a developer account and create an app (client ID, redirect URIs, JWKS for backend auth).
- Run the SMART App Launch or Backend Services flow against the sandbox and confirm you can get a token.
- Read core US Core resources, Patient, Observation, Condition, AllergyIntolerance, and verify your parsing.
- Test the write paths you actually need (for example, DocumentReference or Observation) and handle partial failures.
- Validate error handling, token refresh, rate limits, and pagination, the things that break in production.
Sandboxes prove your code works. They do not prove a given customer's production tenant has the same scopes enabled, which is why your timeline always includes a per-site validation pass.
The pitfalls that actually delay launches
The integration code is rarely what sinks a timeline. These are the recurring traps:
Underestimating per-site approval. Each health system runs its own security review, BAA negotiation, and clinical sign-off. Budget months, not days, for the first one. Always have a signed Business Associate Agreement before any PHI moves, this is a hard requirement, not a formality.
Data quality and mapping gaps. "US Core compliant" does not mean complete. Fields you expect, like structured problem lists or discrete vitals, may be missing, free-text, or coded inconsistently across sites. Plan for normalization and graceful degradation.
Write access is harder than read. Reading data is broadly supported; writing back into the chart is gated more tightly and varies by module licensing and site policy. If your product depends on writes, validate that path early with your specific pilot customer.
Treating PHI casually in dev. Logging, analytics, and error trackers can quietly leak PHI. Audit logging, encryption in transit and at rest, and minimum-necessary access are non-negotiable. Our guide to building AI with patient data covers the de-identification and safety patterns in depth.
Scope creep across EHRs. Supporting "all the EHRs" before product-market fit is a classic mistake. Pick the one your design partner uses and go deep first. See common healthtech MVP mistakes for the patterns that waste runway.
Timeline and cost, realistically
Here is a grounded view for a startup integrating with one or two EHRs, primarily read-heavy with targeted writes:
| Phase | Typical duration | What gates it |
|---|---|---|
| Sandbox prototype (FHIR R4) | 2-4 weeks | Your engineering capacity |
| Aggregator first connection | 2-6 weeks | Contract + customer authorization |
| Direct production go-live (1 site) | 2-4 months | App review, security assessment, clinical sign-off |
| Each additional site | Weeks to months | Per-site security + credentialing |
On cost, budget roughly $20,000-$80,000 in engineering for a focused first integration, more for bidirectional writes, many resource types, or complex mappings. Aggregators add platform and usage fees that commonly scale from a few hundred to several thousand dollars per month. Direct vendor programs may carry registration or annual fees, so confirm current terms with each vendor. For how integration fits the broader budget, see our breakdowns of healthcare app development cost and overall AI MVP cost.
Where integration fits in your product
EHR integration is a means, not the product. The most common reasons startups integrate are: pulling a patient's history into a telemedicine visit, writing AI-generated clinical notes back into the chart, syncing monitoring data, and surfacing labs or medications to patients. Decide which one or two of these your MVP must do, and ignore the rest until you have paying customers asking for them.
A practical sequencing tip: ship the core product value with synthetic or manually uploaded data first, validate that clinicians want it, then add live EHR integration once a design partner commits. That keeps integration from blocking your learning, the same staged thinking behind how to build an AI MVP in 2026.
A note on compliance and advice
This article is general engineering and product information, not legal, regulatory, or clinical advice. HIPAA obligations, BAA terms, state privacy laws, and whether your product qualifies as Software as a Medical Device (SaMD) requiring FDA pathways depend on your specific use case. Engage qualified healthcare counsel and, where relevant, regulatory experts before you handle PHI or make clinical claims. SpeedMVPs builds compliant, HIPAA-ready MVPs and can help you scope these questions, but we are not a substitute for your own legal and regulatory review.
Book a call and ship your integration
EHR integration rewards focus: pick one EHR, build against the sandbox, use an aggregator to move fast, and treat per-site approval as the real timeline. SpeedMVPs ships compliant AI MVPs in 2-3 weeks with fixed pricing and direct developer access, including healthtech products with real FHIR and SMART on FHIR integration. If you want a clear scope, timeline, and budget for your integration, book a free discovery call, explore AI MVP Development, or estimate your build with the AI MVP Cost Calculator.
