本文へ移動
cccskills
無料GitHub で公開

health-cloud-patient-setup

Configure patient or member records in Salesforce Health Cloud: Person Account enablement, patient record types, care team role configuration, patient card customization, clinical data display. Trigger keywords: patient setup, Health Cloud person account, patient card component, care team roles, clinical data display. NOT for Person Accounts outside Health Cloud - use data/person-accounts. NOT for enrolling a patient into a care program - use admin/care-program-management.

インストール方法を見る

含まれるファイル(8)

  • SKILL.md15.1 KB
  • references/examples.md6.0 KB
  • references/gotchas.md6.1 KB
  • references/llm-anti-patterns.md8.0 KB
  • references/well-architected.md6.1 KB
  • scripts/check_health_cloud_patient_setup.py10.8 KB
  • scripts/check_patient_setup.py10.7 KB
  • templates/health-cloud-patient-setup-template.md6.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Health Cloud Patient Setup

This skill activates when a practitioner needs to configure patient or member records in Salesforce Health Cloud — covering Person Account enablement, Health Cloud-specific patient record type creation, care team role setup, and patient card customization for clinical data display. It is NOT for standard Salesforce account setup or general person account tasks outside the Health Cloud context.


Before Starting

Gather this context before working on anything in this domain:

  • Confirm Health Cloud managed package is installed (package namespace HealthCloudGA). Person Account enablement is a prerequisite, but it is also an org-wide, irreversible operation. Never enable in production without a full impact assessment.
  • Determine whether Person Accounts are already enabled. If they are, skip that step entirely — attempting to re-enable causes no change but wastes time and can be confusing.
  • Identify the record types needed: Health Cloud typically requires at minimum a "Patient" (or "Member") person account record type alongside any existing business account record types. Understand what page layouts and profiles will be affected.
  • Clarify what clinical data the org consumes: FHIR/HL7 data flows through dedicated Health Cloud objects (EhrPatientMedication, PatientHealthCondition, PatientImmunization, etc.) — it does not map to standard Contact or Account fields.
  • Understand whether a care team is required and what roles exist (e.g., Primary Care Physician, Care Manager, Social Worker). Care team roles are configured in Health Cloud settings, not through standard role hierarchies.

Core Concepts

Person Accounts: Org-Wide, Irreversible Prerequisite

Health Cloud patients are represented as Person Accounts — a Salesforce platform feature that merges Account and Contact into a single record for individual people. Enabling Person Accounts is a permanent, org-wide change. Once enabled, every Account record gains an IsPersonAccount boolean field and the object model changes globally: person account records have no associated Contact record (the Contact fields are embedded on the Account). This cannot be reversed by Salesforce Support. All integrations, reports, SOQL queries, and third-party tools that assume standard Account/Contact separation must be reviewed and updated after enablement.

Source: Health Cloud Administration Guide — Set Up Person Accounts

Health Cloud Patient Record Type vs. Person Account Enablement

Enabling Person Accounts at the org level is step one. Creating a Health Cloud patient record type is a distinct, sequential step two. These are not the same action. After Person Accounts are enabled, a new record type must be created (typically named "Patient" or "Member") on the Account object. This record type is assigned a Health Cloud-specific page layout that includes clinical components such as the Patient Card, Timeline, and Social Determinants sections. Practitioners who conflate these two steps often end up with Person Accounts that lack the Health Cloud UI components.

Clinical Data Objects vs. Standard Fields

Clinical data in Health Cloud does not live on standard Account or Contact fields. Medications, health conditions, immunizations, procedures, and care gaps are stored on dedicated Health Cloud objects:

  • EhrPatientMedication — medication records imported from EHR systems
  • PatientHealthCondition — diagnoses and chronic conditions
  • PatientImmunization — immunization records
  • PatientMedicalProcedure — procedure history
  • CareDiagnosis — diagnosis linked to a care plan

