Complete Guide to EHR & EMR Integration

EHR integration connects electronic health record systems with the applications, devices, labs, pharmacies, and external organizations that need to exchange clinical data. It is the plumbing that makes healthcare interoperability work — and for most health IT projects, it is the hardest part to get right.

Whether you are building a third-party application that needs to read patient data from an EHR, a health system connecting a new lab instrument, a medical device company sending results back to the chart, or a startup building a clinical decision support tool, the fundamental challenge is the same: getting data in and out of EHR systems reliably, securely, and in a format both sides can use.

This guide covers the standards, platforms, patterns, and architecture decisions you will encounter when building EHR and EMR integrations. It is written from the perspective of an integration team that has built and maintained hundreds of production interfaces across every major EHR platform — see our EHR integration services for the consulting side.

EHR vs EMR: The Practical Difference

The terms are used interchangeably in practice, but there is a technical distinction. An EMR (Electronic Medical Record) is the digital version of a patient’s chart within a single practice or organization. An EHR (Electronic Health Record) is designed to share data across organizations and care settings. In the context of integration, the distinction rarely matters — the protocols, standards, and challenges are the same. This guide uses “EHR” throughout, but everything applies equally to EMR systems.

Integration Standards

Healthcare integration relies on a small number of well-established standards. Most integrations use one or more of these.

HL7 v2

HL7 version 2 remains the dominant messaging standard in healthcare — used by nearly every US hospital for some or all of their clinical interfaces. Messages use a pipe-delimited format (|) transmitted over TCP connections using MLLP (Minimal Lower Layer Protocol). For depth on the format, see our HL7 message types primer and HL7 vs FHIR comparison — or parse and inspect a sample HL7 message in the browser to see the segment structure first-hand.

The most common HL7 v2 message types:

• ADT (Admit/Discharge/Transfer): Patient registration, admission, discharge, and transfer events. These are the backbone of most integration architectures — nearly every downstream system needs to know when a patient arrives, moves, or leaves.
• ORM/OML (Orders): Clinical orders for labs, radiology, procedures, and medications. Order interfaces connect EHRs to ancillary systems like LIS and RIS — see our lab integration practice.
• ORU (Observations/Results): Lab results, pathology reports, radiology readings, and other clinical observations flowing back to the ordering system.
• SIU (Scheduling): Appointment scheduling events used by scheduling systems, patient portals, and analytics platforms.
• MDM (Medical Documents): Clinical document notifications, including transcription results and structured reports.
• DFT (Financial Transactions): Charge capture and billing data flowing to revenue cycle systems.

HL7 v2 is mature, well-understood, and supported by every EHR on the market. Its weaknesses are a lack of strict conformance (implementations vary between vendors) and limited support for modern web-based architectures. For many use cases, HL7 v2 is still the most practical and cost-effective integration approach — our HL7 integration services cover the engineering side.

FHIR R4

FHIR (Fast Healthcare Interoperability Resources) R4 is the modern standard for healthcare API development. Unlike HL7 v2’s message-based approach, FHIR uses RESTful APIs with JSON or XML payloads. FHIR R4 is the first normative release, meaning the core specification is stable and will not change in ways that break existing implementations.

FHIR is the required standard for the ONC Cures Act patient access APIs. Every certified EHR must expose FHIR R4 APIs conforming to the US Core Implementation Guide. This regulatory mandate has accelerated FHIR adoption significantly since 2021. For implementation depth, see our FHIR R4 implementation guide and FHIR R4 vs R5 vs R6 comparison.

Key FHIR capabilities for EHR integration:

• SMART on FHIR: The authorization and launch framework for FHIR apps. Enables apps to launch from within EHRs, authenticate users, and access patient data using OAuth 2.0. See our SMART on FHIR Developer Guide for implementation details.
• Bulk Data ($export): The async operation for extracting large datasets (population health, payer data exchange, analytics).
• CDS Hooks: A standard for embedding clinical decision support into EHR workflows.
• Subscriptions: Event-driven notifications when FHIR resources change.

