Healthcare Integration Guide: HL7, FHIR & Mirth Connect

Key Takeaways:

Healthcare integration is the technical process of connecting disparate clinical systems — EHRs, lab systems, pharmacy networks, billing platforms, medical devices — so they can exchange patient data in real time. Without it, providers work with incomplete information and patients repeat the same data at every touchpoint.
HL7v2 remains the most widely deployed healthcare messaging standard, used by the vast majority of US hospitals for real-time ADT, order, result, and scheduling messages. Despite being decades old, it will remain in production for years because of the massive installed base.
FHIR R4 is the modern regulatory standard mandated by ONC for certified health IT. It uses RESTful APIs and JSON/XML resources, supports SMART on FHIR for third-party app authorization, and is required for patient-facing data access under the 21st Century Cures Act.
Mirth Connect (now Mirth® Connect by NextGen Healthcare) powers one-third of all public Health Information Exchanges in the US and is deployed in over 40 countries. As of version 4.6 (2025), it has transitioned to a commercial licensing model — new releases require an enterprise license.
The Trusted Exchange Framework and Common Agreement (TEFCA), finalized in December 2024, requires qualified health information networks to support HL7 FHIR APIs, creating additional regulatory pressure for organizations to adopt modern interoperability standards.

Why Healthcare Integration Matters

Healthcare organizations operate dozens of disconnected systems — electronic health records, laboratory information systems, pharmacy platforms, radiology PACS, billing engines, patient portals, and increasingly, mobile health applications and IoT devices. Without integration, data lives in silos. A physician cannot see lab results ordered through a different system. A patient repeats their medical history at every visit. Billing teams manually re-enter data from clinical notes. Discharge summaries never reach the primary care provider.

The cost of this fragmentation is measured in patient safety incidents, duplicated tests, delayed diagnoses, and administrative waste. Studies consistently show that poor interoperability contributes to 30–40% of administrative healthcare spending in the United States.

Integration solves this by enabling systems to exchange structured data in real time using standardized protocols. When done correctly, a lab order placed in the EHR automatically reaches the lab system, results flow back into the patient’s chart, the billing system captures the appropriate codes, and the patient sees their results in the portal — all without manual intervention.

For organizations building or buying healthcare software, integration is not a feature — it is an architectural requirement. The healthcare software development process must account for integration from the discovery phase, not as an afterthought.

Healthcare Integration Standards: HL7v2 vs FHIR vs CDA

Three primary standards dominate healthcare data exchange. Understanding their differences, strengths, and appropriate use cases is essential for making the right architecture decisions.

Aspect	HL7v2	FHIR R4	CDA (C-CDA)
Year Introduced	1987	2014 (R4: 2019)	2005
Data Format	Pipe-delimited text (	)	JSON or XML
Transport Protocol	TCP/MLLP	HTTP/REST	File exchange, XDS
Architecture	Message-based (event-driven)	API-based (RESTful)	Document-based
Primary Use	Real-time clinical events	App integration, patient access	Clinical document exchange
Adoption	~95% of US hospitals	Growing rapidly (ONC mandate)	Widely used for transitions of care
Regulatory Status	Industry standard	ONC-mandated for certified HIT	Required for Meaningful Use
Learning Curve	Moderate (complex message structures)	Lower (web-developer-friendly)	High (XML-heavy, complex templates)
Best For	Legacy system interfaces, ADT, orders, results	Modern app development, patient APIs, SMART apps	Summary documents, care transitions

The practical reality is that most healthcare organizations need all three. HL7v2 handles the high-volume real-time messaging between established clinical systems. FHIR powers modern applications, patient-facing APIs, and third-party integrations. CDA documents handle transitions of care, discharge summaries, and other clinical document exchange.

HL7v2 Messaging: ADT, ORM, ORU, SIU Message Types

HL7 Version 2 is a pipe-delimited messaging standard designed for real-time event-driven communication between healthcare systems. Despite its age, it handles the majority of all healthcare data exchange in the United States today.

How HL7v2 Messages Work

An HL7v2 message is triggered by a clinical event — a patient is admitted, an order is placed, a result is finalized. The sending system generates a structured message, transmits it over a TCP/MLLP connection, and the receiving system acknowledges receipt with an ACK message.

Every HL7v2 message consists of segments (MSH, PID, PV1, OBR, OBX, etc.), each containing fields separated by pipe characters. The MSH (Message Header) segment identifies the message type, sending and receiving applications, and timestamp. The PID (Patient Identification) segment contains demographics. Subsequent segments carry the clinical payload.

