Salesforce Health Cloud FHIR Integration Guide

The short answer: Health Cloud stores clinical data in a model aligned to FHIR R4, but it is not a FHIR server, and something has to move the data in. That something is either Salesforce’s own Healthcare API, a MuleSoft integration, or middleware you build. On the other side, your EHR has its own registration and approval steps that no Salesforce setting can skip. Most documented integrations move data from the EHR into Salesforce. Writing back to the EHR is documented only for specific workflows.

This guide walks through each piece: how Health Cloud models FHIR data, the ways to get it in, what Epic and Oracle Health require, and the questions to answer before anyone starts building.

Key Takeaways

Health Cloud’s Clinical Data Model is aligned to FHIR R4, not identical to it. Salesforce says so in its own documentation.
The Salesforce Healthcare API accepts FHIR requests directly, does not require MuleSoft, and is available to Health Cloud customers at no additional cost through a $0 SKU.
MuleSoft offers prebuilt healthcare assets, including Epic and Cerner APIs and an HL7 v2 to FHIR converter, if you already run MuleSoft or need more complex flows.
Epic and Oracle Health each require app registration and approval by the health system. Plan for their timelines as well as yours.
Be careful with “bidirectional sync”. The documented patterns are mostly one-way into Salesforce, with write-back for specific workflows such as scheduling and prior authorization.

A note on names. Salesforce has branded Health Cloud as “Agentforce Health” for a period, and some of its documentation still uses that name. Data Cloud is now called Data 360. Oracle Health was formerly Cerner. We use the names you are most likely to search for.

How Health Cloud models FHIR data

Health Cloud’s clinical objects follow the structure of FHIR R4 resources. Salesforce is direct about the limits: “The Clinical Data Model is built to align with HL7’s FHIR R4. However, because of the way the Salesforce platform works, the Salesforce implementation of FHIR R4 isn’t identical to how it’s defined by HL7.”

The model arrived with the Spring ’21 release. It is switched on in Setup, under FHIR R4 Support Settings, and it is available in Enterprise and Unlimited editions. If your org still uses the older packaged EHR objects, note that new customers have not been able to create records in them since Spring ’23, where a standard FHIR-aligned object exists.

The most common mappings, from Salesforce’s own object reference:

FHIR resource	Health Cloud object
Patient	Person Account (Account and Contact)
Encounter	ClinicalEncounter, with related diagnosis, provider and reason objects
Observation	CareObservation and CareObservationComponent
Condition	HealthCondition
AllergyIntolerance	AllergyIntolerance
MedicationStatement	MedicationStatement
MedicationRequest	MedicationRequest
Immunization	PatientImmunization
Procedure	PatientMedicalProcedure
CarePlan	CarePlan, with detail and activity objects
DiagnosticReport	DiagnosticSummary
Practitioner	HealthcareProvider

Salesforce also says plainly that “a middleware integration solution is required to convert messages from HL7 and FHIR-based systems to the fields and objects in Salesforce.” The data model is where FHIR data lands. It does not fetch anything by itself.

Three ways to get FHIR data into Health Cloud

1. The Salesforce Healthcare API

This is Salesforce’s own FHIR interface. In its words, it “enables you to securely connect and interact with any system that uses FHIR APIs.”

What is worth knowing before you plan around it:

It does not need MuleSoft. Salesforce’s FAQ: “The Salesforce FHIR APIs are accessible as REST APIs.”
It costs nothing extra for Health Cloud customers, but you must add a $0 SKU to enable it.
It covers the core clinical resources, including Patient, Practitioner, Encounter, Observation, Condition, AllergyIntolerance, Procedure, CarePlan, MedicationRequest, Immunization, DocumentReference and Questionnaire.
It reads, searches, creates and updates. The documented scopes cover GET, POST and PUT. Delete is not listed.
Batch calls have limits. Bundles must be of type batch, with up to 30 entries per call and no more than 10 of those being reads or searches.
Authentication uses OAuth 2.0 through an external client app.