FHIR is ideal for new application development, patient-facing apps, and API-first architectures. It is less suited for high-throughput, real-time interfaces where HL7 v2 over MLLP remains more efficient.

CDA and C-CDA

Clinical Document Architecture (CDA) and Consolidated CDA (C-CDA) are XML-based document standards used for exchanging clinical summaries. The Continuity of Care Document (CCD) is the most common C-CDA template, used for care transitions, patient summaries, and health information exchange.

C-CDA is the standard format for:

• Transitions of care (hospital discharge summaries sent to primary care)
• Referral documents
• Public health reporting
• Patient record requests

While FHIR is gradually replacing CDA for new use cases, C-CDA remains the primary format for document-based exchange through health information exchanges (HIEs) and Direct messaging.

DICOM

DICOM (Digital Imaging and Communications in Medicine) is the standard for medical imaging data. It covers image storage, retrieval, and transmission between modalities (CT, MRI, X-ray, ultrasound), PACS systems, and diagnostic workstations. If your EHR integration involves radiology, cardiology, or any imaging workflow, DICOM is part of the picture. See our DICOM resource center and EHR and PACS Integration Guide for more detail.

X12 and EDI

For administrative and financial integrations — claims submission, eligibility verification, prior authorization, and remittance advice — the X12 EDI standard is used. These transactions are typically handled by clearinghouses, but some EHR integrations include direct EDI connections for revenue cycle workflows.

ONC Certification, USCDI, and TEFCA

EHR integration sits inside an active regulatory framework. Three pieces of the 2024–2026 regulatory layer materially affect what every certified EHR must expose and what new integrations must support.

HTI-1 + HTI-2 Final Rules. ONC’s HTI-1 Final Rule (May 2024) and HTI-2 (December 2024) update the ONC Health IT Certification Program — the 2024+ successor to the Cures Act Final Rule. Major changes: USCDI v3 became the minimum data set, predictive AI/Decision Support Intervention (DSI) certification criteria were introduced, and certified EHRs must support new FHIR Bulk Data API behaviors.

USCDI. The US Core Data for Interoperability (USCDI) is the minimum data set that certified EHRs must exchange. USCDI v3 is the 2026 regulatory floor — see our USCDI v7 new data elements post for the forward roadmap as ONC continues to expand the data set annually.

TEFCA. The Trusted Exchange Framework and Common Agreement has been operational since December 2023, with multiple Qualified Health Information Networks (QHINs) live and exchanging data nationally. TEFCA exchange is the federal mechanism for cross-network record retrieval — see our TEFCA integration guide for details. Major EHRs and HIEs are connecting to QHINs as either participants or sub-participants.

CMS-0057-F. Separate from ONC but linked to the same FHIR stack, the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires payers to expose Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs by January 2027.

Together, these regulations mean any new EHR integration you build in 2026+ should assume FHIR R4 + US Core v6.x or later + SMART on FHIR + Bulk Data $export as baseline capabilities.

Major EHR Platforms and Their Integration Capabilities

Each EHR platform has its own integration architecture, tools, and quirks. Here is what you need to know about the major platforms.

Epic

Epic holds the largest market share in the US acute-care market (~43.7% of acute-care hospital share, ~280 million patient records). Epic offers the most mature integration ecosystem of any EHR.

Integration pathways:

• FHIR R4 APIs: Comprehensive FHIR R4 support conforming to US Core. Epic’s FHIR APIs support read, search, create, and update operations across a wide range of resources. SMART on FHIR is the standard authorization model.
• Epic Showroom (formerly App Orchard, then App Market): Epic’s public directory for third-party apps and integrations, with apps registered through Epic Vendor Services. Publishing requires a thorough review process that typically takes several months. See our Epic integration guide for details.
• Bridges: Epic’s HL7 v2 interface engine for inbound and outbound messaging. Bridges configurations handle ADT, orders, results, scheduling, and other message types.
• Care Everywhere: Epic’s proprietary network for data exchange between Epic organizations, also supporting CommonWell and Carequality for cross-platform exchange.
• Interconnect: Epic’s web services layer for SOAP and REST API access beyond FHIR.

