EHR integration is the work of connecting an application, device or another system to an electronic health record so data moves between them automatically: patient demographics, appointments, notes, orders, results and medications. In the US today, most new EHR integration uses FHIR APIs with SMART on FHIR authorisation, while hospital back-office feeds still run on HL7 v2 through an integration engine.
The technical part is rarely the slowest part. Access programmes, customer approvals, security reviews and per-site activation usually take longer than writing the code. This guide covers the integration patterns, how developer access works at Epic, Oracle Health and athenahealth, integration engine choices, a step-by-step plan, and the pitfalls that stretch timelines.
For the standards themselves, see our overview of healthcare interoperability standards; for HL7 v2 and FHIR R4 detail, our HL7 FHIR integration guide.
EHR integration patterns
| Pattern | How it works | Best for |
|---|---|---|
| SMART on FHIR app (EHR launch) | Your app opens inside the EHR, gets the patient and user context and an OAuth token | Clinician-facing tools: calculators, documentation, decision support |
| SMART on FHIR standalone launch | User signs in from your app and authorises access to their EHR data | Patient apps reading their own records |
| Backend services (system to system) | Your server authenticates with a signed token and calls FHIR APIs without a user | Scheduled syncs, population data, analytics |
| FHIR Bulk Data | Asynchronous export of data for groups of patients | Analytics, quality measures, payer data |
| HL7 v2 interface | Event messages (ADT, orders, results) through an interface engine | Labs, radiology, hospital feeds, real-time events |
| CDS Hooks | The EHR calls your service at workflow points and shows returned cards | Alerts and suggestions at order or chart open |
| Vendor proprietary APIs | Non-standard APIs for features FHIR does not cover | Scheduling, billing, documents, write-back gaps |
Most products use two or three of these. A typical clinical app might launch with SMART on FHIR, sync data with backend services and receive admission events over HL7 v2.
Epic integration
Epic runs two developer routes. open.epic is the public programme: documentation, a FHIR sandbox and access to standard and Epic public APIs, with no membership fee. Vendor Services builds on it with additional technologies, support and testing resources, and is listed at $1,900 a year. Epic's Showroom lists products for Epic customers to discover.
What to know:
- FHIR R4 APIs cover patient data such as demographics, conditions, medications, allergies, observations, documents and appointments. Read access is broad; write access is narrower and varies by resource.
- App registration. You register your app on fhir.epic.com, test in the sandbox, then each Epic customer must approve and enable your app in their environment.
- Customer-driven. Hospitals decide which apps they allow, which scopes they grant and when. Your sales cycle with the hospital is part of the integration timeline.
- HL7 v2 and other interfaces are still common for hospital feeds and are set up with the customer's interface team.
Oracle Health (Cerner) integration
Oracle Health's Millennium platform exposes FHIR R4 APIs, documented on Oracle's site. Developers register apps in the code Console, which needs a CernerCare account, and test against a sandbox. Oracle states that DSTU2 APIs are no longer supported, so new work should target R4.
Production works per tenant: according to Oracle's FHIR application provisioning guide, the developer creates the production app, and each customer then activates it for their own domain. Bulk Data access requires registering a separate Bulk Data SMART application. As with Epic, plan for customer-side approvals and interface work for HL7 v2 feeds.
athenahealth integration
athenahealth runs a developer portal with a sandbox and preview credentials, covering certified FHIR R4 APIs and its own athenaOne APIs, which reach areas such as scheduling and documents that the FHIR surface covers less. Production access to the broader APIs is typically tied to athenahealth's Marketplace partner programme, and each practice enables the app it wants to use. Check athenahealth's current terms for fees and approval steps, as they change.
Other EHRs at a glance
| EHR | Typical integration routes |
|---|---|
| eClinicalWorks | Certified FHIR APIs, partner programme, HL7 interfaces |
| NextGen | Certified FHIR APIs, NextGen developer programme, HL7 interfaces |
| MEDITECH Expanse | Certified FHIR APIs, partner programme, HL7 interfaces |
| Open-source (OpenEMR, OpenMRS) | Built-in FHIR support; direct database access possible but discouraged |
| Indian and UAE systems | FHIR for ABDM or emirate exchanges; HL7 v2 or custom APIs for local integration |
For a neutral list of systems by market, see our EHR software examples.
Integration engines and middleware
Point-to-point scripts become fragile quickly. An integration engine gives you routing, transformation, message logs, retries and alerts in one place.
| Option | Notes |
|---|---|
| Mirth Connect (NextGen) | Long the most common open-source engine. NextGen moved it to a commercial licence from version 4.6 in 2025; 4.5.2 was the last open-source release, and community forks now continue the open code |
| Rhapsody | Commercial engine widely used by hospitals and vendors |
| InterSystems HealthShare and IRIS for Health | Commercial platform with integration, FHIR server and data tools |
| Cloud FHIR services | Managed FHIR stores and APIs from major cloud providers, useful as a hub |
| Integration platforms as a service | Third-party networks that offer one API across many EHRs, for a fee |
The right choice depends on volume, budget, in-house skills and whether you are a hospital connecting many systems or a vendor connecting to many hospitals.
Worked example: a data contract for a remote monitoring app
A data contract is a short table agreed with the hospital before any code. Here is a simplified one for a remote patient monitoring app connecting to a hospital EHR.
| Data | Direction | FHIR resource or message | Frequency |
|---|---|---|---|
| Enrolled patient demographics | Read | Patient | On enrolment, then daily |
| Discharge event | Receive | HL7 v2 ADT A03 or FHIR notification | Real time |
| Active medications | Read | MedicationRequest | On enrolment, then weekly |
| Home blood pressure readings | Write | Observation with LOINC codes | Daily summary |
| Alert summary for the care team | Write | DocumentReference (PDF or note) | When thresholds are crossed |
| Follow-up appointment | Read | Appointment | Daily |
Each row then gets an owner, an error rule and a test case. The two write rows are where approvals usually take longest, so confirm them with the EHR vendor and the hospital first.
Security and compliance for integrations
Hospitals will review your integration as carefully as your app. Expect to show encryption in transit and at rest, how OAuth client secrets and private keys are stored and rotated, which scopes you request and why, audit logs of every API call, where data is hosted, and your incident response process. Request the narrowest scopes that support your use case; broad scopes slow approval and widen your risk.
EHR integration step by step
- Define the data contract. List each data element, direction (read or write), frequency and the FHIR resource or HL7 segment it maps to.
- Choose the pattern. SMART launch, backend services, HL7 v2, CDS Hooks, or a mix.
- Join the developer programme. Register apps, get sandbox access, read the vendor's API terms.
- Build against the sandbox. Handle paging, missing data, coding variations and token expiry.
- Security review. Expect hospital questionnaires on hosting, encryption, access control, audit logs and incident response. A BAA is required in the US if you handle PHI; see our HIPAA compliant app development checklist.
- Customer onboarding. The hospital approves the app, grants scopes, and its interface team configures feeds.
- Test with real workflows. Clinicians test in the customer's test environment with realistic data.
- Go live with monitoring. Log every call and message, alert on failures, and agree a support process with the hospital.
- Repeat per site. Each new customer repeats steps 6 to 8, faster each time if you document well.
How long EHR integration takes
| Scope | Indicative timeline |
|---|---|
| Read-only SMART on FHIR app, sandbox working | 4 - 8 weeks |
| First production customer, read-only | 3 - 6 months including approvals |
| Read and write integration with one EHR | 4 - 9 months |
| HL7 v2 feed with a hospital interface team | 4 - 12 weeks per interface |
| Each additional customer on the same EHR | Weeks to a few months |
Approvals, security reviews and the hospital's own IT queue are usually the critical path. Starting customer conversations early saves more time than any code optimisation.
Common EHR integration pitfalls
- Assuming write access. Many FHIR endpoints are read-only or limited for writes. Confirm before you design.
- Ignoring data variation. The same EHR configured by two hospitals can return different codes and fields.
- Patient matching errors. Wrong-patient data is a safety issue. Use reliable identifiers and matching rules.
- No monitoring. Silent failures erode trust. Alert on every failed message or call.
- Rate limits and paging. Large syncs can hit limits; design for incremental updates.
- Token handling. Refresh tokens and key rotation done badly cause outages.
How Algon approaches EHR integration
Algon is a Kochi-based team doing healthcare integration for clients in India, the UAE and the USA. We start with the data contract and the places staff retype information, choose FHIR, HL7 v2 or simpler interfaces depending on what each system supports, and give every connection a named owner, a message log and alerts. The same approach applies when we build patient engagement or clinical documentation AI features that need to read from and write to an EHR.
Conclusion
EHR integration in 2026 means FHIR and SMART on FHIR for apps, HL7 v2 for hospital feeds, and an integration engine to keep it reliable. Epic, Oracle Health and athenahealth each have developer programmes with sandboxes, but production access always runs through the customer's approval and activation.
Define your data contract, choose the right pattern, start customer conversations early and monitor everything. For the US policy context, including TEFCA and CMS API rules, see our post on US interoperability in 2026.
Frequently asked questions
What is EHR integration?
EHR integration connects an application, device or system to an electronic health record so data such as demographics, appointments, notes, orders, results and medications moves automatically, using APIs like FHIR or messaging standards like HL7 v2.
How do I integrate my app with Epic?
Register on Epic's developer site (open.epic), build and test against the FHIR sandbox using SMART on FHIR, consider Vendor Services for extra support, complete the hospital's security review, and have each Epic customer approve and enable your app in their environment.
Is the Epic FHIR API free?
Access through open.epic, including documentation, the sandbox and standard APIs, has no membership fee. Epic's optional Vendor Services programme is listed at $1,900 a year. Hospitals may have their own costs for enabling and supporting integrations.
What is SMART on FHIR?
SMART on FHIR is a standard for launching apps from an EHR or standalone and giving them authorised access to FHIR data, using OAuth 2.0 and OpenID Connect. It lets one app work across different EHRs that support the standard.
How long does EHR integration take?
A read-only SMART on FHIR app can work in a sandbox in 4 to 8 weeks, but the first production customer typically takes 3 to 6 months because of approvals and security reviews. Read and write integrations take longer.
Do I need an integration engine?
If you connect more than a couple of systems or handle HL7 v2 feeds, yes. An integration engine provides routing, transformation, logging, retries and alerts. Options include Rhapsody, InterSystems products, licensed Mirth Connect, its open forks and cloud FHIR services.
