Coexist Without Rewriting: HL7 vs FHIR for Healthcare IT Teams

HL7 v2 remains the operational backbone that keeps ADT, orders, and results moving in real time across hospital systems, while FHIR is the API-first standard you should reach for on new patient-facing apps, partner integrations, and analytics work. Most healthcare organizations run both, choosing standard by workflow rather than replacing one wholesale. Regulatory pressure from ONC and CMS is tilting new API work firmly toward FHIR, so treat that as your default for anything greenlit today.

---

TL;DR:

• Most healthcare organizations will continue running HL7 v2 interfaces alongside FHIR, especially for event-driven tasks like admission and results messaging.
• FHIR is the recommended standard for patient-facing apps, analytics, and cloud integrations due to its RESTful, resource-based architecture and modern developer tooling.
• Migration should focus on domain-by-domain transition, starting with low-risk pilot projects, while keeping legacy HL7 v2 feeds operational during the process.
• In radiology, DICOM handles image data, HL7 manages order and result messaging, and FHIR resources facilitate metadata and portal access efficiently.
• Regulatory mandates from ONC and CMS now require FHIR-based APIs for patient data access, making FHIR essential for compliance and future interoperability efforts.

---

Table of Contents

• HL7 Explained: v2, v3, and CDA , What They Are and Where They Still Win
• FHIR Fundamentals: Resources, REST APIs, Versions, and Developer Experience
• HL7 vs FHIR: Architecture, Transport, and Adoption Compared
• Use Cases and Hybrid Patterns for EHRs, Labs, Patient Apps, and Analytics
• Implementing HL7 and FHIR: Mapping, Testing, and Security
• How DICOM, HL7, and FHIR Work Together in Radiology
• Regulatory Drivers: ONC, CMS, and USCDI
• A Migration Playbook for HL7 to FHIR Coexistence
• How Do Custom Fields Work in HL7 vs FHIR?
• Performance and Scalability: HL7 vs FHIR at Volume
• Community Support and Ecosystem Momentum Behind Each Standard
• Licensing and Openness: What It Means for Your Build
• AstraRad's Perspective: Integrating HL7 and FHIR in Radiology Workflows
• Next Steps: A Decision Checklist for HL7 and FHIR Projects
• Sources

HL7 Explained: v2, v3, and CDA , What They Are and Where They Still Win

If you've worked inside a hospital IT department for more than a year, you've touched HL7 v2. It's the pipe-delimited, segment-based messaging format built in the late 1980s, and it's still the workhorse moving admissions, orders, and results between systems that were never designed to talk to each other gracefully.

HL7 v2 messages travel over MLLP (Minimal Lower Layer Protocol) on top of TCP, and they follow a rigid but predictable structure: segments separated by carriage returns, fields separated by pipes, each message typed by a three-character code. An ADT^A01 message announces a patient admission. An ORU^R01 carries lab results. An ORM^O01 places an order. Any engineer who has debugged one of these messages at 2 a.m. knows the format is unforgiving about field order but forgiving about how loosely vendors interpret the spec, which is exactly why every hospital's interface team keeps a binder of site-specific quirks.

HL7 v3 tried to fix v2's inconsistency problem with a formal reference information model and XML-based messages. Adoption never matched v2's, but its DNA lives on in the Clinical Document Architecture (CDA), and specifically in Consolidated CDA (C-CDA), which still handles summary-of-care documents required for care transitions and Meaningful Use-era reporting.

Here's the adoption reality that surprises people outside interface engineering: HL7 v2 still carries roughly 85% of real-time clinical traffic in US hospitals. That's not inertia alone. Event-driven messaging fits certain jobs better than REST ever will.

HL7 v2 tends to win when:

• Latency matters more than flexibility (an ADT feed triggering a bed-management system in under a second).
• The sending system is a legacy device or vendor appliance that only speaks MLLP.
• The workflow is fundamentally event-driven: something happened, and downstream systems need to react immediately.
• Replacing the interface would require a capital project the health system hasn't budgeted for.