For more on Epic integration, see our Epic EHR Integration Guide and Epic Integration Services.

Oracle Health (Cerner)

Oracle Health (formerly Cerner, acquired by Oracle in 2022) is the second-largest EHR platform, particularly strong in large academic medical centers and federal healthcare (VA, DoD).

Integration pathways:

• Ignite APIs: Oracle Health’s FHIR R4 API platform, accessible through code.cerner.com (with content migrating into docs.oracle.com/en/industries/health/). DSTU2 was deprecated December 2025; FHIR R4 is mandatory for new integrations. Supports SMART on FHIR authorization.
• HL7 v2 interfaces: Millennium supports standard HL7 v2 messaging for ADT, orders, results, and scheduling.
• Open APIs: Additional RESTful APIs beyond FHIR for Millennium-specific functionality.
• Cerner Command Language (CCL): Oracle Health’s proprietary query language for direct database access and custom reporting.

Oracle’s ongoing migration from Millennium to Oracle Cloud Infrastructure (OCI) introduces new integration patterns — ambulatory EHR on OCI launched August 2025, and acute care follows in 2026. Organizations planning Oracle Health integrations should account for this transition in their architecture.

For details, see our Oracle Health Integration Services.

MEDITECH

MEDITECH serves 2,300+ healthcare organizations worldwide, with leading penetration in US community and critical access hospitals. MEDITECH Expanse is the current platform, with many organizations still running legacy platforms (6.x, C/S, MAGIC). The MEDITECH Cloud Platform delivers Expanse on Google Cloud.

Integration pathways:

• HL7 v2: The primary integration method for MEDITECH. ADT, ORM, ORU, and SIU interfaces are well-established.
• FHIR R4: MEDITECH Expanse supports FHIR R4 APIs through Greenfield Workspace (free developer sandbox at fhir.meditech.com), with coverage expanding in recent releases.
• BCA (Business and Clinical Analytics): MEDITECH’s data repository for reporting and analytics, accessible through ODBC/SQL queries.

MEDITECH integrations often require careful attention to the specific platform version, as capabilities and message formats differ significantly between Expanse, 6.x, and legacy platforms. See our MEDITECH Integration Services.

athenahealth

athenahealth is a cloud-native EHR serving primarily ambulatory and specialty practices, with 170,000+ clinicians on the athenaOne network.

Integration pathways:

• athenaOne API: A comprehensive REST API for clinical, financial, and administrative data. Uses OAuth 2.0 for authorization.
• Marketplace: athenahealth’s app marketplace for third-party integrations.
• HL7 v2: Standard HL7 v2 interfaces for lab results, ADT, and orders.
• FHIR R4: FHIR support through the athenaOne API, conforming to US Core.

As a cloud-native platform, athenahealth’s API-first architecture often makes integration more straightforward than with on-premise EHRs.

eClinicalWorks

eClinicalWorks is one of the largest cloud-based ambulatory EHRs, used by 180,000+ physicians and 850,000+ medical professionals (per eClinicalWorks, 2026). Integration primarily uses HL7 v2 interfaces, the healow platform for patient engagement and interoperability, and FHIR R4 + Bulk Data endpoints.

eClinicalWorks FHIR Bulk Data ($export)

eClinicalWorks exposes the standard FHIR R4 Bulk Data API at /fhir/r4/$export, including Patient-level, Group-level, and System-level export modes. This is the canonical mechanism for extracting large clinical datasets from eCW for population health, analytics, or migration projects.

The pattern follows the FHIR Bulk Data v3.0 specification:

