The Interoperability Imperative: FHIR Standards and Data Architecture in 2026

There is a version of this article that leads with the compliance deadlines, walks through the regulatory acronyms, and ends with a vague recommendation to “align your roadmap.” I am not going to write that version.

What I want to talk about instead is the architectural decision that is sitting underneath all of the regulatory activity, a decision that will determine whether your healthcare organization is positioned to work with AI effectively in the next two to three years, or whether it will spend that time unwinding technical debt it is accumulating right now.

The regulatory updates from CMS and ONC provide the forcing function. The architecture is the real story.

What Is Actually Happening Regulatorily

CMS has proposed adopting a specific set of HL7 FHIR Da Vinci implementation guides as mandatory technical requirements for payer APIs. The set includes Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), Prior Authorization Support (PAS), the Payer Data Exchange guide (PDex, which covers US Drug Formulary and Plan Net), and Clinical Data Exchange (CDex) for attachments. These are not suggestions or best-practice references. They are the technical specifications that payer systems will need to conform to.

FHIR R4 is already the baseline under the 21st Century Cures Act, and major EHR vendors including Epic and Cerner have implemented FHIR-based APIs to support patient data access. The 2026 proposals from ONC and CMS effectively extend that baseline, tightening the specific implementation guides required and setting a deprecation clock on older versions by 2028.

What this means practically is that organizations running on earlier FHIR guide versions, or on proprietary integrations that were never properly aligned with FHIR in the first place, now have a defined and shortening window to remediate.

Why This Is an Architecture Problem, Not Just a Compliance Problem

I want to be direct about something. The way most organizations are framing their response to these mandates is backwards. They are treating FHIR conformance as a compliance project, something to be delivered by a specific team, signed off, and closed. That framing will generate technically passing implementations that create significant long-term risk.

The deeper issue is that FHIR, done well, is a data architecture discipline. It requires your organization to answer questions that have nothing to do with API specifications. Questions like: where does the authoritative version of a patient record actually live across your systems? How does your integration layer handle data normalization when source formats from legacy EHRs are inconsistent? What happens to your security posture when you expose clinical data through APIs to external payer systems?

These are not questions a compliance checklist resolves. They are architecture questions, and answering them poorly has compounding consequences.

The Three Risks I See Most Often

Legacy EHR integration complexity. Mapping proprietary formats from legacy systems into FHIR resources is genuinely difficult work. It requires deep knowledge of both the source system’s data model and the target FHIR resource structure. Organizations that underestimate this tend to build translation layers that are brittle, inconsistently tested, and impossible to maintain as FHIR guide versions evolve. The 2028 expiry of older guide versions is not a distant problem for teams in this situation.

Security configurations that were not designed for API-exposed patient data. Secure FHIR implementation requires OAuth 2.0 with SMART on FHIR scopes, TLS for transport, fine-grained access controls at the resource level, and comprehensive audit logging. Each of these has to be deliberately designed and tested. Weak authentication, over-permissive scopes, and gaps in audit trails are common findings in organizations that implemented FHIR APIs under time pressure. In a post-audit environment, those gaps are HIPAA liability. In a breach scenario, they are patient trust destroyed at scale.

Vendor variability in what “FHIR-compliant” actually means. This one is underappreciated. Two systems can both pass a FHIR conformance check and still fail to communicate reliably because their implementations interpret the same resource structures differently, handle missing fields differently, or version their APIs inconsistently. Rigorous integration testing and validation, beyond the basic compliance layer, is not optional. It is the work that actually determines whether your interoperability investment delivers.

The AI Connection That Most Organizations Are Missing

This is where the regulatory compliance framing tends to obscure something strategically important.

Fragmented data in incompatible silos is the single biggest structural barrier to AI working reliably in healthcare. You cannot build effective predictive models on data that does not have a consistent format. You cannot trust inferences from AI systems when the underlying patient record is assembled from disconnected sources with no governed normalization layer. You cannot give an AI agent a coherent view of a patient’s care history if the integration architecture was not designed to produce one.

FHIR-first architecture is, at its core, the prerequisite for AI readiness. Organizations that implement FHIR thoughtfully, as a data design principle rather than a compliance exercise, are creating the data foundation that AI initiatives will actually need. Organizations that treat it as a checkbox will find, when they try to deploy AI-enabled care coordination or prior authorization automation, that their data layer cannot support what they are trying to build.

This connects to something I explored in an earlier piece this quarter on the healthcare AI regulatory landscape. The regulatory environment is converging on a single expectation: that patient data is governed, standardized, and traceable. FHIR is the mechanism through which that expectation becomes operational.

What a Future-Proof Architecture Actually Looks Like

For organizations using Salesforce Health Cloud, the architectural opportunity is real but it requires intentional design. Health Cloud’s native alignment with FHIR clinical data models means the platform is well-positioned to serve as the engagement and coordination layer across care settings. But that positioning is only realized when the EHR integration layer is properly built, typically through middleware capable of handling FHIR API orchestration, transformation, and error management at scale.

The security layer requires equal attention. Salesforce Shield provides field-level encryption, event monitoring, and audit trail capabilities that are directly relevant to HIPAA compliance in a FHIR-integrated environment. Shield is not a default configuration. It has to be scoped, implemented, and tested as part of the integration design. A signed Business Associate Agreement covers the contractual obligation. Shield covers the architectural obligation. Both matter.

For organizations not yet running a modern engagement platform, the architecture decisions are the same but the sequencing is different. The priority is to establish a reliable FHIR normalization layer between legacy EHR systems and any downstream application or analytics surface. That layer becomes the durable foundation that survives EHR vendor changes, platform migrations, and evolving implementation guide versions.

The specific implementation guides CMS is proposing as mandatory, CRD for coverage requirements discovery at the point of care, DTR for documentation and prior authorization rules, PAS for prior authorization submission, PDex for payer data exchange, and CDex for clinical attachments, each have distinct integration patterns. Designing for all of them at once, within a single coherent data architecture, is considerably more efficient than implementing them piecemeal in response to individual compliance deadlines.

What to Examine Before the Deadlines Tighten

If your organization is beginning to think seriously about FHIR readiness, there are a few honest questions worth sitting with before committing to an implementation approach.

Do you have a current picture of which systems are producing and consuming patient data, and how that data is being normalized today? The answer is often less clear than teams expect.

Have your existing FHIR API implementations been tested for security configuration, not just functional compliance? Passing a conformance check and having a secure, audit-ready API are different outcomes.

Is your integration architecture documented at a level where you could assess the impact of a guide version change without reverse-engineering production systems?

These questions sit at the intersection of data architecture, integration design, and security governance. They are also exactly what a structured assessment is designed to answer.

Independent assessments covering API and integration architecture, data and security models, and overall platform health can give organizations a clear, vendor-neutral picture of where they stand before they begin remediation work. That clarity tends to make the remediation itself significantly faster and less expensive, because the scope is defined by evidence rather than assumption.

The 2028 deprecation window may feel comfortable from where we are today. Based on the implementation timelines I see in healthcare organizations, it is not. The architecture work that needs to happen to meet these standards properly takes time, and organizations that start with a clear picture of their current state will have considerably more options than those that start with a project plan built on guesswork.

If your organization is working through the FHIR readiness question and you would find an outside perspective useful, I am happy to have that conversation. Drop a comment below or send me a message.