← All articles

HL7 vs FHIR: which standard should power your integration?

HL7 vs FHIR: which standard should power your integration?

Decorative hand-drawn title card illustration

Pick FHIR for new API-driven interfaces. Keep HL7 v2 wherever entrenched operational messaging already works. Default to a hybrid gateway when both are true at once, which they usually are in any hospital or clinic network older than a few years.

That’s the whole decision in one sentence, but three exceptions change the calculus. High-volume, low-latency event streams (think real-time bed-management feeds or lab instrument interfaces) often still run faster and cheaper on established HL7 v2 pipes. Vendor lock-in matters too. If your core patient administration system only speaks HL7 v2 and the vendor has no near-term FHIR roadmap, you build around that constraint rather than against it. Regulatory and national conformance requirements are the third wrinkle. Some government-facing services mandate specific implementation guides that go well beyond generic FHIR.

  • High-throughput internal feeds: established HL7 v2 interfaces often outperform a fresh FHIR build for pure volume.
  • Vendor lock-in: legacy core systems without FHIR support force pragmatic workarounds.
  • Regulatory mandates: some national services require specific conformance profiles, not generic FHIR.

The rest of this comparison unpacks the technical differences behind that verdict, the migration traps most teams hit, and what to check against Australian conformance guidance like AU Base and AU Core before you commit a build to either path.

Key Takeaways

FHIR wins for new API-driven work and modern app integration, while HL7 v2 remains the pragmatic choice for proven, high-volume internal messaging that already works.

Point Details
Match the standard to the workflow Use FHIR for external APIs and apps; keep HL7 v2 for entrenched internal messaging like ADT and lab orders.
Terminology mapping is the real cost Structural conversion (PID to Patient) is largely mechanical; LOINC, SNOMED CT, and RxNorm mapping needs ongoing governance.
Check AU Base and AU Core early National services like MHR need ADHA-specific implementation guides, not just generic FHIR conformance.
Hybrid gateways are the common outcome Most production environments run HL7 v2 feeds normalised into a FHIR façade rather than picking one standard outright.
Coordination tools sit alongside this infrastructure Meddle’s matching and referral platform complements integration work by simplifying practitioner allocation and referral handoffs for allied health clinics.

Table of Contents

HL7 vs FHIR starts with understanding what HL7 actually is

HL7 isn’t one standard. It’s a family, and knowing which member you’re dealing with changes everything about your integration plan.

HL7 v2 is the workhorse still running inside most hospital and pathology systems today. It’s a pipe-delimited, segment-based messaging format, meaning a single message string looks like a wall of text separated by | characters, with each segment carrying a specific type of data. An ADT (Admit, Discharge, Transfer) message tells downstream systems a patient has been admitted. An ORM (Order) message carries a request for a lab test or imaging study. An ORU (Observation Result) message carries the results back. These three message types alone handle the bulk of daily clinical traffic in most acute care settings.

HL7 v3 arrived as an attempt to fix v2’s inconsistencies with a more rigorous, model-driven approach based on the Reference Information Model. It never achieved broad adoption outside specific document use cases, largely because its complexity made implementation slow and expensive compared to the ubiquity v2 already had.

CDA (Clinical Document Architecture), a product of the v3 effort, found more traction. It’s document-centric rather than message-centric, structuring things like discharge summaries and referral letters as complete, human-readable XML documents rather than discrete transactional messages. CDA still underpins a meaningful slice of clinical document exchange, particularly for summaries that need to be read as a whole rather than parsed field by field.

What ties HL7 v2 and CDA together operationally is how they move:

  1. MLLP over TCP (Minimal Lower Layer Protocol) is the classic transport for HL7 v2, a lightweight wrapper that frames messages for point-to-point delivery over a persistent socket connection.
  2. File drops remain common in older or budget-constrained environments, where a message lands as a text file in a watched directory and gets picked up by a listener process.
  3. Interface engines (commercial products like Rhapsody or Mirth Connect, among others) sit in the middle of most real deployments, translating, routing, and transforming messages between systems that were never designed to talk to each other directly.

