EHR Integration Cost in 2026: HL7, FHIR and Epic Reality Check

The quote you have been given for "Epic integration" is probably a quote for the wrong unit of work. Engineering an FHIR R4 client is a bounded, estimable job. Getting that client into production against a specific hospital, with that hospital's security review, that hospital's Epic analyst, and that hospital's change window, is a different job — and it is the one that determines your calendar and most of your cost.

We have shipped this work. Zee Palm built the State of New Hampshire's immunization platform over HL7 with 50+ schools live, and we have delivered against Epic, Cerner and Athenahealth environments. What follows is the cost structure as it actually behaves, with the vendor-specific commercial terms clearly flagged for you to confirm rather than invented.

The unit of cost is a connection, not a vendor

Say this out loud before you budget anything: you do not integrate with Epic. You integrate with one health system that runs Epic.

Epic, Oracle Health (Cerner) and Athenahealth publish APIs and run developer programs. Those give you a specification and a sandbox. They do not give you data. Data belongs to the provider organization, and every provider organization decides independently whether to enable your app, under what agreement, with which scopes, after which security review, on which quarter's change calendar.

So the cost model is:

Total = one_time_engineering (per EHR vendor)
      + per_connection_cost (per health system, recurring effort)
      + vendor_program_costs (per EHR vendor, see below)
      + ongoing_maintenance (spec versions, cert rotation, breakage)

The first term is the one agencies quote. The second is the one that decides whether your business model works. If your go-to-market requires 40 hospital connections, you are not running an integration project, you are running an implementation function, and you need to staff it.

HL7 v2 is not legacy, and it is often the cheaper path

Founders arrive assuming FHIR replaced HL7 v2. It did not. FHIR is how modern apps read discrete data over HTTP; HL7 v2 is still how enormous volumes of clinical events move between systems inside and between institutions, and for a large class of use cases it is faster and cheaper to implement.

The v2 messages that carry most real work:

Those messages travel over MLLP on a TCP socket, wrapped in start/end block characters, with an ACK or NACK returned per message. They are pipe-delimited, deeply segmented, and every site has customized them — the Z segments, the locally-defined codes in OBX-3, the facility's own interpretation of PID-18. Anyone who tells you HL7 v2 is standardized has not integrated two hospitals.

Our New Hampshire immunization work is the archetype: VXU messages carrying immunization events into a state registry, with 50+ schools live, and the real engineering being validation, code-set mapping, error handling and reconciliation rather than socket plumbing.

When v2 is the cheaper answer: you need a firehose of events rather than on-demand queries; the counterparty already has an interface engine (Mirth/NextGen Connect, Rhapsody, Iguana) with an analyst who builds interfaces every week; or you need to write data somewhere that has no FHIR write path. In those cases a v2 interface can be commissioned through a process the hospital already runs, which is materially faster than getting a novel app through app review.

What "FHIR support" actually means when you read the fine print

FHIR R4 is genuinely good and the ecosystem is genuinely real. Two distinctions decide your scope.

Read versus write. Read access to a broad set of US Core resources — Patient, Observation, Condition, MedicationRequest, AllergyIntolerance, DocumentReference, Encounter — is widely available across major vendors. Write-back is a different conversation. Which resources you may write, in what state, and whether the write lands as discrete data or as an unfiled document awaiting clinician review, varies by vendor, by resource and by the provider organization's configuration. Scope your product so that a write path being unavailable does not kill the value proposition, or confirm the specific write capability with the specific health system before you sell it.

Which launch model you need. SMART on FHIR gives you three shapes, and they have different economics:

• EHR launch — your app is opened from inside the EHR with patient and encounter context handed to you. Best clinical UX. Requires the deepest configuration on the provider side.
• Standalone launch — the patient (or clinician) authenticates from your app against the health system's authorization server. This is the path most patient-facing products take, and it is the one the federal patient-access rules made broadly available.
• Backend services / system-level access — client-credentials with a signed JWT, no user present, for population-level and scheduled workloads. This is what you need for bulk $export (Flat FHIR) if you are pulling cohorts rather than individuals.

Getting this choice wrong is expensive. Building a standalone patient app and then discovering your buyer needs it launched in-context from the chart is a re-architecture, not a tweak.

Bulk data. If your product is population health, quality reporting or analytics, the asynchronous $export operation is the mechanism to design around from day one. Retrofitting bulk onto a per-patient query design produces something that works in the sandbox and times out in production.

Where the money actually goes

Here is the honest breakdown of an EHR integration budget by category, in rough order of size for a first production connection.

1. Certification, review and paperwork — usually the largest non-engineering line. Security questionnaires, architecture documentation, penetration-test evidence, BAA negotiation, and the vendor's own app review. None of this is code. All of it needs someone senior who can answer questions about key management and audit logging without guessing.

