Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
All articles
Industries·May 15, 2026·12 min read·22 views

Salesforce Health Cloud: Complete 2026 Guide (Patient 360, Care Plans & Agentforce for Healthcare)

What Health Cloud is, the household data model, Patient 360, Care Plans, FHIR/HL7 with Epic/Cerner, Advanced Therapy Management, and HIPAA + Shield.

Salesforce Health Cloud complete 2026 guide
By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 6, 2026

Your team has six weeks to stand up a Health Cloud pilot for a hospital system that runs on Epic. The hospital wants Patient 360, care-coordinator dashboards, and a first agent that can answer "when is my next appointment?" without paging a nurse. You open a fresh sandbox, enable Health Cloud, and the first screen has fields you have never seen in a CRM. Accounts that represent a person. Households. Care Plans, Care Programs, Encounters. This guide is the map.

If you are stepping into a Health Cloud project from a core Salesforce background, the data model alone takes weeks to internalize. This article is the canonical mental map. What Health Cloud is, how its objects fit together, where it integrates with Epic and Cerner, what changed in 2026 with Agentforce, and the implementation roadmap that does not blow up at month four.

What Health Cloud is (and is not)

Health Cloud is:

  • A vertical industry SKU built on the Salesforce Platform.
  • A healthcare-specific data model (Patient, Care Team, Conditions, Care Plans, Encounters).
  • A bundle of pre-built UI components for clinical and care-coordinator workflows.
  • An integration framework for Epic, Cerner, Meditech, and other EHRs (via MuleSoft Accelerators or custom).
  • Compliance-aware: designed to be deployable in HIPAA-regulated environments (with Shield).

Health Cloud is not:

  • An EHR. It does not replace Epic. It complements EHR data with CRM-style relationship management.
  • A clinical decision support system. Diagnoses live in the EHR.
  • A free upgrade. Health Cloud is a separate license tier with significant per-user cost.
  • A magic compliance bullet. HIPAA compliance requires you to configure Shield and build with the right architectures, then keep the configuration in source control so the next release does not regress it.

That last point sits behind most failed Health Cloud projects. The platform gives you the building blocks; the architecture choices you make on top of those blocks determine whether the result is compliant, useful, or both.

The household data model

The most distinctive feature of Health Cloud. Patients are not just Accounts and Contacts; they sit in a network of relationships modeled as objects.

Health Cloud's household data model: Patient at center with family, payors, providers, conditions

Core objects:

  • Person Account. The patient (Account plus Contact merged into one record). Most Health Cloud orgs use Person Accounts; some use B2B-style separate Accounts for payors and providers.
  • Patient (Contact-based or Person Account-based). The individual receiving care.
  • Household. A Salesforce Account that groups related Person Accounts (family unit, billing unit).
  • Care Provider. Physicians, nurses, specialists. Often modeled as another Person Account or a separate object.
  • Care Team. Junction between Patient and Care Providers, with role and responsibility.
  • Conditions. Chronic and acute conditions tracked over time.
  • Encounters. Appointments, hospital admissions, telehealth visits.
  • Medications. Current and historical.

The data model is verbose. Plan for roughly 25 standard objects out of the box, plus custom extensions per implementation. The verbose data model is the price you pay for letting clinical operations, care coordination, and patient engagement live in the same system. Treat it as documentation of the real-world relationships rather than as overhead, and the modeling decisions get easier.

Care Plans vs Care Programs

Two related but different concepts that sound interchangeable and absolutely are not.

Care Plan

A Care Plan is patient-specific. A longitudinal plan for one individual. It tracks goals, interventions, and progress for that patient's specific care course.

Example: "Care Plan for Jane Doe, manage Type 2 Diabetes."

  • Goals: HbA1c below 7.0, blood pressure below 130/80
  • Interventions: medication review monthly, dietitian quarterly, lab tests every 3 months
  • Progress notes: timestamped updates from care team

Care Program

A Care Program is cohort-based. A structured engagement program for a group of patients sharing a condition or risk factor.

Example: "Diabetes Management Program, 500 enrolled patients."

  • Enrollment: criteria-based (HbA1c above 8, age above 45)
  • Curriculum: educational content sequence
  • Touchpoints: scheduled emails, calls, telehealth check-ins
  • Outcomes: tracked across the cohort

