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.
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. Approximately 95% of US hospitals use HL7 v2 for some or all of their clinical interfaces. Messages use a pipe-delimited format (|) transmitted over TCP connections using MLLP (Minimal Lower Layer Protocol).
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 (Laboratory Information Systems) and RIS (Radiology Information Systems).
- 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.
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.
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: The $export 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.
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, serving over 300 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 App Market (formerly App Orchard): The marketplace for third-party SMART on FHIR applications. 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. 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 Health Cloud introduces new integration patterns. Organizations planning Oracle Health integrations should account for this transition in their architecture.
For details, see our Oracle Health Integration Services.
MEDITECH
MEDITECH serves over 2,300 community and critical access hospitals, primarily in the US and Canada. MEDITECH Expanse is the current platform, with many organizations still running legacy platforms (6.x, C/S, MAGIC).
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 the Greenfield platform, 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 over 160,000 providers on the athenaOne platform.
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. See our athenahealth Integration Services.
eClinicalWorks and NextGen
eClinicalWorks is the largest ambulatory EHR, used by over 150,000 physicians. Integration primarily uses HL7 v2 interfaces and the healow platform for patient engagement and interoperability.
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.
See our eClinicalWorks and NextGen 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 (and its open-source fork, Open Integration Engine) is the most widely used healthcare integration engine. It supports HL7 v2, FHIR, DICOM, X12, and custom message formats with a visual channel-based design. Other integration engines in the healthcare space include Rhapsody, Cloverleaf (Infor), and Microsoft Azure Health Data Services.
For Mirth Connect best practices, see our Mirth Connect Best Practices Guide and Mirth Connect Resource Center.
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. Our Healthcare Cloud Security team can help architect these connections securely.
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 for what to include.
- 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.
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.
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, and more.
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, App Market, and Bridges
- 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
- How to Integrate with Epic EHR --- Technical deep dive
- SMART on FHIR Developer Guide --- Authorization and app development
- HL7 vs FHIR: When to Use Which --- Standards comparison