Most articles about Salesforce Health Cloud are written to sell it. This one is not. We implement Health Cloud for a living, and a fair share of our discovery calls end with us telling the buyer not to buy it yet.
Four situations come up often enough to be worth writing down.
1. Nobody is actually going to work a case
Health Cloud is built around case-based work. A care coordinator picks up a member, works a queue, escalates, documents, closes. The whole data model assumes somebody is doing that job every day.
If the real requirement is appointment reminders for a few hundred patients, there is no case work happening. The scheduling and messaging module inside the existing EHR does that job for a fraction of the cost and none of the integration effort. Buying a care management platform to send reminders is the healthcare equivalent of buying a CRM to store a mailing list.
The test is simple. Name the person who will open the application on Monday morning and work through a list. If that person does not exist on the org chart, the platform will sit unused.
2. The EHR interface is not in the contract
This is the one that quietly destroys project budgets.
Every Health Cloud project that matters involves moving clinical data in and out of an EHR. The cost of that work has almost nothing to do with Salesforce and almost everything to do with what the EHR vendor allows. If the organisation has HL7 or FHIR access under its existing agreement, the integration is a known quantity. If it does not, the timeline now includes a commercial negotiation with a vendor who has no reason to hurry.
We ask for the interface terms before quoting, not after. A buyer who cannot produce them is not ready to sign a fixed price, and any partner who quotes one anyway is guessing with the buyer's money.
3. Sales Cloud already covers it
Some organisations arrive at Health Cloud because a consultant told them healthcare needs a healthcare product. Sometimes that is right. Sometimes they already run Sales Cloud, the workflow in question is referral tracking or provider relationship management, and the honest answer is to extend what they own.
The distinction worth holding onto: Health Cloud earns its licence when you need the clinical data model, the care management objects and the consent structures. It does not earn it when you need a pipeline with healthcare-sounding field names. Custom-building the clinical model on Sales Cloud is usually the more expensive mistake, but so is licensing a clinical model nobody will populate.
4. Data governance has not been decided
Who is allowed to see which fields. How long records are retained. Who signs off access reviews and how often.
These are policy questions. They get answered by a compliance officer, a privacy lead and a clinical director sitting in a room. They do not get answered by a configuration workshop, and an implementation partner cannot answer them on the customer's behalf without inventing policy.
Projects that start before those answers exist do not fail loudly. They stall in UAT, when somebody from compliance sees the sharing model for the first time and asks a question nobody has a decision on. Then the build gets reworked with the go-live date unchanged, which is where quality goes to die.
Why say any of this out loud
Because the alternative is worse for everyone. A partner who never says no ends up with unhappy references and rework nobody is paid for, and a buyer who never hears no ends up owning a platform their team quietly works around.
The four checks above cost one conversation. Skipping them costs a quarter.
If you want the longer version of how we scope this work, including the integration routes and the HIPAA controls we configure, it is written up here: https://ashapurasoftech.com/blog/salesforce-health-cloud-implementation-services/
Top comments (0)