That interface engine layer is often the unsung hero of hospital IT. It’s also frequently the bottleneck, the single point of failure, and the reason a lot of “simple” integration projects blow their timeline. Understanding that HL7 v2 relies on this middleware ecosystem, rather than working peer-to-peer natively, is essential before you compare it against FHIR’s very different architecture.

What FHIR actually is: resources, REST, and modern tooling

FHIR (Fast Healthcare Interoperability Resources) replaces HL7 v2’s rigid message snapshots with granular, reusable resources you can retrieve or update individually, and it requires human-readable content inside every resource, according to HL7’s own comparison documentation.

That distinction matters more than it sounds. Instead of a whole ADT message describing an entire patient encounter, FHIR breaks the same information into discrete resources: Patient, Encounter, Observation, MedicationRequest, and dozens more, each independently addressable. Want just the patient’s current allergies? Query the AllergyIntolerance resource directly instead of parsing an entire message to extract one field.

FHIR is built on standard web technology, which is precisely what makes it attractive to modern development teams:

  • RESTful operations using standard HTTP verbs: GET to retrieve a resource, POST to create one, PUT to fully replace one, and PATCH to update part of one without resending everything.
  • JSON or XML encoding, with JSON dominating new development because most web and mobile frameworks handle it natively without extra parsing libraries.
  • OAuth2-based security, meaning FHIR APIs plug into the same authentication and authorisation patterns every other modern web API uses, rather than requiring bespoke healthcare-specific security tooling.
  • Profiles and extensions let implementers constrain or extend the base FHIR specification for local needs, such as adding an Indigenous status field or restricting which fields are mandatory for a national program.
  • A mature open tooling ecosystem, including reference servers like HAPI FHIR, validation tools, and public test servers that let a developer stand up a working FHIR endpoint in an afternoon rather than a fortnight.

That last point deserves emphasis. A junior web developer with no healthcare background can pick up FHIR’s REST conventions in days, because they’re the same conventions used by Stripe, Twilio, or any modern SaaS API. That’s a fundamentally different hiring and onboarding proposition than HL7 v2, which usually demands someone who has specifically worked with pipe-delimited healthcare messaging before.

Similarities and why both standards still matter

FHIR didn’t emerge to erase HL7. Both standards support profiling and extension mechanisms, both encode clinical messaging semantics (a lab result is still a lab result, structurally different but conceptually identical), and both remain live, actively maintained specifications.

FHIR can satisfy the needs earlier HL7 standards addressed, but HL7 v2 remains widely used in production, and many organisations run both standards in parallel rather than picking one, according to HL7’s build documentation. The coexistence isn’t a transitional accident. It’s the practical reality of healthcare IT, where:

  • Core hospital systems built over decades on HL7 v2 rarely get ripped out wholesale.
  • New patient-facing apps and external partner integrations almost always default to FHIR.
  • Gateway architectures translate between the two, letting legacy and modern systems each do what they do best.

Deep technical differences that change your mapping work

The high-level pitch (HL7 is old, FHIR is new) undersells what actually changes at the engineering level. Four differences drive most of the real mapping and architecture decisions.

1. Granularity reshapes retrieval and reuse. HL7 v2 messages are self-contained snapshots. If you need one lab value, you’re still parsing an entire ORU message to extract it. FHIR resources are independently addressable, so a mobile app can request a single Observation without pulling an entire encounter’s worth of data. This changes how you design caching, how much bandwidth mobile clients consume, and how granular your access control needs to be.

2. Extension discoverability differs enormously. HL7 v2’s local extension mechanism is the Z-segment, a custom segment prefixed with “Z” that a hospital or vendor invents for something the base standard doesn’t cover. Z-segments are opaque. There’s no registry, no standard documentation format, and no way for an outside developer to discover what a given Z-segment means without asking someone who built it. FHIR extensions, by contrast, are exposed as resolvable URIs, making extensions and profiles discoverable and reducing the collision risk you get when two vendors independently invent incompatible custom fields, per HL7’s comparison guide.

3. Identity handling forks in a way that catches teams out. HL7 v2 tends to embed data inline within a message, contained and self-referential. FHIR resources reference each other by identifier, so a MedicationRequest points to a Patient resource rather than repeating the patient’s details inline. That’s more efficient once your data is properly modelled, but it means identity resolution, making sure the Patient reference in one system actually matches the Patient reference in another, becomes a first-class design problem rather than something you can ignore.

