Health-Cloud-Accredited-Professional Practice Test Questions

Explanation:

Health Cloud's new data model is built on the FHIR (Fast Healthcare Interoperability Resources) standard to enable better interoperability with electronic health records (EHRs) and other healthcare systems. The supported medication-related resources are specific FHIR resource names.

Why B, D, and E are Correct:
B. Medication:
The Medication FHIR resource is supported. This resource describes the medication itself (e.g., the drug name, form, strength, and package details). It is the definition of the medication substance.
D. Medication Dispense:
The MedicationDispense FHIR resource is supported. This resource contains information about the provision of a supply of medication. It records when a medication was dispensed to a patient, in what quantity, for how long, and from which pharmacy.
E. Medical Request:
This refers to the MedicationRequest FHIR resource, which is supported. This is a key resource that represents an order for medication for a patient. It captures the prescribing provider's instructions, including the medication, dosage, frequency, and duration.

Why A and C are Incorrect:
A. Medical Administration:
While a crucial part of the medication lifecycle, "Medical Administration" is not the name of a primary, top-level FHIR resource used for this purpose in the context of Health Cloud's supported list. The act of administering a dose to a patient is typically part of the record within other resources or is handled by the MedicationAdministration resource, which is not highlighted as a core supported resource in the same way as the three correct answers for this standard Health Cloud exam question.
C. Dosage:
Dosage is not a standalone FHIR resource. Instead, dosage instructions are a critical component embedded within other resources, primarily the MedicationRequest resource. They are defined within the dosageInstruction element of that request.

Key Concepts:
FHIR Standard: Health Level Seven International (HL7®) Fast Healthcare Interoperability Resources (FHIR®).
Health Cloud Data Model: The new model leverages specific FHIR resources to represent clinical data, replacing older Salesforce-specific custom objects.
Supported Resources: The Health Cloud documentation specifically calls out support for Medication, MedicationRequest, and MedicationDispense as part of its FHIR-based data model for managing medication information.

Explanation:

The correct answers are B, D, and E. These objects are fundamental components of the standard Care Management data model in Salesforce Health Cloud.
B. CarePlan Template Task: This object is used to define the specific, actionable steps within a Care Plan Template. It's the building block for creating standardized tasks that can be reused across multiple patient care plans, ensuring consistency and efficiency.
D. CareProgramGoal: This object represents a goal that is part of a broader Care Program. Care Programs are a key feature for managing a population of patients or members with similar needs (e.g., a wellness program for a specific chronic condition), and this object tracks the outcomes for those programs.
E. CarePlanGoal: This object is a core component of the individual Care Plan for a patient. It represents a specific, measurable goal for a patient to achieve, such as "Reduce A1C level to below 7%." This object is a direct reflection of a patient's personalized care plan.

The other options are incorrect:
A. CareSpeciality: This is an object used to define a healthcare practitioner's specialty, not a part of the Care Management data model itself. It is related to provider and facility management.
C. TimelineViewConfiguration: This is a custom metadata type used to configure the appearance and content of the Timeline component on a patient's record page. It's an administrative configuration object, not a transactional data object within the Care Management model.

Explanation:

In Salesforce Health Cloud, to display device information on a patient card, you need to follow the data model designed for connected devices or medical devices. This typically includes:

Asset: Represents the actual physical device (e.g., glucose monitor, heart rate tracker).
Care Registered Device: A Health Cloud object used to link a device (Asset) with a Patient (Person Account).
This association allows the device data to be shown on the Patient Card, especially in the Health Timeline or Patient 360 view.

By creating:
An Asset record for the device, and
A Care Registered Device that links the Asset to the Patient (Account),
...the Health Cloud system can surface this device information automatically in the patient card.

❌ Why the other options are incorrect:
A. EHR_Patient – Not the standard object for showing device info; formula fields on this object won't link to device records.
B. EHR_DeviceRequest – This object relates more to ordering devices, not tracking or displaying registered devices on the patient card.
C. FilterCondition_c – This is more likely a metadata/config object for filtering views, not actual device or patient data.
E. EHR_MedicalDevices – Not a standard object used in the Health Cloud Care Registered Device framework.

Explanation:

A. Engagement Layer
Health Cloud is designed as an engagement layer on top of Salesforce’s core CRM capabilities.
It enables patient/member-centric workflows, care coordination, and provider engagement — not just data storage.
It connects clinical, social, and behavioral data to deliver personalized experiences across channels.
C. Managed Package + Core Services
Health Cloud is delivered as a managed package that installs custom objects, Lightning components, and metadata.
It also leverages Salesforce core services like Person Accounts, OmniStudio, and Flow.
This hybrid architecture allows for deep customization while maintaining platform consistency.

❌ Why the Other Options Are Incorrect:
B. AppExchange core package and third party service
Health Cloud is a Salesforce product, not a third-party service. While it’s installable like a package, it’s not sourced from AppExchange as a third-party offering.
D. Core services exposed by permission license
While licenses control access, this doesn’t define what Health Cloud is. It’s more than just exposed services — it’s a full solution layer.
E. A new type of Electronic Health Record (EHR)
Health Cloud is not an EHR. It integrates with EHRs (like Epic or Cerner) but focuses on CRM and engagement, not clinical documentation or billing.

🔗References:
Salesforce Health Cloud Overview
Health Cloud Implementation Guide
Health Cloud Data Model

Explanation:

Migrating from the Individual Model to Person Accounts in Salesforce Health Cloud requires careful planning to align data with Health Cloud’s data model, which relies heavily on Person Accounts for managing patient or member records. Below is an analysis of each option based on Salesforce best practices and Health Cloud requirements:

A. Configure your person account record type in the individual Record type Migration
Correct: Configuring the Person Account record type is a critical step in the migration process. Health Cloud uses Person Accounts to represent patients or members, and specific record types (e.g., Patient or Member) are often set up to differentiate these accounts from business accounts. During migration, the Data Architect must map data from the Individual Model (typically stored in Contact or custom objects) to the appropriate Person Account record type. This involves defining the record type in the migration process to ensure data is correctly assigned to the Person Account structure.

B. Enable ‘Individual to Person Account Migration’ in custom setting
Incorrect: There is no standard custom setting in Salesforce or Health Cloud named “Individual to Person Account Migration.” While custom settings can be used in Salesforce for configuration, no such specific setting exists for this migration process. The migration typically involves enabling Person Accounts and using tools like Data Loader or ETL processes to map and transform data, not toggling a custom setting.

C. Ensure Person Accounts is enabled on the org.
Correct: Enabling Person Accounts is a prerequisite for migrating to the Person Account model in Health Cloud. Person Accounts must be activated in the Salesforce org, which historically required logging a support case with Salesforce, though since the Summer ’22 release, this can be done directly in Setup in some cases. Without Person Accounts enabled, the migration cannot proceed, as Health Cloud relies on Person Accounts to store patient data as a combined Account and Contact record.

D. Log a case with Salesforce to perform the conversion from the Individual Model to Person Accounts.
Incorrect: While logging a case with Salesforce was historically required to enable Person Accounts, this step is not about performing the actual data migration from the Individual Model to Person Accounts. The migration itself is a data transformation process handled by the organization’s Data Architect using tools like Data Loader, ETL tools, or third-party solutions. Salesforce Support does not perform the data migration; they only enable the Person Account feature if needed.

E. Use a CSV field to map PersonRecordTypeId to the Person Account Recordtype
Correct: During data migration, a CSV file is commonly used to map data from the Individual Model (e.g., Contacts or custom objects) to Person Accounts. A key part of this process is mapping the RecordTypeId field to the appropriate Person Account record type (e.g., Patient or Member). This ensures that migrated records are assigned the correct record type in the Person Account structure, aligning with Health Cloud’s data model and enabling proper functionality like patient-specific layouts and processes.

Additional Notes:
The migration process involves several key steps beyond these options, including auditing existing data, cleansing duplicates, mapping relationships (e.g., Opportunities or Cases), and testing in a sandbox environment to avoid data loss or corruption. Tools like Salesforce Data Loader or ETL platforms (e.g., MuleSoft, Jitterbit) are often used to handle the data transformation. Person Accounts, once enabled, cannot be disabled, so thorough testing in a sandbox is critical. The Data Architect should also ensure that sharing settings are compatible (e.g., private sharing model or Contacts set to “Controlled by Parent”) and that storage limits are considered, as Person Accounts consume storage for both Account and Contact objects.

References:
Salesforce documentation on enabling Person Accounts and migration considerations.
Salesforce Health Cloud documentation on data model and Person Account usage.
Salesforce Data Migration Best Practices for mapping and transforming data.