2. MuleSoft

If your organisation already runs MuleSoft, or the integration needs orchestration across several systems, there are two MuleSoft routes. They are easy to confuse.

MuleSoft Accelerator for Healthcare is a set of prebuilt APIs, connectors, templates and reference architectures, free to download for customers with a current Anypoint subscription. Its Patient 360 use case includes “System APIs for two of the most common EHR platforms used globally, Epic and Cerner, and a group of System APIs for Salesforce Health Cloud.” It also includes an HL7 v2 to FHIR converter. The current version was released in March 2025, so treat it as a solid starting point rather than a recently updated one.

MuleSoft Direct for Health Cloud is a set of prebuilt integration apps enabled from Salesforce Setup and deployed into your own MuleSoft instance. Salesforce’s FAQ is clear that “to access the Industry Integrations, you must purchase a MuleSoft instance.” These apps cover the documented patterns in the next section.

3. Your own middleware

Any integration platform that can call FHIR APIs on the EHR side and Salesforce APIs on the other can do this job. It gives you full control, and it leaves you owning the mapping, error handling and monitoring that the prebuilt options include.

The patterns Salesforce actually documents

Salesforce’s healthcare integration documentation describes specific patterns. Choosing among them is most of the design work.

What you need	Documented pattern
Keep a patient’s record and clinical history in Health Cloud	EHR sync. Staff search the EHR from Salesforce and pull the selected patient’s records into the Clinical Data Model.
React to admissions, results and appointments as they happen	HL7 v2 feeds. ADT, ORU and SIU messages are transformed and stored in the Clinical Data Model.
Show EHR data in Salesforce without storing it	Real-time read. Salesforce documents this for Epic, Oracle Cerner and athenahealth.
Population analytics and segmentation	Bulk FHIR into Data 360. Salesforce documents bulk ingestion of Patient, Encounter, AllergyIntolerance, Condition, Procedure, MedicationRequest, Observation and Immunization.
Book appointments or handle prior authorization	Workflow write-back. Appointment create, update and cancel, and prior authorization submission, are documented.

Notice what is missing: a general two-way sync that keeps Salesforce and the EHR identical. Salesforce’s marketing talks about bidirectional data flow, but the documented write-backs are for specific workflows. If a proposal promises general bidirectional sync, ask exactly which data flows back, through which API, and who in the health system approved it.

The EHR side: what Epic and Oracle Health require

No Salesforce setting gets you into an EHR. Each vendor has its own process, and the health system has to take part.

Epic

Register the app on Epic’s developer site, fhir.epic.com. Epic’s App Orchard has been retired, so older guides pointing there are out of date.
Mark the app ready for production. Until you do, it cannot be used in any health system environment, and after you do, it can no longer be edited.
The health system signs Epic’s open.epic API Subscription Agreement and then downloads your app’s client ID.
For server-to-server integrations, Epic uses the OAuth 2.0 client credentials flow, and the health system’s administrator must map your client ID to an Epic user before you can get an access token.
Signing keys: Epic says customers will need a JWK Set URL or .pem files when they upgrade to its May 2026 version.
Bulk FHIR: Epic supports Group export only, with no option to export just what changed since last time, and lists syncing to a data warehouse as a poor use case. Bulk export is for periodic population snapshots, not for keeping Salesforce current.

Oracle Health (formerly Cerner)

Register in Oracle’s code Console, which requires a free CernerCare account.
Authentication supports SMART App Launch and SMART Backend Services.
The health system provisions your app into its own environment through a service request.
Bulk data needs a separately registered bulk data application.

The practical effect: EHR approvals can take longer than the Salesforce build. Start them early, and make sure someone at the health system owns them.

Why EHRs have FHIR APIs at all

