Care Coordination Requirements

Care Coordination Requirements

Use this skill when mapping care coordination process requirements for Health Cloud Integrated Care Management (ICM): designing care team workflows, transition of care handoffs, SDOH barrier tracking, and care gap identification. This skill guides requirements gathering and process-to-object mapping. It does NOT cover the technical implementation of individual components — for Apex, Flow, or configuration build steps, consult the associated implementation skills.

Before Starting

Gather this context before working on anything in this domain:

• Confirm Integrated Care Management (ICM) is enabled in Setup. ICM has two separate checkboxes: (1) Managing Care Plans and (2) Calculating Care Gaps. Both must be enabled for full ICM functionality.
• Identify which coordination scenarios apply: SDOH barriers, referral management, care gap detection, care episodes, or all of the above. Each maps to a different ICM object family.
• Confirm the HealthCloudICM permission set is available and will be assigned to all care coordinators and care team members who interact with ICM objects.
• Identify whether Care Coordination for Slack is required. This is a separate add-on that requires both Slack and Health Cloud integration to be configured first — it is not included in base Health Cloud licensing.

Core Concepts

ICM Object Families

Integrated Care Management organizes care coordination across four object families:

1. SDOH (Social Determinants of Health): CareDeterminant, CareBarrier, CareBarrierType. Used to track social factors that affect health outcomes (food insecurity, housing instability, transportation barriers). CareBarrier records link to both Account (patient) and Case, and are resolved via Tasks.

2. Referrals: ClinicalServiceRequest (API v51.0+). Tracks clinical referrals from one provider to another. Requires the HealthCloudICM permission set.

3. Care Gaps: CareGap (API v59.0+). Represents a gap in preventive care or chronic disease management (e.g., overdue screening, missing vaccination). CareGap records are system-generated by external clinical rules engines or ingested via FHIR R4 APIs — they cannot be manually created by end users.

4. Care Episodes: CareEpisode (API v57.0+). Represents a defined period of care for a patient (e.g., a hospital admission, a chronic condition management episode). Supports care team coordination across a defined time window.

SDOH Barrier vs. CarePlanProblem

This is the most commonly confused distinction in care coordination requirements:

• CareBarrier — An SDOH obstacle at the social determinants level. Linked to Account+Case. Resolved via Task closure. Example: "Patient lacks transportation to appointments."
• CarePlanProblem — A clinical problem or diagnosis goal tracked within a care plan. Part of the ICM care plan hierarchy (ProblemDefinition → GoalDefinition → ActionPlanTemplate). Example: "Uncontrolled Type 2 Diabetes."

They are used at different workflow stages: SDOH barriers are identified during social screening; care plan problems are clinical priorities in an active care plan. Confusing them leads to incorrect object usage and broken workflow automation.

Care Gap Constraints

CareGap records (API v59.0+) have an important constraint: they cannot be created manually. They are system-generated by:

• An external clinical rules engine (e.g., a payer's quality analytics system)
• Ingestion via FHIR R4 APIs from an EHR system

A care coordinator cannot create a CareGap record directly in the UI or via standard Flow DML. Any process design that assumes manual care gap creation must be redesigned to use an external integration or the Business Rules Engine.

Common Patterns

Transition of Care Handoff Design

When to use: A patient is being discharged from a hospital and transitioning to outpatient care coordination.

How it works:

1. On hospital discharge, a CareEpisode record is created covering the inpatient stay, assigned to the inpatient care team.
2. An outbound ClinicalServiceRequest (referral) is created to the receiving outpatient care coordinator.
3. The outpatient coordinator accepts the referral and creates a new CarePlan for post-discharge management.
4. SDOH screening identifies transportation and food security barriers — CareBarrier records are created linked to patient Account and a Case.
5. Care Gaps identified by the payer's quality system are ingested via FHIR R4 API and displayed to the outpatient coordinator on the patient timeline.
6. The care coordinator resolves barriers by closing Tasks linked to CareBarrier records.

Why not the alternative: Without structured ClinicalServiceRequest referrals and CareEpisode records, transition of care handoffs rely on informal communication and cannot be measured or reported.

SDOH Screening and Barrier Resolution

When to use: A care coordinator conducts social needs screening and identifies SDOH barriers that require intervention.

How it works:

1. Care coordinator completes a social screening (typically via a Discovery Framework assessment form).
2. For each identified social barrier, create a CareBarrier record linked to the patient Account and a Case.
3. Set the CareBarrierType to categorize the barrier (food, housing, transportation, etc.).
4. Create Tasks linked to the CareBarrier for specific intervention actions.
5. When the intervention is completed, close the Task. The CareBarrier status updates based on task completion.
6. Track SDOH barrier resolution rates via CareBarrier reports for population health management.

Decision Guidance

Recommended Workflow

1. Enable and verify ICM prerequisites — confirm both ICM checkboxes are enabled (Managing Care Plans + Calculating Care Gaps). Verify HealthCloudICM permission set is assigned to all care coordinator users.
2. Map care coordination scenarios to ICM object families — for each care coordination scenario in scope, identify which of the four ICM object families applies (SDOH/Referrals/Care Gaps/Care Episodes). Document the process-to-object mapping before any configuration begins.
3. Design SDOH barrier tracking — define CareDeterminant and CareBarrierType picklist values for the SDOH categories in scope. Map screening assessment responses to CareBarrier creation triggers. Define Task workflow for barrier resolution.
4. Design care gap display requirements — identify which external systems will generate CareGap records and via which mechanism (FHIR R4 ingestion or direct API write). Design the care coordinator UI to display care gaps appropriately — do not design any manual creation workflow.
5. Design transition of care handoffs — map each handoff scenario to ClinicalServiceRequest referral + CareEpisode creation. Define which care team roles initiate vs. receive handoffs. Document referral status workflow.
6. Validate Care Coordination for Slack requirements — if Slack coordination is needed, confirm the Slack + Health Cloud integration is deployed and the add-on license is provisioned before designing Slack-based care team workflows.

Review Checklist

• ICM enabled (both checkboxes: Managing Care Plans and Calculating Care Gaps)
• HealthCloudICM permission set available for care coordinators
• Process-to-object mapping documented for each care coordination scenario
• CareBarrier vs. CarePlanProblem distinction clarified for all relevant workflows
• Care gap ingestion mechanism identified (external system, FHIR API) — no manual creation process designed
• Care Coordination for Slack add-on license confirmed if Slack workflows are in scope

Salesforce-Specific Gotchas

1. CareGap records cannot be manually created — CareGap (API v59.0+) is a system-generated object. Care coordinators and admins cannot create CareGap records via the UI, standard Flow DML, or bulk data import. Any process design requiring manual care gap creation must be redesigned to use an external clinical rules engine or FHIR R4 API ingestion.

2. ICM requires two separate Setup checkboxes — Integrated Care Management has two distinct settings: "Enable Integrated Care Management for Managing Care Plans" and "Enable Integrated Care Management for Calculating Care Gaps." Enabling only one checkbox limits ICM functionality and causes objects from the unenabled section to be unavailable.

3. Care Coordination for Slack is a separate add-on, not base Health Cloud — Many implementations discover after go-live that Slack-based care team coordination requires a separate purchased add-on and that Slack + Health Cloud integration must already be deployed. This add-on should be confirmed in the licensing contract before care coordination workflows that depend on Slack notifications are designed.

Output Artifacts

Related Skills

• admin/care-plan-configuration — ICM care plan template setup (ProblemDefinition, GoalDefinition, ActionPlanTemplate)
• admin/care-program-management — Care program enrollment that precedes coordination workflow
• admin/referral-management-health — ClinicalServiceRequest referral configuration for handoffs