Explanation:

Configuring Health Cloud is a process that involves installing the correct package and enabling specific Salesforce features that its data model and functionality depend on.

Why B is Correct:
Health Cloud is delivered and installed as a Managed Package (often referred to by its namespace HealthCloud). Unmanaged packages are for custom development and are not used for deploying core Salesforce products like Health Cloud.

Why C is Correct:
Chatter must be enabled because Health Cloud uses Feed Tracking for its core collaborative features, such as the Care Team and the updates that appear on the Patient Timeline. Without Chatter enabled, these key social and collaborative aspects of Health Cloud will not function correctly.

Why E is Correct:
This is a critical and mandatory step. Health Cloud uses the Person Account model to represent Patients. Person Accounts are a hybrid of Account and Contact records. To allow a single Patient (a Contact under the hood of a Person Account) to be associated with multiple Provider or Facility Accounts (e.g., a primary care doctor, a specialist, a hospital), you must enable the Salesforce feature "Contacts to Multiple Accounts". This is a fundamental org setting that underpins the entire provider relationship model in Health Cloud.

Why A is Incorrect:
Health Cloud is not an unmanaged package. Installing an unmanaged package would not provide the upgradeable, supported solution that Salesforce offers. The correct method is to install the managed package.

Why D is Incorrect:
While configuring the console view (like the Service Console) is a common and recommended practice for implementing a call center or agent workspace in Health Cloud, it is not one of the three universal, required steps to configure the foundation of Health Cloud itself. It is a subsequent, application-specific configuration task.

References:
Managed Package Installation: The starting point for enabling Health Cloud functionality.
Prerequisite Org Settings: Key dependencies that must be configured before or immediately after installing Health Cloud include:
Enabling Chatter.
Enabling Contacts to Multiple Accounts (in Setup -> Account Settings).
Enabling Person Accounts (this is often done automatically during package installation but is a key dependency).

Explanation:

A. Custom Label
This is a standard Salesforce metadata component.
You can customize labels to support multi-language apps, UI tweaks, or branding.
Health Cloud leverages these for dynamic text across components.

C. Patient Card
The Patient Card is a customizable Lightning component.
You can modify what data appears (e.g., allergies, conditions, care plans) and how it’s displayed.
Often tailored to different user roles like care coordinators or providers.

D. Timeline
The Timeline component shows clinical and non-clinical events.
It’s configurable via metadata and can be extended to include custom events (e.g., appointments, outreach).
You can also control icons, colors, and filters.

❌ Incorrect Options:
B. HER data
Likely a typo — should be EHR data. EHR data is not directly customizable within Health Cloud. It’s typically integrated via HL7/FHIR APIs or MuleSoft, but the data structure is governed by the external EHR system.
E. Life Events
Life Events are standard objects in Health Cloud, but they are not customizable in the same way as UI components. You can add records, but the structure and behavior are limited.

🔗 Reference:
Health Cloud Developer Guide – Custom Components
Health Cloud Implementation Guide – Timeline & Patient Card

Explanation:

To provide clinicians with an overview of a patient's life, such as starting a new job, the birth of a baby, or a divorce, the administrator should configure Life Events in Health Cloud. This component is specifically designed to capture and display significant life milestones and social determinants of health that can impact a patient's well-being and influence their care plan.

The other options are incorrect:
A. Life Goals and D. Milestones are similar concepts but in Health Cloud, the specific component for this purpose is called "Life Events."
C. Household Map is a component that visualizes the relationships between a patient and their family members or other related individuals. It does not display a chronological timeline of life events.
E. Life Map is not a standard Health Cloud component.

Explanation:

Salesforce Health Cloud includes a Clinical Data Model that allows storing and managing structured healthcare data such as:

Conditions, Procedures, Allergies, Medications, Encounters, and Immunizations
Standardized alignment with HL7 FHIR® resources

To use these objects in a new Health Cloud implementation, the administrator must enable the “Clinical Data Model” org preference.
This preference unlocks the Clinical Data Model objects in the org so they can be used for EHR integration, care coordination, and analytics.

