Why Your FHIR API Is Failing Clinicians: The Missing Terminology Layer

The Question: Why Is My FHIR API Not Improving Clinical Workflows?

You've built a FHIR API. You've mapped your data to US Core. You've checked every box. Yet clinicians still complain that the data feels 'off' — that the lab results are cryptic, the diagnoses are vague, and the medications are unrecognizable. I've seen this happen at hospitals that spent millions on interoperability. The problem isn't FHIR. It's that you forgot the terminology layer.

The Myth: FHIR Is Enough

FHIR is a fantastic standard for transporting data. It gives you RESTful APIs, resources like Patient and Observation, and a modern, developer-friendly approach. Since FHIR R4 (published December 27, 2018) introduced normative content, it's become the gold standard for new integrations (HL7 FHIR Version History). But FHIR doesn't tell you what the codes mean. It's like having a reliable mail carrier who delivers packages in boxes with labels — but the labels are in a language your recipient doesn't speak.

I've argued before that HL7 v2 is legacy and FHIR is the future. I still believe that. But I've also realized that FHIR's flexibility is a double-edged sword. You can throw any code system into an Observation resource. If you send a LOINC code for a lab test, great. But if you send a local lab code that happens to be in your system, the receiving clinician sees a string of digits that means nothing. The result: they ignore it, call the lab, or — worse — make a clinical decision based on a misinterpreted value.

The Reality: Terminology Is the Bridge

Think of it this way. FHIR is the vehicle. Terminology is the road map. Without SNOMED CT for clinical concepts, LOINC for lab observations, and RxNorm for medications, you're driving a sports car on a dirt road — you'll get there eventually, but you'll be lost and muddy.

SNOMED CT is the international clinical terminology, designated for use in U.S. federal systems. LOINC is the international standard for lab observations, with 109,325 concepts in version 2.82 (released February 24, 2026) — that's 66,861 lab concepts alone (LOINC). And RxNorm provides normalized names for clinical drugs, bridging the gap between different pharmacy vocabularies (NLM RxNorm). These aren't optional add-ons. They're the semantic glue that makes FHIR resources meaningful.

The Comparison: FHIR Alone vs. FHIR + Terminology

The Example: A Lab Result That Speaks

Let me paint a picture. A patient's hemoglobin A1c result is sent via FHIR. The Observation resource has a code system of 'urn:oid:2.16.840.1.113883.6.1' — that's LOINC. The code is '4548-4' — that's the LOINC code for Hemoglobin A1c. The value is '7.8 %'. Instantly, the clinician knows this patient's glucose control is poor. Now imagine the same result with a local code 'HBA1C' and no LOINC mapping. The clinician sees 'HBA1C: 7.8 %'. They might guess, but they're not sure. That ambiguity is dangerous.

Similarly, for a diagnosis, SNOMED CT gives you a precise concept like 'Diabetes mellitus type 2' (code 44054006) instead of a vague 'DM'. For a medication, RxNorm gives you 'Metformin 500 mg oral tablet' instead of a jumble of brand names from different pharmacies. These standards are not just nice-to-have — they're the difference between data that's exchanged and data that's understood.

The Fix: Make Terminology a First-Class Citizen

So here's my recommendation: Stop treating terminology as a post-processing step. When you design your FHIR API, include a terminology server from day one. Map every code to SNOMED CT, LOINC, or RxNorm before you send it. Use US Core profiles, which are built on FHIR R4 and reflect the U.S. Core Data for Interoperability — they already enforce some of these requirements (US Core Implementation Guide). But don't stop there. Validate your resources against terminology servers to ensure codes are active and correct.

Yes, it takes effort. You'll need to train your team, invest in mapping tools, and possibly hire a terminology specialist. But the payoff is enormous: clinicians actually trust the data, analytics become meaningful, and you avoid the costly mistakes that come from misread codes. In the long run, a FHIR API without terminology is like a car without fuel — it looks great in the driveway, but it won't take you anywhere.

The Bottom Line

The single most important thing to remember: FHIR is a transport protocol, not a clinical language. If you want your clinical data to be useful, you must pair FHIR with SNOMED CT, LOINC, and RxNorm. Anything less is just moving noise.

Sources

• HL7 FHIR Version History - https://www.hl7.org/fhir/history.html
• LOINC - https://loinc.org/
• NLM (RxNorm) - https://www.nlm.nih.gov/research/umls/rxnorm/index.html
• US Core Implementation Guide - https://hl7.org/fhir/us/core/