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 implementation of technical components — this skill covers requirements gathering and process design, not Apex/Flow build.

Best use case

care-coordination-requirements is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

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 implementation of technical components — this skill covers requirements gathering and process design, not Apex/Flow build.

Teams using care-coordination-requirements should expect a more consistent output, faster repeated execution, less prompt rewriting, better workflow continuity with your supporting tools.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.
  • You already have the supporting tools or dependencies needed by this skill.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/care-coordination-requirements/SKILL.md --create-dirs "https://raw.githubusercontent.com/PranavNagrecha/AwesomeSalesforceSkills/main/skills/admin/care-coordination-requirements/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/care-coordination-requirements/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How care-coordination-requirements Compares

Feature / Agentcare-coordination-requirementsStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

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 implementation of technical components — this skill covers requirements gathering and process design, not Apex/Flow build.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 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

| Situation | Recommended Object | Reason |
|---|---|---|
| Social screening identified food insecurity | CareBarrier + CareBarrierType | SDOH social factor, not a clinical diagnosis |
| Patient has uncontrolled diabetes needing care planning | CarePlanProblem | Clinical problem within care plan hierarchy |
| Patient is overdue for A1c screening | CareGap (system-generated) | Preventive care quality measure gap; cannot be created manually |
| Patient referred to a specialist | ClinicalServiceRequest | Clinical referral with provider network integration |
| Defined period of inpatient care | CareEpisode | Episode of care with time-bounded care team coordination |
| Care coordination via Slack required | Care Coordination for Slack add-on | Separate SKU; requires Slack + HC integration prerequisites |

---

## 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

| Artifact | Description |
|---|---|
| ICM object family mapping | Document mapping each care coordination scenario to its ICM objects |
| SDOH screening to barrier resolution workflow | Process flow from social screening through CareBarrier creation and Task resolution |
| Care gap integration requirements | Specification for external system integration to populate CareGap records |
| Transition of care handoff design | ClinicalServiceRequest + 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 workflow
- admin/referral-management-health — ClinicalServiceRequest referral configuration for handoffs

Related Skills

volunteer-management-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when designing or implementing volunteer management in Salesforce for nonprofits using NPSP or Nonprofit Cloud — covers V4S managed package objects vs. NPC-native volunteer objects, hours tracking, scheduling, and recognition workflows. NOT for HR systems, commercial employee volunteering programs, or Field Service Lightning crew management.

agent-console-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when gathering and documenting requirements for a Lightning Service Console deployment: agent workspace layout, page template selection, utility bar composition, macro requirements, case handling workflows, split-view navigation design, and licensing requirements. Triggers: service console requirements, agent workspace design, console page layout, utility bar planning, console licensing. NOT for console configuration steps or click-by-click setup (use admin/case-management), NOT for Omni-Channel routing model design (use architect/service-cloud-architecture), NOT for CTI telephony integration details.

wealth-management-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill when gathering, structuring, and documenting requirements for a Financial Services Cloud (FSC) wealth management implementation — including financial planning workflow discovery, portfolio review process mapping, client lifecycle requirements, advisor tooling needs, and FSC architecture determination (managed package vs. FSC Core). Trigger keywords: wealth management requirements, FSC requirements gathering, financial planning workflow, portfolio review process, advisor tools setup, FSC data model scoping, wealth management process mapping. NOT for implementation, configuration, or code — use financial-account-setup, fsc-action-plans, or apex/fsc-financial-calculations for those. NOT for FSC architecture decisions — use architect/wealth-management-architecture. NOT for Health Cloud or NPSP requirements.

territory-design-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill when gathering or evaluating requirements for a Salesforce Enterprise Territory Management (ETM) territory design: alignment criteria, coverage model selection, assignment rule logic, geographic considerations, hierarchy depth and breadth, and user-to-territory ratios. Trigger keywords: territory design, territory alignment, territory model requirements, sales coverage model, territory criteria, geographic territory, named account territory, overlay territory. NOT for ETM configuration or setup steps — use enterprise-territory-management for that. NOT for role hierarchy design — use sharing-and-visibility.

