Enterprise EHR platforms — Epic, Oracle Health (formerly Cerner), Meditech, Athenahealth, and others — are the hub of clinical data exchange in most healthcare organizations. Every system that touches patient data connects to them in some way: imaging systems, lab systems, pharmacy, scheduling, patient engagement platforms, and the interface layer that routes the messages between them.
The challenge of EHR integration is that each platform has its own message structure preferences, its own interface tooling, its own upgrade cadence, and its own set of behaviors that affect every downstream connected system. Understanding those platform-specific characteristics is as important as understanding the underlying HL7 and FHIR standards. Generic integration knowledge without platform context produces interfaces that are technically correct in isolation and unreliable in production.
HL7 v2 versus FHIR for EHR integration: choosing the right approach
The question of whether to use HL7 v2 or FHIR for a given integration is not primarily a standards debate — it is a practical question about what the use case requires and what both systems support.
HL7 v2 remains the dominant standard for operational event-driven integration in healthcare. ADT feeds, imaging order routing, results delivery, scheduling messages, and document notifications all run on HL7 v2 in most current environments. The strength of HL7 v2 is its ubiquity, its real-time push model, and the deep existing support in clinical systems that were built around it.
FHIR is the appropriate choice when the use case involves application-level data access, patient data synchronization across multiple systems, or new integration patterns where REST-based APIs are more suitable than event-based message feeds. Most major EHR platforms have invested significantly in FHIR APIs over the past several years, and new integration capabilities are increasingly being built on FHIR rather than HL7 v2.
In practice, HL7 v2 and FHIR coexist in enterprise EHR environments. HL7 v2 handles the operational backbone. FHIR supports newer application access patterns. The integration architect's job is to choose the right tool for each interface requirement, not to standardize on one standard for all use cases. The article on HL7 versus FHIR in healthcare integration covers the architectural tradeoffs in more depth.
Common integration patterns for clinical imaging and EHR systems
The integration patterns between an EHR and clinical imaging systems are well-established. Understanding which patterns apply to a given environment is the starting point for any integration scope definition.
| Integration pattern | HL7 message type | Purpose |
|---|---|---|
| Patient registration / demographics | ADT A01, A04, A08, A28, A31, A40 | Keeps imaging system patient records synchronized with EHR registration |
| Imaging order routing | ORM O01 | Routes imaging orders from the EHR to the RIS and imaging modality worklist |
| Results / reports delivery | ORU R01 | Delivers finalized radiology reports from RIS/PACS back to the EHR for provider access |
| Scheduling | SIU S12–S15 | Communicates appointment scheduling events between EHR and RIS |
| Documents and notes | MDM T02, T04 | Routes clinical documents and reports between systems |
| DICOM modality worklist | DICOM MWL (C-FIND) | Provides patient and order context to imaging modalities at time of study acquisition |
Platform-specific considerations
Each enterprise EHR platform has characteristics that affect integration design. These are not value judgments about platform quality — they are practical notes on what integration teams encounter in each environment.
Epic uses its own interface engine internally (Bridges) and publishes a well-documented set of HL7 message specifications. Epic's FHIR API capabilities (SMART on FHIR, bulk FHIR export) are among the most mature in the industry. Integration teams connecting to Epic environments often have access to detailed implementation guides, but the specificity of Epic's message content — particular segment usage, code values, and field expectations — requires careful review against Epic's specifications rather than relying on HL7 standards alone.
Oracle Health (formerly Cerner) uses CCL (Cerner Command Language) and Discern Rules for internal clinical logic, and its interface engine capabilities center on the Cerner MPage and CareAware platforms. Integration into Cerner environments typically involves working with Cerner's integration team through their client channel, and interface builds may require coordination with both the customer's IT team and Cerner professional services.
Meditech has a strong presence in community hospitals and smaller health systems. Its integration architecture varies across platform versions — Meditech Expanse (web-based, current) and Meditech Magic/6.x (legacy, still widely deployed) have different integration patterns. Organizations on legacy Meditech versions often have significant interface debt and older HL7 implementations that require careful mapping when connecting to modern clinical or imaging systems.
Athenahealth serves ambulatory and physician group environments and exposes integration primarily through its API platform. Its HL7 integration capabilities are more limited than inpatient EHR platforms; organizations connecting Athena to hospital-based imaging systems typically work through Athena's API or through a third-party interface engine that bridges between Athena's API model and the HL7 v2 interfaces that imaging systems expect.
Interface governance and change management
Enterprise EHR platforms receive regular upgrades, and every upgrade has the potential to affect connected interfaces. Message content changes, segment structure updates, value set modifications, and routing behavior adjustments can all alter the behavior of interfaces that were working correctly before the upgrade.
Without a formal interface governance process, these changes surface as production incidents — orders not routing, results not delivering, ADT events not reaching imaging systems. With a governance process, they are identified during testing and resolved before impacting clinical operations.
The components of effective interface governance include: a complete and maintained interface inventory, a change notification process with the EHR vendor, a regression testing protocol that exercises all connected interfaces before each upgrade, and post-upgrade monitoring that watches for anomalies in the 24 to 72 hours following production changes.
Platforms like Flow Bridge Integration, also known as FBI Engine, are designed to support this type of integration governance by providing transport visibility, runtime truth, diagnostics, replay paths, and operational triage capabilities that help keep interface environments stable across EHR upgrade cycles.
When those same HL7, FHIR, and API events need to support patient flow, worklist management, status management, and operational visibility, VioFlow provides a patient operations layer for turning inbound clinical workflow data into governed, actionable work.
Planning a new EHR integration engagement
EHR integration engagements for clinical imaging systems follow a consistent sequence of phases, regardless of which platforms are involved: discovery, design and build, testing, and production cutover with post-go-live monitoring.
Discovery establishes the requirements: which message types are needed, what fields each system requires in what format, what the routing topology should be, and what the non-production testing environments look like. This phase is where scope is defined and where under-specification creates the most downstream risk.
Design and build translates requirements into interface engine configuration, transformation logic, and connection parameters. Testing validates the build against all required message types, including edge cases and failure scenarios. Production cutover should include a parallel monitoring period where both IT and clinical teams are watching for anomalies.
Frequently asked questions
When should teams use HL7 v2 versus FHIR for EHR integration?
HL7 v2 remains the appropriate choice for operational event-driven integration — ADT feeds, order routing, results delivery, scheduling messages — where real-time, high-volume message exchange is required and the receiving system has existing HL7 v2 support. FHIR is increasingly appropriate for application-level data access, patient data synchronization, and new integration patterns where a REST-based API model is more suitable than a message-based feed. In most enterprise EHR environments today, HL7 v2 and FHIR coexist: HL7 v2 handles the operational backbone and FHIR supports newer application integration needs. Choosing based on what the specific use case requires — rather than defaulting to one standard — produces the best results.
How should interface teams manage the impact of EHR upgrades on connected systems?
EHR upgrades frequently introduce changes to HL7 message content, segment structure, value set updates, or routing behavior that affect downstream connected systems. Interface teams should establish a formal notification process with their EHR vendor to receive advance notice of upgrade-related interface changes, maintain a complete interface inventory so that impact scope can be assessed quickly, and run regression tests against connected systems using message samples from the upgraded environment before production cutover. Monitoring interface queues and acknowledgment patterns closely in the 24 to 72 hours following an upgrade is the practical safety net that catches issues the test environment missed.
What does a typical EHR integration engagement look like for a clinical imaging system?
A typical EHR integration engagement for a clinical imaging system involves four phases: discovery and requirements definition, interface design and build, testing, and production cutover with post-go-live monitoring. Discovery identifies which message types are needed, what fields each system requires, and what the routing topology should be. Design and build configures the interface engine, writes transformation logic, and establishes connection parameters. Testing validates in a non-production environment across all relevant message types and edge cases. Production cutover includes post-go-live monitoring. Engagement duration varies from four to sixteen weeks depending on interface complexity and the availability of non-production environments on both sides.
Viogenx delivers EHR and clinical system integration
Viogenx works with healthcare organizations on HL7 and FHIR interface design, EHR integration architecture, interface governance, and the integration monitoring that keeps clinical systems aligned through upgrades and change.
Explore HL7 and FHIR integration services