Salesforce in Healthcare

What is Salesforce used for in healthcare?

Salesforce in healthcare is the use of the Salesforce platform, most often Health Cloud, to manage relationships and work around patients, members and providers. Typical uses are patient outreach, intake and referrals, care program enrollment, contact centers and provider network management, with clinical data pulled in from the EHR for context.

The common thread is coordination work that EHRs handle poorly: tasks that span several organizations, campaigns, call queues and case management outside a single encounter.

The EHR remains the legal medical record in almost every design. Salesforce holds a working copy of selected clinical data, plus the engagement history the EHR never sees.

What does Health Cloud add to the core platform?

Health Cloud adds healthcare data models and care management features on top of the core Salesforce platform. The most important addition for integration teams is the clinical data model.

Salesforce documents that its Health Cloud implementation of FHIR aligns with FHIR v4.0.1. The FHIR-aligned clinical data model is switched on through an org preference in Setup. Objects include HealthCondition for problems and diagnoses, PatientMedicalProcedure, ClinicalEncounter, PatientImmunization, AllergyIntolerance and CareObservation for observed values such as biometrics.

Aligned is not the same as identical. Salesforce states that the model supports most FHIR R4 attributes but not all, and that where cardinality differs it uses a parent record reference instead of FHIR's zero-to-many reference. Mapping code has to account for those gaps.

Health Cloud also brings care plans, care programs and care team features. Which of those a project uses should follow the workflow being moved into Salesforce, not the feature list.

Which Salesforce services can hold PHI?

Only services on Salesforce's HIPAA Covered Services list can hold PHI, and only after the customer and Salesforce sign a business associate addendum that includes them. Salesforce publishes the list and its restrictions on its Business Associate Addendum Restrictions page.

• Listed without service-specific restrictions: Health Cloud and Salesforce Shield appear on the list as of the page's 30 September 2026 update.
• Listed with limits: MuleSoft is covered only for certain named services, some only when provisioned on AWS or Hyperforce. Tableau Cloud and Tableau Next are covered, while Tableau Bridge, Tableau Data Connect and Tableau Server are not.
• Feature restrictions: The page restricts specific features inside covered services, for example the Discover feature on Lightning Platform and Einstein features in Marketing Cloud Next.
• Heroku: PHI may be handled only inside Shield Private Spaces.
• Encryption duties: The restrictions include customer obligations to encrypt PHI transmitted through the covered services.
• Changes over time: Salesforce keeps a change log for the restrictions, so a design checked last year needs checking again.

The list matters because HIPAA lets a covered entity share PHI with a vendor only under a business associate contract. PHI that lands in a service outside the addendum has no contract behind it, however well that service is secured.

Treat the list as a design input, not a one-time legal check. Every new feature request, managed package or connected app should start with the question of whether it will see PHI, and if so, whether it sits inside the addendum. Record the answer next to the feature in the backlog so the reasoning survives staff changes.

Managed packages from the AppExchange need the same check. A package that runs inside the org may still send data to its publisher's own servers, and that publisher then needs its own agreement with the client before PHI flows to it.

How does EHR data reach a Salesforce org?

EHR data usually reaches Salesforce through an integration layer that reads from the EHR, maps to Salesforce objects and loads through Salesforce APIs. The choice of source interface sets how fresh and complete the data is.

• HL7 v2 feeds: ADT messages from the EHR's interface engine give near real-time admissions, discharges and demographic updates, which suit care transitions and outreach triggers.
• FHIR read APIs: Certified EHRs expose a standardized FHIR read API for patient and population data built on US Core profiles. It suits pulling problems, medications and encounters, not writing back.
• Bulk extracts: Scheduled exports or FHIR Bulk Data jobs suit initial loads and nightly refreshes of large patient panels.
• Middleware: MuleSoft or another integration platform handles mapping, retries and monitoring, and should be checked against the covered services list if it touches PHI.
• Salesforce APIs: The REST API suits single records, the Bulk API suits large loads, and Platform Events or Change Data Capture suit pushing Salesforce changes back out.

Writing data back into the EHR needs the EHR vendor's own write APIs or an HL7 v2 inbound interface, agreed with the health system's integration team.

Whatever the source, map codes as well as fields. Problems, medications and observations arrive with code systems such as SNOMED CT, RxNorm and LOINC, and reports or care program rules built on free-text names break as soon as a second EHR sends a different label.

Shield, sharing and audit trails

Salesforce Shield adds the encryption and monitoring controls a PHI design needs, while the sharing model decides who sees which records. Both have to be designed, not just switched on.

