EHR Integration Services: What They Cost and How to Choose a Partner

EHR integration is the work of connecting an application to a clinical record system so patient data moves between them. That definition is easy. What makes projects fail is that the hard part is almost never the code: it is the institution on the other end, its review queue, and the gap between an API that answers in a sandbox and a credential that works in production.

The market has moved a long way in five years, which is why so many teams are surprised when the project still takes six months. Seven in ten US hospitals now let patients reach their records through FHIR-configured apps, according to the federal government's own survey data. Federal exchange volume went from 10 million records to over a billion in under a year. And yet the median health-tech company still budgets weeks for an integration that will take two quarters.

This piece covers what the standards actually do, the three separate routes into Epic and which one applies to you, why every published cost range is noise, and the questions that separate an EHR integration company that has been through institutional review from one that has only seen a sandbox.

The short version

• Scope is set by two answers: which data classes you need, and in which direction. Everything else, including cost, follows from those.
• HL7 v2 and FHIR R4 coexist. FHIR carries structured queries and patient access; HL7 v2 carries the real-time event feeds off the clinical floor. Most production integrations run both.
• Epic has three doors, and they have nothing in common operationally: patient-authorized SMART on FHIR (self-serve), provider-facing launch (institution approves), and backend system-to-system (Epic plus the institution).
• Published EHR integration cost ranges are worthless because the real multiplier is institutions × interfaces × direction, not lines of code.
• The institutional queue sets the timeline. Security review, a BAA, and a go-live slot on someone else's roadmap do not compress.
• Choosing an EHR integration company comes down to one question: have they carried a client through a real institutional security review, and can they describe it in specifics.

What EHR integration connects, and the two questions that scope it

EHR integration connects an external application to a clinical record system so that a defined set of patient data flows in a defined direction. Medication lists, lab results, problem lists, allergies, appointments, encounters, notes: each of those is a data class, and each one is scoped, approved, built and tested separately.

Two questions settle the entire project shape, and answering them badly is the most common way to lose a quarter.

Which data classes do you actually need at launch? Not the ones you might want in year two. Product teams routinely list eight and ship with two, having paid for the approval cycle on all eight.

In which direction? Reading is one problem. Writing back into the chart is a different problem with a different approval path, different failure modes and a different risk profile, because a bad write lands in a clinician's workflow.

The answers differ sharply by product type. A telemedicine application usually needs scheduling and encounter data in both directions. Patient engagement software often needs a broad read and almost no write. An analytics product feeding healthcare data analytics pipelines needs bulk export rather than per-patient queries, which is a different FHIR capability again.

The adoption data explains why the read side has gotten so much easier while the write side has not. The federal ASTP Data Brief No. 79, published in August 2025 from the 2024 American Hospital Association IT Supplement, found that 81% of non-federal acute care hospitals let patients access records through apps meeting API specifications, and 70% did so through apps configured to FHIR specifications. Federal policy pushed hard on exactly that capability and it worked.

The same survey shows where the pushing stopped. Only 56% of hospitals let patients import records from other organizations, and 62% accept patient-generated data. Capabilities that regulation incentivized are near-universal. Capabilities it did not are roughly half-adopted. If your product depends on one of the latter, your integration is a custom conversation with every institution rather than a standard one.

That spread matters commercially. A product selling into large academic health systems meets 84% FHIR readiness. The same product selling to independent community hospitals meets 56%, and the difference is not technical sophistication on your side. It is whose IT department has an interface team.

EHR integration standards: HL7 v2, FHIR R4, and where each one wins

Two standards carry almost all clinical data exchange in the United States, and they are not competitors. They solve different problems and coexist inside the same hospital.

HL7 v2 is a pipe-delimited message format that dates to the late 1980s. Messages are organized into segments: MSH for the header, PID for patient identification, OBR for an observation request. An ADT feed pushes A01 (admission), A03 (discharge) and A08 (update) events to every downstream system that subscribed. An ORU message carries lab values back. To a developer raised on JSON it looks like a fossil, and it is, but it is a fossil that moves enormous volume reliably and that nobody is funding a replacement for.

