EHR integration with HL7/FHIR

What EHR integration with HL7/FHIR actually involves

Successful ehr integration with hl7/fhir connects clinical workflows, not just endpoints. An appointment booked in an external application must reach the correct scheduling context; a laboratory result must attach to the correct patient and order; an AI-generated summary must preserve provenance and follow the organization’s approval workflow. The challenge is making these exchanges reliable, secure, and clinically meaningful across systems that implement standards differently.

For decision-makers, the key questions are which workflows the EHR actually supports, what access requires, and who owns failures. For practitioners, the work includes interface configuration, identity matching, terminology mapping, authentication, reconciliation, and operational monitoring.

This MyDiscussions guide explains how to choose between HL7 v2 and FHIR, build a workable architecture, and validate an integration before it handles production clinical data.

Understand the roles of HL7 v2 and FHIR

HL7 is a standards organization, not one interface format. In everyday integration discussions, “HL7” often means HL7 version 2 messaging, while FHIR refers to the newer resource-based interoperability standard.

HL7 v2: event-driven clinical messaging

HL7 v2 commonly carries admission, discharge, and transfer events; orders; results; and scheduling messages. Typical message families include:

• ADT: Patient registration and encounter updates.
• ORM or specialized order messages: Order-related workflows.
• ORU: Observation and diagnostic result reporting.
• SIU: Scheduling notifications.

Messages are often transmitted over Minimal Lower Layer Protocol, or MLLP. MLLP provides message framing, not encryption; secure transport requires an additional protected channel.

HL7 v2 is established in hospitals, but local variations matter. Optional fields, custom Z-segments, identifier conventions, and acknowledgment behavior frequently differ between facilities.

FHIR: resources, APIs, and implementation guides

FHIR models healthcare information as resources such as Patient, Encounter, Observation, DiagnosticReport, and MedicationRequest. Many implementations expose these resources through REST APIs.

FHIR simplifies application development, but it does not eliminate interpretation. A conformant server may support only selected resources, searches, profiles, and operations. Read access does not imply write access.

Start with the server’s CapabilityStatement, then verify vendor documentation and actual behavior. The official HL7 FHIR documentation defines the standard; your implementation must additionally follow the release, profiles, and implementation guides required by the target environment.

Pin the supported FHIR version explicitly. Do not assume examples from the latest published specification match a vendor endpoint.

Choose an interface based on the workflow

The best choice is often a hybrid architecture rather than an HL7 v2-to-FHIR replacement program.

Three criteria should drive the decision:

• Workflow coverage: Can the interface perform the complete business action, including corrections and cancellations?
• Operational behavior: Does it support the required latency, replay, reconciliation, and failure handling?
• Access feasibility: Will the health system and vendor enable the interface under acceptable contractual and security conditions?

A standards-based endpoint that cannot complete the required workflow is not a viable substitute for a supported proprietary API.

Design the integration architecture

Separate transport, clinical meaning, and application logic

A maintainable architecture typically has four layers:

1. Connectivity: MLLP listeners, HTTPS clients, OAuth flows, certificates, and network controls.
2. Normalization: Parsing, profile validation, terminology translation, and identifier handling.
3. Workflow orchestration: Routing, state transitions, approvals, retries, and reconciliation.
4. Application services: Clinician interfaces, analytics, patient applications, or approved AI workflows.

Avoid embedding hospital-specific mappings directly into application code. Version them independently so a new facility’s message conventions do not require rewriting the product.

A canonical FHIR representation can reduce downstream complexity, but converting HL7 v2 into FHIR is not automatically lossless. Preserve necessary source context and transformation lineage, with retention and access controls appropriate for protected health information.

Select tools against operating requirements

Established interface engines include NextGen Connect, InterSystems Health Connect, and Rhapsody. These can support routing and transformation, but connector availability, licensing, deployment models, and operational features vary.