Salesforce's security guide describes Shield as three tools: Platform Encryption for data at rest, Event Monitoring for user activity, and Field Audit Trail for field history over long periods. Platform Encryption lets the customer generate and hold key material outside Salesforce.

Encryption has side effects. Some field types and features behave differently on encrypted fields, so decide which fields need it during data modeling, then test reports, search and integrations against the encrypted configuration in a sandbox.

Choose encrypted fields by risk, not by habit. Identifiers, diagnoses, notes and free-text fields that staff may fill with clinical detail are the usual candidates. Fields used for matching or reporting need extra testing, because encryption can limit how they are filtered and sorted.

Event Monitoring is only useful if someone reads it. Send the events to the client's security monitoring tool, define alerts for bulk exports, report downloads and access outside working patterns, and name the person who reviews them.

The sharing model is where HIPAA's minimum necessary principle becomes real. Profiles, permission sets, organization-wide defaults and sharing rules should give a call center agent the contact data they need without exposing every clinical object.

Should Salesforce be a system of record?

Salesforce should be the system of record only for the data it creates, such as engagement history, cases and program enrollment. Clinical data copied from the EHR should stay a reference copy with a clear source.

• Demographics: The EHR or master patient index owns them. Salesforce stores the identifiers needed to match and update records.
• Problems, medications and results: The EHR owns them. Salesforce keeps a read-only copy with a source system and last-updated time on every record.
• Consent and communication preferences: Often owned in Salesforce, but the EHR may need a copy for portal and messaging rules, so agree on one owner.
• Care programs and tasks: Salesforce owns them when the coordination work happens there.
• Clinical notes: Leave them in the EHR unless a clear workflow needs them, because notes carry the most sensitive content.

In what order should a Health Cloud build run?

A Health Cloud build should settle the PHI boundary and data ownership before any configuration, then add integrations, then users. Reversing that order means rebuilding permissions and mappings after real data has arrived.

• 1. Workflow inventory: Write down the coordination work moving into Salesforce, who does it today, and which records each step reads or creates.
• 2. PHI boundary: Mark which objects and fields will hold PHI, and check every service, feature and connected app that touches them against the current covered services list.
• 3. Data ownership: Agree, field by field, whether the EHR, a master patient index or Salesforce owns each value, and record the source system on every copied record.
• 4. Security model: Design profiles, permission sets and sharing rules for each role, and choose which fields Shield Platform Encryption will cover.
• 5. Integration build: Build the HL7 v2, FHIR or bulk feeds with retry, error queues and alerting, and test them with synthetic patients rather than production copies.
• 6. Matching and deduplication: Set the rules that link an incoming record to an existing person before the first full load, not after duplicates appear.
• 7. Pilot and release routine: Start with one team, review access logs and data freshness, then add a sandbox test step for each Salesforce release.

Steps 2 and 3 are the easiest to skip under schedule pressure. They are also the hardest to fix later, because a wrong ownership decision is copied into every integration and report built on top of it.

Where Salesforce health projects stall

Healthcare Salesforce projects can stall on data ownership and PHI boundaries as easily as on configuration. This failure-point list covers the issues worth settling early.

• PHI in uncovered features: A team turns on a feature or connected tool that the addendum does not cover, and PHI flows into it.
• Duplicate patients: Records arrive from several EHRs and forms without a matching strategy, so one person becomes three contacts.
• Full copies in sandboxes: Full sandboxes copied from production carry real PHI to environments with looser access.
• Release surprises: Seasonal Salesforce releases arrive on a fixed schedule, and untested changes break custom code or integrations.
• Stale clinical copies: A nightly load fails quietly and staff act on outdated medications or problems.
• Over-broad access: Default sharing gives every user every patient, which the minimum necessary standard does not support.

How Agnotic can help

A healthcare Salesforce org stays useful when its PHI boundaries, data ownership and integrations are designed together and maintained after launch. Agnotic Technologies builds and runs that work for the client: Health Cloud configuration, sharing and permission design, Shield setup and EHR integrations through HL7 v2 and FHIR.

Agnotic also checks each design against Salesforce's current covered services list, tests every seasonal release in a sandbox and monitors the integrations that keep clinical copies fresh. Contracting for the business associate addendum stays between the client and Salesforce.

Sources

• Salesforce: Business Associate Addendum Restrictions and HIPAA Covered Services
• Salesforce Help: The Clinical Data Model and FHIR
• Salesforce Help: Salesforce Shield