FHIR R4, published by HL7 and documented at hl7.org/fhir/R4, is a REST specification. Resources are JSON or XML documents (Patient, Observation, MedicationRequest, Encounter) at addressable endpoints, secured with OAuth 2.0 through SMART on FHIR. The US Core implementation guide constrains those resources so the same query returns comparable structures across EHR vendors, which is the part that makes cross-vendor code possible at all.

Dimension	HL7 v2	FHIR R4
Paradigm	Event-driven messaging	REST API, addressable resources
Format	Pipe-delimited segments (MSH, PID, OBR)	JSON or XML resources
Introduced	Late 1980s	R4 stabilized in the late 2010s
Best for	High-volume real-time feeds off the clinical floor	Structured on-demand queries, patient access
Auth	Handled at the interface or network layer	OAuth 2.0 via SMART on FHIR
Regulatory role	Dominant in back-end clinical messaging	Required for certified patient-access APIs

The practical rule: use FHIR when you need to ask a question ("give me every MedicationRequest for this patient") and HL7 v2 when you need to be told something happened ("this patient was just admitted"). Sophisticated integrations run both, with an ADT feed triggering processing and FHIR calls pulling the structured detail.

One caution before you plan around FHIR adoption curves. The growth has flattened.

Inpatient FHIR app access jumped from 56% to 68% between 2021 and 2022, then moved a single point across the next two years. The institutions that were going to enable it under regulatory pressure have done so. The remaining third are the harder cases, and waiting for the curve to carry you into them is not a plan.

Epic EHR integration: three doors, and which one you need

Epic is the largest EHR vendor in US acute care by a wide margin, and if your users are American providers you will meet it. KLAS put Epic at 43.7% of acute care hospitals and 56.9% of beds in its 2026 US Acute Care EHR Market Share report, with Oracle Health at 21.9% and Meditech at 14.7%. Epic added 77 hospitals in 2025 while Oracle Health lost 56.

The scale of what moves through Epic is worth knowing before you scope. On its open.epic developer site, Epic publishes over 750 no-cost APIs and interfaces, reports almost 800 patient-facing apps live and exchanging data, and puts annual volume at 8.91 billion patient records exchanged, of which 54% go to non-Epic organizations. Interface transactions run at 660 billion a year and web service calls at 297 billion.

Read that "no-cost" line carefully, because it kills a common budgeting assumption. Epic does not charge you per API call for standard access. The cost of Epic EHR integration is engineering time and institutional coordination, not license fees.

There are three routes in, and teams lose months by assuming their situation is the one they read about.

Patient-authorized apps: standalone SMART on FHIR

Your app asks a patient to log in with their MyChart credentials and authorize access to their own record. You register as a developer at fhir.epic.com, get a client ID, and that ID propagates to Epic organizations without each one approving you individually. Information-blocking rules under the Cures Act mean institutions cannot block a patient from choosing an app.

This is the self-serve door, and it is the reason "we integrated with Epic in three weeks" stories exist. If your product is patient-facing and read-only, this is your path and the rest of this section does not apply to you.

Provider-facing apps: EHR launch inside the clinician workflow

Your app launches from inside Epic, in a clinician's session, with the patient context passed through. Now the institution is the gatekeeper. Someone at the health system has to activate your client ID in their environment, configure the launch point, and sign off on go-live.

That is an organizational process running on an organizational calendar. Your code being finished changes nothing about it.

Backend services: system-to-system EHR integration

No human in the loop. Your system authenticates as itself and exchanges data continuously. This route needs Epic's vendor program review and configuration work by the institution's own Epic analysts, who have a backlog. Write operations for most clinical data types land here, and they often require configuration packages installed on the institution's instance, which means capacity on a team you do not manage and cannot escalate to.

Oracle Health, athenahealth, and EMR integration past the big two

Oracle Health, formerly Cerner, runs a developer program with a similar sandbox-to-production shape and similar dynamics. Its FHIR support has improved materially and its documentation is sufficient to get moving. The commercial trend is against it (KLAS recorded a net loss of 56 hospitals and 14,676 beds in 2025), which matters if you are deciding where to invest integration effort for a product with a three-year horizon.