❌ Eliminations
A. FHIR-Aligned Data Model org preference
❌ Not the correct label. While the Clinical Data Model is FHIR-aligned, the actual preference you enable is called Clinical Data Model org preference.
B. Clinical R4 Model org preference
❌ Salesforce doesn’t call it “Clinical R4 Model.” R4 is a version of FHIR, but this is not the Salesforce org preference name.
D. FHIR-Aligned EHR Data Model org preference
❌ Incorrect wording. Salesforce documentation refers specifically to Clinical Data Model, not “FHIR-Aligned EHR Data Model.”

📌 Reference
Salesforce Docs: Enable the Clinical Data Model in Health Cloud
Salesforce Implementation Guide – Clinical Data Model

Explanation:

The Advanced Patient Card in Salesforce Health Cloud is a configurable Lightning component used to display key patient information, such as clinical alerts, on a patient’s record page. To modify the out-of-the-box Advanced Patient Card to display specific fields (Category, SubjectID, and Date) for active Clinical Alerts, a developer must customize the card’s configuration and data retrieval process. Below is an analysis of each option based on Salesforce Health Cloud’s architecture and customization capabilities:

A. Create and activate a new child card.
Correct: The Advanced Patient Card in Health Cloud uses a parent-child card structure, where the parent card defines the overall layout, and child cards display specific data sets, such as Clinical Alerts. To show the Category, SubjectID, and Date for active Clinical Alerts, the developer needs to create a new child card (e.g., via the Health Cloud Admin console or Lightning App Builder) and configure it to display these fields. Activating the child card ensures it is visible within the parent card’s display.

B. Clone the parent card.
Incorrect: Cloning the parent card is not necessary for this requirement. The parent card in the Advanced Patient Card framework serves as a container for multiple child cards, and modifying the display of Clinical Alerts involves creating or updating a child card, not duplicating the entire parent card. Cloning the parent card would create an entirely new card structure, which is unnecessary and inefficient for this use case.

C. Define session variables to control visibility of clinical data.
Incorrect: Session variables in Salesforce are typically used in OmniScript or FlexCards to manage temporary data or control flow within a session. While session variables might be used in advanced customizations, they are not a standard or necessary step for modifying the Advanced Patient Card to display specific fields for Clinical Alerts. The requirement focuses on data display, which is handled through child card configuration and data retrieval, not session variables.

D. Create a DataRaptor to extract necessary data.
Correct: A DataRaptor is a Salesforce tool (part of OmniStudio, often used with Health Cloud) that extracts, transforms, and maps data from Salesforce objects to display in components like the Advanced Patient Card. To display the Category, SubjectID, and Date for active Clinical Alerts, the developer needs to create a DataRaptor Extract to query the relevant Clinical Alert records (e.g., from the HealthCloudGA__ClinicalAlert__c object) with a filter for active alerts (e.g., Status__c = 'Active'). The DataRaptor maps these fields to the child card for display.

E. Change the child card state to show active.
Correct: To ensure only active Clinical Alerts are displayed, the developer must configure the child card’s state or filter conditions to show only records where the Clinical Alert status is active. This can be done by setting a filter in the child card configuration or within the DataRaptor query to include only active records (e.g., Status__c = 'Active'). This ensures the card displays only relevant, active alerts with the specified fields.

Additional Notes:
Steps in Detail:
Create a Child Card: In the Health Cloud Admin console or Lightning App Builder, create a new child card under the Advanced Patient Card. Configure it to display the Category, SubjectID, and Date fields from the Clinical Alert object.
Create a DataRaptor: Use OmniStudio to create a DataRaptor Extract that queries the HealthCloudGA__ClinicalAlert__c object, filtering for active alerts and mapping the required fields (Category, SubjectID, Date).
Set Child Card Filter: Configure the child card to use the DataRaptor and apply a filter to show only active Clinical Alerts, either through the card’s configuration or the DataRaptor’s query logic.
Testing: The developer should test the configuration in a sandbox to ensure the child card displays only active Clinical Alerts with the correct fields and that the parent card integrates the new child card seamlessly.
Permissions: Ensure users have access to the HealthCloudGA__ClinicalAlert__c object and the specific fields via their profile or permission sets.

References:
Salesforce Health Cloud documentation on configuring the Advanced Patient Card and child card setups.
Salesforce OmniStudio documentation on DataRaptors for data extraction and mapping.
Salesforce Health Cloud object reference for Clinical Alerts (HealthCloudGA__ClinicalAlert__c).