Common HL7v2 Message Types

ADT (Admission, Discharge, Transfer) — The most common HL7v2 message family. ADT messages notify downstream systems of patient movement events: A01 (admit), A02 (transfer), A03 (discharge), A04 (register), A08 (update patient information). These drive bed management, census tracking, and downstream clinical workflows.

ORM (Order Messages) — Generated when a clinician places an order (lab test, imaging study, procedure). The ORM message contains the order details, patient identification, and ordering provider information. It flows from the EHR to the receiving system (lab, radiology) to initiate fulfillment.

ORU (Observation Result) — The return path for ORM. When a lab completes a test or a radiologist finalizes a report, an ORU message carrying the results flows back to the ordering system. ORU messages populate the results tab in the EHR and trigger clinical alerts.

SIU (Scheduling) — Manages appointment creation, modification, and cancellation across scheduling systems. SIU messages synchronize appointment data between the EHR, patient portal, and departmental scheduling applications.

MDM (Medical Document Management) — Handles clinical document notifications, including transcribed reports, clinical notes, and discharge summaries.

HL7v2 Implementation Considerations

HL7v2’s primary challenge is variation. The standard is intentionally flexible, which means every implementation is slightly different. Two hospitals may both send ADT A01 messages, but the field mappings, segment usage, and optional fields will differ. This is why integration engines like Mirth Connect exist — to handle the transformation and routing logic that bridges these differences.

FHIR Deep Dive: Resources, APIs, SMART on FHIR

FHIR (Fast Healthcare Interoperability Resources) represents a fundamental architectural shift from message-based to API-based healthcare data exchange. Developed by HL7 International, FHIR leverages modern web technologies that any developer with REST API experience can work with.

FHIR Resources

The basic building block in FHIR is a Resource — a discrete, self-contained unit of healthcare data. FHIR R4 defines over 140 resource types covering clinical, administrative, and infrastructure domains. The most commonly used resources include Patient (demographics, identifiers), Encounter (visit/admission data), Observation (vitals, lab results, clinical findings), Condition (diagnoses, problems), MedicationRequest (prescriptions, orders), Procedure (surgical and clinical procedures), DiagnosticReport (lab reports, imaging reports), AllergyIntolerance (allergy and adverse reaction records), and DocumentReference (clinical documents, attachments).

Each resource has a defined structure, is accessible via a RESTful API endpoint, and can be represented in JSON or XML.

FHIR REST API Operations

FHIR uses standard HTTP operations for data access: GET retrieves resources (read a patient record, search for observations), POST creates new resources, PUT updates existing resources, DELETE removes resources, and PATCH applies partial updates.

Search operations support complex queries using chained parameters, includes, and reverse includes. For example, retrieving a patient’s complete medication list with prescriber details can be accomplished in a single API call using _include parameters.

SMART on FHIR

SMART (Substitutable Medical Applications, Reusable Technologies) on FHIR is the authorization framework that enables third-party applications to launch from within an EHR and securely access patient data. It combines FHIR for data access with OAuth 2.0 for authorization.

SMART on FHIR supports two launch modes. EHR Launch is where the app launches from within the EHR context (the user is already authenticated, the patient is already selected). Standalone Launch is where the app launches independently and authenticates against the FHIR server.

SMART on FHIR is the regulatory standard for third-party app authorization. ONC requires certified EHRs to support SMART on FHIR for patient-facing and provider-facing applications. Taction builds FHIR API integrations and SMART on FHIR applications that meet ONC certification requirements.

CDS Hooks

CDS Hooks is a companion standard that enables clinical decision support services to integrate with EHR workflows. When a clinician performs a specific action (opening a patient chart, prescribing a medication, ordering a lab test), the EHR calls a CDS service endpoint, which returns recommendations displayed as information cards within the EHR interface. CDS Hooks combined with FHIR enables externalized clinical logic that works across multiple EHR platforms.

Bulk Data Access

FHIR Bulk Data Access (the “Flat FHIR” specification) enables population-level data export for analytics, quality reporting, and research. Instead of querying individual patient records, Bulk Data operations export large datasets asynchronously in NDJSON format. This is critical for population health management, clinical quality measure (CQM) reporting, and health plan data exchange.