The pattern: Care Programs run for a population; Care Plans run for an individual. A patient enrolled in a Care Program typically also has a personal Care Plan. The Program drives the cohort-level intervention rhythm; the Plan captures what makes this specific patient's situation different.

FHIR and HL7 integration

This is where Health Cloud meets the rest of healthcare's tech stack.

  • HL7 v2. The dominant legacy interface protocol. Pipe-delimited messages flowing between EHRs, lab systems, and billing.
  • FHIR (Fast Healthcare Interoperability Resources). The modern REST/JSON-based standard. Used in newer integrations and required by US regulations (CMS interoperability rules).

Salesforce ships Health Cloud Accelerators for MuleSoft that handle the most common patterns:

  • Patient demographics sync (Epic to Salesforce)
  • Encounter ingestion (real-time on appointment creation)
  • Lab result delivery
  • Medication reconciliation

For everything else, custom MuleSoft flows or Apex callouts. Most Epic implementations expose FHIR over OAuth, and the Accelerators wrap that handshake so you do not write it from scratch. Plan to spend roughly a third of the integration time on identity mapping (matching Epic patient IDs to Salesforce Person Account Ids), because that is where the project burns the most calendar time when it goes badly.

FHIR/HL7 integration topology: Salesforce Health Cloud connecting to Epic, Cerner, Meditech via MuleSoft

Advanced Therapy Management

A 2024-2025 addition that has matured in 2026. Designed for CAR-T, gene therapy, and other complex specialty therapies where a single treatment involves dozens of steps across weeks.

Tracks the full path:

  1. Patient identification plus qualification
  2. Insurance authorization
  3. Cell collection scheduling (for autologous therapies)
  4. Manufacturing plus shipping logistics
  5. Treatment infusion plus monitoring
  6. Long-term outcomes tracking

The complexity is what justifies building on Health Cloud rather than rolling it from scratch. These workflows touch 8 to 12 stakeholders and have hard regulatory requirements. Trying to do this in a generic CRM means rebuilding the data model on top of opportunities, which is the kind of thing that looks fine in a demo and falls apart at the first audit.

Agentforce for healthcare

The 2026 layer that is changing Health Cloud workflows.

Common Agentforce-on-Health-Cloud patterns:

  • Patient self-service. An agent answers eligibility questions, schedules appointments, and triages symptoms before routing to a nurse.
  • Care coordinator copilot. Suggests next interventions on a Care Plan based on recent encounter notes; drafts patient communication.
  • Insurance pre-auth. An agent gathers required documentation, files prior authorization, and follows up.
  • Medication adherence outreach. Outbound voice or text agent contacts patients who missed refills.

Critical constraints in healthcare:

  • HIPAA-compliant grounding. Patient data only flows through the Trust Layer with your masking config. PHI must not leak to model providers.
  • Strict identity resolution. A wrong-patient match in a healthcare agent is catastrophic. Identity rules must be tighter than in retail or B2B.
  • Care team handoff. Agents triage but humans deliver care. The handoff to a clinician must be smooth and auditable.

Build the handoff path before you build the agent. A patient-facing agent that cannot reliably transfer to a human within ten seconds is not deployable in healthcare; building the agent first and the handoff second is how pilots stall.

HIPAA compliance plus Shield

Health Cloud does not make you HIPAA-compliant. The architecture does.

Required:

  • Salesforce Shield. Platform Encryption (PII at rest), Event Monitoring (audit trail), Field Audit Trail (detailed change history).
  • Sandbox Anonymization. Masks PHI in non-prod environments.
  • Strict access controls. Role Hierarchy plus OWDs plus Sharing Rules calibrated to "minimum necessary" access principles.
  • BAA (Business Associate Agreement) with Salesforce. Covers their handling of PHI.
  • Audit logs. Multi-year retention for HIPAA's documentation requirements.

Do not:

  • Store PHI in unencrypted custom fields.
  • Email PHI via unencrypted standard email.
  • Sandbox-refresh full prod data without Anonymization configured.
  • Assume the Trust Layer auto-handles PHI. It masks based on YOUR configuration.

The single most useful auditor-readiness practice: keep a one-page document that maps every field containing PHI to its encryption state, masking rule, and access-control configuration. Update it on every release. Auditors love the doc and the doc reveals drift before drift becomes a finding.

Implementation roadmap

The pattern that works for new Health Cloud implementations.

