Explanation:

To implement Virtual Care in Salesforce Health Cloud for Bloomington Caregivers, the following three steps are required as part of the setup:

B. Set up and configure Salesforce Scheduler:
Salesforce Scheduler (formerly Lightning Scheduler) is a key component for Virtual Care, enabling the scheduling of virtual appointments. It must be configured to manage provider availability, appointment types, and virtual meeting details, integrating seamlessly with Health Cloud’s Virtual Care functionality.
D. Assign Health Cloud Video Calls permission set:
This permission set grants users access to the video call functionality within Health Cloud, which is essential for conducting virtual consultations. It includes permissions for initiating and managing video calls, ensuring secure and compliant communication.
E. Install the Virtual Care unmanaged package:
The Virtual Care unmanaged package provides additional components, such as prebuilt flows, objects, and configurations, to enable video-based virtual care in Health Cloud. Installing this package is a critical step to activate the out-of-the-box Virtual Care features.

Why the other options are incorrect:
A. Configure Provider Search:
While Provider Search is useful for finding providers based on criteria like specialty or location, it is not a required step for setting up Virtual Care, which focuses on enabling video consultations and scheduling.
C. Connect to an external electronic health record (EHR) scheduling system:
Connecting to an external EHR is optional and depends on the organization’s needs. Health Cloud’s Virtual Care can function without an external EHR integration, using internal scheduling tools like Salesforce Scheduler.

Reference:
Salesforce Health Cloud documentation on Virtual Care setup (Salesforce Help).
Health Cloud Accredited Professional exam resources, which detail the configuration steps for Virtual Care, including Scheduler and permission sets.

Explanation:

A. Health Care Facility Network
Represents a network of facilities (e.g., hospital system, clinic chain).
Too high-level; doesn’t directly track a provider’s practice location.

B. Health Care Provider
Represents the organization itself (hospital, clinic, pharmacy).
Not tied to where an individual practitioner works.

C. Health Care Practitioner Facility ✅
Junction object between Health Care Practitioner (the person) and Health Care Facility (the place).
Used to track each facility/location where a provider practices.
Exactly matches the requirement in the scenario.

D. Health Care Provider Specialty
Tracks specialties (e.g., Cardiology, Pediatrics) for providers.
Not related to location.

E. Business License
Used to track provider licensing/certification details.
Not related to practice locations.

Reference:
Salesforce Health Cloud PRM Guide: Provider Data Model
Key note:
“Use Health Care Practitioner Facility to track the locations where a practitioner is affiliated with one or more facilities.”

⚡ Exam Tip:
Facility Network = system of organizations.
Provider = organization (hospital, clinic).
Practitioner = individual person (doctor, nurse).
Practitioner Facility = link between provider + facility (tracks where they practice).

Explanation:

A. Assign users the Health Cloud Crisis Support Center Management permission set license
Why? Grants users access to crisis-specific features (e.g., emergency intake, risk assessment tools).
Note: This is a permission set license, not a standard permission set.

D. Review and modify the Crisis Center Intake flow in Flow Builder to meet requirements
Why? Health Cloud provides out-of-the-box Crisis Center flows that need customization for:
Patient triage logic
Risk-level automation
Compliance with organizational protocols

Why Not the Others?
❌ B. Install the Crisis Support Center unmanaged package
Health Cloud’s crisis features are native (no unmanaged package needed). Installing one could create conflicts.
❌ C. Enable Crisis Support Center Management App in Setup
There’s no standalone "Crisis Support Center" app in Health Cloud. Crisis tools are part of core functionality.

Explanation:

Configuring an org to use Person Accounts with Health Cloud in Lightning Experience requires specific, deliberate setup steps to ensure the data model and features align correctly.

C. Under Custom Metadata Types, Update the Health cloud ‘HCFeature’…:
Health Cloud uses Custom Metadata Types (specifically HCFeature) to control the activation of certain features. To properly integrate Person Accounts, you must update the relevant HCFeature record to indicate that Person Accounts are in use. This ensures Health Cloud's functionality (like Timeline, Care Plans, etc.) points to the Person Account object instead of the individual Contact and Account objects.
D. Enable “Use Person Accounts” custom setting.:
This is a critical prerequisite. The "Use Person Accounts" setting is an org-wide custom setting that tells Salesforce to make the Person Account record type available and to activate the underlying data model that merges Account and Contact information into a single record. Health Cloud cannot leverage Person Accounts unless this foundational setting is first enabled for the org.

Why the other options are incorrect:
A. Under Custom Metadata Types, enable the Health cloud Setting: This is too vague. You don't simply "enable" a general Health Cloud setting; you configure specific records within specific metadata types (like HCFeature in option C).
B. Disable “Use Individual Data Model” in custom setting: The "Use Individual Data Model" setting is for a different, mutually exclusive data model. The Individual object is used for B2C marketing and privacy (GDPR, CCPA) purposes. It is not related to the Person Account model. You do not need to disable it to use Person Accounts; these are separate configurations.
E. Under Custom Metadata Types, Create a mapping records for Person accounts.: This is not a standard step. The mapping and integration are handled by updating the existing HCFeature record (as in option C), not by creating new mapping records.

Reference:
The official Salesforce Help article "Enable Person Accounts for Health Cloud" details these exact steps, specifically highlighting the requirement to enable the org-wide setting and then update the HCFeature metadata. This is a key data model configuration task for the Health Cloud Accredited Professional exam.

Explanation:

For external patient users who need advanced sharing and customizable dashboards, the Customer Community Plus for Health Cloud license is the most appropriate choice. This license supports:
Role-based sharing rules
Access to reports and dashboards
More granular CRUD permissions on Health Cloud objects
Enhanced collaboration features for patient engagement and contact tracing workflows

These capabilities are essential for a patient portal that includes sensitive data, dynamic dashboards, and personalized care coordination.

🛑 Why not the other options?
A. External Apps for Health Cloud: Designed for B2B partner use cases (e.g., brokers, suppliers), not patient-facing portals.
B. Experience Cloud for Health Cloud: Suitable for basic B2C use cases but lacks advanced sharing and dashboard access.
C. Customer Community for Health Cloud: Limited in terms of sharing rules and dashboard/report access; not sufficient for this scenario.

📚 References:
Salesforce Help: Experience Cloud for Health Cloud FAQ
Salesforce Health Cloud Licensing Overview