For a hands-on implementation guide with code examples, see our blog post on HL7 FHIR Integration Tutorial.

Mirth Connect: Architecture, Channel Configuration, Best Practices

Mirth Connect (now Mirth® Connect by NextGen Healthcare) is the most widely used healthcare integration engine, powering one-third of all public Health Information Exchanges in the US with deployments in over 40 countries. It serves as the central hub for healthcare data routing, transformation, and delivery.

What Mirth Connect Does

Mirth Connect acts as a translator and traffic director for healthcare data. It receives messages from source systems, transforms them into the format required by destination systems, applies routing logic to determine where each message goes, and delivers the transformed data to the correct endpoints. It supports HL7 v2/v3, FHIR, DICOM, CCD/C-CDA, X12, XML, JSON, and more, across protocols including TCP/MLLP, HTTP/S, file polling, JDBC (database), SFTP, and web services.

Channel Architecture

Mirth Connect organizes integration logic into channels. Each channel has a source connector (where data comes in), one or more filters (which messages to process), one or more transformers (how to modify the data), and one or more destination connectors (where to send the output).

A typical healthcare integration environment may have dozens or hundreds of channels handling different data flows — ADT messages from the EHR to the lab system, results from the lab back to the EHR, discharge summaries to the HIE, appointment data to the patient portal, and so on.

The 2025/2026 Licensing Change

As of version 4.6 (released 2025), Mirth Connect has transitioned from open-source to a fully commercial licensing model. New releases require an enterprise license from NextGen Healthcare. The source code for version 4.6+ is no longer publicly available. Organizations running earlier open-source versions can continue to use them but will not receive updates. This licensing change has prompted the emergence of open-source alternatives including Open Integration Engine (OIE) and BridgeLink, though neither has yet achieved the maturity or community size of Mirth Connect.

For organizations that depend on Mirth Connect, the licensing change means three options: purchase a NextGen enterprise license, remain on the legacy open-source version (with the understanding that it will not receive security updates or new features), or evaluate alternative integration engines.

Mirth Connect Best Practices

Channel naming conventions — Use consistent, descriptive names that indicate source, destination, and data type (e.g., “EHR_to_Lab_ORM_Orders” or “Lab_to_EHR_ORU_Results”).

Error handling — Configure channel error queues, implement automatic retry logic for transient failures, and set up alerting for persistent errors. Every failed message must be captured, not silently dropped.

Message transformation — Use Mirth’s built-in JavaScript engine for complex transformations. Keep transformation logic modular — extract reusable functions into code templates.

Monitoring — Implement centralized logging and dashboard monitoring. The new Mirth Command Center (available with enterprise licenses) provides channel analytics, performance metrics, and centralized monitoring. For self-hosted installations, integrate with ELK Stack, Grafana, or Datadog.

Security — Enable TLS on all connectors, implement certificate-based authentication for inter-system communication, and ensure all channels handling PHI are configured with appropriate access controls and audit logging.

Taction Software provides Mirth Connect development, migration, and optimization services for organizations at every stage of their integration maturity.

EHR Integration: Epic, Oracle Health, Allscripts, athenahealth

Integrating with electronic health record platforms is the most common and often most complex healthcare integration requirement. Each major EHR vendor has its own integration approach, API ecosystem, and certification process.

Epic

Epic is the largest EHR vendor in the US, installed in the majority of large health systems. Epic offers integration through Open Epic (public FHIR R4 APIs for patient-facing and provider-facing applications), Epic App Orchard / Showroom (marketplace for approved third-party apps), HL7v2 interfaces (for traditional ADT, order, and result messaging), and Epic’s proprietary web services.

Developing apps for Epic requires registration with Epic’s developer program, development against their sandbox environment, and submission through App Orchard/Showroom for marketplace listing. Epic’s FHIR support is comprehensive and is generally considered the most mature among major EHR vendors.

Oracle Health (Cerner)

Oracle Health (formerly Cerner) provides integration through the Millennium FHIR API (R4-compliant), HL7v2 interfaces, CareAware integration platform, and Oracle Health’s Ignite APIs. Oracle Health’s FHIR implementation is solid and continues to expand resource coverage. Their platform benefits from Oracle’s broader cloud and database ecosystem.

Allscripts

Allscripts offers FHIR APIs, the Allscripts Developer Program, HL7v2 interfaces, and Unity API for deeper integration. Allscripts’ integration landscape is more fragmented due to multiple product lines (Sunrise, TouchWorks, Professional EHR), each with different integration capabilities.

