Care Coordination Requirements
Use this skill when mapping care coordination process requirements for Health Cloud Integrated Care Management (ICM): care team workflows, transition of care handoffs, SDOH barrier tracking, and care gap identification. This skill covers requirements gathering and process-to-object mapping. It does NOT cover building individual components; for Apex, Flow, or configuration build steps, use the implementation skills listed at the end.
Licence gate: every object named here is a Health Cloud object. The developer guide titles itself "Agentforce Health Developer Guide" in Summer '26; the social determinants objects additionally require the Health Cloud managed package and its permission sets.
Before Starting
Gather this context before working on anything in this domain:
- Confirm the ICM data model is enabled. The Health Cloud developer guide says: "go to Setup and enable the FHIR R4-Aligned Data Model setting on the FHIR R4 Support Settings page and the Enhanced Care Plans setting on the Integrated Care Management Settings page." UNVERIFIED (2026-10-03): earlier versions of this skill described two other checkboxes ("Managing Care Plans" and "Calculating Care Gaps"); those labels are not in the guide.
- Identify which coordination scenarios are in scope: SDOH barriers, referrals, care gaps, care episodes. Each maps to a different object family.
- Confirm permission set licenses and permission sets for coordinators. The social determinants objects "are visible to users with the Health Cloud and the Health Cloud Platform permission set licenses and the Health Cloud Permission Set License and Health Cloud Social Determinants permission sets." UNVERIFIED (2026-10-03): a permission set named
HealthCloudICM, cited by earlier versions of this skill, is not named in the guide.
- If Slack-based coordination is in scope, the org setting is
IndustriesSettings.enableCareMgmtSlackAccess ("Care Coordination for Slack app", API 56.0). UNVERIFIED (2026-10-03): that the app is a separately purchased add-on is a commercial claim not stated in the guides read.
Questions to Ask Before Configuring
Ask these before mapping a single object. Each one traces to a gotcha in references/gotchas.md.
| Question | Why it matters | What a good answer adds | What proper configuration adds over just doing it |
|---|
| "Where do care gaps come from: calculated from clinical measures, imported from a payer system, or opened by a coordinator?" | CareGap.RecordOriginType distinguishes Calculated, Imported, and ManuallyCreated (gotcha 1) | The origin per gap source and who owns each | Gap lists a coordinator can trust, with the source system recorded on every record |
| "Who can close or exclude a gap, and what reason must they record?" | CareGap.Status is not writable; closure runs through MeasureEvaluationStatus and StatusReason (gotcha 2) | A closure and exclusion policy with required reasons | An auditable gap lifecycle instead of edits that fail or vanish |
| "Is the barrier always tied to a Case, or sometimes just to the patient?" | CareBarrier.CaseId is optional; the patient lookup is not (gotcha 4) | The rule for when a Case is created | Barriers that appear in the right views without forcing empty Cases |
| "Will barriers be written by screening automation or an integration?" | The guide's CareBarrier supported-calls list omits create() (gotcha 5) | A sandbox insert test planned before design sign-off | No late redesign of the screening flow |
| "Do referrals and episodes need the FHIR-aligned objects?" | ClinicalServiceRequest needs the FHIR-Aligned Clinical Data Model org pref (gotcha 6) | The org preferences to enable, in order | Objects that exist when the build starts |
| "Is Slack part of the care team's working day?" | Care Coordination for Slack is a separate org setting (gotcha 7) | The Slack decision and its prerequisites | No Slack-dependent workflow designed into an org where the app is off |
What a proper requirements map adds over "just using the objects": every gap, barrier, referral, and episode has an owner, an origin, and a lifecycle that the platform allows, decided before anyone builds a flow.
Core Concepts
ICM Object Families
| Family | Objects | API version | Notes |
|---|
| SDOH (social determinants) | CareBarrier, CareBarrierDeterminant, CareBarrierType, CareDeterminant, CareDeterminantType, CareInterventionType | 45.0 | Needs the Health Cloud managed package and the Social Determinants permission sets |
| Referrals | ClinicalServiceRequest, ClinicalServiceRequestDetail | See note | Listed among objects that need the FHIR-Aligned Clinical Data Model org pref |
| Care gaps | CareGap, CareGapCriteriaResult, ClinicalMeasure, ClinicalMeasureCriteria, ClinicalMeasureCriteriaGrp | 59.0 | Gaps are evaluated against clinical measures |
| Care episodes | CareEpisode, CareEpisodeDetail | 57.0 | Based on the FHIR EpisodeOfCare resource |
| Care plans | CarePlan, CarePlanActivity, CarePlanTemplate, CarePlanTemplateProblem, GoalAssignment, ProblemDefinition, GoalDefinition, ActionPlanTemplateAssignment | 56.0 to 57.0 | The PGI (problem, goal, intervention) library |
UNVERIFIED (2026-10-03): the API version for ClinicalServiceRequest (51.0 in earlier versions of this skill) was not re-read for this pass.
SDOH Barrier vs Care Plan Problem
This is the most commonly confused distinction in care coordination requirements:
| Concept | Object | What it represents |
|---|
| Social barrier | CareBarrier | "The circumstances or obstacles affecting a patient or member"; status Open or Addressed |
| Care plan problem (instantiated) | HealthCondition | ProblemDefinition records "create HealthCondition records that serve as problems in care plans" |
| Care plan problem (template) | CarePlanTemplateProblem | Positions a problem in a care plan template |
There is no standard object named CarePlanProblem. The name exists only as the legacy managed-package object HC24__CarePlanProblem__c. A barrier can be linked to a care gap through CareGap.CareBarrierId.
Care Gap Lifecycle
CareGap (API 59.0) supports create(), update(), and upsert(). Records carry a RecordOriginType of Calculated, Imported, or ManuallyCreated, a reporting period, and source-system fields. Status (Open, Closed, Excluded) has no Create or Update property in the field list. Coordinators act through MeasureEvaluationStatus, which includes ManuallyOpened, ManuallyClosed, and ManuallyExcluded, with StatusReason holding "the reason for force closing the care gap".
Common Patterns
Transition of Care Handoff Design
When to use: A patient is discharged from hospital and moves to outpatient care coordination.
How it works:
- On discharge, a
CareEpisode record covers the inpatient stay; CareEpisodeDetail can reference the referral that started it or the diagnoses it addresses.
- A
ClinicalServiceRequest (referral) goes to the receiving outpatient team.
- The outpatient coordinator accepts the referral and creates a
CarePlan for post-discharge management.
- SDOH screening identifies transportation and food barriers;
CareBarrier records are linked to the patient and, where coordination work is needed, to a Case.
- Care gaps arrive by calculation or import and appear in the coordinator's list.
- The coordinator works barrier interventions through tasks, and an Action Plan on the Case can generate them (see
references/metadata-examples.md).
SDOH Screening and Barrier Resolution
When to use: A coordinator runs social needs screening and finds barriers that need intervention.
How it works:
- Run the screening assessment;
CareBarrier.SurveyResponseId can reference the survey response.
- For each positive finding, record a barrier with its
CareBarrierType and Priority (Low, Normal, High).
- Create a Case when a community resource intervention must be tracked.
- Generate intervention tasks on the Case.
- Set the barrier's
Status to Addressed when the intervention is complete. UNVERIFIED (2026-10-03): earlier versions of this skill said the barrier status updates automatically when tasks close; the guide does not describe that automation.
Decision Guidance
| Situation | Recommended Object | Reason |
|---|
| Screening found food insecurity | CareBarrier with a CareBarrierType | Social determinant, not a clinical diagnosis |
| Uncontrolled diabetes needs a care plan problem | HealthCondition instantiated from a ProblemDefinition | Clinical problem in the PGI hierarchy |
| Patient overdue for A1c screening | CareGap evaluated against a ClinicalMeasure | Quality measure gap with origin, period, and status |
| Coordinator knows of a gap the engine missed | CareGap with RecordOriginType = ManuallyCreated | The data model records manual origin explicitly |
| Patient referred to a specialist | ClinicalServiceRequest | Clinical referral; needs the FHIR-aligned org pref |
| Defined period of inpatient care | CareEpisode | Episode of care based on FHIR EpisodeOfCare |
Recommended Workflow
- Verify prerequisites. Confirm the FHIR R4-Aligned Data Model setting and the Enhanced Care Plans setting are enabled, the FHIR-Aligned Clinical Data Model org pref is on if referrals are in scope, and coordinators hold the Health Cloud permission set licenses and Social Determinants permission sets.
- Map scenarios to object families. For each scenario in scope, name the objects from the table above and the record that anchors it (patient account, Case, care plan).
- Design SDOH tracking. Define
CareBarrierType and CareDeterminantType values, the screening-to-barrier rule, when a Case is created, and the intervention tasks. Test a barrier insert in a sandbox before sign-off.
- Design care gap sourcing and lifecycle. Decide which gaps are calculated, imported, or manually created; who may close or exclude them; and the reasons they must record.
- Design transition of care handoffs. Map each handoff to
ClinicalServiceRequest and CareEpisode, and name the roles that send and receive.
- Decide on Slack. If Slack is in scope, confirm
enableCareMgmtSlackAccess and its prerequisites before designing Slack-dependent steps. Deployable settings are in references/metadata-examples.md.
Review Checklist
Salesforce-Specific Gotchas
The deep versions, with sources, live in references/gotchas.md.
| # | Gotcha | One-line consequence |
|---|
| 1 | Care gaps can be calculated, imported, or manually created | Designs that forbid manual gaps block a supported workflow |
| 2 | CareGap.Status is not writable | Flows that set Status fail; use MeasureEvaluationStatus |
| 3 | ICM needs two named settings plus licences | Objects are missing at build time |
| 4 | CareBarrier.CaseId is optional | Forcing a Case on every barrier creates empty Cases |
| 5 | The guide lists no create() call for CareBarrier | Screening automation may fail to insert barriers |
| 6 | Referrals need the FHIR-Aligned Clinical Data Model org pref | ClinicalServiceRequest is unavailable without it |
| 7 | Slack coordination is its own setting | Slack steps silently do nothing when the app is off |
Output Artifacts
| Artifact | Description |
|---|
| ICM object family mapping | Each care coordination scenario mapped to its objects |
| SDOH screening to barrier resolution workflow | From screening through barrier, Case, tasks, and Addressed |
| Care gap sourcing and lifecycle | Origin per source, closure and exclusion policy, required reasons |
| Transition of care handoff design | ClinicalServiceRequest and CareEpisode workflow for care transitions |
Related Skills
admin/care-plan-configuration: ICM care plan template setup (ProblemDefinition, GoalDefinition, ActionPlanTemplate)admin/care-program-management: care program enrollment that precedes coordination workflowadmin/referral-management-health: ClinicalServiceRequest referral configuration for handoffsadmin/clinical-data-requirements: FHIR-aligned clinical data model prerequisites