Below the top two, EMR integration fragments fast. Meditech holds 14.7% of acute care hospitals. athenahealth, eClinicalWorks, NextGen and a long tail of specialty and regional systems each run their own program at wildly different maturity: some full FHIR R4, some proprietary REST, some HL7 v2 feeds and nothing else.

There is one architectural answer to that fragmentation, and it is worth adopting before you need it. Normalize every vendor into your own internal representation behind an adapter layer. The adapter absorbs the vendor's quirks, your domain code never learns what an OBX segment is, and adding the third integration costs a fraction of the second. Teams that skip this and wire vendor models directly into application logic end up rewriting when the second customer arrives on a different EHR.

Federal exchange infrastructure is also changing the baseline in a way worth planning around. HHS reported in June 2026 that records exchanged through TEFCA grew from 10 million to more than 1 billion in under a year, running across the 11 designated QHINs. Epic alone reports 625 hospitals connected through its QHIN, with over 2,000 Epic hospitals and 50,000 clinics live or preparing. For treatment-purpose record retrieval, a QHIN connection is increasingly a real alternative to negotiating point-to-point access with every institution.

Healthcare API integration architecture that survives production

Healthcare API integration fails in production in a small number of predictable ways, and the architecture that prevents them is well understood. None of it is exotic. All of it gets skipped under deadline.

Queues and retries. EHR endpoints go away. Institutional maintenance windows, network problems between your infrastructure and the hospital's, expired credentials, transient API errors: every one of these will happen. Any write to an EHR needs a durable queue, exponential backoff, and an alert when retries are exhausted. A write that fails silently is the worst outcome in clinical software, because the clinician believes the data arrived.

Idempotency. A message delivered twice must not create a duplicate order or a duplicate medication entry. Key every write to a stable external identifier the receiving system uses for deduplication. This is not an optimization to add later, because retrofitting idempotency onto a live clinical interface means reconciling whatever the duplicates already created.

Interface engine or point-to-point. An interface engine (Mirth Connect, now NextGen Connect, plus Rhapsody, Cloverleaf and InterSystems at the enterprise tier) earns its operational cost when you have multiple targets or high-volume HL7 feeds. For a single FHIR integration at modest volume it is overhead. Managed platforms such as Azure Health Data Services and AWS HealthLake solve a different problem, FHIR storage and hosting rather than message routing, and buying one expecting the other is a common and expensive mistake.

Audit logging. Every read and every write touching protected health information needs a trail: who asked, which patient, what came back or went in, and when. HIPAA requires it and incident response depends on it. The log has to be tamper-evident and retained for whatever your compliance posture demands. Our HIPAA-compliant software development guide covers the surrounding control set.

Reconciliation. Bidirectional syncs drift. Two systems both accepting edits will disagree eventually, and the answer is a scheduled reconciliation pass that detects divergence and a documented rule for which side wins, decided by clinicians rather than by whoever writes the merge logic.

What EHR integration costs, and why published ranges are worthless

Search for EHR integration cost and you will find confident ranges: $15,000 to $150,000, $10,000 to over $1 million, $20,000 to $250,000 for Epic. Every one of them comes from a vendor describing its own book of business. None comes from a survey. They span two orders of magnitude and agree on nothing, which tells you the range is not the useful output.

Four things actually determine the number, and none of them is a line of code.

The four multipliers

Driver	Why it moves the bill
Number of institutions	Each one is a separate security review, BAA and go-live. This is the largest multiplier and the one teams underestimate.
Interfaces per institution	Medications, labs, scheduling and documents are separate builds, separate tests, separate approvals.
Direction	Writes cost several times what reads cost: approval path, error handling, reconciliation, clinical risk review.
Institutional queue length	Calendar time you pay for in project management and idle engineering, not in code.

Notice what is absent: the size of your engineering team, your language choice, your cloud. Those affect the build, and the build is not where the money goes.

