Explanation:

When creating a new Care Plan Task in Salesforce Health Cloud, the Goal and Problem fields are optional. Here's a breakdown of each field:
A. Status:
This field is required as it indicates the current state of the task (e.g., In Progress, Completed, Not Started). Health Cloud mandates setting a status to track task progress.
B. Due Date:
This is a required field to ensure tasks are associated with a timeline for completion, critical for care plan management.
C. Goal:
This field is optional. While associating a task with a goal (from the CarePlanGoal object) provides context, it is not mandatory, as tasks can exist independently to address immediate actions.
D. Problem:
This field is optional. Linking a task to a specific problem (from the HealthCondition or CarePlanProblem object) is useful for traceability but not required for task creation.
E. Task Owner:
This field is required to assign responsibility for the task, ensuring accountability within the care team.

Reference:
Salesforce Health Cloud documentation on Care Plan Tasks (Salesforce Help).
Health Cloud Accredited Professional exam resources, which detail the configuration of care plans and tasks.

Explanation:

To add a new search parameter for Identity Verification in Salesforce Health Cloud, the consultant should configure the Identity Verification Parameter Item record. This record defines individual fields—such as name, phone number, or postal code—that are used during the verification process. Each parameter item specifies:
The field name to be used for verification
The data source type (e.g., Salesforce object)
The label and field type (e.g., optional verifier or result field)

This configuration enables customer service representatives to verify a caller’s identity using multiple data points, and it’s part of the broader Identity Verification Process Definition.

🛑 Why not the other options?
A. Linked Identity Search Detail: Not used for defining search parameters; more relevant to linking search results.
B. Identity Verification Process Detail: Defines the overall process but doesn’t configure individual search fields.
C. Verification Search Feature: Refers to the feature set, not the specific configuration record for adding parameters.

📚 References:
Salesforce Developer Guide: Identity Verification API and Configuration
Salesforce Help: Identity Verification and Engagement in Health Cloud

Explanation:

A. Create a new case record type for each Care Request type:
Care Requests leverage the standard Salesforce Case object. To differentiate between various types of requests (e.g., Pre-Authorization, Appeal, Admission Notification), you must create a separate Case record type for each. This allows you to customize the layout, fields, and picklist values for each specific request type.
B. Install UM unmanaged package for Health Cloud. Then assign Health cloud Utilization management permission set to users along with Health cloud permission set licenses:
To unlock the full functionality of Care Requests, specifically for utilization management (UM), you need to install the Utilization Management unmanaged package. This package adds key objects and features. After installation, you must grant users access by assigning them the Health Cloud Utilization Management permission set and the required Health Cloud permission set licenses. This ensures users have the necessary permissions to create and manage Care Requests.
E. Choose case Care Request record type for each Care Request configuration:
In Health Cloud, the Care Request Configuration is a custom setting that links the specific Care Request types you created (in step A) to their corresponding objects and settings. For each configuration, you must explicitly select the correct Case record type you created, thereby connecting the user-facing request type to the underlying data model.

Why the other options are incorrect:
C. All Care requests are pre-setup on all Health Cloud orgs by default.
This is incorrect. While the underlying objects exist, the specific configurations, record types, and permissions needed for a functioning Care Request process are not pre-configured and must be set up manually by an administrator.
D. Choose any existing case record type for each Care Request type.
This is too broad and often an incorrect practice. While you could technically use a generic case record type, best practice and proper Health Cloud setup require creating specific, dedicated record types to ensure data integrity and a clear user experience tailored to each type of Care Request.

Explanation:

Enabling external users (e.g., patients or members visiting a Digital Experience/Community site) to use Provider Search requires both data access and UI access.

B. Give the site user profile Read access to the Care Provider Searchable Field object:
The CareProviderSearchableField object is a key component of the Health Cloud data model for Provider Search. It stores the indexed, searchable data about providers (e.g., name, specialty, location). For an external user's profile (the "Site User" profile) to be able to query and retrieve this data, it must have Read permission on this object. This is a fundamental data security requirement.

D. Use Experience Builder to add the Provider Search component to a page on the site:
Granting data access is not enough; users need a way to interact with the functionality. The pre-built Provider Search component must be added to a page within the Digital Experience (Community) using Experience Builder. This provides the user interface (search bar, filters, results list, map view) that external users need to perform searches.

Why the other options are incorrect:
A. Give the site user profile Read access to the Data Pipeline object:
The DataPipeline object is used for the background process that aggregates and processes provider data to make it searchable. It is an administrative object. External users do not need, and should not have, any access to this object to use the search results; they only need access to the final output (CareProviderSearchableField).

C. Create a sharing rule on the Care Provider Searchable Field object to share with external users:
Sharing rules are typically used to share records within an internal org. External users (via a Digital Experience) access records through sharing sets, guest user sharing rules, or the external user's profile permissions. A standard sharing rule is not the primary mechanism for controlling external user access; the critical step is configuring the Site User profile's object-level read permission (as in option B).

Reference:
Salesforce Help articles such as "Provide Access to Provider Search for Experience Cloud Users" and "Set Up Provider Search" explicitly cover these steps. This is a key configuration task in the "Provider Search" and "Digital Experiences" sections of the Health Cloud implementation guide and exam objectives.

Explanation:

A. Timeline ✅
The Enhanced Timeline in Health Cloud is customizable.
You can configure which clinical events, encounters, tasks, assessments show up, and how they’re displayed for providers.

B. EHR Data
Health Cloud integrates with EHR systems (via FHIR, HL7, MuleSoft, etc.).
But the EHR data itself is not customizable within Health Cloud — it’s managed in the external EHR.
You can map or surface it, but not customize the actual component.

C. Life Events ✅
Life Events (like marriage, childbirth, graduation) are customizable objects in Health Cloud.
Organizations can configure which events are tracked and how they impact engagement plans.

D. Patient Card ✅
The Patient Card (mini profile summary) is configurable.
You can decide which fields, KPIs, or key patient info (allergies, meds, demographics) appear.

E. Custom Label
Custom labels are a Salesforce platform feature, not a Health Cloud-specific customizable component.
They help with localization/translation, but they’re not a Health Cloud component.

Reference:
Salesforce Health Cloud Implementation Guide:
Customize the Patient Card
Configure Enhanced Timeline
Track Life Events

⚡ Exam Tip:
If the question is “Which Health Cloud components are customizable?” → look for UI-based features (Timeline, Life Events, Patient Card), not backend data integration (EHR) or Salesforce platform utilities (Custom Label).