None of that makes HL7 outdated. It makes it specialized. HL7's own comparison guidance acknowledges as much: FHIR can satisfy many needs previously handled by v2, v3, and CDA, but coexistence is the expected state for years to come, not a transitional inconvenience.

FHIR Fundamentals: Resources, REST APIs, Versions, and Developer Experience

FHIR flips the model. Instead of discrete event messages, everything is a resource: Patient, Observation, DiagnosticReport, ImagingStudy, Encounter, and dozens more, each with a defined structure and defined relationships to other resources. You request a Patient resource, and you get back a JSON (or XML) object with a predictable shape, versioned and documented in the FHIR specification.

The transport is what makes FHIR feel native to modern engineering teams. It's RESTful: GET a resource, POST a new one, PUT an update, PATCH a partial change, DELETE when appropriate. Search is built into the model, so you can query Observation?patient=123&category=vital-signs and get back a Bundle, FHIR's container format for grouping search results, transaction batches, or paginated response sets.

Security follows the same modern pattern. SMART on FHIR layers OAuth 2.0 on top of the REST API, giving you scoped, token-based access instead of trusting whatever sits on the same network segment. That single design choice is why FHIR APIs can be exposed to third-party apps and patient-facing tools without opening a hole in the hospital firewall.

A few things worth knowing before you commit to a FHIR project:

• R4 is the current normative version for most production work; R5 is progressing but adoption lags behind R4 in live systems.
• Public test servers and sandbox environments make it possible to prototype against real FHIR endpoints before touching production data, and Healthdata catalogs sample datasets useful for exactly this kind of pilot work.
• Tooling has matured fast: validators, profile-conformance checkers, and code generators exist for most major languages.
• FHIR is the right pick when you're building a patient portal, exposing data to a partner organization, feeding an analytics pipeline, or launching any new cloud-native application that needs to talk to a health record.

The developer experience gap between the two standards is the real story here. A junior engineer can hit a FHIR endpoint with Postman and get a readable JSON response in minutes. Getting a usable HL7 v2 test message flowing usually takes a working knowledge of segment structure and a patient interface engineer's help.

HL7 vs FHIR: Architecture, Transport, and Adoption Compared

Put side by side, the two standards solve different problems with different tools, and the gap shows up clearly once you line up the technical dimensions engineers actually have to plan around.

Dimension	HL7 v2 / v3 / CDA	FHIR
Architecture/paradigm	Message and event-driven	Resource-based, RESTful
Transport & wire format	MLLP over TCP; pipe-delimited (v2) or XML (CDA)	HTTPS; JSON by default, XML/RDF supported
Typical use cases	ADT feeds, order/result messaging, legacy device interfaces	Patient apps, partner APIs, analytics, cloud integrations
Security & auth	Network-level trust, TLS on the transport link	OAuth 2.0, SMART on FHIR, scoped tokens
Tooling & developer experience	Interface engines, segment mapping, steep onboarding	REST clients, JSON tooling, public test servers
Adoption in production	~85% of real-time hospital traffic	Growing fast, mandated for new patient-access APIs

That 85% figure deserves a second look, because it's easy to misread as evidence that FHIR adoption is lagging. It isn't. HL7 v2's dominance reflects decades of embedded infrastructure that nobody is ripping out on a whim, not a verdict on which standard is more capable for new work.

A few patterns hold up across almost every implementation:

• HL7 v2 debugging happens with segment-level log inspection and ACK/NACK tracing; FHIR debugging happens with standard HTTP tooling, which most engineering teams already know.
• FHIR's search API lets you ask arbitrary questions of the data model; HL7 v2 gives you whatever fields the sending system chose to populate, in whatever order it chose to send them.
• Security models aren't interchangeable. MLLP links depend on network segmentation and, ideally, TLS wrapping; FHIR depends on token scopes and identity federation. Treating one as a drop-in replacement for the other's security posture is a mistake.
• Migration rarely happens standard by standard. It happens domain by domain, one interface at a time, while the rest of the environment keeps running on whatever already works.