The anchors that are actually verifiable

API access is usually free. Epic publishes over 750 no-cost APIs and interfaces on open.epic. Budget for engineering and coordination, not for access.

Platform pricing is published, when a platform is the answer. Medplum lists its cloud tiers publicly at $2,000 and $6,000 per month with a free tier for prototyping. That is a real, checkable number to compare a build against. Most integration vendors will not give you one before a call, which is itself a data point.

The upside is measurable at industry scale. The 2025 CAQH Index, published in February 2026, found US healthcare avoided $258 billion in administrative cost in 2024 through electronic transactions, with $21 billion still on the table in transactions that remain manual or partly manual. The interoperability solutions market itself sits at $3.4 billion in 2023 heading to $8.57 billion by 2030 on Grand View Research's numbers, a 14.15% CAGR.

Clinician time is the operational payback. Ambulatory physicians spend a mean of 5.8 hours in the EHR for every 8 hours of scheduled patient time, per a 2024 JAMIA study, and a 2024 JAMA Network Open analysis put median EHR time at 36.2 minutes per visit with 6.2 of those minutes falling after hours. Integration that removes duplicate entry is competing against that baseline, and the business case should be written in those terms rather than in feature counts.

If you need a defensible internal number, price the first institution and the first interface honestly, then model the rest as multiples. That estimate will be wrong in a way you can correct. A range copied off a vendor blog will be wrong in a way you cannot.

Build it, buy a platform, or hire an EHR integration company

Three routes into EHR integration services, and the right one is a function of how many times you will pay the per-target cost.

Build directly when you have one EHR target, one direction, and a handful of data classes. A platform in that situation adds a dependency, a bill and a vendor relationship without removing much work. Your engineers can read the FHIR spec.

Use a platform or interface engine when you have three or more EHR vendors to reach, or when you sell the same product to many provider organizations. The normalization layer is the piece that would otherwise multiply, and paying someone to maintain it against vendor drift is usually cheaper than doing it yourself. Redox, Health Gorilla and Particle Health sit in this category, as do the classic interface engines.

Hire an EHR integration company when the constraint is institutional rather than technical: you need someone who has been through security review at a health system, knows what a BAA negotiation looks like, and can write the interface request in the language the institution's team expects. You are buying that experience. Most competent engineering teams can write the client code; far fewer have sat through the review that decides whether the code ever gets a credential.

These combine more often than they compete. A common shape is a platform for breadth across small targets plus custom work for the two or three large accounts that justify a direct interface.

How to evaluate an EHR integration company

Most of the differentiation claimed by firms selling EHR integration services is not real. Everyone lists HL7, FHIR, Epic, Cerner and HIPAA. Five questions separate the teams that have done this from the teams that have read about it, roughly in the order worth asking them.

Ask them to describe the last institutional security review they went through. Not a customer name, a description: what the questionnaire covered, what came back, how long from first contact to production credential. Teams who have only shipped sandbox integrations cannot answer this in specifics and will pivot to technology talk.

Ask which door they used at Epic. If they say "we integrated with Epic" without distinguishing patient-authorized from provider-facing from backend, they have done one of the three and are implying all of them.

Ask what happens when a write fails. The answer should mention a queue, a retry policy, an alerting threshold and a reconciliation process. If it is "we log it," they have not run a bidirectional sync in production.

Ask what they own after go-live. Interfaces break when the institution upgrades. Someone has to watch, and if that is not in the contract it is you.

Ask for the failure story. Every team that has done this work has an integration that went badly. The ones who will tell you about it, and what they changed, are the ones who learned something. For the wider vendor-selection frame, our guide to choosing a software development company covers due diligence beyond the integration specifics.

An EHR integration timeline the institution can actually meet

Technical work and institutional work run on different clocks, and planning as though they are one is why these projects slip.

The technical half is predictable. Sandbox access, authentication, data mapping, error handling and testing land in weeks for a read-only FHIR integration, longer for bidirectional writes with reconciliation. A competent team estimates this accurately.