For Java-based FHIR services, HAPI FHIR provides client, server, and validation components. Managed options include Azure Health Data Services and Google Cloud Healthcare API. They provide useful infrastructure capabilities but do not grant access to an EHR or resolve clinical workflow semantics.

Redox is another option for organizations seeking a managed integration layer. Compare its supported workflows and responsibility boundaries with direct vendor integrations.

Evaluate candidates using concrete acceptance criteria:

• Support for required HL7 versions, FHIR releases, and profiles.
• Durable queuing, replay, quarantine, and traceability.
• Private connectivity and required deployment regions.
• Mapping version control and automated testing.
• Environment isolation and auditable administration.
• Total costs for interfaces, environments, support, storage, and traffic.

The trade-off is straightforward: managed platforms can reduce infrastructure work, while self-managed engines offer more control but require specialist staffing and on-call ownership.

Implement the integration step by step

1. Define a workflow contract

Document the actors, trigger, source of truth, destination, and completion criteria.

“Send laboratory results” is too vague. Specify whether the integration handles preliminary, final, corrected, and canceled results; whether attachments are included; and how results connect to patients, encounters, and orders.

For AI workflows, define whether outputs remain drafts, require clinician review, or enter the legal medical record. API write permission is not authorization to bypass clinical approval.

2. Confirm EHR access before committing the delivery plan

Review the target vendor’s developer program, including Epic on FHIR, Oracle Health’s developer resources, or the relevant platform documentation.

Ask the customer and vendor to confirm:

• Production enablement and customer sponsorship.
• Supported read and write operations.
• Interface fees and contractual restrictions.
• Sandbox differences from production.
• Rate limits, maintenance windows, and support escalation.
• Whether each hospital or tenant requires separate onboarding.

Test the highest-risk operation early. A successful patient lookup does not prove that scheduling or documentation write-back is available.

3. Establish identity and authorization

Use identifiers with their issuing authority or namespace. A medical record number is not globally unique; FHIR resource IDs are scoped to their server context.

Define handling for duplicate patients, merged records, and ambiguous matches. Avoid unattended demographic matching without approved thresholds, exception handling, and governance.

For user-facing FHIR applications, SMART on FHIR commonly supplies an OAuth-based authorization and launch framework. Backend integrations may use SMART Backend Services when supported. Follow the official SMART App Launch specification for applicable flows.

Request minimum necessary scopes and keep credentials isolated by environment and customer. SMART scopes do not replace the EHR’s user permissions, consent rules, or organizational authorization decisions.

4. Build explicit mappings and terminology rules

Create a mapping specification that includes source fields, destination elements, transformations, defaults, and rejection conditions.

For example, an HL7 v2 laboratory feed may map:

• Patient identifiers from PID into Patient.identifier.
• Order and report context from OBR into relevant order references and DiagnosticReport.
• Individual OBX results into Observation resources.
• Value type, units, status, and interpretation into distinct FHIR elements.

This is not a universal one-to-one mapping. Repeated fields, local codes, and differing order workflows require source-specific decisions.

Use LOINC, SNOMED CT, RxNorm, and UCUM where appropriate and permitted. Preserve original codes alongside mapped codes when needed for traceability. Do not convert a missing value into zero or assume that identically named tests have interchangeable units.

5. Implement delivery guarantees and recovery

Design around at-least-once delivery with idempotent processing, unless the entire workflow demonstrably supports another model.

For HL7 v2, define when acknowledgments are issued and what they mean. A transport acknowledgment is not necessarily confirmation that downstream clinical processing succeeded. Combine message control IDs with sending-system context and agreed duplicate-detection rules.

For FHIR:

• Distinguish validation failures from transient service errors.
• Honor Retry-After when supplied.
• Use bounded retries with backoff and jitter.
• Follow pagination links rather than constructing assumptions.
• Evaluate conditional create and version-aware updates where supported.
• Inspect OperationOutcome details and individual batch responses.

After an ambiguous write timeout, reconcile before retrying blindly. A duplicate order or note can be clinically consequential.

6. Validate syntax, semantics, and workflow outcomes