That last point is why coexistence isn't a hedge, it's the honest engineering answer. Ripping out a functioning v2 interface to a lab system that's worked reliably for a decade, just to standardize on FHIR, usually costs more in risk than it returns in elegance.

Use Cases and Hybrid Patterns for EHRs, Labs, Patient Apps, and Analytics

Most integration decisions boil down to a simple question: is this an internal operational event, or an external-facing data request? Answer that, and the standard usually picks itself.

Keep HL7 v2 running for:

1. ADT feeds that trigger bed management, census updates, and downstream registration systems the moment a patient is admitted, transferred, or discharged.
2. Lab and radiology results delivery (ORU messages) where the receiving system expects a real-time push, not a poll.
3. Scheduling feeds between practice management systems and ancillary departments, where timing matters more than query flexibility.

Move to FHIR when you're building:

1. A patient portal or third-party health app that needs scoped, authenticated access to a patient's own records.
2. A payer data exchange integration, where USCDI-aligned resources make compliance mapping far more direct.
3. An analytics or population-health pipeline pulling structured Observation and Condition data across multiple source systems.

The pragmatic middle ground, and the pattern most mid-size and large health systems land on, is a hybrid architecture. HL7 v2 keeps running as the operational backbone, an interface engine translates relevant events into FHIR resources, and a FHIR façade exposes that data to apps and partners without ever touching the legacy feeds directly. Practitioner guidance on integration patterns consistently points to this façade approach as the lowest-risk way to modernize access without a rip-and-replace migration.

Implementing HL7 and FHIR: Mapping, Testing, and Security

Whichever mix you land on, the engineering discipline underneath it looks similar. Pick an interface engine and commit to a canonical internal data model early, because every new one-off translation you skip now is a maintenance headache you avoid in two years.

Practical steps that hold up in real deployments:

• Build a segment-to-resource mapping table (PID to Patient, OBX to Observation) and version it alongside your canonical model, not as a side document nobody updates.
• Document every optional or locally extended field your vendors actually populate, because "per the spec" and "what this vendor sends" rarely match exactly.
• Write contract tests for both directions: does the v2 message you generate still parse correctly, and does the FHIR resource you produce still validate against its profile?
• Replay historical messages against updated mappings before cutting over, and verify ACK/NACK behavior hasn't silently changed.
• Instrument both message queues and API endpoints for observability. A silent MLLP timeout and a silent 401 on a FHIR token refresh fail very differently, and your monitoring needs to catch both.
• Harden the transport layer specifically: TLS on every MLLP link, tightly scoped OAuth tokens with short lifetimes for FHIR clients, and audit logging on every PHI-bearing request regardless of which standard carries it.

Pro Tip: Don't wait for a production incident to find out your interface engine's mapping logic isn't test-covered. Treat every segment-to-resource mapping as code, with the same review and test requirements you'd apply to a billing calculation.

How DICOM, HL7, and FHIR Work Together in Radiology

Radiology workflows make the division of labor between standards obvious, because three different jobs need three different tools. DICOM handles pixel-level image transport, moving actual image data between modalities, PACS, and viewers. HL7 v2 handles the order and result messaging around that image, telling systems a study was ordered, scheduled, or completed. FHIR's ImagingStudy and DiagnosticReport resources add a metadata and discovery layer on top, letting apps find and reference a study without ever moving the underlying pixels through the API.

The pattern that works in practice, and the one worth designing toward:

• Modality to PACS: DICOM, full stop, because that's what the equipment vendors build for.
• Orders and workflow status: HL7 v2, because scheduling and results delivery are event-driven by nature.
• App-level access and viewer launch: FHIR ImagingStudy referencing DICOM instance UIDs, with a DICOMweb viewer handling actual pixel retrieval.

