Healthcare interoperability is the ability of different electronic health record systems and health IT platforms to exchange patient information and use it effectively within each receiving system. FHIR (Fast Healthcare Interoperability Resources), the HL7 standard now mandated by federal regulation, is the primary technical mechanism for that exchange in the United States. Understanding what FHIR enables, what it does not handle, and where EHR integration actually breaks down is the first thing healthcare organizations need to establish before committing to integration projects.
This post is for healthcare IT decision-makers, health system IT leaders, and digital health companies building on top of EHRs. It covers what FHIR actually is (and what it is not), how EHR integration works in practice across a multi-system environment, where Salesforce fits into the interoperability picture, and what your organization needs in place before starting.
What FHIR is and what it is not
FHIR stands for Fast Healthcare Interoperability Resources. It is an API standard developed by HL7 International for exchanging healthcare information electronically. FHIR defines how clinical and administrative data is structured (as modular "resources" such as Patient, Observation, MedicationRequest, and Encounter) and how those resources are exchanged between systems using standard web protocols: REST APIs, JSON or XML formats, and OAuth 2.0 authentication.
The key thing to understand about FHIR is what it standardizes and what it does not. FHIR standardizes the API interface and the data structure of individual resources. It does not standardize the content of those resources, the quality of the data inside them, or the clinical terminology used to code that data. A FHIR API will return a structured Patient resource with a consistent format; whether the underlying data is complete, accurate, and coded consistently using SNOMED CT or LOINC is a separate problem that FHIR does not solve.
FHIR is also not middleware. It is not an integration engine, a data warehouse, or a clinical data repository. FHIR defines how two systems talk to each other at the API layer. The infrastructure that sits between those two systems (the integration engine, the data transformation logic, the terminology mapping) is built on top of FHIR, not by FHIR.
The current regulatory baseline is FHIR R4, mandated under ONC's certification requirements stemming from the 21st Century Cures Act. HL7 released FHIR R5 in 2023, and the ONC's 2026 Standards Version Advancement Process has designated FHIR R5 as an approved advancement for certified health IT. Most production implementations in 2026 are still built on R4, with R5 adoption concentrated in new builds and digital health applications.
The regulatory framework driving FHIR adoption
The regulatory environment around healthcare interoperability has changed significantly since 2020, and healthcare organizations that do not understand the current rules are making integration decisions without the full picture.
The 21st Century Cures Act and ONC certification. Under ONC's certification program, any EHR product seeking ONC certification (required for participation in most CMS quality programs and incentive payments) must expose FHIR R4 APIs for patient, provider, and payer access. This means every major certified EHR your organization runs already has FHIR APIs available. The practical implication: you do not need a vendor to build a custom interface for basic data exchange. The FHIR endpoint exists, and the question is how your organization accesses and uses it.
Information blocking rules. The Cures Act established information blocking rules prohibiting healthcare actors (providers, health IT developers, and health information networks) from engaging in practices that interfere with the access, exchange, or use of electronic health information, except as specified under defined exceptions. For healthcare organizations, this means you generally cannot prevent patients, other providers, or authorized applications from accessing electronic health information through FHIR APIs. Organizations that have historically used proprietary data formats or contractual restrictions to limit data sharing face compliance exposure under these rules.
TEFCA. The Trusted Exchange Framework and Common Agreement, launched operationally in 2023 and expanding through 2026, provides a governance and technical framework for nationwide health information exchange using FHIR. TEFCA connects qualified health information networks and their participants under a common set of rules, enabling record retrieval, event notifications, and public health reporting across organizational boundaries. For health systems and payers evaluating their interoperability strategy, decisions about TEFCA participation are now part of that conversation.
ONC HTI-1 Rule. The Health Data, Technology, and Interoperability rule published in January 2024 introduced requirements for clinical decision support transparency (affecting AI-powered CDS tools) and updated standards for information exchange. Healthcare organizations that run AI-enabled clinical tools need to understand how HTI-1 applies to their environment and which documentation requirements it triggers.
How EHR integration actually works in practice
Most healthcare organizations operate in a hybrid integration environment. Legacy HL7 v2 interfaces handle the bulk of internal clinical messaging (ADT notifications, lab results, orders) because that infrastructure was built before FHIR existed and replacing it is expensive and operationally risky. FHIR APIs layer on top, primarily handling patient access applications, payer data exchange, and external digital health integrations.
The integration architecture for a typical health system in 2026 includes several distinct layers.
Interface engines. Products like Mirth Connect, Rhapsody, and Infor Cloverleaf translate between HL7 v2 messages, FHIR resources, and proprietary formats. They route messages between systems, apply transformation rules, and handle the operational complexity of keeping dozens of point-to-point interfaces functioning. Interface engines are essential infrastructure in most health systems and are not going away with the adoption of FHIR. They are evolving to handle FHIR alongside HL7 v2.
Cloud health data platforms. Microsoft Azure Health Data Services, AWS HealthLake, and Google Cloud Healthcare API provide FHIR-native data stores that ingest, normalize, and make clinical data available for analytics, AI applications, and downstream integrations. These platforms are becoming the foundation for health system data strategy in organizations modernizing their integration infrastructure. They do not replace the interface engine layer but sit above it, providing a normalized FHIR data layer accessible to applications and analytics tools.
Clinical data repositories and HIEs. Health information exchanges provide regional and statewide record retrieval and patient matching across organizational boundaries. HIE connectivity, combined with TEFCA participation, gives health systems access to patient records outside their own networks without having to build bilateral connections with each external organization.
Direct FHIR integrations. Digital health applications, patient portals, payer systems, and third-party analytics tools now connect directly to EHR FHIR endpoints using SMART on FHIR authentication, an OAuth 2.0 profile designed for healthcare API security. This is where most of the new integration development is happening, and where organizations need to think carefully about API management, rate limiting, and governance.
Clinical data integration across multiple systems
The phrase "clinical data integration" covers a set of problems that are harder than the API layer. Getting two systems to exchange a FHIR resource is solvable with the right technical team. Getting the data inside that resource to mean the same thing in both systems, and to remain accurate and usable over time, is where most multi-system integration projects run into trouble.
Terminology normalization. Clinical data is coded using multiple terminologies: ICD-10-CM for diagnoses, CPT for procedures, LOINC for lab tests and observations, SNOMED CT for clinical findings, RxNorm for medications. When data moves between systems, those codes need to map consistently. A lab result coded with one LOINC code in the source system needs to be recognized correctly in the receiving system. Inconsistent terminology mapping produces data that appears to have arrived but cannot be used clinically or analytically without additional cleanup.
Patient identity matching. When patient records exist in multiple systems, as they do in virtually every health system, payer, and digital health company, matching those records to the same individual is a persistent problem. Different systems use different patient identifiers, different name formatting conventions, and different demographic data fields. A Master Patient Index spanning your integration environment is not optional in a multi-system architecture; it is the foundation on which everything else depends.
Data governance. Who owns the integration layer? Who is responsible when data does not arrive, arrives corrupted, or arrives out of order? Who validates that the FHIR resources your systems are exchanging actually contain the data your clinical and operational workflows expect? These governance questions need to be answered before integration projects start, not after they encounter problems. The most common reason healthcare IT integration projects stall is not a technical failure. It is a governance failure, typically around ownership, accountability, and the process for resolving data quality issues.
HIPAA and BAA coverage. Every vendor, cloud platform, or third-party service that touches PHI in your integration environment requires a Business Associate Agreement. In a modern healthcare data architecture with multiple integration components, cloud platforms, and application vendors, BAA coverage needs to be tracked systematically, not managed as an afterthought when a new vendor is onboarded.
Where Salesforce fits in the interoperability picture
Salesforce Health Cloud is not an EHR. It is a CRM platform built for healthcare, designed for care coordination, patient engagement, population health management, and provider relationship management. Understanding where it sits in the interoperability architecture prevents a common and expensive category error.
The integration pattern for Salesforce Health Cloud in a health system environment is as follows: the EHR remains the system of record for clinical documentation, orders, and medications; Health Cloud connects to the EHR via FHIR APIs to surface relevant patient data for care coordination and engagement workflows. A care manager working in Health Cloud can see a patient's recent hospitalizations, active conditions, and medication list pulled from the EHR, without duplicating the clinical record or requiring the EHR to manage the patient relationship workflow.
Salesforce's Einstein Trust Layer provides HIPAA-compliant data handling for PHI within the Salesforce platform, which addresses a core concern for healthcare organizations evaluating whether Salesforce can operate in a regulated data environment.
The areas where Health Cloud integration with EHRs delivers measurable value are care gap closure (identifying patients who have not had required screenings or follow-ups), care management for high-risk populations (coordinating complex care across clinical and social services), and patient outreach (automated, personalized communication at scale). These are workflows where the CRM layer adds value precisely because the EHR was not designed to support them.
For organizations evaluating whether Health Cloud belongs in their interoperability architecture, the question to ask is not "what data can it receive from the EHR" but "what clinical and operational workflows are we trying to support that our EHR cannot handle?" The FHIR integration is the plumbing; the workflow design is the work.
Our healthcare IT consulting practice has helped health systems, digital health companies, and medtech organizations design the integration architecture for Health Cloud implementations, including FHIR API configuration, data governance frameworks, and the clinical workflow design that determines what Health Cloud can actually do once the data arrives.
What your organization needs in place before starting
Healthcare organizations that approach EHR integration as a technology procurement problem consistently underestimate the work. The technology decisions (which integration platform, which FHIR implementation, which cloud data services) are answerable questions with good answers. The organizational questions are where projects stall.
Before committing budget and vendor relationships to an interoperability initiative, the organizations that execute well have typically worked through these questions.
Who owns the integration layer? In most health systems, the EHR team, the network team, and the data analytics team all have partial ownership of different pieces of the integration infrastructure. When a FHIR API fails, who gets the call? When a data mapping breaks and lab results arrive in the wrong format, who fixes it and within what SLA? Interoperability infrastructure needs a defined owner, defined escalation paths, and a team with the authority to make decisions across the affected systems.
What is the patient identity strategy? Before integrating clinical data across systems, the organization needs a functioning Master Patient Index or a clear plan for one. Patient matching is not a problem that resolves itself after integration. It compounds over time if it is not addressed before data starts flowing.
What does HIPAA compliance look like across the integration architecture? BAA coverage, data retention policies, audit logging, and access controls need to be mapped to the specific vendors, platforms, and data flows in your environment. This is not a one-time compliance exercise; it needs to be maintained as the architecture evolves and vendors are added or changed.
What is the clinical use case? The most technically successful EHR integrations are those where the clinical use case is specific, the expected workflow change is understood, and the clinicians who will use the data are involved in defining their needs. Integration projects driven primarily by IT strategy, without a defined clinical problem they are solving, tend to produce data that arrives and sits unused.
Tristella's healthcare IT partner, works with organizations at this stage: before the platform decisions, to define the integration architecture that matches clinical and operational goals, and to identify the governance questions that need answers before the project starts. Tristella's healthcare IT advisory practice works with a small number of clients at a time. Senior partners are on every engagement, not a staffed delivery team, which matters when the questions being answered require judgment, not a playbook.
Tristella's healthcare IT practice covers EHR integration strategy, Salesforce Health Cloud advisory, and clinical AI governance for health systems, digital health companies, and medtech organizations. Contact us to discuss what your organization is working through.
Related reading:
What Is Salesforce Health Cloud and Is It Right for Your Healthcare Organization?
What Is a Healthcare IT Consultant? Roles, Costs, and When to Hire One
What Does a Healthcare IT Strategy Consultant Do, and When Do You Need One?
AI Governance for Healthcare: HIPAA, Clinical AI, and What Regulated Organizations Actually Need
Healthcare IT Strategy for Medtech, Pharma, and Life Sciences