athenahealth

athenahealth provides integration through the athenahealth Marketplace (certified third-party integrations), FHIR R4 APIs, HL7v2 interfaces, and a RESTful proprietary API (athenaNet). As a cloud-native platform, athenahealth’s API-first architecture generally makes integration more straightforward than legacy on-premises EHRs.

For a detailed implementation guide specific to Epic integration, see our blog post on Epic EHR Integration: APIs, FHIR & Best Practices.

Integration Architecture Patterns

Healthcare integration architectures follow several common patterns, each suited to different organizational contexts.

Point-to-Point

The simplest pattern: System A connects directly to System B. Works for small environments with few systems but becomes unmanageable as the number of systems grows (N systems require up to N×(N-1)/2 connections). Avoid for any organization with more than 3–4 systems that need to exchange data.

Hub-and-Spoke (Integration Engine)

The most common pattern in healthcare. An integration engine (Mirth Connect, Rhapsody, InterSystems HealthShare) sits at the center, and all systems connect to the hub. The engine handles transformation, routing, and delivery. This reduces the connection count from N×(N-1)/2 to just N and centralizes all integration logic in one place.

Enterprise Service Bus (ESB)

A more sophisticated pattern that adds service orchestration, complex event processing, and workflow management on top of basic message routing. Appropriate for large health systems with complex multi-step workflows that span multiple systems.

Event-Driven Architecture

Systems publish events to a message broker (Apache Kafka, RabbitMQ) and interested systems subscribe to relevant event streams. This pattern supports real-time analytics, audit trails, and loosely coupled system integration. Increasingly popular for connecting modern microservices-based healthcare applications with legacy systems.

API Gateway Pattern

For FHIR-based integrations, an API gateway sits between consuming applications and backend FHIR servers, handling authentication, rate limiting, request routing, and response transformation. This is the standard pattern for exposing FHIR APIs to third-party applications and patient-facing apps.

ONC Interoperability Rules and Information Blocking

The regulatory landscape for healthcare interoperability has shifted dramatically. The 21st Century Cures Act and subsequent ONC rulemaking have created mandatory interoperability requirements that directly affect every healthcare software development project.

The 21st Century Cures Act

The Cures Act prohibits information blocking — practices that unreasonably restrict the access, exchange, or use of electronic health information (EHI). As of October 2022, this prohibition applies to the full scope of EHI (not just the limited USCDI dataset).

ONC Health IT Certification

Certified health IT must support standardized API access using FHIR R4, patient access APIs that enable individuals to access their complete EHI through third-party applications, and provider directory APIs for care coordination. Mirth Connect has received ONC Health IT Cures Update Certification, confirming its compliance with these requirements.

TEFCA (Trusted Exchange Framework and Common Agreement)

TEFCA, finalized in December 2024, establishes a nationwide framework for health information exchange. Qualified Health Information Networks (QHINs) participating in TEFCA must support HL7 FHIR APIs by the mandated timeline. TEFCA creates additional regulatory pressure for organizations to adopt FHIR-based interoperability capabilities.

What This Means for Development Teams

Every healthcare software application should be built with FHIR R4 support as a baseline, not an optional feature. Patient-facing applications must provide access to the complete USCDI dataset. Any practice that restricts data access — including onerous API terms, unreasonable fees, or technical barriers — may constitute information blocking and trigger enforcement action.

For a broader explanation of these regulatory requirements, see our blog on Healthcare Interoperability Explained.

Testing and Validation

Healthcare integration testing must be thorough and systematic because errors in data exchange can directly affect patient safety.

Unit Testing

Test individual transformation logic, message parsing, and routing rules in isolation. Mirth Connect supports channel-level testing through its built-in message sender and channel debugging tools.

Integration Testing

End-to-end testing of message flows between connected systems. This requires test environments that replicate production connectivity. For EHR integrations, vendors typically provide sandbox environments (Epic’s sandbox, Oracle Health’s test environment) for development and testing.

Conformance Testing

Validate that your HL7v2 messages conform to the agreed-upon message specifications and that your FHIR resources comply with the relevant implementation guides (US Core, USCDI, QI-Core). Tools include the HL7 FHIR Validator, Touchstone (FHIR testing platform), and vendor-specific conformance testing tools.

Load and Performance Testing