That last piece matters more than it sounds. Routing gigabyte-scale image data through a FHIR API would be slow and wasteful; letting FHIR carry the reference and metadata while DICOMweb handles retrieval keeps latency reasonable and keeps each standard doing what it's actually good at.

Regulatory Drivers: ONC, CMS, and USCDI

Federal policy is the reason "FHIR or HL7" stopped being a purely technical debate. ONC's interoperability rules require certified health IT to support FHIR-based patient-access APIs, and CMS pairs that with anti-information-blocking provisions that make withholding accessible data a compliance risk, not just a bad look.

USCDI (the United States Core Data for Interoperability) defines the data classes, demographics, medications, lab results, that certified systems must be able to exchange, and those classes map directly onto FHIR resources rather than onto legacy v2 segments.

If you're writing an RFP for a new system or interface, put these questions in it directly:

• Does the vendor support current USCDI data classes natively through FHIR endpoints?
• Is SMART on FHIR authentication supported out of the box, or does it require a custom build?
• What's the vendor's plan for maintaining v2 interfaces alongside FHIR APIs during a transition period?
• Can the vendor demonstrate a working ImagingStudy or DiagnosticReport implementation if imaging is in scope?

A Migration Playbook for HL7 to FHIR Coexistence

A realistic migration doesn't start with a mandate to "move everything to FHIR." It starts with an inventory.

1. Discovery: Catalog every v2 feed in production and classify each by business criticality. Not every interface deserves the same urgency.
2. Pilot: Pick one low-risk domain, often read-only Patient or Observation access, and expose it through FHIR while the underlying v2 feed keeps running untouched.
3. Translate: Build mapping logic and interface engine transforms with acceptance tests that catch regressions before they hit production.
4. Operate: Add observability, define rollback criteria, and expand incrementally only once the pilot has proven stable under real load.

How Do Custom Fields Work in HL7 vs FHIR?

HL7 v2 handles custom data through Z-segments, locally defined segments that sit outside the base standard and carry whatever a vendor or site decides it needs. They're flexible, but that flexibility is exactly the problem: two hospitals' Z-segments for the same data almost never match, and nothing in the standard forces documentation.

FHIR's extension mechanism is more disciplined by design. Every FHIR resource can carry formally defined extensions, each with its own URL, data type, and cardinality rules, and profiles can constrain or require specific extensions for a given use case. That's a meaningful difference for interoperability at scale: a well-built FHIR profile is self-documenting in a way a Z-segment never was.

This doesn't mean FHIR's approach is friction-free. Building and maintaining custom profiles takes real governance discipline, and organizations that skip that discipline end up with a sprawl of ad hoc extensions that's arguably no better organized than a decade of undocumented Z-segments. The technical ceiling on FHIR extensibility is higher. Whether a given team clears that ceiling depends entirely on whether someone owns the profile governance process.

For teams weighing this trade-off on new integration work, generic EHR integration approaches from partners like ClaroClaim illustrate how profile-driven extensibility gets applied in claims and technology contexts outside pure clinical messaging.

Performance and Scalability: HL7 vs FHIR at Volume

HL7 v2's performance profile is well understood because it's been load-tested by three decades of production hospital traffic: low per-message overhead, predictable latency over a persistent MLLP connection, and throughput that scales with however many parallel TCP connections your interface engine can manage. It's not fancy, but it's proven at the volume a large hospital system generates every day.

FHIR's scalability story runs through standard web infrastructure instead of custom protocol tuning. REST APIs scale with load balancers, caching layers, and horizontal scaling patterns any web engineering team already knows, which is an advantage when you're exposing data to thousands of patient app sessions rather than a fixed set of internal system connections. The tradeoff is per-request overhead: HTTP headers, JSON parsing, and token validation on every call add latency that a raw MLLP message doesn't carry.

