Most teams arrive at EHR integration expecting an API problem. They have built against Stripe and Twilio, the hospital says it supports FHIR, and the work looks like a sprint.
Then the specification arrives. It is an HL7 version 2 ADT feed over MLLP, a transport protocol nothing outside healthcare uses. The patient identifiers in it do not match the ones in your database. The hospital's integration analyst has a four-week queue. And the security questionnaire has not even been sent yet.
We do this work for a living. This page is a straight description of what it involves, what moves the timeline, and what you should ask before anyone quotes you a number.
What we build
Inbound clinical feeds. Patient admissions, discharges and transfers (ADT), lab results (ORU), orders (ORM), scheduling (SIU). These are the backbone feeds that tell your product something happened in the hospital.
Bidirectional interfaces. Writing back into the clinical system: orders, results, documents, notes. Harder than inbound, held to a higher standard by the hospital, and reviewed more carefully, because you are now changing the record clinicians rely on.
FHIR APIs and SMART on FHIR apps. Modern REST integration where the EHR supports it, including apps that launch inside the clinician's workflow rather than sending them to a separate tab.
Document exchange. C-CDA documents in and out, which is still how a great deal of clinical summary data moves between organisations.
Interface engine work. Building and maintaining routes in Mirth Connect, Rhapsody, Corepoint or Iguana, including monitoring and message replay when something fails at 2am.
Migrations and consolidations. Moving interfaces when a health system switches EHR, or when your platform absorbs a second data source and nothing lines up.
Systems we work with
Epic, Oracle Health (formerly Cerner), athenahealth, eClinicalWorks, NextGen, Meditech, AdvancedMD, DrChrono.
Plus the network and aggregator layer that often sits between you and the data: Redox, Health Gorilla, Particle Health, 1upHealth.
A note on the two we are asked about most.
Epic integration goes through Epic's developer programme, which is now called Showroom. If you are reading older guides that reference App Orchard, that name is retired. Access tiers, review and fees differ by what you are building and whether the hospital sponsors you, so the access path is worth confirming early. We cover the full picture in our guide to what Epic costs.
Oracle Health and athenahealth integration each have their own developer programmes, sandbox environments and approval queues. The engineering is comparable. The waiting is not, and it varies by vendor and by what the hospital has already approved.
Standards we work in
HL7 v2 is the pipe-delimited message format from 1989 that still moves most hospital data. It is a standard the way a dress code is a standard, which is why two hospitals running the same EHR can send you feeds that need different mapping. We wrote up what HL7 integration actually involves in detail.
FHIR is the newer REST and JSON standard from the same organisation. Cleaner to build against, genuinely better, and not a replacement for v2 in most hospitals yet. Expect to work in both.
C-CDA for clinical documents, X12 for eligibility and claims transactions, and the terminology standards underneath all of it: LOINC for lab observations, SNOMED CT for clinical concepts, ICD-10-CM for diagnoses, RxNorm for medications.
How an engagement runs
1. Interface analysis. We read the hospital's specification, get real sample messages, and work out what is actually in them rather than what the documentation claims. Projects that skip this discover in week nine that a required field arrives empty. This is the step that most protects your timeline, and it is the one most often cut from a cheap quote.
2. Mapping. Translating their message structure into your data model, field by field, including the undocumented ones. This is the bulk of the engineering.
3. Transport and connectivity. MLLP over TCP, VPN tunnels, firewall rules, certificates, or REST endpoints and OAuth where it is FHIR. Rarely difficult, frequently slow, because it involves the hospital's network team and their calendar is not yours.
4. Error handling and acknowledgements. What happens to a lab result that arrives while your service is restarting. Which failures page someone and which queue silently. How a message gets replayed. This is the part that separates teams who have done this before from teams who have not.
5. Testing and validation. Test environment, sample data, then parallel running against live data before anyone trusts it.
6. Monitoring and support. Interfaces drift. Senders change formats without telling you. Someone needs to notice.
If a quote covers mapping and transport but goes quiet on steps 4 and 6, the project did not get cheaper. Two phases moved to an invoice you have not seen yet.
What drives the timeline
| Scope | Typical effort | | --- | --- | | One-way ADT feed | 2 to 4 weeks | | Inbound lab results (ORU) | 3 to 5 weeks | | Bidirectional orders and results | 6 to 10 weeks | | FHIR read-only integration, single EHR | 3 to 6 weeks | | Several message types across multiple sites | 3 to 6 months |
Two things bend these more than anything technical.
Site count. Every additional hospital means new mapping, new testing, new sign-off, because every site reads the standard slightly differently. Five sites is not five times one site, but it is not close to one site either.
Waiting. Access approvals, security review, network changes, test environments, a clinical stakeholder free only on Thursdays. You can compress engineering by adding people. You cannot compress a hospital's change control board.
Worth knowing before you plan: the security review usually comes first and runs in parallel at best. Expect a Business Associate Agreement, a vendor security questionnaire, and questions about SOC 2, SSO and audit logging. None of that is integration work, and all of it sits between you and the integration.
What you get
Working interfaces, with the mapping documented well enough that the next engineer can pick it up. Monitoring and alerting you can see. A test environment that matches production. Runbooks for the failure modes we know about. And the interface specification written down, because in two years the person who remembers why a field was mapped that way will have left.
Questions to ask before anyone quotes
A partner who has done this will raise most of these first. If they do not, that tells you something.
Which sites, and which system at each one, by name and version? Not "the hospital."
Which message types, and which direction? Inbound only is a different project from bidirectional.
Can we see real sample messages before you quote? This matters most. Anyone quoting from the specification alone is quoting a guess.
Who owns the network changes on their side, and what is the realistic turnaround?
What happens when a message fails at 2am? If the answer is not specific, there is not an answer yet.
Who maintains this in year two?
Common questions
How long does EHR integration take? A single one-way feed to one site is usually four to eight weeks end to end, and most of that is waiting rather than engineering. Multi-site or bidirectional work runs to months.
Do we need an interface engine? For one or two simple interfaces, no. For several interfaces, multiple sites, or anything needing routing and transformation, an engine pays for itself in monitoring and message replay alone. It does not do the mapping for you; it gives you a better place to do it.
Can you work with our existing integration? Yes. A good share of our work is inheriting interfaces someone else built, usually when they break or when a site is added.
Is FHIR enough on its own? Rarely, today. FHIR standardises the envelope. Patient identity, terminology mapping, data freshness and provenance all sit inside the envelope and remain yours. Clinical data integration covers why.
Do you sign a BAA?
Working out what your integration actually involves? Tell us what you are building and we will give you a straight read on scope and timeline before you commit to anything. No pitch.