Simulate production-level message volumes to identify bottlenecks. Healthcare integration engines may handle thousands of messages per minute — ensure your infrastructure can sustain peak loads without message loss or unacceptable latency.

Negative Testing

Test error scenarios: malformed messages, network timeouts, duplicate messages, out-of-order delivery, and system outages. Your integration architecture must handle all failure modes gracefully — no message should be silently lost.

Common Integration Challenges and Solutions

Challenge: HL7v2 Variation Across Sites

Problem: Every hospital implements HL7v2 slightly differently. Field mappings, segment usage, and optional elements vary between installations. Solution: Develop a comprehensive interface specification for each connection. Use Mirth Connect’s transformation engine to normalize incoming messages to your internal canonical format before processing.

Challenge: FHIR Implementation Maturity

Problem: While FHIR R4 is the standard, not all EHR vendors have implemented all resource types, and implementation quality varies. Solution: Test against each specific EHR’s FHIR sandbox before making architectural commitments. Build fallback mechanisms that can use HL7v2 interfaces when FHIR endpoints are not yet available for specific data types.

Challenge: Real-Time vs Batch Processing

Problem: Some systems require real-time data exchange while others work on batch schedules. Solution: Use an integration engine that supports both paradigms. Mirth Connect handles real-time TCP/MLLP messaging and scheduled file-based or database-polling batch operations within the same platform.

Challenge: Data Quality and Mapping

Problem: Source systems may contain incomplete, inconsistent, or incorrectly formatted data. Solution: Implement validation rules in your integration engine that catch and flag data quality issues. Build error queues for messages that fail validation, with alerting to integration teams for manual review.

Challenge: Security and Compliance

Problem: All healthcare data exchange must be encrypted, audited, and compliant with HIPAA requirements. Solution: Enable TLS on all connectors, implement certificate-based mutual authentication, log all message transactions with tamper-proof audit trails, and ensure all integration infrastructure is covered under BAAs.

CTA: Get a Free Integration Architecture Assessment Not sure how to connect your healthcare application to existing EHR platforms? Schedule a free 30-minute consultation with our integration architects. We will assess your current environment, map your data flows, and recommend the right integration strategy. Schedule Free Assessment →

Related Resources:

Frequently Asked Questions

Q: What is the difference between HL7v2 and FHIR?

HL7v2 is a message-based standard using pipe-delimited text transmitted over TCP/MLLP, designed for real-time event notifications between clinical systems. FHIR is an API-based standard using JSON/XML over HTTP/REST, designed for modern application integration and patient data access. Most healthcare organizations need both — HL7v2 for legacy system interfaces and FHIR for modern applications and regulatory compliance.

Q: What is Mirth Connect used for?

Mirth Connect is a healthcare integration engine that routes, transforms, and manages data flows between disparate healthcare systems. It translates between different data formats (HL7v2, FHIR, CDA, X12, DICOM) and protocols (TCP/MLLP, HTTP, SFTP, JDBC), enabling systems that speak different languages to exchange data seamlessly. It powers one-third of all public Health Information Exchanges in the US.

Q: Is Mirth Connect still open source?

As of version 4.6 (2025), Mirth Connect has transitioned to a commercial licensing model. New releases require an enterprise license from NextGen Healthcare. Earlier open-source versions remain available but will not receive updates. Open-source alternatives like Open Integration Engine (OIE) and BridgeLink have emerged but are less mature.

Q: What is SMART on FHIR?

SMART on FHIR is an authorization framework that enables third-party applications to launch from within an EHR and securely access patient data. It combines FHIR for data access with OAuth 2.0 for authorization. ONC requires certified EHRs to support SMART on FHIR, making it the regulatory standard for healthcare app authorization.

Q: How do I integrate with Epic EHR?

Epic offers integration through Open Epic (public FHIR R4 APIs), the App Orchard/Showroom marketplace, and traditional HL7v2 interfaces. Development requires registration with Epic’s developer program, building against their sandbox, and certification through App Orchard if you plan to distribute your application to Epic customers. See our Epic EHR Integration Guide for detailed steps.

Q: What is TEFCA and how does it affect my integration strategy?

TEFCA (Trusted Exchange Framework and Common Agreement) is a nationwide framework for health information exchange finalized in December 2024. It requires participating health information networks to support FHIR APIs, creating regulatory momentum toward FHIR adoption. If your organization exchanges data with other health systems, TEFCA compliance will increasingly become a requirement.