Health-Cloud-Accredited-Professional Practice Test Questions

Explanation:

The Patient Info component in Salesforce Health Cloud displays key demographic and care-related details to give care teams a quick view of the patient's identity and relationships. This component is usually shown at the top of patient records.

✅ A.
Displays the name and contact details of the care coordinator assigned to the patient.
Essential for care team collaboration.

✅ C.
Standard demographic field.
Shown prominently on the Patient Info component.

✅ D.
These fields help users quickly identify the patient's age group and lifecycle stage.

❌ B. List of Patient/Member Conditions

While conditions (such as diagnoses) are part of the clinical record, they are typically shown in a separate component like Clinical Timeline or Care Plan, not in the Patient Info component itself.

Explanation:

Health Cloud in Lightning Experience offers two primary app options:

1. Health Cloud – Console: Optimized for care teams with a multi-tab interface for efficient patient management (e.g., split views for patient records, care plans, and tasks).
2. Health Cloud – Workspace: A more flexible layout for individual workflows (less rigid than the console).

Why Not the Other Options?

❌ A. Health Cloud – Worklist: Not a standard app name; worklists are features within the Console or Workspace apps.
❌ B. Health Cloud – Individual: Doesn’t exist as a standalone app.
❌ C. Health Cloud – Personal: Incorrect; no such app is predefined.

Explanation:

Householding Map is the visual relationship tool in Health Cloud that:

Displays all connections between a patient, their care team, providers, and organizations.
Shows cross-care-plan relationships (e.g., family members, caregivers, affiliated clinics).
Uses a network diagram format for clarity.

Why Not the Other Options?

❌ A. Timeline View: Shows chronological events (e.g., appointments, diagnoses) but not relationships.
❌ B. Care Team: Lists members but lacks visual mapping of broader relationships.
❌ C. Lightning Empower Components: Custom UI tools, not designed for relationship mapping.
❌ E. Patient Card: Summarizes patient details (e.g., demographics) but not relationships.

Explanation:

Program Management in Salesforce Health Cloud (especially for Life Sciences companies) enables organizations to track and manage structured Care Programs. These programs can involve services, products, clinical monitoring, and engagement plans for patients.

✅ C. Clinical Indicators
Program Management tracks clinical indicators (e.g., blood pressure, A1C levels) that need to be monitored throughout the program.
These are essential for measuring patient outcomes and adherence.

✅ D. Products Associated with Care Program
Many Care Programs are tied to specific therapies or medical products (e.g., specialty drugs).
Salesforce allows you to track which products are involved with or dispensed as part of the program.

✅ E. Engagement Plans
You can track the plans or tasks that patients (enrollees) are participating in — such as education sessions, follow-ups, or medication schedules.

❌ Incorrect Options:

A. Marketing Campaigns
Care Programs focus on clinical care and patient support, not marketing activity.
Marketing campaigns would be tracked in Marketing Cloud or Pardot, not Program Management.

B. Budget & Expenses
While financial tracking may happen in connected systems (like ERP), Program Management in Health Cloud is not primarily used to track budgets and expenses.

Explanation:

In Salesforce Health Cloud, specifically when working with insurance data models, PurchaserPlan and MemberPlan are two standard objects used during member onboarding and benefit management.

✅ PurchaserPlan
Represents the plan offering purchased by an organization or employer (e.g., an insurance policy package).
Acts as a template or blueprint for individual member-level plans.

✅ MemberPlan
Represents the actual plan enrollment for an individual insurance member (the patient/insured person).
When onboarding a new member, a MemberPlan is created based on the PurchaserPlan.

❌ Incorrect Options:

A. This is misleading. While a PurchaserPlan can be linked to many MemberPlans, it’s not a many-to-many relationship.
B. This is not accurate. The relationship is a lookup, not master-detail.
C. False. There is a relationship — MemberPlans reference PurchaserPlans to inherit plan design details.

Explanation:

When creating Health Care Providers for a Care Program in Salesforce Health Cloud, there are two required steps to ensure the provider is correctly associated and functional within the program:

✅ D.
You begin by navigating to the Care Program Providers object through the App Launcher.
This is where you initiate the creation of providers who will participate in a specific Care Program.

✅ E.
You must link a Care Program Health Care Provider record to a Care Program Provider record.
This step associates the provider with a specific Care Program and ensures they appear in the program’s workflows.

❌ Incorrect Options:

A. Adding an NPI (National Provider Identifier) is good practice, but it's not a required step to create the provider in the context of a care program.
B. Associating a facility might be part of broader care team setup, but it's not a required step for setting up a care program provider.
C.The UPIN (Unique Physician Identifier Number) is deprecated in the U.S. and not a required field.

Explanation:

Health Cloud’s HcFeatureDriver Custom Metadata Type
This is the primary configuration point for enabling/disabling core Health Cloud features, including CTI (Computer Telephony Integration) settings.
To ensure phone numbers trigger Screen Pop (matching incoming calls to Contact records), the admin must:
Update HcFeatureDriver to enable CTI integration.
Configure call routing rules (e.g., matching caller ID to Contact phone fields).

Why Not the Other Options?

❌ A. Flow Session Setting – Not related to CTI; governs Flow runtime behavior.
❌ B. Feature Flag Setting – Generic feature toggles, not specific to Health Cloud CTI.
❌ C. Job Flow Setting – Unrelated to Screen Pop functionality.

Explanation:

Codesets in Health Cloud
The Codesets object is specifically designed to store mappings between different medical coding systems (e.g., ICD-10 → HCC, SNOMED → LOINC).
Enables interoperability and standardized reporting across systems.

Why Not the Other Options?

❌ A. Identifier – Tracks unique IDs (e.g., patient MRNs), not code mappings.
❌ C. ContactPoint – Stores communication details (phone/email), unrelated to coding.
❌ D. Codeset Bundle – A collection of codesets, not the mapping mechanism itself.

Explanation:

To access and use Salesforce Health Cloud features and functionality, users must be assigned the proper Permission Set Licenses (PSLs) and permission sets. The key licenses are:
✅ B.
This is the core Permission Set License (PSL) that grants access to standard Health Cloud features like clinical data models, care plans, timeline views, and more.
Users must have this license assigned before they can be assigned any Health Cloud-related permission sets.

✅ D.
This refers to the underlying license object required to assign permission sets for Health Cloud (such as Health Cloud Admin, Care Coordinator, etc.).
Without this PSL, you cannot assign the permission sets that unlock Health Cloud features.

❌ Incorrect Options:

A. Not a standard PSL. Health Cloud features can be extended to Experience Cloud (Community) users, but this is done using the main Health Cloud license in conjunction with community licenses — it's not a standalone PSL.
C.This is not a recognized Salesforce license. Likely a distractor.
E. Not an official name of any license or permission set in Salesforce Health Cloud.

Explanation:

Salesforce Health Cloud does not natively parse or consume HL7 v2 messages out of the box. HL7 v2 is a text-based, delimited format that requires transformation before Salesforce can use it effectively.

✅ D. Use an HL7 broker/engine
This is the industry-standard approach.
HL7 brokers or integration engines like Mirth Connect, Rhapsody, or InterSystems Ensemble are used to:
1. Parse HL7 v2 messages
2. Transform them into JSON or FHIR format
3. Send them via APIs to Salesforce
Once in JSON or FHIR format, the data can be stored in custom objects or FHIR-enabled models in Health Cloud.

❌ Incorrect Options:

✖️ A. Incorrect — Salesforce does not natively understand HL7 v2 messages.
✖️ B. Incorrect — Salesforce Connect is used to reference external data (e.g., via OData), not to parse HL7 messages.
✖️ C. Incorrect — Technically possible but not recommended. HL7 parsing is complex and best handled by dedicated engines, not Apex.