Phase 1: Foundation (months 1-2)

  • Stand up a sandbox; enable Health Cloud plus Shield.
  • Configure Person Account model.
  • Set OWDs and base sharing model for HIPAA.
  • Stand up basic Patient plus Provider plus Care Team objects.

Phase 2: Integration (months 2-4)

  • MuleSoft plus Health Cloud Accelerators for Epic/Cerner integration.
  • Patient demographics sync (one-way from EHR).
  • Encounter ingestion.
  • First Care Plan templates.

Phase 3: Workflow (months 4-6)

  • Care coordinator UI.
  • Care Plan authoring plus execution.
  • Notifications plus tasks for care team.
  • Reporting plus dashboards for care managers.

Phase 4: Engagement (months 6-9)

  • Care Program enrollment plus automation.
  • Patient-facing portal (Experience Cloud).
  • Marketing automation for outreach (via Marketing Cloud).
  • Telehealth integration.

Phase 5: Agentforce (months 9-12)

  • Self-service patient agents.
  • Care coordinator copilots.
  • Outbound adherence agents.
  • HIPAA review of all agent flows.

This is a 12-plus month roadmap for a serious Health Cloud implementation. Compressing below that means cutting integration depth or workflow coverage. Both painful later. The teams that try to ship in six months almost always end up reworking Phase 1 in month nine because the foundation was rushed and now blocks everything downstream.

Common pitfalls

  • Ignoring the household model. Treating patients as standalone Contacts loses the Health Cloud value. Use Person Accounts and Households.
  • Custom data model when you do not need it. The standard Health Cloud objects cover roughly 80 percent of real cases. Extend; do not replace.
  • Assuming standard validation rules cover HIPAA. They do not. HIPAA requires more discipline than typical CRM data quality.
  • Skipping Shield. Eventually it becomes mandatory; configure from day one.
  • No identity resolution rules. "Wrong patient" mistakes are not acceptable; tune rules early and quarterly.
  • Single Apex namespace for all integrations. Refactor by integration domain (EHR, billing, lab, etc.) early.
  • Treating Care Plans as "rich tasks." They are a longitudinal data model with goals and outcomes, not a task list.
  • No regression tests on the encryption configuration. A test class that asserts every PHI field is encrypted catches the kind of accidental config rollback that becomes an audit finding six months later.

Frequently asked questions

How is Health Cloud different from Service Cloud? Service Cloud is generic case management. Health Cloud is healthcare-specific data model plus UI plus integration. Most Health Cloud orgs include Service Cloud capability for non-clinical service operations.

Is Health Cloud HITRUST-certified? The platform has HITRUST CSF certification. Your implementation needs to be assessed separately.

Do I need Marketing Cloud for outreach? Not strictly. Health Cloud plus Email Studio basics work for many. Marketing Cloud opens up more sophisticated cohort engagement.

What is the relationship to Data Cloud (Data 360)? Data 360 federates clinical data, normalizes patient identities across systems, and grounds Agentforce. For complex multi-EHR environments, Data 360 plus Health Cloud is the modern stack.

Does Agentforce handle PHI? Only with proper Trust Layer configuration. Mask all PHI fields in your prompt template paths. Audit every agent action.

What is the cost? Per-user pricing significantly higher than core CRM. Add-ons (Marketing Cloud, MuleSoft, Shield) compound. Plan budget conservatively.

Can Health Cloud work for life sciences and pharma? Yes, especially with Advanced Therapy Management and the Health and Life Sciences Cloud variants. The data model and integration patterns translate; the regulatory layer changes (FDA Part 11 audit requirements instead of strict HIPAA covered-entity rules) and you should plan for both Shield and additional compliance tooling.

Health Cloud is one of the most rewarding Salesforce specialties and one of the most demanding. The combination of data model depth, regulatory complexity, and clinical-workflow nuance keeps it interesting for years.

The teams that succeed treat Health Cloud as a five-year platform investment rather than a six-month project. They keep architectural decisions documented, they invest in identity resolution from the first integration, and they pair every new Agentforce action with a HIPAA review the same week it ships. The pattern is not unique to healthcare, but the cost of getting it wrong in this vertical is higher than almost any other, which is why the discipline shows up early in successful projects and never relaxes.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.

Share this article

Share on XLinkedIn

Sources

Related dictionary terms

Comments

    No comments yet. Start the conversation.

    Sign in to join the discussion. Your account works across every page.

    Keep reading