FHIR Alone Won't Fix Interoperability: Why You Need to Master the Data First

The Contrarian Claim: FHIR Is Not the Problem, and It's Also Not the Solution

You've heard it a hundred times: 'Just adopt FHIR and your interoperability problems will melt away.' It's a seductive pitch, and it's half right. FHIR is a powerful tool, but if you think swapping your HL7 v2 interfaces for FHIR APIs is the magic bullet, you're in for a rude awakening. The truth is, FHIR is just the messenger. If the data you're sending is garbage, all you've done is build a faster, more modern pipeline for garbage. And that's exactly what I see happening in health systems across the country.

Here's the blunt reality: interoperability isn't about the transport protocol. It's about the data. You can have the most elegant FHIR implementation on the planet, but if your problem lists are free-text scribbles, if your lab codes are a mix of LOINC and local codes, if your medications are entered as brand names instead of RxNorm concepts, then your FHIR API is just a pretty wrapper around a data swamp. Clinicians will still have to hunt for the information they need, and you'll still be drowning in 'integration' tickets. So, before you spend another dollar on FHIR tooling, ask yourself one question: Do I actually understand, standardize, and govern the data that flows through my systems? If the answer is no, then FHIR is a distraction.

The Real Issue: Semantic Interoperability vs. Syntactic Interoperability

Let's get one thing straight. There are two levels of interoperability, and most organizations are stuck at the first. Syntactic interoperability means your systems can exchange data — the messages are well-formed, the fields line up, the JSON parses. FHIR handles this beautifully. But semantic interoperability means the receiving system understands the data in the same way the sending system does. That's where the rubber meets the road, and that's where most health IT projects fail.

The fact base makes this distinction clear. HL7's own materials note that 'HL7 v2 remains the standard for high-throughput legacy workflows, while FHIR is favored for developer-facing, mobile, and cloud-native applications' (HL7 International). But neither standard solves the semantic problem on its own. To achieve true semantic interoperability, you need to adopt and enforce terminology standards like SNOMED CT, LOINC, and RxNorm. These aren't optional add-ons; they're the backbone of meaningful data exchange.

Consider this: LOINC version 2.82, released in February 2026, contains over 109,000 concepts, including 66,000+ lab and 28,000+ clinical terms (LOINC, loinc.org). That's a rich vocabulary, but it's only useful if your systems actually map their local codes to LOINC. Similarly, SNOMED CT is a designated standard for U.S. federal systems, and RxNorm normalizes drug names across pharmacy vocabularies (NLM). If you're not using these standards as the foundation of your data, then FHIR is just rearranging deck chairs on the Titanic.

The Hidden Cost of Ignoring Data Quality: HIPAA Penalties and Information Blocking

Now, you might think, 'We'll get to data quality later.' But the stakes are higher than you think. Poor data quality doesn't just frustrate clinicians; it can trigger HIPAA violations and information blocking claims. Under the HIPAA Privacy Rule, the 'minimum necessary' standard requires that you limit uses and disclosures of PHI to what's needed for the intended purpose (45 CFR 164.502(b), eCFR). If your data is a mess, you might inadvertently disclose more than necessary — or fail to provide the right data to a patient or another provider, which could be construed as information blocking.

The Cures Act made information blocking a real legal risk. It applies to healthcare providers, health IT developers, and HIEs, and the definition is broad: any practice that is likely to interfere with access, exchange, or use of EHI, unless covered by an exception (ONC/HHS, Information Blocking). The ONC even delayed the applicability date to April 5, 2021, but that's ancient history now. The point is, if you can't share clean, complete data in a timely manner because your systems are a tangle of incompatible codes, you're exposed. And let's not forget the HIPAA penalties: as of January 2026, the annual cap for willful neglect not corrected is a whopping $2,190,294 (Federal Register, 2026 HIPAA CMP Adjustment). That's enough to sink a small health system.

How to Fix Your Data Foundation: A Practical Framework

So, what do you do? Stop chasing FHIR, and instead, invest in a data governance program. Here's a step-by-step framework that will actually move the needle:

• Inventory your data elements. Know what you're storing, where, and in what format. Create a data dictionary that maps local codes to standards like LOINC, SNOMED CT, and RxNorm.
• Adopt a terminology server. You need a centralized tool to manage mappings and cross-walks. Don't try to do this in spreadsheets.
• Enforce standards at the point of entry. Build validation into your EHR workflows so clinicians can't enter free-text where a coded value is required.
• Track and measure. Use dashboards to monitor the percentage of data elements that are properly coded. Set targets and hold teams accountable.

This isn't glamorous work, but it's the work that matters. The fact base confirms that as of 2021, 96% of U.S. hospitals and 4 in 5 office-based physicians have adopted certified EHRs (ONC/HHS, Report to Congress). So, the plumbing is in place. The problem is what's flowing through the pipes.

Quick tip: Don't try to map everything at once. Start with the most critical data elements — medications, allergies, problems, and lab results. Get those clean, and you'll see immediate gains in clinician satisfaction and patient safety.

The Bottom Line: FHIR Is a Tool, Not a Strategy

Let me be clear: I'm not anti-FHIR. FHIR is a fantastic standard for modern, API-based applications, and it's the right choice for many use cases. But it's not a substitute for data governance. The fact base notes that FHIR R5 defines 157 resources (HL7 FHIR, Resource Index), and US Core provides a set of profiles for US Realm (US Core IG). That's great — but those resources are only as good as the data you populate them with.

So, my recommendation is simple: Stop building FHIR APIs until you've cleaned up your data. Invest in terminology management, data quality, and governance first. Then, when you do deploy FHIR, it will actually deliver on its promise. Otherwise, you're just adding a modern facade to a crumbling foundation.

Remember: interoperability is not a technology problem. It's a data problem. And the sooner you embrace that, the sooner you'll see real, lasting progress.

Sources

• ONC / HHS (Health IT) - https://www.healthit.gov/topic/health-it-basics
• HL7 International - https://www.hl7.org/fhir/
• LOINC (loinc.org) - https://loinc.org/
• NLM (SNOMED CT) - https://www.nlm.nih.gov/healthit/snomedct/index.html
• eCFR 45 CFR Part 164 Subpart E - https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E
• Federal Register (2026 HIPAA CMP Adjustment) - https://www.federalregister.gov/documents/2026/01/28/2026-01688