We’ve implemented Health Cloud at health systems that were told it would take three months. It took nine. Here’s why.

A Salesforce partner quoted the project at 12 weeks. The health system signed. Eight months in, they were still untangling patient record conflicts between Health Cloud and Epic, records the implementation spec had described as “a standard data migration.”

It wasn’t standard. It never is.

Health Cloud implementations miss timelines not because the technology doesn’t work, but because the people scoping them don’t fully account for what healthcare data actually involves. Patient matching is hard. EHR integrations are complex. HIPAA compliance adds layers that a standard CRM rollout doesn’t have.

This post covers what Health Cloud implementation actually requires, where projects stall, and what questions to ask before you start.

What does a Health Cloud implementation actually include?

Salesforce Health Cloud is a patient relationship management platform built on top of Salesforce CRM. It gives care coordinators, case managers, and clinical staff a unified view of each patient, including health history, care plans, appointments, communications, and insurance details, without touching the EHR.

A Health Cloud implementation covers six workstreams:

• Data architecture setup: mapping your existing patient and member data to Health Cloud’s native objects (Person Accounts, Contact Point objects, care gap records)
• EHR/EMR integration: connecting Health Cloud to Epic, Cerner, or your existing clinical system via FHIR APIs or middleware
• User configuration: building care coordinator and case manager views, permission sets, and care plan templates
• Workflow automation: appointment reminders, care gap alerts, and escalation rules
• Compliance configuration: HIPAA-compliant data handling, field encryption via Salesforce Shield, and BAA execution with Salesforce
• Training and enablement: getting clinical and administrative staff actually using the system

That’s the scope on paper. The problem is that each of these workstreams is more complex than it looks, and the EHR integration alone can double your timeline.

Why Health Cloud timelines almost always run long

Here’s what vendor timelines promise versus what actually happens:

The gap comes from three places.

The data model. Health Cloud uses Person Accounts rather than standard Salesforce contacts. That distinction breaks assumptions experienced Salesforce admins bring from other projects. Migrating from a contact-based model requires more rework than most scopes account for.

Messy patient data. The same patient often exists in multiple systems with slightly different names, DOBs, or record IDs. Deduplication and patient matching takes real time, and you can’t automate your way around every edge case.

Stakeholder availability. Clinical and compliance teams review implementation decisions differently than enterprise software buyers. Sign-off cycles are longer. Change requests come late. This isn’t anyone’s fault. It’s just not built into the vendor’s estimate.

What nobody tells you about EHR integration

Health Cloud doesn’t replace your EHR. Epic stays. Cerner stays. Health Cloud sits alongside it and pulls data in. That sounds straightforward until you try to actually build it.

Epic’s Interconnect and FHIR R4 APIs have real limitations on what data they expose and how frequently. Not every clinical data point you want in Health Cloud is available via the standard API. Custom integrations require Epic’s approval process, which adds time. Cerner has its own API behavior, its own authentication patterns, and its own definition of “standard.”

Middleware is almost always required. Mulesoft is Salesforce’s promoted default, but plenty of real implementations use Boomi, Rhapsody, Azure integration services, or whatever enterprise integration engine the organization already runs. Whatever the tool, that layer sits between the EHR and Health Cloud handling transformation, error logging, and retry logic. It’s its own project, and it needs maintenance after go-live.

Before the project starts, your integration spec should answer these four questions:

• Which data elements need bidirectional sync versus read-only?
• How frequently does data need to sync: real-time, hourly, or nightly?
• Who owns the integration layer post-launch, and does your team have the skills to maintain it?
• What happens when the EHR API changes in a version upgrade, or when Epic moves between FHIR versions?

If your prospective partner hasn’t asked you these questions, that’s a signal. We treat these as non-negotiables in our Salesforce implementation process.

HIPAA, Shield, and the compliance work you can’t skip

Health Cloud is HIPAA-eligible, meaning Salesforce will sign a Business Associate Agreement (BAA) and the platform can store and process Protected Health Information (PHI). “Eligible” is not the same as “compliant by default.” You have work to do on your end.

Salesforce Shield. Shield adds field-level encryption, event monitoring, and audit trail capabilities that most healthcare implementations require for compliance. It’s a separate license. If it wasn’t in your initial quote, find out whether it should be.

Data classification. Your implementation team needs to identify which fields contain PHI and apply appropriate encryption, masking, and access controls. This doesn’t come pre-configured.

Access controls and permission sets. Care coordinators, case managers, billing staff, and executives all need different levels of access to patient records. Building permission sets correctly takes time, and getting it wrong creates compliance exposure.

