SfSkills Domains Docs GitHub

Home / admin / care-coordination-requirements

care-coordination-requirements

Use this skill when mapping care coordination process requirements for Health Cloud: designing care team workflows, transition of care handoffs, social determinants of health (SDOH) barrier tracking, and care gap identification. NOT for building care plan templates, problems, and goals — use admin/care-plan-configuration. NOT for referral routing and provider networks — use admin/referral-management-health.

Open the skill folder on GitHub

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:

Questions to Ask Before Configuring

Ask these before mapping a single object. Each one traces to a gotcha in references/gotchas.md.

QuestionWhy it mattersWhat a good answer addsWhat 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 eachGap 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 reasonsAn 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 createdBarriers 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-offNo 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 orderObjects 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 prerequisitesNo 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

FamilyObjectsAPI versionNotes
SDOH (social determinants)CareBarrier, CareBarrierDeterminant, CareBarrierType, CareDeterminant, CareDeterminantType, CareInterventionType45.0Needs the Health Cloud managed package and the Social Determinants permission sets
ReferralsClinicalServiceRequest, ClinicalServiceRequestDetailSee noteListed among objects that need the FHIR-Aligned Clinical Data Model org pref
Care gapsCareGap, CareGapCriteriaResult, ClinicalMeasure, ClinicalMeasureCriteria, ClinicalMeasureCriteriaGrp59.0Gaps are evaluated against clinical measures
Care episodesCareEpisode, CareEpisodeDetail57.0Based on the FHIR EpisodeOfCare resource
Care plansCarePlan, CarePlanActivity, CarePlanTemplate, CarePlanTemplateProblem, GoalAssignment, ProblemDefinition, GoalDefinition, ActionPlanTemplateAssignment56.0 to 57.0The 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:

ConceptObjectWhat it represents
Social barrierCareBarrier"The circumstances or obstacles affecting a patient or member"; status Open or Addressed
Care plan problem (instantiated)HealthConditionProblemDefinition records "create HealthCondition records that serve as problems in care plans"
Care plan problem (template)CarePlanTemplateProblemPositions 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:

  1. On discharge, a CareEpisode record covers the inpatient stay; CareEpisodeDetail can reference the referral that started it or the diagnoses it addresses.
  2. A ClinicalServiceRequest (referral) goes to the receiving outpatient team.
  3. The outpatient coordinator accepts the referral and creates a CarePlan for post-discharge management.
  4. SDOH screening identifies transportation and food barriers; CareBarrier records are linked to the patient and, where coordination work is needed, to a Case.
  5. Care gaps arrive by calculation or import and appear in the coordinator's list.
  6. 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:

  1. Run the screening assessment; CareBarrier.SurveyResponseId can reference the survey response.
  2. For each positive finding, record a barrier with its CareBarrierType and Priority (Low, Normal, High).
  3. Create a Case when a community resource intervention must be tracked.
  4. Generate intervention tasks on the Case.
  5. 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

SituationRecommended ObjectReason
Screening found food insecurityCareBarrier with a CareBarrierTypeSocial determinant, not a clinical diagnosis
Uncontrolled diabetes needs a care plan problemHealthCondition instantiated from a ProblemDefinitionClinical problem in the PGI hierarchy
Patient overdue for A1c screeningCareGap evaluated against a ClinicalMeasureQuality measure gap with origin, period, and status
Coordinator knows of a gap the engine missedCareGap with RecordOriginType = ManuallyCreatedThe data model records manual origin explicitly
Patient referred to a specialistClinicalServiceRequestClinical referral; needs the FHIR-aligned org pref
Defined period of inpatient careCareEpisodeEpisode of care based on FHIR EpisodeOfCare
  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. Design transition of care handoffs. Map each handoff to ClinicalServiceRequest and CareEpisode, and name the roles that send and receive.
  6. 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.

#GotchaOne-line consequence
1Care gaps can be calculated, imported, or manually createdDesigns that forbid manual gaps block a supported workflow
2CareGap.Status is not writableFlows that set Status fail; use MeasureEvaluationStatus
3ICM needs two named settings plus licencesObjects are missing at build time
4CareBarrier.CaseId is optionalForcing a Case on every barrier creates empty Cases
5The guide lists no create() call for CareBarrierScreening automation may fail to insert barriers
6Referrals need the FHIR-Aligned Clinical Data Model org prefClinicalServiceRequest is unavailable without it
7Slack coordination is its own settingSlack steps silently do nothing when the app is off

Output Artifacts

ArtifactDescription
ICM object family mappingEach care coordination scenario mapped to its objects
SDOH screening to barrier resolution workflowFrom screening through barrier, Case, tasks, and Addressed
Care gap sourcing and lifecycleOrigin per source, closure and exclusion policy, required reasons
Transition of care handoff designClinicalServiceRequest and CareEpisode workflow for care transitions

Dependencies

Package files