Salesforce Health Cloud FHIR Integration: How to Connect Your EHR in 2026

What a Health Cloud EHR integration actually does

Health Cloud is Salesforce’s CRM for healthcare. In 2026 Salesforce started marketing it as Agentforce Health; its product pages say "formerly Health Cloud", recent developer guides carry the new name, and the objects and APIs are the same. This guide uses the familiar name.

The EHR (Epic, Oracle Health, athenahealth, MEDITECH and others) is where clinicians document care. It stays the legal record and the system of record for clinical data. Health Cloud gets a working copy of the parts that non-clinical and care-team workflows need:

• Care coordination: who was admitted or discharged yesterday, active conditions, care gaps, who needs a follow-up call.
• Contact center: an agent sees the caller’s upcoming appointments and recent visits, and can book or reschedule.
• Patient engagement: reminders, outreach campaigns and portal experiences driven by real encounters and appointments.
• Referrals and intake: tracking a referral from order to scheduled visit.

For the wider picture of connecting Salesforce to other systems, see the Salesforce integration guide. This page covers the healthcare case, which has its own standards, approvals and rules.

The building blocks, in plain words

• FHIR R4. The HL7 standard for healthcare APIs. Data comes as resources: Patient, Encounter, Condition, MedicationRequest, Observation, Appointment. In the US, certified EHRs must expose FHIR R4 APIs that follow the US Core profiles.
• HL7 v2. The older message format most hospitals still run on. ADT messages announce admissions, discharges, transfers and demographic updates; SIU messages announce scheduling changes; ORU messages carry results. They arrive in real time through an interface engine.
• Health Cloud’s clinical data model. Standard Salesforce objects that Salesforce describes as aligned with FHIR R4: ClinicalEncounter, HealthCondition, MedicationStatement, MedicationRequest, CareObservation and more. According to Salesforce’s documentation, new development is built on this model, and the older packaged EHR objects are not.
• Salesforce Healthcare API. A FHIR-style API for writing and reading those objects; for bundles it supports the batch type. Salesforce’s documentation notes that its FHIR implementation is not identical to the HL7 specification, so test every resource you plan to send.
• MuleSoft Accelerator for Healthcare. Prebuilt MuleSoft APIs and templates, including FHIR R4 system APIs for Epic and Cerner, a "Patient 360" flow that brings EHR data into Health Cloud over FHIR or HL7 v2, and an appointment scheduling flow for call center agents.

Your integration options compared

Every path ends in the same Health Cloud objects. They differ in who builds the plumbing, what you pay for and how real time the data is.

Generic iPaaS tools such as Boomi or Workato can move data into Salesforce too, but they are general-purpose platforms, so check how well they handle FHIR and HL7 v2 for your case, and you need a BAA with that vendor before PHI touches it. Zapier-style tools are a poor fit for clinical data.

How the data flows

Getting access to the EHR

Engineering is rarely what decides the timeline. Access is. Who grants it depends on the EHR and on whose project this is.

Epic

Epic publishes its FHIR R4 APIs and a sandbox on open.epic, where it lists hundreds of APIs and interfaces at no cost. Vendor Services, Epic’s developer program, adds Epic support, more documentation and an expanded testing sandbox; confirm any fees with Epic. Health systems find products that work with Epic in Showroom. You may still see the older App Orchard name in guides; Vendor Services and Showroom are Epic’s current programs.

The step that matters most: each health system decides whether to enable your app in its own Epic environment, which scopes it gets and which environments (test, then production) it can reach. If you are the health system, your Epic analysts own that step. If you are a vendor, every customer goes through it.

Oracle Health (Cerner)

Oracle Health exposes FHIR R4 APIs on the Millennium Platform; according to Oracle’s documentation, the older DSTU2 APIs are no longer supported. Apps are registered in Oracle’s code Console with a free CernerCare account, with an open, read-only sandbox and a secure sandbox for testing authentication and scopes. As with Epic, each client organization activates the app for its own domain.