In practice, the two rarely compete for the same workload. Nobody is trying to push admission-event volume through a FHIR API, and nobody should try to serve ten thousand concurrent patient-app sessions over MLLP. Scalability planning matters most at the handoff points, the interface engine or FHIR façade translating between the two, where a poorly designed mapping layer can become the actual bottleneck regardless of which standard sits on either side of it.

Community Support and Ecosystem Momentum Behind Each Standard

HL7 v2's ecosystem is mature and quiet: established interface engine vendors, a deep bench of experienced integration engineers, and documentation shaped by decades of real deployments. There's little buzz around it, but there's also little risk of the knowledge base drying up, given how embedded it remains across US hospital infrastructure.

FHIR's community is the more energetic one right now. HL7 International runs active working groups, public Connectathons let implementers test interoperability against real servers before going to production, and the specification itself evolves through visible, versioned releases rather than infrequent, opaque updates. That momentum shows up in tooling too: open-source validators, reference implementations, and public test servers are far more abundant for FHIR than they ever were for v2.

For a hiring manager or team lead, this translates into a practical hiring reality. Finding engineers who already know FHIR's REST patterns is generally easier than finding engineers fluent in HL7 v2 segment structure, because FHIR's skill set overlaps with mainstream web development. That doesn't make v2 talent obsolete, it's still in demand precisely because it's harder to find, but it does shape how you plan a hiring pipeline for either standard.

Licensing and Openness: What It Means for Your Build

Both standards are published by HL7 International, and both are free to implement without licensing fees, so cost isn't the differentiator here. The difference is in how open the ecosystem around each one feels in practice.

FHIR was built with public accessibility as a design goal from the start. The specification is freely browsable online, public test servers let you validate against a real implementation without a membership agreement, and the HL7 FHIR overview itself is written to be approachable by developers who've never touched a healthcare standard before. That openness is a big part of why FHIR attracted mainstream software engineers faster than HL7 v2 ever did.

HL7 v2 and CDA aren't gated behind fees either, but their documentation and tooling ecosystem grew up in an era before public developer-first standards were the norm. Getting productive with v2 has historically required vendor-specific implementation guides and institutional knowledge that isn't always written down anywhere public. Neither standard poses a legal or cost barrier to adoption. FHIR's openness is baked into its developer experience; HL7 v2's openness exists on paper but takes more institutional effort to actually use.

AstraRad's Perspective: Integrating HL7 and FHIR in Radiology Workflows

Radiology sits at the intersection of both standards. Order and result messaging still runs on HL7 v2 in most imaging environments, while FHIR's ImagingStudy and DiagnosticReport resources increasingly power viewer launches and portal access without a second login.

AstraRad's PACS integrations connect through existing systems rather than adding another portal for staff to manage, and turnaround performance, under one hour for STAT cases, holds up against a 99.4% SLA compliance rate. When you evaluate a teleradiology partner, ask directly how they handle PACS integration, whether they support ImagingStudy and DiagnosticReport resources, and whether SMART on FHIR single sign-on is available for your viewer stack.

Rafael

Next Steps: A Decision Checklist for HL7 and FHIR Projects

Start with an honest inventory before committing budget to either standard.

• Catalog every current interface and rank it by business criticality, not by how old or unglamorous it feels.
• Pick one FHIR pilot domain with a clear, measurable success metric before expanding further.
• Keep HL7 v2 running for operational feeds until there's a concrete reason, not just a preference, to replace it.
• Invest early in mapping documentation and observability, since that discipline determines whether coexistence stays manageable or turns into technical debt.

If your team is evaluating imaging-specific integration work as part of this planning, AstraRad's pricing by study type and PACS integration approach are worth reviewing alongside your interface roadmap.

Sources

• NLM: Health data standards overview
• HL7: Comparison between FHIR and other HL7 standards
• Healthit
• PMC: DICOM versus HL7 for modality interfacing