4. Update behaviour is a genuine architectural fork. HL7 v2 works in snapshots. An update means sending a whole new message describing the current state. FHIR supports incremental change through PATCH operations and the Task resource pattern, letting a system update a single field or track an asynchronous workflow step without resending the entire resource. This is the difference between “resend the whole file every time something changes” and “update just what changed,” and it has real bandwidth and concurrency implications at scale.

Pro Tip: Don’t assume structural mapping (PID to Patient, OBX to Observation) is the hard part. It’s mechanical and mostly solved. The genuine time sink is identity resolution and terminology mapping, and teams that budget for structural conversion alone consistently blow their timelines on the parts nobody warned them about.

Deep technical differences that change your mapping work — overview diagram

Transport, encoding and the developer experience gap

The engineering cost of each standard shows up well before go-live, in how hard the code is to write and who you can hire to write it.

Parsing pipe-delimited HL7 v2 messages requires either a dedicated library or hand-rolled string splitting that’s more fragile than it looks, especially once you account for repeating fields, escape characters, and vendor-specific quirks. FHIR’s JSON or XML payloads parse with standard libraries available in every mainstream language, with zero healthcare-specific tooling required to get started.

  • HL7 v2 typically runs over MLLP/TCP with security bolted on separately, often via VPN tunnels or private network segments rather than anything built into the protocol itself.
  • FHIR uses standard HTTPS and OAuth2, meaning your existing API gateway, load balancer, and identity provider likely already support it without modification.
  • Middleware patterns diverge too: HL7 v2 leans on interface engines for transformation and routing, while FHIR often sits behind a straightforward API gateway doing much lighter lifting.

The staffing implication is significant. FHIR is web-native and aligns with mainstream web development skills, which generally makes developer hiring and delivery faster for API-focused projects than sourcing HL7 v2 specialists, according to analysis from OpenMalo. If your project timeline depends on finding and onboarding contractors quickly, that skills gap alone can decide which standard you choose for new work.

Use cases and a simple decision matrix

Cut through the theory with a straightforward checklist. Ask these questions before you commit to either standard for a given integration:

  1. What’s the workflow type? Internal, high-frequency operational messaging (admissions, orders, results) points toward HL7 v2. External-facing, app-driven, or partner-integration work points toward FHIR.
  2. Who are the downstream consumers? A hospital’s own ADT feed to twenty internal systems is a different problem to a patient-facing mobile app calling an API from outside your network.
  3. What are the performance and SLA requirements? Sub-second, high-throughput internal messaging often still favours the mature, battle-tested HL7 v2 pipes already in production.
  4. Does a national or regulatory mandate apply? Some government services specify exact conformance requirements that override general preference either way.

Mapped against common scenarios, the pattern holds fairly consistently:

  • ADT and results messaging between core hospital systems: stick with HL7 v2. It works, it’s proven, and ripping it out for the sake of modernity rarely justifies the risk.
  • Patient-facing apps and external partner APIs: build on FHIR. It’s the standard the wider developer ecosystem, and increasingly regulators, expect for anything reaching outside your four walls.
  • Everything in between: a hybrid gateway, where HL7 v2 feeds normalise into a FHIR façade for external consumption, according to OMOPHub’s technical guide.

A worked example: a mid-sized allied health network wants a patient app showing upcoming appointments and recent test results. The core practice management system only speaks HL7 v2. The sensible outcome isn’t ripping out the practice management system. It’s building a FHIR façade that translates the existing v2 feed into Appointment and Observation resources the app can query directly, leaving the proven internal messaging untouched.

Migration and interoperability challenges from HL7 v2 to FHIR

Converting HL7 v2 to FHIR is really two separate projects wearing one name, and treating them as one is where most timelines go wrong.

Structural translation (mapping PID segments to Patient resources, OBX segments to Observation resources) is comparatively mechanical. The build.fhir.org comparison notes this mapping is generally straightforward for common segments, though identity resolution and provenance handling often demand extra design decisions beyond simple field-to-field conversion.