BAA execution. The BAA with Salesforce needs to be in place before any PHI enters the system. Not after go-live.

User training on PHI handling. If staff access patient data through Health Cloud on personal devices, or share screenshots in Slack, you have a compliance problem the technology can’t fix.

Compliance work often gets scoped as a single line item. In practice, it touches every other workstream. Treat it as a thread running through the entire project, not a phase at the end.

How to scope a Health Cloud project before you start

The most common scoping mistake is treating Health Cloud like any other Salesforce implementation. It’s not. Before signing a statement of work, push your prospective partner on these questions.

On data:

• Have you reviewed our current patient data structure and identified deduplication risks?
• How will you handle the Person Account migration if we’re coming from a standard Contact model?
• What patient matching logic will you use, and what’s the fallback for records that don’t match?

On EHR integration:

• Which version of Epic/Cerner APIs are you certified to work with?
• Have you built a Mulesoft or comparable integration layer for Health Cloud before?
• What’s the plan if the EHR API changes after we launch?

On compliance:

• Is Salesforce Shield included in your proposal?
• Who is responsible for the PHI field inventory and encryption configuration?
• At what point in the project does the BAA need to be executed?

On timeline:

• What assumptions are built into your 12-week estimate, and what would cause it to extend?
• Which phases have the most variability in your experience?

A partner who answers these specifically, with examples from actual healthcare implementations, is a different category from one who gives general answers. Vague answers to specific questions are a pattern worth paying attention to. See our full Salesforce implementation checklist for the complete pre-kickoff list.

What to look for in a Health Cloud implementation partner

The Salesforce partner ecosystem is large. Most of it wasn’t built for healthcare. For a Health Cloud implementation, look for four things.

Healthcare-specific implementation history. General Salesforce expertise doesn’t transfer automatically. EHR integrations, patient data models, and HIPAA configuration are Health Cloud-specific skills. Ask for examples from comparable health system or medical group implementations, not “healthcare-adjacent” work.

Integration experience with your EHR. Epic and Cerner behave differently. If your prospective partner has only used simple HL7 feeds rather than modern FHIR APIs, flag that before you start.

Compliance knowledge that lives with the project team. Not a compliance checklist handed off to your legal team. An implementation team that understands which decisions trigger PHI handling requirements.

A clear post-launch support plan. EHR versions update. Salesforce releases three times a year. Health Cloud implementations need ongoing support, not just a hypercare window. If a partner’s engagement ends at go-live, ask who owns the integration layer the week after.

At Cabin, our Salesforce work sits inside a broader healthcare consulting practice. EHR integration architecture and compliance configuration are part of the initial design, not afterthoughts we scope in after something breaks. And the team you meet is the team that ships, so the people answering your integration questions in week one are still answering them in month six.

FAQ

What is the typical timeline for a Salesforce Health Cloud implementation?

Most Health Cloud implementations run 5 to 9 months from kickoff to go-live. Shorter timelines (12-16 weeks) are possible for smaller organizations with simple EHR setups and clean patient data. Larger health systems with Epic integrations, complex data models, or significant deduplication work typically run 6 to 9 months.

Does Salesforce Health Cloud require Salesforce Shield?

Shield isn’t required by default, but most healthcare implementations need it for HIPAA-compliant field-level encryption and audit trail capabilities. It’s a separate license. If it’s not in your implementation quote, ask whether PHI encryption is covered through another mechanism and what that mechanism actually is.

How does Health Cloud integrate with Epic or Cerner?

Health Cloud connects to Epic and Cerner via FHIR APIs (typically FHIR R4) or HL7 interfaces, usually through a middleware layer like Mulesoft, Boomi, or your organization’s existing integration engine. The exact architecture depends on which data elements need to sync, sync frequency, and the EHR API version available to your organization. One thing worth knowing: FHIR R4 alone rarely covers everything. Most implementations still rely on a mix of FHIR, Epic Interconnect, and HL7 interfaces to fill the gaps.

What’s the difference between Health Cloud and standard Salesforce CRM?

Health Cloud uses a Person Account data model instead of standard Contact records, and includes healthcare-specific objects like care plans, care gaps, and member/patient timelines. It also supports HIPAA-eligible data handling with the right configuration and Salesforce BAA in place.

Can we implement Health Cloud without replacing our EHR?

Yes. Health Cloud is designed to sit alongside your EHR, not replace it. Epic or Cerner stays as your clinical system of record. Health Cloud adds a patient relationship management layer for care coordination, case management, and patient communication, work that clinical systems typically don’t handle well.