Salesforce Health Cloud Implementation: A Practitioner's Guide for 2026

Health Cloud is not Sales Cloud with a healthcare skin. That distinction matters enormously — and it’s the first thing most organizations get wrong when they start evaluating it. Health Cloud is a purpose-built layer on the Salesforce platform that introduces a fundamentally different data model, purpose-specific objects, and a set of compliance requirements that don’t exist in any other Salesforce product. If your team is approaching a Health Cloud implementation the same way it would approach a Sales Cloud implementation, expect a rework.

This guide covers what Health Cloud actually is, the objects and architecture that make it different, what HIPAA compliance means inside Salesforce, integration patterns with major EHR systems, realistic timelines and costs, and the five mistakes we see most often.

What Health Cloud Actually Is

Salesforce Health Cloud runs on top of the core Salesforce platform, which means everything you know about Salesforce — Apex, Flow, Lightning components, the AppExchange — still applies. What Health Cloud adds is a clinical and care management data model built for healthcare organizations.

The product targets three primary use cases: care management (coordinating care across a patient population), patient engagement (giving patients a portal-like experience to interact with their care team), and provider relationship management (a more sophisticated version of account management designed for payer-provider dynamics). Some organizations use all three; most start with one.

Health Cloud is licensed per user, not per patient. As of 2026, Health Cloud Enterprise runs approximately $300/user/month, and Unlimited is $450/user/month. These are on top of any add-ons like Data Cloud, Marketing Cloud for healthcare campaigns, or Agentforce for patient service automation.

How It Differs from Sales Cloud and Service Cloud

Sales Cloud organizes the world around Leads, Accounts, Contacts, Opportunities, and Cases. Service Cloud adds a more robust case management model and omnichannel routing. Health Cloud adds an entirely different set of objects — and changes the relationship model in ways that affect everything downstream.

The most significant architectural difference is the shift from the standard Account-Contact hierarchy to a Person Account model combined with household-level grouping. In Health Cloud, a patient is typically a Person Account (a record that is simultaneously an Account and a Contact), and patients are grouped into Households or Care Teams, not just accounts.

Key Health Cloud Objects

Person Accounts

Person Accounts collapse the Account-Contact distinction into a single record that represents an individual patient. This changes how you query data, how you build page layouts, and how integrations need to be structured. Any integration that writes Contact records to a standard Salesforce org will need to be rearchitected to write Person Accounts in Health Cloud.

Person Accounts are enabled at the org level and cannot be undone without a full data rebuild. Enable them in a sandbox, test every integration, and test every report before enabling them in production.

Household Model

The Household model groups Person Accounts into family units, which matters for care coordination (treating a family as a unit) and for payer use cases (tracking plan members in a household). Households in Health Cloud are a specialized Account record type that acts as a container for multiple Person Accounts with defined relationship types.

Care Plans

The Care Plan object is the centerpiece of care management. A Care Plan is linked to a patient and contains Problems (clinical issues being addressed), Goals (measurable outcomes), Care Plan Tasks (specific actions, with assignees and due dates), and progress notes. Care Plans can be templated — a Congestive Heart Failure care plan template might include 12 standard goals and 40 tasks — and cloned for new patients.

Building a useful Care Plan structure requires substantial input from clinical stakeholders. Every implementation that rushed the care plan design phase produced care plans that nurses refused to use.

Provider Networks

For payer organizations, Health Cloud includes a Provider Management data model: Provider objects, Provider Locations, Provider Specialties, and Network membership. This replaces the common workaround of using Accounts to represent providers. The Provider Network objects integrate with member-facing portals where patients search for in-network providers.

HIPAA Considerations in Salesforce

Salesforce signs a Business Associate Agreement (BAA) for Health Cloud — this is a prerequisite you must complete before storing any Protected Health Information (PHI) in the org. Do not load patient data before the BAA is signed. This sounds obvious, but we have seen it happen.

Having a signed BAA does not mean your org is automatically HIPAA-compliant. HIPAA compliance is a shared responsibility between Salesforce and your organization. Your obligations include:

Access controls: Role hierarchy, profile permissions, and sharing rules must be designed so that users only see records they are authorized to see. In a health system, this is complex — a nurse in cardiology should not see oncology patient records unless those patients are in their care team.

Audit trails: Salesforce’s field history tracking and event monitoring must be enabled and retained according to your organization’s HIPAA retention schedule (minimum six years). Event Monitoring is an additional-cost add-on, but it is effectively required for HIPAA compliance.

Encryption: Salesforce Shield Platform Encryption adds field-level encryption for sensitive fields. Standard Salesforce encryption (at-rest encryption of the database) is included with Health Cloud, but field-level encryption of specific PHI fields requires Shield.

Session management: HIPAA requires automatic session timeout. Configure Salesforce session settings to time out inactive users in 15–30 minutes. Document this configuration as part of your compliance documentation.

Data residency: For organizations with specific data residency requirements, Salesforce Hyperforce allows selection of data region. This requires additional negotiation with Salesforce.

Implementation Phases

Phase 1: Discovery (Weeks 1–3)