Terminology mapping is the harder, ongoing stage. Local clinical codes, hospital-specific lab codes, internally invented diagnosis shorthand, need translation to standard terminologies like LOINC, SNOMED CT, or RxNorm, and that mapping work needs continuous governance rather than a one-off migration sprint.

Common blockers worth planning around before they surprise you:

  • Local and legacy codes with no clean mapping to a standard terminology, requiring manual clinical review rather than automated translation.
  • Identifier gaps, where the same patient or provider has inconsistent identifiers across systems being merged.
  • Version fragmentation, where different departments or vendors run different HL7 v2 versions or FHIR releases simultaneously, each with subtly incompatible field behaviours.

The 2025 State of FHIR survey found fragmented version use and inconsistent implementation remain ongoing adoption barriers, with terminology mapping and governance cited as the largest persistent obstacles to genuinely usable FHIR data, per AIGILX Health’s conversion guide.

Pro Tip: Build a normalisation layer between your HL7 v2 feeds and your target data model, and treat structural conversion and terminology mapping as genuinely separate stages with separate owners. Teams that assign one person to “do the FHIR migration” end up with someone doing excellent structural mapping and hoping terminology issues sort themselves out. They don’t.

Implementation checklist and best practices

A well-scoped integration project follows a predictable sequence, whether you’re building your first FHIR façade or extending a decade-old HL7 v2 estate.

  1. Inventory your current messaging. Document every interface, message type, and downstream consumer before touching architecture decisions.
  2. Define scope and success metrics up front. What does “done” look like, and how will you measure it, before code gets written?
  3. Choose your interface engine and FHIR server. Whether that’s a commercial interface engine paired with an open-source FHIR server like HAPI FHIR, or a fully managed alternative, decide early since it shapes everything downstream.
  4. Pick a terminology service. Mapping to LOINC, SNOMED CT, or RxNorm needs a defined tool and owner, not an ad hoc spreadsheet.
  5. Build a profiling and governance plan, including a check against AU Base and AU Core conformance where the integration touches Australian national services.
  6. Set up CI/CD for schema validation. Automated tests catching broken resource structures before deployment save far more time than manual QA cycles.
  7. Plan your rollout strategy and ongoing mapping maintenance. Terminology mapping isn’t a launch task, it’s a standing operational responsibility.

The governance step is where most projects underinvest. A normalisation layer pattern that separates structural conversion from terminology mapping gives you two smaller, testable problems instead of one unmanageable one, and it makes the ongoing terminology maintenance work someone’s actual job rather than an afterthought nobody owns.

Australian conformance and operational notes to check

If your integration touches any Australian national health service, generic FHIR conformance isn’t enough on its own.

AU Base is Australia’s national baseline FHIR R4 profile set. AU Core sits on top as a stricter conformance layer, and ADHA-specific implementation guides govern services like the My Health Record (MHR), electronic prescriptions, and immunisation records, according to Australian digital health technical standards documentation. Assuming vanilla FHIR compliance is sufficient for a national service is one of the more common and expensive mistakes implementers make.

Practical checkpoints before you build:

  • Confirm whether your integration falls under AU Base (general baseline conformance) or requires the stricter AU Core profile.
  • Check whether an ADHA-specific implementation guide applies, particularly for anything touching MHR, prescriptions, or immunisation data.
  • Review HL7 Australia’s guidance and the Australian FHIR Management Framework, which local implementer communities and HL7 Australia maintain alongside regular connectathon events where implementers test conformance against real scenarios.
  • Verify identifier and terminology particulars specific to national services. Australian identifier schemes and terminology bindings don’t always map cleanly from generic international guidance.

Connectathons run by HL7 Australia are worth attending even if you’re not ready to submit an implementation for testing. Watching other teams hit the same identifier and terminology snags you’re about to hit is cheaper than discovering them in production.

Practical mapping examples: lab results, medications and patient portals

Three everyday scenarios show where mapping effort actually concentrates, beyond the theory.

Hands sorting data cards representing HL7 and FHIR