1. Authorize. Client obtains an access token via SMART Backend Services (grant_type=client_credentials, JWK-signed assertion) — the standard for server-to-server access.
2. Kick off. Client POSTs to /fhir/r4/$export with Prefer: respond-async and optional _type (resource types) and _since (changed-since timestamp) parameters.
3. Accept. The server returns 202 Accepted with a Content-Location polling URL.
4. Poll. Client polls the status URL until the job completes (typically minutes for moderate exports).
5. Download. The server returns a JSON manifest with NDJSON file URLs — one file per resource type — that the client downloads and processes.

For the broader FHIR Bulk Data pattern, see our FHIR R4 implementation guide. For the regulatory backdrop driving widespread $export adoption, see CMS-0057-F.

See our eClinicalWorks Integration Services for hands-on engineering support.

NextGen + Veradigm

NextGen Healthcare serves specialty and ambulatory practices with both NextGen Enterprise and NextGen Office. HL7 v2 is the primary interface method, with FHIR R4 support expanding. (NextGen also owns Mirth Connect — see below.)

Veradigm (rebranded from Allscripts in January 2023) serves a similar ambulatory + specialty market with HL7 v2 + FHIR R4 endpoints.

See our Allscripts/Veradigm Integration Services.

Common Integration Patterns

Regardless of the EHR platform, most integrations follow a small number of well-established patterns.

ADT Feeds (Registration and Census)

ADT (Admit/Discharge/Transfer) interfaces are the foundation of most integration architectures. When a patient is registered, admitted, transferred, or discharged, the EHR sends an ADT message to downstream systems. This ensures that patient demographics, locations, and visit information stay synchronized across the organization.

ADT feeds are consumed by: lab systems, radiology, pharmacy, billing, bed management, nurse call systems, patient tracking boards, and third-party analytics platforms. Getting ADT right is critical because errors cascade to every downstream system.

Lab Orders and Results

The orders-results cycle is the second most common integration pattern. The EHR sends orders (ORM or OML messages) to the laboratory information system, and the LIS returns results (ORU messages) to the EHR. This interface must handle:

• Order placements, modifications, and cancellations
• Preliminary, final, and corrected results
• Discrete results (individual lab values) and narrative results (text reports)
• Reference ranges and abnormal flags

Document Exchange

Clinical documents (discharge summaries, consultation notes, pathology reports, operative notes) are exchanged using MDM messages (HL7 v2) or C-CDA documents (via Direct messaging or HIE networks). FHIR DocumentReference resources provide a modern API-based approach to document exchange.

Real-Time vs Batch

Most clinical interfaces are real-time: the EHR sends a message as soon as an event occurs, and the receiving system processes it within seconds. Some integration patterns are better suited to batch processing: bulk data exports, analytics data feeds, claims submission, and population health reporting.

FHIR Bulk Data ($export) is the modern approach to batch extraction, replacing legacy flat-file exports and custom database queries.

Integration Architecture

Integration Engines

An integration engine sits at the center of most healthcare integration architectures, acting as a message broker, transformer, and router. Rather than building point-to-point connections between every system pair, all messages flow through the engine where they can be transformed, filtered, routed, and monitored.

Mirth Connect (now commercial under NextGen Healthcare; first commercial-only release was Mirth Connect 4.6 mid-2025, with two MPL 2.0 community forks — Open Integration Engine (OIE) and BridgeLink by Innovar Healthcare — continuing from v4.5.2) is among the most widely used healthcare integration engine families. See our OIE vs BridgeLink vs Commercial Mirth Connect comparison for the full ecosystem.

Other integration engines in the healthcare space include Rhapsody (Rhapsody Health Solutions), Cloverleaf (Infor), and Microsoft Azure Health Data Services.

Point-to-Point vs Hub-and-Spoke

Point-to-point connections are simple: system A connects directly to system B. This works for a small number of interfaces, but quickly becomes unmanageable as the number of systems grows. Ten systems with point-to-point connections require up to 45 individual interfaces.

Hub-and-spoke architecture routes all interfaces through a central integration engine. Each system connects to the engine once, and the engine handles message transformation and routing. This reduces the number of connections, centralizes monitoring, and simplifies maintenance. This is the standard architecture for healthcare organizations with more than a handful of interfaces.

