Salesforce Health Cloud

Why it matters

The thing the demos skip is that Health Cloud's real product is the data model, not the screens. Out of the box you get standard objects for clinical and care concepts — care plans, clinical encounters, conditions, care teams, social determinants — mapped to FHIR resources, plus a Person Account model that makes a human the unit of record instead of a Lead-plus-Contact pair. Everything downstream inherits that schema: reporting, sharing rules, field-level security, and especially AI. An agent that answers 'what is this patient's medication-adherence risk' or 'is there an open care gap before this visit' is only as trustworthy as the structured, governed data beneath it. Rebuild the same concepts as ad-hoc custom fields on a generic org and you save license cost up front, then inherit a data-quality and compliance debt that surfaces the first time you try to automate anything clinical — because there is no consistent schema for an agent to reason over, and no clean audit trail when a regulator or a patient asks how a decision was reached.

How it works

• A healthcare-specific data model sits on the core platform: standard objects such as CarePlan, ClinicalEncounter, Condition, CareTeam, and care-request entities aligned to FHIR resources, so clinical facts have a typed schema instead of free text in a notes field.
• The Person Account / patient model unifies an individual across roles — patient, member, caregiver, provider contact — so one human is one governed record rather than several disconnected leads and contacts that drift apart over time.
• Interoperability is FHIR-oriented: data is ingested from EHRs and payer systems and mapped to Health Cloud objects through integration tooling rather than screen-scraped, which is what makes the unified view reconstructable and auditable instead of a one-way copy.
• Compliance posture is platform-level: Health Cloud is sold within Salesforce's HIPAA-eligible services, which require a signed Business Associate Agreement; Shield (Platform Encryption, Event Monitoring, Field Audit Trail) and a deliberate sharing model are how PHI handling becomes a configuration decision rather than an afterthought.
• Engagement and automation — Flows, prebuilt care-management and patient-engagement apps, and increasingly Data Cloud and Agentforce agents — run on top of that model and inherit its sharing rules and field-level security, so an agent cannot surface PHI the underlying user is not permitted to see.

Where it fits

Health Cloud is the system of engagement, deliberately not the system of record for clinical truth — the EHR usually keeps that. Its job is the human-facing work around the patient or member: outreach, scheduling, care-plan follow-up, prior authorization, provider relationship management, and member services. In a Data-to-Agent stack it is where the governed person model lives so Data Cloud can resolve identity across sources and an agent can act — confirm an appointment, surface a care gap, route a benefits question — inside HIPAA-eligible controls rather than on top of an ungoverned copy of PHI. The architecture decisions that pay off later are made early: confirm the BAA and encryption strategy, decide which objects are FHIR-mapped versus genuinely custom, and define patient identity and the sharing model before building patient-facing automation. Reworking PHI handling and identity after launch is the expensive path, and in a regulated setting it is also the one that stalls the AI roadmap — you cannot safely point an agent at data whose access model you are still arguing about. If you want a second opinion on that sequencing before you build, that is the kind of call SkySync takes at /start.