Discovery for Health Cloud is more intensive than for Sales or Service Cloud because you’re mapping clinical workflows, not just business processes. A proper Health Cloud discovery produces a data model, an integration architecture document, a Care Plan template library, a persona matrix (which user types need what access), and a HIPAA risk assessment.

Key stakeholders to involve: clinical operations, IT/EHR team, compliance/legal, and front-line clinical staff. The gap between what administrators think nurses do and what nurses actually do is almost always larger than expected.

Phase 2: Configuration (Weeks 3–8)

This phase covers the core build: Person Account configuration, household model setup, care plan template creation, page layout design per user persona, role hierarchy and sharing rule design, and custom fields for your specific workflows.

Care plan templates are the most time-consuming element and the most often underestimated. A health system with five disease state programs should plan for two to three weeks of care plan configuration alone, including clinical review cycles.

Phase 3: Integration (Weeks 6–12)

EHR integration runs in parallel with configuration and typically takes the longest. See the section below on Epic and Cerner integration patterns.

Phase 4: UAT (Weeks 10–14)

User acceptance testing for Health Cloud requires clinical staff, not just administrators. Build test scripts that mirror real clinical workflows — care coordinators should run through complete patient scenarios, not just click through screens. Plan for at least two UAT cycles; first-pass feedback from clinical users is almost always extensive.

Phase 5: Go-Live and Hypercare (Weeks 14–16)

A phased go-live by department or patient population reduces risk. Go-live for an entire health system simultaneously creates support burdens that overwhelm any team. Run the first cohort for two weeks before expanding. Plan for 30 days of hypercare support at elevated staffing levels.

Common EHR Integrations

Epic

Epic’s FHIR R4 APIs are the current standard integration path for Health Cloud. The Epic-Salesforce integration uses FHIR resources (Patient, Encounter, Condition, Observation, CarePlan) to synchronize patient demographics, clinical data, and care records bidirectionally.

Salesforce maintains a pre-built Health Cloud FHIR integration framework, which reduces custom development but still requires significant configuration. Plan 6–10 weeks for an Epic integration, including Epic MyChart Portal integration if patient-facing functionality is in scope. Epic integration projects require a technical resource on the Epic side — you cannot implement this integration without Epic IT involvement.

Cerner (Oracle Health)

Cerner’s integration path is similar to Epic’s — FHIR R4 APIs for clinical data exchange, with Cerner’s HealtheIntent platform as a data aggregation layer for some organizations. The Cerner integration is generally less complex than Epic’s in our experience, with a typical timeline of 4–8 weeks for core patient data synchronization.

Both EHR integrations require a middleware layer — MuleSoft, Boomi, or an equivalent. Direct point-to-point connections between EHR and Salesforce are technically possible but operationally unsustainable.

Realistic Timelines

For a mid-size health system (500–5,000 patients under management, one or two clinical programs), plan for 10–16 weeks from kickoff to go-live. This assumes:

• A dedicated internal project manager with decision-making authority
• Clinical stakeholder availability of 4–6 hours per week during discovery and UAT
• An IT/EHR team that can dedicate a resource to integration work
• No major scope changes after Week 4

Timeline killers specific to Health Cloud: late involvement of compliance/legal in HIPAA review, care plan templates that go through multiple clinical review cycles, and EHR integration delays caused by Epic or Cerner team availability.

Cost Ranges

Small health system or single-specialty practice ($80,000–$130,000): Core Health Cloud configuration, one or two care plan programs, basic EHR data read integration, and 90 days of hypercare.

Mid-size health system ($130,000–$200,000): Multi-program care management, bidirectional EHR integration, patient portal integration, and advanced reporting and analytics.

Large health system or payer ($200,000–$400,000+): Multi-cloud implementation (Health Cloud + Marketing Cloud for patient communications + Experience Cloud for patient portal), complex provider network configuration, and full FHIR R4 bidirectional integration with multiple EHR systems.

These ranges exclude Salesforce license fees, which are separate and recurring.

5 Common Mistakes

1. Not enabling Person Accounts in the sandbox before configuring anything. This is an irreversible org change. Enabling Person Accounts after building significant configuration in standard Contact mode means rebuilding page layouts, validation rules, reports, and integrations.

2. Skipping clinical stakeholder involvement in care plan design. IT-designed care plans that bypass clinical review are consistently rejected by the nurses and care coordinators who have to use them. Involve clinical operations from Day 1.

3. Treating EHR integration as a later phase. EHR integration dependencies affect the Health Cloud data model. Discovering mid-project that your Epic integration requires a specific field structure means rebuilding work already done.

4. Underestimating the HIPAA configuration workload. Sharing rules, field-level encryption, event monitoring, and session management are not afterthoughts. They need to be designed alongside the data model, not added at the end.

5. Going live with all users simultaneously. A phased go-live by department or program is standard practice for a reason. Full health-system simultaneous launch creates a support crisis that no team can handle, and issues that would be caught in a small cohort propagate to everyone.

---

Estarei is a boutique Salesforce consulting firm built by ex-Salesforce alumni. We specialize in Health Cloud implementations, EHR integrations, and healthcare data architecture. Book a free consultation to discuss your project.