subscription-lifecycle-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when documenting, reviewing, or gathering requirements for Salesforce CPQ subscription lifecycle behavior: how amendments, renewals, upgrades, downgrades, and cancellations must work for a specific business. Trigger keywords: subscription requirements, amendment requirements, renewal requirements, proration requirements, co-termination, subscription ledger, upgrade downgrade policy. NOT for CPQ setup or configuration, not for Apex amendment API implementation, and not for Revenue Cloud advanced order management.

revenue-recognition-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill to configure and troubleshoot Salesforce Billing revenue recognition rules, schedules, and GL transaction generation in compliance with ASC 606. Triggers: 'revenue schedule not generated after order activation', 'blng__RevenueSchedule__c records missing', 'how to configure blng__RevenueRecognitionRule__c on a product', 'Finance Periods not set up before revenue schedule generation', 'revenue schedule did not update after contract amendment', 'performance obligation allocation for bundled products', 'distribution method for revenue spread', 'ASC 606 implementation in Salesforce Billing'. NOT for billing schedule setup (see billing-schedule-setup skill), NOT for standard Salesforce CPQ quoting, NOT for OpportunityLineItem native Revenue Schedules (standard platform feature unrelated to Salesforce Billing), NOT for Salesforce Revenue Cloud (Revenue Lifecycle Management).

requirements-traceability-matrix

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill when building or maintaining a Requirements Traceability Matrix (RTM) on a Salesforce project: one row per requirement, columns for source, user-story id(s), test-case id(s), defect id(s), sprint, release, and status. Covers forward traceability (req → story → code → test) and backward traceability (test → req). Trigger keywords: RTM, requirements traceability matrix, audit trail for salesforce delivery, traceability for steerco, deferred requirement tracking, regulatory traceability. NOT for requirements elicitation (use requirements-gathering-for-sf). NOT for user-story authoring (use user-story-writing-for-salesforce). NOT for UAT test design (use uat-test-case-design). NOT for Apex test design (use agents/test-generator/AGENT.md). NOT for backlog prioritization (use moscow-prioritization-for-sf-backlog).

requirements-gathering-for-sf

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill when eliciting, documenting, and structuring requirements for a Salesforce implementation or enhancement: writing Salesforce-specific user stories with acceptance criteria, mapping As-Is and To-Be business processes, conducting stakeholder discovery interviews, and performing gap analysis against standard Salesforce capabilities. Trigger keywords: requirements gathering, user story, As-Is To-Be, gap analysis, stakeholder interview, process mapping, business requirements, fit gap. NOT for technical design decisions (use solution-design-patterns). NOT for automation implementation (use flow/* or apex/* skills). NOT for data model design (use data-model-design-patterns or object-creation-and-design).

quote-to-cash-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when gathering, designing, or validating the end-to-end quote-to-cash process on standard Salesforce: Opportunity to Quote (with line items) to Synced Quote to Approval Process to Quote PDF to Order creation. Trigger keywords: quote approval, discount policy, quote PDF limits, order from quote, quote sync, quote template. NOT for CPQ/Revenue Cloud pricing rules, discount schedules, or guided selling — use CPQ skills for those.

portal-requirements-gathering

8
from PranavNagrecha/AwesomeSalesforceSkills

Use when gathering requirements for a customer portal, partner community, or self-service Experience Cloud site. Triggers: 'gathering requirements for customer portal', 'planning Experience Cloud site', 'what license for community portal', 'portal user journey mapping', 'self-service requirements'. NOT for Experience Cloud implementation or configuration. NOT for post-launch portal optimization or redesign.

patient-engagement-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill when defining patient engagement portal requirements for Health Cloud: appointment scheduling, secure in-portal messaging, health assessments, patient education, and self-service features. NOT for Experience Cloud site configuration, OmniStudio development, or standard CRM portal setup unrelated to clinical patient engagement.

partner-community-requirements

8
from PranavNagrecha/AwesomeSalesforceSkills

Use this skill to define and validate the requirements for a Salesforce Partner Relationship Management (PRM) implementation: deal registration flows, lead distribution models, partner tier hierarchies, MDF budget tracking, and co-marketing content entitlement. Trigger keywords: partner community requirements, PRM deal registration setup, channel partner portal requirements, lead distribution partner, partner tier management, MDF tracking, co-marketing entitlement. NOT for partner portal technical configuration (Experience Cloud site builder, Visualforce pages, LWC development). NOT for partner account management (account hierarchy or channel account teams).