Lab result (ORU to Observation): an HL7 v2 ORU message carries a result segment with a local lab code. Converting it to a FHIR Observation resource is structurally simple, the result value and units map cleanly, but the local lab code needs translation to a standard LOINC code before the resource is genuinely interoperable outside its originating system. That terminology step is where the real effort sits, not the resource structure itself.

Medication update (order to MedicationRequest): an HL7 v2 medication order maps to a FHIR MedicationRequest resource, but tracking the order’s progress, dispensed, administered, discontinued, benefits from FHIR’s Task resource pattern, which HL7 v2’s snapshot model has no clean equivalent for. This is a case where FHIR’s incremental update model genuinely outperforms the older message-based approach.

Patient portal (GET patterns vs message snapshots): a patient portal querying “show me my last three blood pressure readings” is a natural FHIR GET request against the Observation resource, filtered by patient and code. Doing the same thing against an HL7 v2 feed means either storing every historical message or maintaining a separate queryable database built from parsed messages, since v2 has no native query interface at all.

Scenario HL7 v2 source FHIR target Where mapping effort concentrates
Lab result ORU message Observation resource LOINC terminology mapping
Medication order Order segment MedicationRequest + Task Status tracking across lifecycle
Patient portal query Parsed message store Observation GET query Identity and access control

Genomics-driven clinical decision support is a good illustration of where this granularity pays off in practice. SignalPGx’s work integrating pharmacogenomics with FHIR and CDS Hooks shows how discrete, queryable resources let a clinical decision support tool pull exactly the genomic data point it needs at the point of prescribing, without parsing an entire message to find one variant result.

Where the real risk sits in this decision

Most HL7 vs FHIR debates get framed as a technology contest, and that framing misses the actual failure mode. The standards themselves rarely break projects. Governance does.

I’ve seen the structural mapping phase, PID to Patient, OBX to Observation, treated as the hard part when it’s genuinely the easy part. The terminology mapping and the identity resolution work, the unglamorous stuff nobody wants to own long-term, is where projects quietly stall for months. Teams that phase into FHIR pragmatically, keeping HL7 v2 running where it’s proven and building FHIR façades only where external access is genuinely needed, consistently outperform teams chasing a full rip-and-replace on a deadline.

How Meddle fits alongside your integration work

Building HL7 or FHIR interfaces solves how systems exchange data. It doesn’t solve how patients actually get matched to the right practitioner once that data exists. Meddle sits on top of that infrastructure layer as a coordination platform purpose-built for allied health, using algorithmic matching to connect patients with practitioners who genuinely suit their needs, not just whoever has the next available slot.

Meddle

For clinics already investing in modern integration work, Meddle adds referral automation, secure messaging, and a practice management dashboard that plugs into your existing workflow rather than replacing it. Referring GPs and support coordinators get structured referral templates that cut back-and-forth clarification, and clinics get analytics on where patient demand and practitioner capacity actually align. If you’re scoping an integration roadmap and want to see how coordination and matching fit into it, explore how Meddle works and check pricing for your clinic size.

Sources

FAQ

Is FHIR replacing HL7?

FHIR is displacing HL7 v2 for new API-driven and app-facing work, but HL7 v2 remains widely used in production, and most organisations run both standards in parallel rather than fully retiring v2, per HL7’s own comparison.

Is HL7 outdated?

HL7 v2 is decades old but still handles the bulk of daily operational messaging in hospitals reliably. It’s mature rather than obsolete, and ripping it out where it already works rarely justifies the risk.

What are the disadvantages of FHIR?

FHIR still requires solving terminology mapping and identity resolution, which the 2025 State of FHIR survey flagged as the largest persistent adoption barriers, and Australian implementers must also check AU Base and AU Core conformance rather than assuming generic FHIR compliance is sufficient.

Is HL7 a coding language?

No. HL7 is a messaging and document standard, a specification for how healthcare data is structured and exchanged, not a programming language. HL7 v2 messages use a pipe-delimited text format, while FHIR resources use JSON or XML, both parsed and generated by code written in ordinary programming languages.

When should I keep HL7 v2 instead of migrating to FHIR?

Keep HL7 v2 for high-volume, proven internal messaging like ADT and lab order feeds where the existing interface engine setup already performs reliably, and reserve FHIR for new external APIs, patient-facing apps, and partner integrations.