HL7 v2 through your interface engine

Most hospitals already send ADT and scheduling messages to dozens of systems from Rhapsody, Mirth/NextGen Connect or a similar engine. Adding Salesforce as a destination is often the fastest way to get admissions, discharges and appointment changes in near real time. The catch: every site’s HL7 v2 is slightly different, so mapping takes testing with real message samples.

For system-to-system access over FHIR, plan on a backend (server-to-server) authorization pattern, not a user login. Epic’s backend apps authenticate with signed JWTs; Oracle Health system accounts use a client secret or signed JWTs, according to Oracle’s documentation.

Step-by-step: from first use case to go-live

1. Pick one use case and the minimum data for it"Care coordinators see yesterday’s discharges with diagnoses and follow-up appointments" is a use case. "All clinical data in Salesforce" is not. Write down the exact resources and fields; HIPAA’s minimum necessary standard expects this anyway.
2. Sign the BAA and secure the org firstConfirm that Salesforce’s Business Associate Agreement covers every service that will touch PHI, including add-ons and AI features. Turn on Shield Platform Encryption for sensitive fields, Event Monitoring and Field Audit Trail if you bought Shield, and lock down profiles and sharing before any real data arrives.
3. Enable the FHIR R4-aligned data modelIn Setup, the FHIR R4 support settings turn on the clinical objects. Decide early which ones you will use and how they relate to your existing person accounts, cases and care plans. Don’t mix the older packaged EHR objects with the new model.
4. Request EHR accessApp registration, scopes and environments for FHIR; a new outbound interface for HL7 v2. Start in week one: health system security reviews and analyst queues often take longer than the build.
5. Decide how patients are matchedStore the EHR’s MRN and the enterprise ID from the master patient index as identifiers on the person account. Match on identifiers, never on name plus birth date alone. Agree on what happens with merges (ADT A40) and corrections.
6. Map resources and codesBuild the mapping table (below) field by field. Keep the code, the code system and the display text for every coded value, so a SNOMED CT condition or an RxNorm medication stays meaningful.
7. Load history once, then sync changesUse Bulk FHIR export or a paged backfill for the initial load, within the date range the use case needs. Then run incremental updates from HL7 v2 events or scheduled FHIR queries. Make every write idempotent with an external ID so replays don’t create duplicates.
8. Test in a full sandbox with synthetic dataUse the EHR’s sandbox and synthetic patients. Keep PHI out of developer sandboxes. Test merges, cancelled appointments, entered-in-error records and deceased patients, not only the happy path.
9. Go live in waves and monitorStart with one clinic or one team. Watch error queues, unmatched patients and API usage daily. Give users a clear "source: EHR, last updated" label so nobody edits clinical data in Salesforce.

FHIR resource to Health Cloud object mapping

Object names below follow Salesforce’s FHIR R4 mapping and data model documentation for recent releases. Check the mapping guide for your org’s release before you build: field coverage changes between versions, and some FHIR elements are not supported.

Two rules keep this table honest. First, clinical objects in Salesforce should be read-only for users; corrections happen in the EHR and flow back. Second, Salesforce owns what the EHR doesn’t have: outreach history, preferences, care team tasks, contact center cases.

Code systems: LOINC, SNOMED CT, RxNorm

FHIR tells you the shape of the data. Code systems tell you what it means. US Core expects:

• Conditions: SNOMED CT, with ICD-10-CM for billing diagnoses.
• Labs and vitals: LOINC.
• Medications: RxNorm.
• Procedures: CPT, SNOMED CT and a few others, such as HCPCS and ICD-10-PCS.

Real EHR data also carries local codes that exist only in that health system. Store every code with its system, keep the display text, and build care-gap rules and reports on standard codes or curated value sets, not on display strings. Health Cloud’s code set objects hold the codes your org uses; load them before the clinical data that references them.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

HIPAA, consent and the rules around the data

For the full checklist, see how to build a HIPAA-compliant app. For a Health Cloud integration, these points matter most:

• BAA scope. Salesforce signs a BAA for specific services. Anything outside that list, and every other vendor in the path (iPaaS, hosting, logging, email), needs its own BAA or must never see PHI.
• Shield. Platform Encryption, Event Monitoring and Field Audit Trail are a paid add-on. Most healthcare orgs treat them as required: encrypted sensitive fields, a log of who viewed what, and field history kept long enough for audits.
• Minimum necessary. Sync only what the use case needs, and restrict who sees clinical objects with permission sets and sharing rules. A contact center agent rarely needs full medication history.
• Integration user. Run the integration as a dedicated API-only integration user with only the permissions it needs, never as an admin’s login.
• Consent and sensitive data. Respect patient restrictions recorded in the EHR. Substance use disorder records under 42 CFR Part 2, behavioral health and some state-protected data often should not sync at all. Decide this with your privacy officer before mapping.

The regulatory backdrop works in your favor. The 21st Century Cures Act and ONC’s rule implementing it require certified EHRs to offer standardized FHIR APIs, and the Act prohibits information blocking. Under ONC’s HTI-1 rule, certified health IT had to support USCDI v3 and US Core 6.1.0 from January 1, 2026, so more data elements are reachable through standard APIs. TEFCA, the national exchange framework run through Qualified Health Information Networks, helps organizations query each other’s records, but it does not replace a direct integration between your EHR and your CRM.

Pitfalls and how to fix them

• Duplicate patients. Matching on name and birth date creates two Salesforce records for one person, or merges two people. Fix: match on MRN or enterprise ID, store them as external IDs, process ADT merge messages, and route uncertain matches to a review queue.
• Multiple MRNs. A patient seen at three facilities can have three MRNs. Fix: use the master patient index identifier as the key and keep facility MRNs as additional identifiers.
• Sync loops. A Salesforce flow updates a patient, the integration sends it back, the EHR echoes it. Fix: one system of record per field, and skip updates made by the integration user.
• Codes nobody can read. Conditions arrive as local codes or display text only. Fix: keep code plus system, map local codes to standard ones in the integration layer, report on value sets.
• Too much history. Ten years of observations fill storage and slow pages. Fix: load only the window the use case needs; link to the EHR for the rest.
• API limits on both sides. EHR APIs throttle, and Salesforce counts API calls per 24 hours. Fix: batch writes, use bulk loads for backfills, and queue and retry instead of hammering.
• Write-back assumed to be easy. Reading a FHIR resource is routine; writing to an EHR needs extra approval, specific APIs and often the vendor’s paid program. Some operations are not available at all; the MuleSoft accelerator documents gaps such as appointment cancellation for Epic. Fix: launch read-only, then add write-back one transaction type at a time.
• PHI in the wrong places. Debug logs, email alerts and developer sandboxes collect PHI quietly. Fix: mask logs, keep alerts free of patient details, use synthetic data outside production and full sandboxes.

When a custom integration makes sense

Custom work pays off when you are a digital health company or payer without a hospital interface engine, when you integrate with many smaller EHRs, when the data needs heavy transformation (risk scores, care-gap logic) before it reaches Salesforce, or when MuleSoft licensing doesn’t fit the budget. It typically involves a small service on HIPAA-eligible cloud hosting that handles FHIR authorization, patient matching, code mapping, a retry queue and audit logs, plus the Salesforce side: objects, permission sets, Lightning pages and flows. Teams that build it usually start with an API development partner or extend their custom software team.

The full breakdown, with what drives each range, is in the API integration cost guide. Planning a data warehouse alongside the CRM? See the cost of data integration. If you are building the patient-facing side too, start with how to build a medical app.

Go-live checklist

Tick what is already true for your integration.

FAQ

Where Gilzor fits

Gilzor builds and maintains Salesforce integrations. For a Health Cloud EHR project, Gilzor’s engineers can map the data flow from your EHR, build the integration layer and the Salesforce side, and support it after launch. See our Salesforce integration services, or tell us which EHR you run and which team needs the data first.