Cloud vs On-Premise

Historically, integration engines ran on-premise within the hospital’s data center, close to the EHR. Cloud-hosted integration is increasingly common, driven by:

• Cloud-native EHRs (athenahealth, some MEDITECH Expanse deployments)
• Third-party vendors needing to connect to multiple health system EHRs
• FHIR API integrations that use internet-facing endpoints
• Cost and operational advantages of cloud infrastructure

For cloud-hosted integrations, VPN tunnels or dedicated network connections provide secure connectivity back to on-premise EHR systems. See our healthcare cloud migration guide for AWS / Azure / GCP comparison, and our Healthcare Cloud Security practice for architecture support.

Security and Compliance

Every EHR integration that touches patient data must comply with HIPAA. This is non-negotiable.

HIPAA Requirements for Integrations

• Business Associate Agreement (BAA): Any third-party vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity must have a BAA in place before data flows. See our HIPAA BAA Checklist.
• Encryption in transit: All data must be encrypted during transmission. For HL7 v2, this means TLS-wrapped MLLP connections (MLLP/S). For FHIR and REST APIs, HTTPS (TLS 1.2+) is required. For DICOM, TLS-wrapped DICOM connections are recommended.
• Encryption at rest: PHI stored in databases, message queues, file systems, or logs must be encrypted.
• Access controls: Role-based access to integration engine consoles, FHIR API scopes, and HL7 v2 interface configurations.
• Audit logging: All access to PHI must be logged, including message processing events, API calls, and administrative actions.

For comprehensive HIPAA compliance guidance, see our HIPAA Compliance Services and HIPAA-Compliant Software Development guide.

Authentication and Authorization

• SMART on FHIR / OAuth 2.0: The standard for FHIR API access. Uses access tokens with scoped permissions.
• Mutual TLS (mTLS): Client certificate authentication for system-to-system connections, common for HL7 v2 and DICOM interfaces.
• API keys: Simple but less secure. Some EHR APIs use API keys for non-PHI endpoints.
• VPN with IP whitelisting: Network-level security for on-premise integrations.

Build vs Buy vs Hire

Organizations approaching EHR integration face a fundamental question: build the integration team internally, buy an integration platform, or hire specialists.

Approach	Best for	Cost profile	Time to first interface	Ongoing burden
Build internally	Large, stable interface portfolio (50+ interfaces); existing HL7/FHIR expertise	High up-front + ongoing FTE	3-6 months	High — 24/7 ops
iPaaS platform	Small number of cloud-based integrations; minimal customization	Per-transaction + subscription	1-2 months	Low — vendor-managed
Hire specialists	Complex / high-stakes integrations; lack of internal expertise; accelerated timeline	Project-based	4-12 weeks	Low — hand-off to internal

Build internally when you have a large, stable interface portfolio, experienced integration engineers on staff, and the operational capacity to manage an integration engine 24/7. Health systems with 50+ interfaces often have dedicated integration teams.

Use an integration platform (iPaaS) when you need to connect a small number of cloud-based systems with minimal customization. Platforms like Redox, Health Gorilla, and Particle Health abstract away protocol-level complexity but add per-transaction costs and reduce control.

Hire integration specialists when you need deep expertise for complex or high-stakes integrations, lack internal HL7/FHIR expertise, or need to accelerate a project timeline. This is where Saga IT’s EHR integration services provide value — our engineers bring cross-platform experience across Epic, Oracle Health, MEDITECH, athenahealth, eClinicalWorks, NextGen, and Veradigm.

Frequently Asked Questions

What is EHR integration?

EHR integration is the engineering practice of moving clinical, administrative, and financial data into and out of an electronic health record system in a structured, secure, and auditable way. The mechanics typically combine HL7 v2 messaging (for real-time clinical events like ADT, orders, results), FHIR R4 REST APIs (for app integration and bulk data exchange), C-CDA documents (for transitions of care), DICOM (for imaging), and X12 EDI (for claims). The integration is usually mediated by an integration engine like Mirth Connect, OIE, BridgeLink, or Rhapsody.

