Interoperability Is Not a Tech Problem: Why You Must Stop Blaming FHIR

Why is everyone still talking about HL7 v2 when FHIR is supposed to be the future?

Because 95% of U.S. healthcare organizations still run on HL7 v2 (HL7 International). That's not a typo. The standard first published in 1987 is still the workhorse for high-throughput legacy workflows. But here's the blunt truth: if you're building new integrations on v2, you're cementing a 35-year-old architecture that was never designed for modern, patient-mediated data sharing. FHIR, with its RESTful APIs and discrete resources, is the only realistic path forward for the interoperability you actually need—not just for Meaningful Use credit, but for the patient access and data liquidity that are now regulatory expectations.

Isn't FHIR just another standard that will be replaced in five years?

No, and here's why. FHIR R4, published in December 2018, was the first release with normative content (HL7 FHIR Version History). That means the core resources are stable. Since then, FHIR R5 (March 2023) expanded the resource count to 157 (HL7 FHIR Resource Index). The US Core Implementation Guide, based on R4, is now the foundation for US interoperability, defining the minimum data elements for patient access (US Core Implementation Guide). The Cures Act made information blocking illegal, and the ONC’s TEFCA framework is designed to use FHIR as the backbone (ONC / HHS TEFCA). So no, FHIR isn't a flash in the pan—it's the standard that the government is betting on. The risk isn't that FHIR will be replaced; it's that you'll keep delaying your migration because you're comfortable with the devil you know.

Can I just keep using HL7 v2 and add FHIR later?

You can, but you're making a costly mistake. HL7 v2 is still the standard for high-throughput legacy workflows, like ADT messages from your registration system (HL7 International). But it's terrible for patient-facing apps, mobile, and cloud-native development. The problem is that most organizations treat FHIR as an add-on, bolting a RESTful API onto an existing v2 backbone. That creates a Frankenstein architecture where you still have to maintain two message formats, two security models, and two governance structures. Instead, you should be actively planning to phase out v2 for all new integrations. Use v2 only for the legacy systems that are too expensive to replace. For everything else, mandate FHIR. The US Core Implementation Guide gives you a clear starting point—use it as your baseline, not a suggestion (US Core Implementation Guide).

What about the 'semantic' problem? Isn't FHIR just a wrapper for messy data?

That's a common misconception. FHIR doesn't solve semantics, but it gives you the structure to apply them. You still need terminologies like SNOMED CT, LOINC, and RxNorm (HL7 International). But FHIR resources are designed to carry those codes in a standardized way. For example, a lab result in FHIR uses an Observation resource with a LOINC code and a SNOMED CT finding. Without those codes, you're back to free-text chaos. The real issue is that many organizations skip the terminology layer and just map FHIR resources to their own proprietary codes. That's not interoperability—that's just a new way to exchange the same old silos. If you're serious about this, you need to invest in a terminology server and commit to using standardized codes from the start. LOINC alone has over 109,000 concepts (LOINC 2.82, released February 24, 2026), so there's no excuse for not mapping your labs.

How does HIPAA fit into all this? Will FHIR make me more compliant?

HIPAA doesn't care which standard you use—it cares how you protect ePHI. The Security Rule requires administrative, physical, and technical safeguards (45 CFR 164.308, 164.310, 164.312). FHIR doesn't automatically make you HIPAA-compliant, but it can help. For example, FHIR's RESTful API model lets you implement fine-grained access controls and audit logging more easily than with v2 batch messages. But remember, the HIPAA Breach Notification Rule gives you only 60 days to notify individuals after a breach (45 CFR 164.404). And the penalties are not trivial: the calendar-year cap is now over $2.1 million (Federal Register, January 28, 2026). So, if you're moving to FHIR, make sure your security team is involved from day one. Use NIST SP 800-66 as a guide—it's the official HIPAA Security Rule implementation guide (NIST SP 800-66).

Quick tip: Before you write another interface, check if the data you need is in USCDI—if it is, you should be able to get it via FHIR. If not, you're likely looking at a gap that will cost you under MIPS.

What does MIPS have to do with interoperability?

If you're a clinician, a lot. For the CY 2026 performance period, the Promoting Interoperability category is worth 25% of your MIPS score (Federal Register, CY 2026 Physician Fee Schedule). That's not a rounding error. And to avoid a 9% penalty, you need to score at least 75 points (the performance threshold). The PI category rewards things like electronic patient access and care coordination—which are exactly what FHIR enables. So, if you're still relying on v2, you're likely missing out on PI points and may even face a penalty. The choice is clear: start your FHIR journey now, or watch your reimbursement shrink.

Sources

• HL7 International - https://www.hl7.org/fhir/
• HL7 V2 Product Brief - https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
• HL7 FHIR Version History - https://www.hl7.org/fhir/history.html
• HL7 FHIR Resource Index - https://www.hl7.org/fhir/resourcelist.html
• US Core Implementation Guide - https://hl7.org/fhir/us/core/
• ONC / HHS TEFCA - https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca
• Federal Register (CY 2026 Physician Fee Schedule) - https://www.federalregister.gov/documents/2025/11/05/2025-19787
• eCFR 45 CFR Part 164 Subpart D - https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D
• Federal Register (2026 HIPAA CMP Adjustment) - https://www.federalregister.gov/documents/2026/01/28/2026-01688
• NIST SP 800-66 - https://csrc.nist.gov/publications/detail/sp/800-66/rev-1/final