How Long an EHR Integration Really Takes

EHR integration timelines are routinely underestimated. Here is what the work actually involves, where time gets lost, and how to plan for it honestly.

The Numbers Engineers Quote vs. The Numbers That Actually Land

Most teams budget four to eight weeks for an EHR integration. The actual median for a production-grade, bidirectional integration sits closer to four to six months, and that is for a single EHR vendor with a well-documented API. Multi-vendor integrations, legacy on-premise deployments, or anything touching clinical decision support can run twelve months or longer.

The gap is not incompetence. It is a systematic undercount of what the work involves.

What Does an EHR Integration Actually Require?

"Integration" tends to mean different things to different people in the same planning meeting. Clarifying scope is the first thing to do, because scope determines the timeline more than anything else.

Data access patterns

Are you reading patient demographics and lab results, or are you writing clinical notes, medication orders, and problem lists back into the record? Read-only integrations through a FHIR R4 API, where the EHR vendor has a decent developer portal, are genuinely achievable in six to ten weeks from credential approval to production go-live. Write-back integrations, especially anything that touches medication administration or clinical documentation, require EHR-vendor certification, which adds four to sixteen weeks depending on the vendor.

The standards layer

HL7 v2 is still the dominant message format in most hospital environments, despite FHIR getting most of the attention. If you are connecting to a hospital system built before 2015, plan for HL7 v2.x ADT, ORU, and ORM message types, usually delivered over MLLP. FHIR R4 is common in newer ambulatory systems and is mandated under the 21st Century Cures Act for patient-facing apps, but the implementation quality varies enormously between vendors. Epic's FHIR R4 sandbox is solid. Some smaller vendors give you a FHIR endpoint that returns 200 OK on every request regardless of payload validity.

Terminology mapping

ICD-10 codes, LOINC codes for lab observations, SNOMED CT for clinical findings, RxNorm for medications. No two EHRs use exactly the same subset, and many still mix proprietary codes with standard ones. A mapping layer is not optional; it is just often forgotten until the data looks wrong in production.

Credentialing and access approval

Epic's App Orchard review takes a minimum of eight weeks for new vendors. Cerner (now Oracle Health) has a similar timeline through its code program. Both require security questionnaires, HIPAA BAA execution, and in some cases a formal clinical review of your application's use case. This clock does not start until you have submitted a complete application, and incomplete submissions restart the clock.

Why Does Certification Take So Long?

The certification process is the single most common source of timeline slippage, and it is largely outside your control.

Epic, for instance, runs a structured review cycle. If your submission misses a review window, you wait for the next one. The windows are typically four to six weeks apart. One missed deadline costs you a month and a half. Add the time for your team to respond to revision requests, and a "simple" certification can consume three months without anyone doing anything wrong.

Oracle Health's Ignite program has improved over the past two years, but enterprise-tier access (the level you need for full clinical data) still involves a sales process alongside the technical one. You are not just proving your app is secure; you are proving there is a business case the EHR vendor cares about.

Smaller EHRs like Athenahealth and DrChrono have lighter-touch certification programs, usually two to four weeks, but their APIs are less capable and their documentation is patchier. You trade speed for coverage.

How Should You Structure the Timeline?

This is the question worth planning around carefully.

Phase	What Happens	Realistic Duration
Scoping and vendor selection	Define data flows, identify EHR systems in scope, confirm FHIR vs HL7 v2	2–3 weeks
Sandbox access and credential approval	Apply for developer access, execute BAAs, receive test credentials	2–6 weeks
Prototype integration	Build against sandbox, validate data models, identify terminology gaps	4–6 weeks
Certification submission	Package app, submit for vendor review, respond to RFIs	8–16 weeks
UAT and clinical validation	Test with real (de-identified) data, validate clinical logic, fix edge cases	3–5 weeks
Production go-live and monitoring	Phased rollout, alert setup, on-call coverage	2–4 weeks

Run scoping and sandbox access in parallel. Do not wait for certification approval to begin UAT preparation; you can build your test harness and data validation scripts against the sandbox while the review is in progress. That overlap is where most of the schedule compression comes from.

What Goes Wrong That Engineers Do Not Anticipate?

Four things cause the most damage.

Patient matching. EHRs do not share a universal patient identifier. You will implement a probabilistic matching algorithm based on name, date of birth, MRN, and possibly SSN. It will be wrong sometimes. Deciding how to handle mismatches, flagging for manual review vs. rejecting the record, requires clinical input, not just engineering judgment, and that takes time to get right.

Rate limits under production load. Epic's FHIR API allows 100 requests per second per client ID in most configurations. That sounds like a lot until you are doing a bulk backfill of 200,000 patient records. Plan for exponential backoff, retry queues, and a realistic estimate of how long bulk operations will take.

EHR version mismatches. Epic releases new versions quarterly. A hospital may be running Epic 2021 or Epic 2023. The FHIR capability statements differ between versions, and a resource type that works in 2023 may not be available in 2021. You need to handle version negotiation or pin your integration to a minimum supported version.

Scope creep from clinical stakeholders. Once clinical staff see data flowing, they ask for more of it. "Can we also pull the care team? And the latest vitals? And the allergies?" Each addition needs its own data mapping, testing, and sometimes its own certification scope extension.

Conclusion

A realistic EHR integration timeline is three to six months for a single-vendor, scoped integration, and six to twelve months if certification is required or multiple EHRs are in scope. The technical work is manageable. The process work, certification, credentialing, patient matching decisions, clinical validation, is where the time goes.

The clearest next step is to draft a data flow diagram before you do anything else. Know exactly which resources you are reading or writing, which EHR systems are in scope, and whether you need write-back. That document is the foundation for every timeline conversation that follows, with vendors, with clinical stakeholders, and with your own team.

---

FAQ

How long does Epic App Orchard certification take? Plan for a minimum of eight weeks from a complete submission to approval, and that assumes no revision requests. Most teams experience at least one round of revisions, which adds four to six weeks. Budget twelve weeks as your working assumption and treat anything faster as a bonus.

Do we need HL7 v2 support if we are building a FHIR-first integration? Often yes. Many hospital systems still route real-time ADT feeds (admissions, discharges, transfers) over HL7 v2 MLLP, even if they expose a FHIR endpoint for query-based access. FHIR subscriptions are improving but are not universally supported at the production level. Check the specific EHR version your target hospitals are running.

Can we use a middleware platform like Mirth Connect or Azure API for Health to speed things up? Yes, but with caveats. Mirth Connect handles HL7 v2 transformation well and reduces boilerplate. Azure API for Health (FHIR Service) simplifies FHIR persistence. Neither platform shortcuts the certification process or resolves patient matching ambiguity. They reduce integration engineering time by roughly 20–30%, not the overall project timeline by the same margin.

What is the difference between a sandbox integration and a production integration? Sandbox environments use synthetic or de-identified data and relaxed rate limits. Production environments enforce stricter rate limits, require signed BAAs, and often have additional IP allowlist requirements. Data structures can also differ; some fields present in sandbox test data are empty or absent in real patient records. Always allocate time for a dedicated production validation phase.

Is SMART on FHIR mandatory for patient-facing apps? Under the 21st Century Cures Act information-blocking provisions, EHR vendors must support SMART on FHIR for patient-facing application access to the US Core data set. For clinician-facing or backend system integrations, it is not mandatory, but many vendors prefer it because it handles OAuth 2.0 scopes in a standardised way. Check your specific use case against the ONC's finalised rules before assuming it applies.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.