What's the difference between EHR and EMR integration?

Technically, an EMR (Electronic Medical Record) is a single-organization chart while an EHR (Electronic Health Record) is designed to exchange data across organizations. In practice, the integration mechanics are identical: HL7 v2, FHIR R4, C-CDA, and the same EHR vendors (Epic, Oracle Health, MEDITECH, athenahealth, eClinicalWorks, etc.) ship both labels. Search engines treat the terms as synonyms.

How long does EHR integration take?

A first interface to a new EHR partner runs 8-16 weeks from kickoff to production. The bulk is process — security review, BAA execution, network firewall changes, EHR analyst coordination, and clinical validation — not engineering. Once a vendor has a repeatable pattern (FHIR endpoint registration, VPN template, channel definitions in the integration engine), subsequent sites can drop to 4-6 weeks. EHR-vendor-specific certifications (Epic Showroom, Oracle Health Developer Program) add additional review months on top.

Do I need HL7 v2 if my EHR has FHIR APIs?

Often, yes. FHIR R4 is excellent for app-style and bulk-data workloads — patient portals, third-party apps, population health exports. But for high-throughput, low-latency clinical event streams — ADT, orders, results — HL7 v2 remains the more efficient protocol with the broader install base. Most large integrations use FHIR for new app surface and HL7 v2 for the existing message rails. Modern integration engines speak both.

Which EHRs support FHIR Bulk Data ($export)?

All ONC-certified EHRs support FHIR R4 Bulk Data $export as part of the §170.315(g)(10) Standardized API certification criterion. Epic, Oracle Health, MEDITECH, athenahealth, eClinicalWorks, NextGen, and Veradigm all expose $export endpoints, though the supported export levels (Patient, Group, System) and parameter handling (_type, _since, _typeFilter) vary. Always test against the specific EHR’s developer sandbox before assuming behavior.

Is FHIR R4 required by law?

For ONC-certified EHRs in the US, yes — the §170.315(g)(10) Standardized API certification criterion requires FHIR R4 + US Core + SMART on FHIR as a condition of certification. CMS’s interoperability rules (CMS-0057-F) extend the FHIR R4 + US Core requirements to payers. Outside the US, FHIR R4 is widely adopted by national programs but not always legally mandated.

What does EHR integration cost?

A first production interface to a new EHR partner typically runs $30K–$150K depending on complexity, vendor-side fees, and integration engine licensing. Recurring costs include the integration engine subscription (or open-source ops cost), interface monitoring, and ongoing maintenance — budget 15-20% of initial build cost per year for maintenance. Vendor-specific app marketplace fees (Epic Showroom, Oracle Health) are separate. See our healthcare app development cost guide for the broader cost picture.

---

EHR integration is complex, but it follows established patterns. The standards are mature, the platforms are well-documented, and the architectural patterns are proven. The key is choosing the right approach for your use case and executing it with attention to security, reliability, and the specific quirks of your target EHR platform.

For help with your EHR integration project, explore our related services and resources:

• EHR Integration Services — Multi-platform EHR integration engineering
• Epic Integration Services — Epic FHIR, Showroom, and Bridges
• Oracle Health Integration — Ignite APIs, CCL, Millennium migration to OCI
• eClinicalWorks Integration — HL7 v2, FHIR, healow, $export
• FHIR API Integration — FHIR R4 development and US Core compliance
• HL7 Integration — ADT, ORM, ORU, and SIU interface development
• Mirth Connect Services — Integration engine implementation and support
• TEFCA Integration Guide — QHIN exchange + Common Agreement
• SMART on FHIR Developer Guide — Authorization and app development
• HL7 vs FHIR: When to Use Which — Standards comparison
• USCDI v7 New Data Elements — Latest USCDI update