2. Data mapping. Your schema is not their schema. Local codes to LOINC, local medication codes to RxNorm, local problem lists to SNOMED, unit normalization, and the reconciliation rules for when the same observation arrives twice from two sources. This is where estimates go wrong, and it is the same class of problem as deduplicating wearable data — merge rules, source priority and timezone boundaries — just with clinical consequences.

3. Engineering. The client, the auth flow, token refresh and rotation, retry and backoff, idempotency, error surfacing. Genuinely bounded work. Frequently the smallest line in the budget.

4. Environment access and waiting. Sandbox to non-production to production is a sequence of approvals, each with a queue. Budget calendar time you cannot compress with money.

5. Ongoing maintenance. Certificates expire. Vendors upgrade. The hospital's Epic analyst changes a build and your interface starts rejecting messages at 3am. A live clinical integration needs a named owner and a monitoring posture, which is why our app maintenance retainers start at $1,000/mo and why we say plainly that an unmaintained clinical interface is a liability rather than an asset.

The middleware question: aggregators vs direct

You can also buy the connection rather than build it. Companies including Redox, Health Gorilla, 1upHealth, Particle Health and Metriport sell normalized access to networks of provider organizations, so you write one integration against their API instead of one per vendor.

The honest trade:

The pattern we recommend most often: use an aggregator to get to market and prove demand, then evaluate direct integration for the two or three health systems that become a material share of your revenue. Building forty direct connections before you have proven anyone wants the product is the most expensive way to learn a lesson available in health tech.

And the unprofitable version, which we say to founders on calls: for a great many health products, version one should not integrate with an EHR at all. A CSV drop over SFTP, a manual export, or patient-mediated data entry will prove the clinical value and get you a pilot site. EHR integration is what you do once a paying customer is asking for it, because a paying customer asking for it is also the thing that unlocks the provider-side sponsorship you need to get through their security review in the first place.

What we charge, and what that buys

We publish our prices. EHR work is scoped, not fixed-price off a menu, but the surrounding numbers are real and public.

What that does not buy, stated plainly: a certification. Zee Palm builds HIPAA-aware, compliance-conscious systems and maps sensitive-data, claims and clinical boundaries during planning. We do not issue certifications or legal sign-off, and we do not determine whether your product is a regulated medical device. Our security and BAA posture is on the trust page; the engagements to ask us about are on the case studies page.

If you are scoping clinical integration into a telehealth or remote-care product, the cheapest hour you will spend is the one where someone who has shipped VXU messages into a state registry tells you which of your three integration requirements is actually necessary for version one. Send us the requirement and we will tell you what it costs and, more usefully, what it costs to defer.

Frequently asked questions

How much does EHR integration cost?

Engineering a client against one EHR vendor's FHIR R4 API is a bounded project, typically the smallest line in the budget. The cost that decides your business case is per-connection: each health system requires its own security review, agreement, configuration and change window. Budget by number of connections, not by number of vendors, and include maintenance from $1,000/mo for anything live.

Is FHIR cheaper to integrate than HL7 v2?

Not automatically. FHIR is cleaner to develop against and far better for patient-facing apps. HL7 v2 is often faster and cheaper to commission when the counterparty already runs an interface engine with staff who build interfaces routinely, and it remains the practical path for high-volume event feeds and for writes with no FHIR equivalent. Choose by use case, not by which acronym sounds more modern.

Do Epic, Cerner and Athenahealth charge to use their APIs?

Each runs a developer and app-listing program with its own structure, requirements and commercial terms, and those terms change. Confirm the current details directly with each vendor rather than relying on any third-party article, including this one — we deliberately do not publish figures for another company's commercial programs.

Can we write data back into the EHR?

Sometimes, narrowly, and it depends on the vendor, the resource and the individual health system's configuration. Reading is broadly available; writing is negotiated. Design version one so that value survives a read-only connection, then treat any write path as an upgrade you confirm in writing with the specific site before you promise it to a customer.

Should our MVP integrate with an EHR at all?

Usually not. A file drop, a manual export or patient-entered data proves the clinical value at a fraction of the cost and calendar. EHR integration is best triggered by a specific provider customer who wants it, because that customer is also the sponsor who gets you through their own security review. Our $1,999 Healthtech MVP Blueprint exists in large part to make that call correctly.

How long does it take to get an EHR integration into production?

The engineering is weeks. The path from sandbox to a live production connection at a specific health system is governed by their security review, contracting and IT change calendar, and is frequently measured in months regardless of how fast your team is. Plan your funding and your customer commitments around the queue, not around the code.