Your system is FHIR R4 compliant. The ONC checklist is complete. The certification audit has passed. Still, clinicians are waiting two days for a patient summary from a partner EHR. Billing team still sending manual follow-up messages to reconcile data that two “integrated” systems cannot agree on?
FHIR compliance is a core component that builds your system. According to Forrester Research, 52% of health system executives identify a lack of integrated data as the biggest barrier to delivering effective care, and most of those organizations have already implemented FHIR APIs. The certification has passed. The data still is not flowing.
The gap between compliance and interoperability is real; it is specific, and it is fixable. This post explains exactly where the gap lives and what it takes to close it.
Why FHIR Compliance Does Not Equal Interoperability
There is a useful distinction to hold onto throughout this post: FHIR compliance means you have passed an API certification test. Interoperability means data moves between two live systems in a way that both can understand and act on.
Think of FHIR compliance as having a passport. It proves you are eligible to cross borders. It does not mean you have traveled anywhere. You still need a visa, a destination, a shared language, and transportation infrastructure, and in healthcare data exchange, all four have equivalents.
Only 40% of healthcare organizations have a mature interoperability strategy in place, even as the push toward value-based care demands real-time, coordinated patient data. The other 60% are compliant. They are not interoperable.
The clinical cost of that gap is measurable. A 2024 study found that 70% of non-federal acute care hospitals participated in all four interoperability domains, sending, receiving, finding, and integrating data, yet nearly 70% of clinicians still report difficulty accessing complete patient information due to non-standard data formats, according to the Journal of the American Medical Informatics Association. And on the patient side: 32% of transferred patients experience duplicate testing, with 20% of those tests clinically unnecessary.
This is not a FHIR problem. FHIR is a capable standard. These are implementation gaps, specific, identifiable, and addressable.
Source: Health Affairs / Deloitte (via teqfocus.com, 2025)
~1 in 4 US hospital dollars goes to administrative work caused by poor data sharing. A Deloitte study estimates that unified data and workflow automation could save healthcare systems an average of $12 million annually in administrative costs.
The Five Gaps Between FHIR Compliance and True Interoperability
FHIR compliance testing validates that your API conforms to the specification. It does not test for any of the following.
Gap 1: Data Quality
A FHIR API can carry poorly coded, incomplete, or non-standardized clinical data. The standard defines the container and the resource structure, but not the quality of what goes inside it. An Observation resource that contains a local lab code that no receiving system can map is FHIR-compliant and clinically useless.
Data quality is a source system problem, not a FHIR problem. But FHIR compliance testing does not catch it. The only way to find it is to run real-world integration tests with actual partner systems and actual patient data and to build source data validation into the translation layer from day one.
Gap 2: Terminology Mapping
Two FHIR-compliant systems can still disagree on what a clinical concept means. A diagnosis coded as ICD-10 in one system and SNOMED in another will not automatically reconcile, even if both systems are FHIR R4 compliant. Value set mismatches are one of the most persistent causes of data that moves but cannot be interpreted.
This is the semantic layer of interoperability, the “shared meaning” layer that sits above structural compliance. USCDI v3 helps standardize the required data elements, but terminology mapping still needs to be explicitly built and tested for every integration.
Gap 3: Patient Matching
FHIR defines how to structure patient demographic data. It does not define how to match the same patient across two different systems that may use different patient identifiers, different name formats, or different date representations.
Without a patient matching strategy, typically a Master Patient Index (MPI) or an implementation of the IHE PIXm/PDQm profile, records either fail to match (result in missing data) or over-match (resulting in duplicate records). This is one of the most underestimated risks in any cross-organization integration. The US Match IT Act of 2024 signals that federal support for a national patient matching strategy is gaining momentum, but most organizations need a local solution now.
Gap 4: Consent and Access Control
FHIR APIs must be wrapped in SMART on FHIR‘s OAuth2 framework to ensure that data only reaches authorized consumers. But consistent consent management across a multi-system ecosystem is harder than it sounds. Different systems may handle patient consent differently, different SMART on FHIR scope implementations may grant different levels of access, and the absence of a unified consent management layer means that data sharing is either too broad (compliance risk) or too restricted (operational failure).
This gap is particularly acute in payer-to-provider and provider-to-provider integrations, where each organization has its own consent policies and access control implementations.
Gap 5: Network Reach
FHIR compliance within your own system does not help you exchange data with trading partners who are not on the same network or connected through a shared trust framework. This is where TEFCA becomes relevant.
TEFCA: the Trusted Exchange Framework and Common Agreement, is the ONC’s national framework for health information exchange. In 2024, several Qualified Health Information Networks (QHINs), including CommonWell, eHealth Exchange, and Health Gorilla, began live data exchange under the TEFCA framework. For healthcare vendors whose clients include providers or payers that participate in TEFCA-connected networks, FHIR compliance is necessary but not sufficient; QHIN participation and TEFCA alignment are the emerging requirements for true nationwide interoperability [21st Century Cures Act compliance]
What True Interoperability Actually Requires
True interoperability is not a feature you implement. It is an ongoing engineering and governance capability built on four pillars.
Standards-Aligned Architecture
Not FHIR in isolation, but FHIR R4 together with USCDI v3 data classes, SMART on FHIR for authorization, and TEFCA-readiness for network reach. Each standard addresses a different layer of the interoperability stack. Using FHIR without USCDI is like building a road without lane markings; the structure exists, but the traffic does not flow consistently.
Semantic Harmonization
Consistent terminology mapping across all data flows, including value set management and a defined approach to code system translation. This is not a one-time mapping exercise; it is an ongoing maintenance responsibility because source systems change their coding practices and USCDI data classes expand over time.
Building a terminology management layer, or using a terminology server, is the sustainable approach for organizations managing more than a handful of integrations.
Proactive Monitoring
Real-time alerting on interface failures, data mismatches, and message drops, not just reactive support. The best-implemented integration in the world will degrade over time as source systems are updated, partner feeds change, and data volumes grow. Monitoring that catches these issues before they become clinical or operational failures is a core part of interoperability, not an optional addition.
This means interface monitoring dashboards, automated conformance checks on incoming data, and exception alerting that routes issues to the right team within minutes rather than hours.
TEFCA-Readiness
As 85% of healthcare CIOs plan to increase interoperability spending over the next twelve months (Accenture, 2024), the direction is clear: organizations that are not preparing their systems for TEFCA-aligned exchange are building infrastructure that will need to be reworked. Aligning your FHIR implementation to USCDI data classes, ensuring your QHIN onboarding criteria are understood, and building audit trail capabilities now reduces the cost of TEFCA participation significantly.
Moving from FHIR Compliance to Full Interoperability [A Practical Path]
If your FHIR implementation is live but your data is still not flowing the way you expected, here is the sequence that addresses the most common gaps in priority order.
- Audit your current integrations: Map every data flow. Identify which connections have known data quality issues, unresolved terminology mismatches, or manual workarounds that signal a deeper gap. This audit does not need to be exhaustive; it needs to be honest.
- Standardize terminology: Implement a value set management layer aligned to USCDI v3. If you are using local codes, map them to standard code systems (SNOMED, LOINC, ICD-10, RxNorm) in the translation layer, not in the source system.
- Solve patient matching: If you are exchanging data with external systems, implement a patient matching approach now. An MPI or IHE PIXm/PDQm implementation prevents the silent data loss and duplication that makes integrated data unreliable.
- Harden authentication: Ensure OAuth2 and SMART on FHIR are consistently applied across all API consumers, with documented consent management policies. Test what happens when a consumer presents an expired token, a revoked scope, or an unsupported grant type.
- Prepare for TEFCA: Review your QHIN onboarding criteria. Understand which of your FHIR resources align with USCDI v3 data classes. Build the audit trail and monitoring capability that a QHIN audit will require.
None of these steps requires starting over. In most cases, they are incremental additions to an existing FHIR implementation, a terminology layer here, a monitoring dashboard there. The Deloitte estimate of $12 million in annual administrative savings from unified data gives some sense of the ROI available to organizations that invest in closing these gaps.
Closing Thoughts
FHIR compliance was the right first step. But the industry is moving past compliance as the primary measure of interoperability maturity.
The five gaps above are not unique to any one organization. They are structural features of FHIR adoption in its current phase, where the standard is widely implemented but inconsistently operationalized. Closing them is an engineering project. It starts with an honest audit of where your current healthcare integration sits on the compliance-to-interoperability spectrum.
READY TO TAKE THE NEXT STEP?
Not sure which of the five gaps applies to your system? Nalashaa’s integration team offers a free interoperability assessment, a one-hour diagnostic of your current FHIR implementation, and a clear picture of what stands between you and true data exchange.
→ Book a Free Interoperability Assessment | nalashaahealth.com/healthcare-interoperability-solutions/
Quick Reference Glossary
1: What is the difference between FHIR compliance and interoperability?
A: FHIR compliance means your API passes a conformance test against the FHIR R4 specification. Interoperability means data actually moves between two live systems in a way that both can understand and act on. Compliance is a necessary first step, not a sufficient one.
2: What is TEFCA in healthcare?
A: TEFCA (Trusted Exchange Framework and Common Agreement) is the ONC’s national framework for health information exchange. It connects health information networks under shared policies and technical standards through Qualified Health Information Networks (QHINs). Several QHINs, including CommonWell and eHealth Exchange, began live data exchange in 2024.
3: What is patient matching in healthcare interoperability?
A: Patient matching is the process of identifying that two records in different systems belong to the same individual. Without a patient matching strategy, such as a Master Patient Index or IHE PIXm/PDQm implementation, cross-system integrations either fail to connect records (data loss) or incorrectly merge them (data corruption).
4: What is SMART on FHIR?
A: SMART on FHIR is the OAuth2-based authorization framework for FHIR APIs. It defines how third-party apps authenticate, what data they can access, and how patient consent is represented. It is required for ONC Patient Access API compliance.
5: What is USCDI v3?
A: USCDI v3 (United States Core Data for Interoperability, version 3) is the set of data classes and data elements that all certified health IT systems must be capable of exchanging. It defines the standard vocabulary for what patient data should be included in FHIR-based exchanges.
Latest posts by Priti Prabha (see all)
- How to Build a FHIR API in Weeks, Not Months - April 13, 2026