EHR and EMR Integration Services: What It Actually Takes
Healthcare software projects rarely fail on the software. They fail at the integration boundary. This guide covers the standards you will actually meet, how Epic access works now that App Orchard is gone, what integration touches on your side, and what it costs.
Most healthcare software projects do not fail on the product. They fail at the boundary where the product meets the record system the client already runs.
That boundary is where the timeline goes. A team scopes twelve weeks for the application and three for the integration, then discovers that the integration is a different discipline with its own standards, its own gatekeepers and its own review queues — none of which move faster because a sprint is ending.
This guide is about that boundary: which standard you will actually be working with, how access to the major EHRs works in 2026, what integration touches in your own system, and what it realistically costs.
What is the difference between EHR and EMR integration?
An EMR is a single organization’s digital chart — one practice’s record of its own patients. An EHR is built to be shared across organizations, so a record can follow a patient between providers. In integration terms the distinction matters less than vendors imply: you are connecting to a specific product, and that product’s interfaces decide the work, not the acronym.
What does change the work is who controls the instance. A hospital’s Epic deployment is administered by that hospital, on its schedule, with its security review. A cloud-hosted EMR at a twelve-person clinic may be a single API key. Same category of task, entirely different project.
Which standard will you actually be integrating with?
Four answers cover almost every healthcare integration, and you rarely get to choose which one — the incumbent system does. Knowing which you are facing before you quote is the difference between an accurate estimate and an apology in month three.
| Standard | What it is | Where you still meet it | What it costs you |
|---|---|---|---|
| HL7 v2 | Pipe-delimited messages over a persistent connection. Decades old and still the workhorse of hospital interfacing. | Admissions, orders, results and scheduling feeds inside most hospitals | Cheap to parse, expensive to get right — every site implements it slightly differently, so “standard” means standard-ish |
| HL7 v3 / CDA | XML document architecture. Verbose, heavily structured. | Clinical document exchange, continuity-of-care documents | Steep parsing effort for the value returned; usually met rather than chosen |
| FHIR (R4) | Modern REST and JSON resources. What every vendor now leads with. | New integrations, patient-facing apps, anything built in the last few years | By far the least painful — but coverage varies by vendor and by deployment, so confirm the resources you need exist on that instance |
| Proprietary API or flat file | Vendor-specific interface, or a scheduled file drop | Smaller EMRs, billing systems, legacy departmental software | Wildly variable. Budget for discovery before committing to a date |
The decision most teams are actually facing
It is usually not FHIR or HL7 v2. It is FHIR where it exists, HL7 v2 for everything it does not cover yet. Real deployments run both, and a realistic architecture assumes a hybrid rather than betting on full FHIR coverage at a site you have not surveyed.
What integrating with the major EHRs involves in 2026
Access to the large EHR vendors runs through formal programmes, and those programmes change. Plan for a process with an application, a technical review, a security review and a sandbox period before production access — the names and tiers shift, the shape does not.
Epic
This is where outdated guidance does the most damage, because much of what is written online is several years stale. App Orchard no longer exists. It was renamed App Market in 2021 and shut down at the end of 2022. Epic launched Showroom in early 2024 as its customer-facing marketplace, organized into tiers — Connection Hub for data integrations and system connections, Toolbox for clinical tools and workflow applications, and Workshop for enterprise-level integrations and analytics. Deeper proprietary integration runs through a separate paid developer programme, Vendor Services.
The practical consequences for a project plan: listing and integration are two different things, the tier you need depends on how deeply you touch the workflow, and each tier carries its own technical and security review. If a proposal you are reading still says App Orchard, it was written against a programme that closed four years ago — treat the rest of its timeline with the same suspicion.
Everyone else
Oracle Health (formerly Cerner), athenahealth, Allscripts/Veradigm and MEDITECH each run their own developer programmes with their own review steps and sandbox arrangements. The common pattern is: register, pass technical and security review, build against a sandbox, then arrange production access with the individual provider organization. That last step is the one most plans forget — vendor approval is not the same as the hospital saying yes, and the hospital has its own committee and its own calendar.
What EHR integration touches on your side
The interface is maybe a third of the work. Six things in your own system change the moment real clinical data starts arriving, and a proposal that does not name them has not been scoped.
- Identity and access. Which clinician is allowed to see which record, enforced at query time rather than filtered after retrieval.
- Patient matching. The same human appears with different identifiers in different systems. Matching them wrongly is a clinical safety problem, not a data-quality inconvenience — it deserves explicit design, not a fuzzy string comparison bolted on late.
- Data mapping. Codes, units and vocabularies differ between systems. LOINC, SNOMED and ICD mappings are project work in their own right.
- Audit logging. Who accessed what, when. Required, and far easier to build in than to retrofit.
- Error handling for partial records. Real feeds deliver malformed, duplicated and out-of-order messages. What happens to a message you cannot parse is an architectural decision — drop, quarantine or retry — and the wrong answer silently loses data.
- Encryption in transit and at rest. Table stakes, and specified rather than assumed.
Why compliance here is architecture, not paperwork
HIPAA’s Security Rule sets technical safeguards that read like an architecture brief: access control, audit controls, integrity, person or entity authentication, and transmission security. Every one of those is a design decision made early or an expensive retrofit made late.
The practical version: you cannot add audit logging convincingly after the fact, you cannot bolt on record-level access control once queries assume full visibility, and you cannot prove integrity for data you never checksummed. Empat is HIPAA compliant and an AWS, Microsoft Azure and Google Cloud partner — which matters most when the question is where protected health information physically lands and who can reach it.
A note on honesty: compliance posture is shared between you, your client and the infrastructure. Any vendor who tells you their platform makes you compliant is describing a product, not a regulation.
What EHR integration costs and how long it takes
Integration work fits a discovery-then-proof-of-concept shape far better than a fixed build, because the unknown is not your product — it is the interface and the counterparty. Empat prices that shape directly: AI-driven discovery from $5,000 (1–2 weeks), then a proof of concept from $15,000 (2–4 weeks) that puts the riskiest assumption into working code against a real sandbox.
What actually drives the number:
- Which standard, and whether you need one or several
- How many resource types — reading demographics is not reading demographics, encounters, medications, allergies and results
- Read or write — writing back to the chart raises the review bar substantially
- How many sites — each provider organization is its own approval, and often its own quirks
- Vendor review queues — calendar time you do not control and cannot compress
Treat vendor and hospital review as the critical path. Engineering rarely is.
How to choose an EHR integration partner
Six questions whose answers actually predict how the project will go.
- What happens to a malformed or partial message? The sharpest question available. Listen for quarantine, replay and alerting. “That should not happen” means it will, silently.
- How will you handle patient matching? You want a deliberate strategy, not a similarity score.
- Which Epic tier or vendor programme does this need, and who applies? If the answer includes App Orchard, their information is four years old.
- What is in the sandbox that is not in production? Experienced teams have a list. It is where schedules die.
- How do you enforce access control at query time? Filtering after retrieval is not access control.
- Who owns the interface code and the mappings? You should, in a repository you control, from the first commit.
How we approach it
Empat has built products since 2013 — more than 300 across 23 markets — with healthcare among the strongest verticals. Dr. Alexa is the closest reference point: consultations, test ordering and prescriptions, exactly the class of product where the record system is the hard part rather than the interface.
Billing is transparent by default — no hidden infrastructure or onboarding fees, prepayment rolls into your first invoice, and utilization tracking is shared with you weekly rather than summarized afterwards. Delivery is AI-augmented, with Claude Code, Cursor and Copilot in daily use and every line human-reviewed before it ships.
Related reading: healthcare software development is the service hub, custom healthcare software development covers the broader build, and healthcare app development covers the patient-facing side. For a range on your own project, there is the estimator.
FAQ
What is the difference between EHR and EMR integration?
An EMR is a single organization’s own digital chart; an EHR is designed to be shared across organizations so a record follows the patient. For integration work the more important difference is who controls the instance: a hospital Epic deployment involves that hospital’s security review and calendar, while a small cloud-hosted EMR may be a single API credential.
Should we integrate using HL7 v2 or FHIR?
Usually both. FHIR is the modern REST and JSON standard and is far less painful to work with, so use it wherever the target system supports the resources you need. HL7 v2 still carries most hospital admissions, orders and results traffic, so plan a hybrid rather than assuming full FHIR coverage at a site you have not surveyed.
How long does an Epic integration take?
The engineering is rarely the constraint. Expect an application, technical and security review, a sandbox build period, and then separate production approval from each individual provider organization. Budget calendar time you do not control, and confirm current programme requirements directly with Epic — App Orchard closed at the end of 2022 and was replaced by Showroom and Vendor Services in 2024.
How much does EHR integration cost?
At Empat, discovery starts from $5,000 over one to two weeks and produces a chosen approach, an architecture and an estimate; a proof of concept against a real sandbox starts from $15,000 over two to four weeks. The main cost drivers are which standards are involved, how many resource types you need, whether you write back to the chart, and how many provider sites must each approve access.