The institutional half is not yours to estimate. Security review, BAA execution, the interface request entering a queue, validation against de-identified production data, and a go-live checklist tied to the institution's change-freeze calendar. At large academic medical centers this runs for months and is not affected by how ready your code is.

Three moves compress the total, and they all involve starting the slow thing first.

Start the institutional track on day one. Send the security questionnaire and open the BAA conversation while engineers are still working against the sandbox. The two tracks are independent until the credential is issued, so run them in parallel.

Scope to the minimum first interface. One data class, one direction, one institution. Get through the full path once, learn where the real friction sits, then widen. Teams who batch eight interfaces into the first request wait for the slowest one.

Name the institution-side owner before you sign anything. Every integration that lands on time has someone inside the health system whose job it is to move it. Integrations without that person do not stall for technical reasons; they stall because nobody there is accountable for the queue.

Compliance is an integration requirement, not a checkbox

Two regulatory forces shape every US EHR integration, and they push in opposite directions.

Information blocking rules make institutions share. HHS OIG can impose civil monetary penalties up to $1 million per violation on health IT developers, health information networks and exchanges, under a rule effective since September 2023. Providers face separate disincentives through Medicare programs. This is why patient-authorized access works the way it does: an institution refusing to let a patient use the app of their choice has a compliance problem.

HIPAA makes them careful. The Security Rule obligations that generate the security questionnaire, the BAA and the audit-log requirements are the same obligations that create the queue you are waiting in. The institution is not being obstructive. It is being audited.

Design for both from the start. Every read and write logged in tamper-evident form, encryption in transit and at rest, access scoped to the minimum data class set, and a documented retention policy. Retrofitting an audit trail into a live clinical integration is an expensive way to learn this.

Where EHR integration projects fail

Patterns repeat across these projects, and none of the common failures are exotic.

Scoping to the roadmap instead of the launch. Eight data classes approved, two shipped, six paid for.

Treating the sandbox as evidence. A working sandbox integration proves your code parses the response. It says nothing about whether the institution will issue a production credential, or when.

Underestimating writes. Reading is a technical problem. Writing is a clinical-safety problem with an approval path attached, and it costs several times what the read cost.

No reconciliation plan. Bidirectional syncs drift. Without a scheduled reconciliation pass and a documented conflict rule, drift is discovered by a clinician looking at a wrong medication list.

One integration, hardcoded. The vendor's data model wired straight into application logic, and then the second customer arrives on a different EHR. Related reading: our knowledge-base entries on API integration and system integration cover the adapter pattern in general terms, and legacy system modernization covers the surrounding problem when the EHR is not the only old system in the path.

What we learned shipping bidirectional EHR integration

We built AddMed, a medication management platform connecting patients with their care teams, and the EHR integration was the thing that made the clinical workflow viable rather than a feature attached to it. Medication schedules import through HL7 and FHIR instead of being retyped. When a clinician changes an order in the EMR, the change reaches the patient's app; when the patient's schedule changes in the app, it syncs back.

Bidirectional medication sync is where every architecture pattern above stops being theoretical. Queue-backed retries matter because a missed medication change is a clinical event. Idempotency matters because a duplicated medication entry is worse than a missing one. The audit trail matters because when a clinician asks why the schedule shows what it shows, the answer has to be reconstructible. The full write-up is in the AddMed case study.

The other thing that transferred was scoping discipline. Start with the smallest interface that delivers the clinical outcome, get it through the institutional path end to end, and only then widen. Teams that try to launch complete lose the quarter to the approval queue on interfaces nobody used in the first release.

For the records taxonomy underneath all of this, including how an EMR differs from an EHR and what certification actually means, see EHR vs EMR. The compliance and architecture surface sits under healthcare software development, and where an integration is one part of a larger build, the scoping conversation is the same one we run for any custom software development engagement: data classes, direction, and named targets, before anyone opens an editor.

Talk to engineers who have shipped clinical integrations

We scope EHR integration the way institutions do: data classes, direction, named targets, and the review queue. Bring us the product and we will tell you what the first interface really costs.

Start an EHR integration conversation