The Diagram That Stayed Theoretical
A senior integration engineer at a regional health system showed me a target architecture diagram from her predecessor's planning documents. The diagram showed all healthcare data flowing as FHIR. EHR data as FHIR. Lab results as FHIR. Claims as FHIR. Imaging metadata as FHIR. Beautiful diagram.
The actual data flowing through her integration platform in 2024 was different. About 30 percent was FHIR. About 40 percent was HL7v2 (the older HL7 standard that has been around since the 1980s). About 20 percent was X12 (claims and EDI formats). About 10 percent was PDFs, fax-derived images, custom formats, and other miscellaneous content. The diagram showed an aspirational future; her work was the present reality.
She told me the lesson was that FHIR-only thinking produces architectures that do not match what healthcare data actually looks like in 2026. The real mix has not gone away despite years of FHIR promotion. Engineering teams that handle the real mix produce platforms that work. Teams that assume FHIR universality produce platforms that hit the gap between aspiration and reality.
EHR Integration Reality
The three gaps between Epic's FHIR R4 documentation and production behavior.
What the Real Healthcare Data Mix Looks Like
Healthcare data in production in 2026 still spans multiple formats and protocols. Each has specific characteristics and use cases.
FHIR has grown substantially through 2024 and 2025. FHIR R4 is the dominant version with broad EHR support. The protocol fits modern integration patterns. FHIR R5 is emerging with additional capabilities. FHIR carries probably 30-50 percent of new healthcare data integrations, varying by region and organization type.
HL7v2 remains the workhorse for many real-time clinical data flows. ADT messages for patient movements, ORM and ORU for orders and results, MDM for medical documents. The protocol is old, structurally unusual, and works at scale. Hospital integration engines (Mirth, Rhapsody, Cloverleaf, others) handle HL7v2 routing as core capability.
X12 dominates payer-provider data exchange. 837 for claim submission, 835 for remittance, 270/271 for eligibility, 276/277 for claim status. The protocol is more standardized than HL7v2 but with different complexities (envelope structures, multiple version variations, payer-specific implementations).
CDA (Clinical Document Architecture) and CCD (Continuity of Care Document) handle some document-based exchange, particularly for care transitions and patient summaries. The structure is XML-based with substantial flexibility that produces implementation variation.
DICOM handles imaging data and its associated metadata. The protocol is specialized for imaging workloads with its own integration patterns.
Beyond these standards, healthcare integration handles custom formats, scanned documents, faxes, and email content. The miscellaneous category is smaller than the standardized formats but operationally meaningful.
Why FHIR Has Not Replaced the Others
FHIR's growth has been substantial. The replacement of older protocols has been slower than the marketing suggested. Three factors explain the gap.
The first factor is installed base. Healthcare integration infrastructure built around HL7v2 and X12 has decades of investment. Replacement requires not just FHIR support but also retirement of existing systems. The retirement is slow because the existing systems work.
The second factor is operational maturity. HL7v2 and X12 have mature operational practices, mature tooling, and mature problem-solving knowledge. FHIR is younger. Some operational considerations (high-throughput processing, specific edge cases, vendor-specific implementations) have been worked out for the older protocols more thoroughly than for FHIR.
The third factor is workload fit. Some workloads fit FHIR well. Some workloads fit HL7v2 better (real-time clinical messaging with specific structural patterns). Some workloads fit X12 better (claim submission with regulatory structure requirements). FHIR is not strictly superior for all workloads.
The trajectory is toward FHIR for new integrations and continued operation of HL7v2 and X12 for existing flows. The displacement happens slowly. Engineering teams operating in 2026 work with the mix rather than with pure FHIR.
The Patterns That Handle the Real Mix
Three patterns help engineering teams handle the realistic healthcare data mix.
The first pattern is protocol-specific ingestion with normalized internal representation. The integration platform has dedicated handlers for each protocol. HL7v2 handler parses HL7v2 messages. FHIR handler consumes FHIR resources. X12 handler processes X12 transactions. Each handler transforms to a common internal representation.
The internal representation can be FHIR-shaped or a custom canonical model. Either choice works. The pattern is decoupling external protocols from internal processing. New protocols can be added by writing handlers. Internal processing changes once for all protocols rather than per protocol.
The second pattern is workflow-specific routing rather than protocol-driven processing. The integration platform routes messages by what they mean rather than by what protocol they came in. An ADT message and a Patient FHIR resource both representing patient registration get processed by the same patient-registration workflow.
The pattern produces consistent behavior across protocols. Adding a new source means writing the handler that maps to the existing workflows. The workflow stays stable.
The third pattern is bidirectional translation as a service. The integration platform exposes services that translate between protocols. A consumer that wants FHIR can read data originally received as HL7v2 through a translation service. A producer that emits HL7v2 can send to consumers that want FHIR through a translation service.
The pattern handles the gradual transition between protocols. Different consumers and producers can be at different points in the FHIR transition. The translation service bridges them.
What Goes Wrong With Healthcare Integration
Three patterns of integration failure are common.
The first pattern is FHIR-only architecture against non-FHIR sources. The team builds a FHIR-native platform. The sources still emit HL7v2 and X12. Integration becomes a constant translation exercise. The architecture's elegance does not match the operational reality.
The remediation is multi-protocol architecture from the start. The platform accepts what sources actually send. Internal processing handles the mix.
The second pattern is treating older protocols as legacy to be tolerated rather than as production systems to be operated well. The team neglects HL7v2 or X12 operational excellence because those protocols are "going away." The neglect produces operational issues. The protocols do not actually go away on the assumed timeline.
The remediation is treating each protocol as a first-class operational concern for as long as it carries production traffic. Operational discipline applies regardless of the protocol's perceived modernity.
The third pattern is hand-rolled implementations of standards that mature libraries handle. Teams write custom HL7v2 parsers, custom X12 processors, custom FHIR clients. The custom code accumulates bugs and operational burden. Mature libraries exist for each standard.
The remediation is using established libraries (HAPI FHIR, NHapi for HL7v2, EDI specific tools for X12) and contributing to them when extensions are needed. The leverage of community-maintained libraries exceeds what custom code provides.
What This Costs
Healthcare integration infrastructure at production scale typically requires a dedicated integration team of five to twenty engineers depending on transaction volume and protocol breadth.
Tooling investment includes integration engines (commercial or open-source), protocol-specific libraries, monitoring infrastructure, and integration testing capabilities. The annual cost typically lands in the $500K-$3M range for serious capability.
The alternative cost is the cost of integration failures that affect clinical or business operations. Each failed integration has direct cost and downstream impact. The investment in robust multi-protocol integration is justified by the prevention of these failures.
HIPAA and AI
Why 90% of healthcare organizations are unknowingly exposing patient data through AI tools.
Call to Action
What Logiciel Does Here
Logiciel works with healthcare integration teams operating multi-protocol environments or modernizing integration architecture. The work is typically structured around protocol-by-protocol assessment and architecture patterns appropriate to the specific data mix.
The Healthcare Data Engineering: EHR, Claims, Device Data framework covers the broader healthcare data engineering patterns. The AI Integration Into Legacy Systems: A Field Guide framework covers the legacy integration patterns that apply across protocols.
A 30-minute working session is enough to assess your current integration architecture against the real protocol mix.
Frequently Asked Questions
Should I migrate everything to FHIR?
Eventually for new integrations; rarely worth the effort to migrate existing working integrations. FHIR-first for greenfield. Multi-protocol for the production reality.
What about FHIR R5 versus R4?
R4 is the production standard in 2026. R5 is emerging. Most integration platforms support R4 as primary with R5 capability building. The migration from R4 to R5 will be incremental over years rather than immediate.
How does AI integration affect protocol handling?
AI workloads typically consume normalized internal representations rather than raw protocol output. The protocol layer is upstream of the AI layer. The AI architecture benefits from the protocol-agnostic internal representation that good integration architecture provides.
What about Da Vinci Project and other FHIR profiles?
Da Vinci accelerator and similar projects produce FHIR profiles for specific payer-provider workflows. The profiles add FHIR capability for use cases that X12 has historically handled. The transition is happening; complete displacement of X12 by FHIR profiles will take years.
How do I prioritize integration improvements across protocols?
By workload value and protocol-specific pain. Protocols carrying high-value workloads with operational pain get prioritized. Protocols with stable operations and lower-value workloads can wait. The prioritization is workload-driven rather than protocol-driven. Sources: - HL7 FHIR specification, 2024 - ONC, "Interoperability and Patient Access Final Rule," 2024 update