Certified EHRs must offer a standardised FHIR API under the ONC certification criterion known as (g)(10), which requires FHIR Release 4.0.1 with the US Core implementation guide. That is why Epic and Oracle Health both expose FHIR R4.

For health plans, the CMS Interoperability and Prior Authorization rule (CMS-0057-F) matters most right now. Its operational provisions generally began on 1 January 2026, and its new APIs, including Provider Access, Payer-to-Payer and Prior Authorization, are generally due by 1 January 2027. A common mistake online is to say the APIs were due in 2026. They were not.

HIPAA: what the BAA covers

Salesforce signs a Business Associate Addendum that covers Health Cloud, and the BAA applies only once it is signed and includes the specific services you use. A few details matter for integration:

MuleSoft Anypoint is covered only when provisioned on Salesforce’s Hyperforce infrastructure.
Einstein and Agentforce features are covered only when Data Masking in the Einstein Trust Layer is switched on.
You must encrypt PHI in transit, and at rest to the extent it is within your control.

Salesforce Shield (Platform Encryption, Event Monitoring and Field Audit Trail) is widely used by healthcare organisations, but Salesforce describes compliance as a shared responsibility rather than something any one product provides. “Covered under Salesforce’s BAA” is an accurate statement. “Health Cloud is HIPAA compliant” on its own is not.

Questions to answer before anyone builds

Which EHR, which version, and who at the health system owns the app approval?
Store or view? Do you need the data kept in Salesforce, or just visible there?
Which direction? List every data element that must flow back to the EHR, and the workflow it belongs to.
How current does it need to be? Event feeds, on-demand sync and bulk snapshots behave very differently.
Which integration route? The Healthcare API, MuleSoft, or your own middleware, and who will own monitoring once it is live.
Is every service you plan to use covered by your BAA?

What we are not claiming

This is not a substitute for the vendors’ documentation. Both Salesforce and the EHR vendors change their APIs and names often. We checked every fact here against their current documentation in September 2026, and we list the sources below.

We have not put timelines or prices in this post. EHR integration effort depends on which data moves, in which direction, and how quickly each health system approves access.

Frequently asked questions

Is Health Cloud FHIR-native? No. Its Clinical Data Model is aligned to FHIR R4, and Salesforce says the implementation is not identical to HL7’s definition. Data still needs an API or middleware to move in and out.

Do I need MuleSoft to connect FHIR data to Health Cloud? Not for the Salesforce Healthcare API, which accepts FHIR requests directly. You do need a MuleSoft instance for the MuleSoft Direct integration apps.

Does the Healthcare API cost extra? Salesforce says it is available to existing Health Cloud customers at no additional cost, through a $0 SKU you must add.

Can Health Cloud write data back to Epic? For specific documented workflows, such as appointment scheduling and prior authorization. General two-way synchronisation is not a documented pattern.

Can we use Bulk FHIR to keep Salesforce in sync with Epic? Not well. Epic supports Group export only, with no incremental option, and describes data warehouse synchronisation as a poor use case. Use event feeds or on-demand sync for currency, and bulk exports for population analysis.

Is Health Cloud HIPAA compliant? Health Cloud is covered under Salesforce’s Business Associate Addendum once one is signed. Compliance also depends on your own controls, including encryption and access.

Sources

Salesforce, Health Cloud object reference: FHIR R4 mapping and considerations
Salesforce, Healthcare API: get started and FAQ
Salesforce, Health integrations
MuleSoft, Accelerator for Healthcare
Epic, OAuth 2.0 documentation and Bulk FHIR
Oracle Health, Authorization framework
ASTP/ONC, Standardized API certification criterion (g)(10)
CMS, Interoperability and Prior Authorization final rule (CMS-0057-F)
Salesforce, Business Associate Addendum

Estarei is a Salesforce consulting partner working with healthcare and life sciences teams. If you are planning a Health Cloud integration and want a second opinion on the design before you commit, talk to us. For the wider project, see our Health Cloud implementation guide.