Salesforce Health Cloud: Architecture, Governance, and Implementation Guide

What Health Cloud is—and is not

Salesforce Health Cloud extends the Salesforce platform with healthcare-oriented data models and workflows for patient and member engagement. It can support care coordination, service operations, provider relationships, and contact-center experiences. It does not by itself create a compliant architecture, replace a clinical system of record, or guarantee that data is clinically complete.

An implementation should begin with defined users and decisions: a care coordinator preparing outreach, a service representative resolving a coverage question, or a patient viewing an approved part of a care plan. Each use case determines what data is necessary, how fresh it must be, who may see it, and which source remains authoritative.

Model around authoritative sources

Map each Health Cloud object to its system of record and document the direction of synchronization. Identity and demographics may originate in a master patient index; encounters and observations may come from an electronic health record; coverage may come from a payer platform; communication preferences may be managed in Salesforce. Avoid silently allowing several systems to overwrite the same field.

Use stable enterprise identifiers and explicit crosswalks rather than relying on names, email addresses, or phone numbers for matching. Define how merges, splits, duplicate identities, and changed identifiers propagate. Clinical and claims data also require provenance: source system, source identifier, effective time, received time, and transformation history.

Plan interoperability as a product

FHIR APIs can improve exchange, but the standard does not remove local variation. Specify the FHIR version, implementation guide, profiles, required terminology, search behavior, pagination, error handling, and update semantics for each interface. Test representative bundles as well as missing references, unknown codes, late updates, and duplicate messages.

Salesforce maintains current Health Cloud data model documentation. HL7 publishes the normative FHIR specification. Treat both as versioned dependencies and review release notes before platform upgrades.

Security and privacy require shared responsibility

HIPAA compliance is an organizational outcome, not a product setting. A covered entity or business associate must determine whether a service is appropriate for protected health information, execute required agreements, configure safeguards, and operate policies and procedures. The U.S. Department of Health and Human Services publishes the HIPAA Security Rule guidance.

• Minimize access: Design roles around job functions and limit sensitive fields, records, exports, and administrative capabilities.
• Protect data: Evaluate encryption, key management, masking, secure integration credentials, and non-production data handling against the use case.
• Audit meaningful events: Retain access and change evidence appropriate to risk, and create a reviewed process for alerts and investigations.
• Secure every integration: Authenticate both parties, restrict scopes, rotate credentials, validate payloads, and avoid logging protected data.
• Prepare for incidents: Assign response roles, test containment and recovery, and document notification decision paths.

Salesforce Shield capabilities can contribute encryption, event monitoring, and field-history controls, but they do not “solve” HIPAA compliance. Configuration choices, integrations, user behavior, contracts, risk analysis, and day-to-day operations remain material.

Make consent and preferences explicit

Separate legal authorization, communication consent, channel preference, and operational opt-out concepts. Record the scope, purpose, status, source, effective period, and evidence for each decision. Before outreach or data sharing, evaluate the applicable policy at the time of action rather than copying a single boolean across systems.

Implementation checklist

1. Define the user journey, system of record, minimum necessary data, and measurable outcome.
2. Complete privacy, security, regulatory, and contractual reviews before loading sensitive data.
3. Document identity resolution, provenance, consent, retention, deletion, and correction workflows.
4. Build interfaces against versioned contracts and test clinical, operational, and failure scenarios.
5. Validate role and field access with real job personas, including contractors and support administrators.
6. Rehearse cutover, reconciliation, rollback, incident response, and continuity procedures.
7. Assign owners for data quality, integration health, access reviews, release changes, and user adoption.

Keep the platform current

This article was originally published in 2019 and substantively reviewed in 2026. Product capabilities and regulations change. Before making an architecture or compliance decision, verify current Salesforce release documentation, applicable law, organizational policy, and contractual terms. Schedule reviews after major platform releases and whenever a new category of health data, user, geography, or automated decision enters the design.