These objects hold a lookup to the patient Account record. Data flows into them via FHIR/HL7 integrations (using Health Cloud's FHIR APIs or MuleSoft) or direct DML from custom integrations. Attempting to store clinical data in custom fields on Account or Contact creates an unsupported data model that breaks Health Cloud reporting, timeline views, and care plan components.

Patient Card Component

The Patient Card (healthCloudUtility:patientCard in the Aura namespace, or the equivalent LWC) is the primary clinical summary displayed on a patient record page. It can display fields from the patient Account record itself and from any related object that has a lookup relationship to the patient Account. Customization is done through the Health Cloud app in Setup (Patient Card Configuration) — not through the standard Lightning App Builder field configuration. A common mistake is attempting to add clinical fields directly to the Lightning record page layout instead of configuring them through the Patient Card settings.


Common Patterns

Pattern 1: Full Patient Setup from Scratch

When to use: New Health Cloud implementation — no Person Accounts enabled, no patient record type exists.

How it works:

  1. Submit a case to Salesforce Support (or use the Setup wizard in some editions) to enable Person Accounts. Org must have at least one Account record type already.
  2. Wait for confirmation that Person Accounts are enabled. Verify by checking that the IsPersonAccount field exists on Account.
  3. In Health Cloud Setup, navigate to Patient Setup and create the Patient record type on Account.
  4. Assign the Patient record type to the appropriate profile(s) via Profile > Record Type Settings.
  5. Assign the Health Cloud patient page layout to the Patient record type.
  6. Enable care team functionality in Health Cloud Settings if care team management is required.
  7. Configure care team roles in Health Cloud Settings > Care Team Roles.

Why not the alternative: Some practitioners attempt to create a custom object for patients rather than using Person Accounts. This bypasses all Health Cloud clinical components (Patient Card, Timeline, Care Plans) since they are hardwired to Person Account records.

Pattern 2: Patient Card Customization with Clinical Data

When to use: Patient record type exists, but the Patient Card needs to display additional fields from clinical objects or related records.

How it works:

  1. In Setup, navigate to Health Cloud > Patient Card Configuration.
  2. Select the card section to modify (e.g., Medications, Conditions, or a custom section).
  3. Add the desired fields from the target object. The object must have a lookup to the patient Account record.
  4. Save and verify the configuration on a test patient record.
  5. For clinical objects fed by FHIR integrations, confirm the integration is populating the source objects before expecting data on the card.

Why not the alternative: Editing the Lightning record page layout directly to show clinical fields works only for Account-level fields. Clinical data from related objects (EhrPatientMedication, PatientHealthCondition) requires Patient Card configuration to display in the clinician-facing summary format.


Decision Guidance

SituationRecommended ApproachReason
Person Accounts not enabled, starting freshEnable via Setup wizard/Support, then create HC patient record typeSequential prerequisites — cannot skip or reverse
Person Accounts already enabled, no patient record typeGo directly to Health Cloud Setup > Patient SetupDo not re-enable; that step is done
Need to display medication data on patient recordConfigure Patient Card via Health Cloud SettingsClinical objects need Patient Card config, not LP layout fields
Need to add a non-standard care role (e.g., Social Worker)Add role in Health Cloud Settings > Care Team RolesCare team roles are HC-specific, not standard Salesforce role hierarchy
Org has mixed B2B and patient recordsCreate separate record types: Business Account and PatientPerson Account coexists with business accounts via record types
Clinical data not showing on Patient CardVerify source HC object has data AND Patient Card config references that objectBoth the data population and the card config must be correct

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

  1. Assess prerequisites: Confirm Health Cloud managed package is installed and check whether Person Accounts are already enabled (IsPersonAccount field exists on Account). Document the current state before taking any action.
  2. Enable Person Accounts (if not already enabled): Ensure at least one Account record type exists, then enable Person Accounts via Setup. Brief all stakeholders on the irreversibility and org-wide impact on Account/Contact queries, integrations, and reports before proceeding.
  3. Create the Health Cloud patient record type: In Health Cloud Setup, create the Patient (or Member) record type on Account. Assign the Health Cloud patient page layout. Assign the record type to appropriate profiles.
  4. Configure care team roles: In Health Cloud Settings > Care Team Roles, add all needed roles (clinical and non-clinical). Assign default roles to the care team template if applicable.
  5. Customize the Patient Card: Navigate to Health Cloud > Patient Card Configuration in Setup. Add fields from the patient Account and from related clinical objects. Verify that any clinical objects used (EhrPatientMedication, PatientHealthCondition, etc.) already have a lookup to the patient Account and are populated with data.
  6. Validate with a test patient record: Create a test person account with the Patient record type. Confirm the Patient Card renders, care team roles are selectable, and clinical data displays correctly.
  7. Review access and sharing: Confirm that the patient record type is accessible to the correct profiles, that Health Cloud permission sets are assigned (HealthCloudFoundation, HealthCloudSocialDeterminants, etc.), and that field-level security is appropriate for any sensitive clinical fields.

Review Checklist

Run through these before marking work in this area complete:

  • Person Accounts confirmed enabled (IsPersonAccount field visible on Account object in Object Manager)
  • Patient record type created on Account object and assigned to correct profiles
  • Health Cloud patient page layout assigned to Patient record type (includes Patient Card, Timeline components)
  • Care team roles configured in Health Cloud Settings and reflect all required clinical and non-clinical roles
  • Patient Card configuration updated to display required clinical and administrative fields
  • Test patient record created and visually verified (Patient Card displays, care team is selectable)
  • Health Cloud permission sets assigned to all relevant user profiles
  • Integration touchpoints (FHIR, HL7, MuleSoft) verified to populate clinical HC objects, not standard fields

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

  1. Person Account Enablement Is Permanent — Once Person Accounts are enabled, the org-wide Account/Contact model changes irreversibly. All SOQL queries, Apex triggers, reports, and third-party integrations that assume separate Account and Contact records may break. There is no undo. Always enable in a sandbox first and run a full regression before enabling in production.
  2. Enabling Person Accounts Does Not Create the Patient Record Type — Person Account enablement (org-level feature toggle) and Health Cloud patient record type creation (Health Cloud Setup action) are separate, sequential steps. Administrators who enable Person Accounts and stop there will see no Health Cloud clinical components on patient records. The Patient record type and its page layout must be explicitly created and assigned.
  3. Clinical HC Objects, Not Standard Fields — Medications, conditions, immunizations, and procedures live in dedicated Health Cloud objects (EhrPatientMedication, PatientHealthCondition, etc.), not in custom fields on Account or Contact. Mapping FHIR data into custom Account fields breaks Health Cloud Timeline, Patient Card, and Care Plan components.
  4. Patient Card Requires HC-Specific Configuration — The Patient Card cannot be configured via the standard Lightning App Builder field editor. It has its own configuration UI in Setup under Health Cloud. Attempts to drag clinical fields onto the record page layout will result in them appearing outside the Patient Card, not inside it.

Output Artifacts

ArtifactDescription
Patient record typeAccount record type named "Patient" (or "Member") with Health Cloud page layout assigned
Care team role configurationList of roles defined in Health Cloud Settings, ready for care team assignment
Patient Card configurationConfigured sections displaying clinical and administrative fields on the patient record
Test patient recordVerified person account used to validate end-to-end setup before go-live

Related Skills

  • data/person-accounts — Core person account enablement details, SOQL impacts, and data model changes that apply across all clouds using person accounts
  • admin/care-program-management — Care plans, care programs, and care gap management built on top of the patient setup established here
  • data/health-cloud-data-model — Deep reference for Health Cloud-specific objects including clinical data objects referenced in this skill

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use this skill when writing test-first, behavior-driven acceptance criteria in Given/When/Then format for a Salesforce user story. Covers happy path, edge cases, negative paths, permission boundaries, and data-state preconditions so the AC block can drive UAT scripts and Apex test design downstream. Trigger keywords: given when then, gherkin, behavior driven AC, test first acceptance criteria, scenario outline, BDD acceptance criteria. NOT for the user-story format itself (use admin/user-story-writing-for-salesforce). NOT for UAT script writing (use admin/uat-test-case-design). NOT for Apex test method generation (use agents/test-class-generator). NOT for high-level UAT planning (use admin/uat-and-acceptance-criteria). More triggers: acceptance criteria record, ac_id, req_id on a criterion, artefact under test, negative case for a rule-type requirement, no-match fall-through criterion, oracle for a Then clause, test type apex flow manual, criteria linter, check_ac_format.py, --manifest-dir.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Task and Event objects: polymorphic WhatId/WhoId, Activity object model, ActivityHistory vs OpenActivity, activity timeline customization, bulk task creation, Einstein Activity Capture boundaries. NOT for turning on EAC or calendar sync — use admin/einstein-activity-capture-setup. NOT for Email-to-Case — use admin/case-management-setup. Covers ActivitiesSettings metadata, enableActivities, shared Task/Event custom fields and FLS, TaskStatus value sets, Shared Activities and TaskRelation/EventRelation, recurring and child activities, and partial-success bulk DML on Task.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Design Invocable Apex actions that return deterministic, agent-friendly errors instead of surfacing raw exceptions to the LLM. NOT for authoring the action itself — @InvocableMethod schema, labels, security context — use agentforce/custom-agent-actions-apex. NOT for the Apex tests that force each error branch — use agentforce/agent-action-unit-tests.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Use when designing how an Agentforce agent extracts structured input parameters (slots) from a user's natural-language utterance to invoke an action. Triggers: 'agent extract date from user', 'agent action argument extraction', 'agentforce slot filling', 'agent invocable input mapping', 'agent fails to fill required parameter'. NOT for action authoring (use agentforce/agent-actions) or for prompt-template variable binding (use agentforce/prompt-builder-templates).

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Apex test patterns for @InvocableMethod agent actions: per-reason-code branch coverage, bulk safety, callout mocking, deterministic assertions. NOT for testing whether the agent routes to the right topic or answers well — use agentforce/agent-testing-and-evaluation. NOT for designing the error envelope the tests assert on — use agentforce/agent-action-error-handling.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Designing or reviewing Agentforce actions: Flow actions, Apex invocable actions, prompt-template actions, action naming, input and output contracts, confirmation requirements, and safe error behavior. Triggers: 'agent actions', 'build an agent that can look up an order', 'make the agent able to check order status', 'give the agent a capability', 'agent that can retrieve a record', 'flow action for agent', 'agent invocable action', 'action schema design'. NOT for writing the Apex class itself — use agentforce/custom-agent-actions-apex. NOT for the reason_code error envelope that stops an agent retry loop — use agentforce/agent-action-error-handling.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

PranavNagrecha のスキルをすべて見る

このスキルの問題を報告する