Use the HL7 FHIR Validator or HAPI FHIR validation support with the correct profiles and terminology dependencies.

Validation should cover three levels:

• Structural: Does the message or resource satisfy its declared constraints?
• Semantic: Are identifiers, terminology, units, timestamps, and statuses meaningful?
• Workflow: Does the receiving EHR place the information in the intended clinical context?

Test with synthetic fixtures, then appropriately governed representative data. Include merges, corrections, canceled orders, missing identifiers, delayed delivery, time-zone changes, pagination, duplicate events, and downtime recovery.

Schema-valid data can still be clinically wrong. Require clinical or operational review of representative outcomes.

7. Roll out with measurable acceptance gates

Pilot a limited facility, department, or workflow before expanding.

Agree on gates such as:

• Every supported event has a documented success and failure path.
• No unresolved critical patient-association defects remain.
• Replay tests do not create duplicate clinical artifacts.
• Reconciliation detects deliberately omitted events.
• Support teams can locate failures without exposing unnecessary PHI.

Maintain a rollback plan that includes queued messages, partially completed writes, and coordination with clinical operations. Reverting application code alone may not undo an EHR change.

Secure and operate the integration

In US deployments, assess HIPAA obligations and applicable business associate agreements; other jurisdictions require their own legal analysis. The HHS Security Rule guidance provides an authoritative starting point for US security requirements.

Apply encryption in transit and at rest, least-privilege access, credential rotation, audit controls, and documented retention policies. Avoid putting patient names, access tokens, or full clinical payloads into ordinary application logs.

Track operational measures that reveal actual delivery health:

• Oldest queued event and end-to-end processing delay.
• Unmatched patient or encounter references.
• Repeated validation and authorization failures.
• Source-to-destination reconciliation discrepancies.
• Dead-letter queue volume and recovery progress.

A low HTTP error rate is insufficient. The integration can return successful responses while silently omitting records because of search filters, pagination mistakes, or unsupported fields.

Assign ownership for interface monitoring, terminology changes, certificate renewal, and vendor upgrades. Production reliability depends as much on these responsibilities as on the initial implementation.

Common mistakes and their consequences

• Treating FHIR as plug-and-play: Resource availability varies by vendor and deployment. Verify the exact operation, profile, and permissions.
• Assuming standards compliance guarantees completeness: APIs may expose only a subset of the clinical record. Document coverage and exclusions.
• Ignoring corrections and merges: Initial delivery works, but longitudinal records become inconsistent. Model update and reconciliation paths explicitly.
• Equating HTTP success with clinical completion: Confirm downstream workflow state when required.
• Using one universal mapping without local review: Local codes and workflow conventions can change meaning. Approve mappings per source.
• Budgeting only for development: Customer onboarding, security reviews, clinical validation, and ongoing interface support also require capacity.

For adjacent architecture and implementation guidance, browse more Integration topics.

Frequently asked questions

Is FHIR replacing HL7 v2 in EHR integration?

Not universally. FHIR is useful for application access, standardized resource exchange, and supported bulk workflows. HL7 v2 remains important for hospital event feeds, orders, and results. Many production architectures use both, selected by workflow and vendor capability.

Can a FHIR API write data directly into an EHR?

Sometimes. Support depends on the resource, operation, EHR configuration, application permissions, and customer approval. Even when a write succeeds, the data may require review or signing before becoming part of the finalized record. Verify both technical support and clinical behavior.

How long does an HL7/FHIR integration take?

A sandbox demonstration may be quick, but production delivery depends on access approval, interface provisioning, mapping complexity, security review, and workflow validation. Estimate these as separate workstreams. Reusing a connector helps, but it does not remove customer-specific onboarding or acceptance testing.

What should teams build first?

Build a thin end-to-end workflow covering authorization, patient identification, one clinically meaningful exchange, error handling, and reconciliation. Choose the riskiest required capability rather than the easiest API call. This proves feasibility early and creates a foundation for expansion.