Free Health-Cloud-Accredited-Professional Practice Test Questions (2026)

Explanation:

To display a custom field on the Patient Card in Salesforce Health Cloud, especially one that categorizes High Risk Conditions, you need to follow two key steps:

Create a custom formula field on the HealthCondition object that identifies or flags high-risk conditions. This field could use logic based on condition severity, status, or other clinical indicators. For example, you might use a formula like IF(Severity__c = "High", "High Risk", "Standard").
Add this formula field to the Patient Card by creating a Patient Card Configuration record. This configuration allows you to specify the object (HealthCondition), the field to display, and how it should appear on the card. This step ensures the field is visible to care coordinators and other users in the console.

You do not need to:
Create a formula on the Account object unless you're aggregating data across conditions, which isn’t required here.
Use an Apex Trigger, since formula fields and Patient Card Configuration provide declarative tools to meet the requirement without custom code.

📚 References:
Salesforce Help: Add a Field to the Patient Card Component
Trailhead: Adapt the Patient Card in the Console
Salesforce Help: Customize Medical Data on the Patient Card

Explanation:

A. Health Cloud helps HLS organization achieve HIPAA Compliance
Correct: Salesforce Health Cloud provides features and configurations designed to help healthcare and life sciences (HLS) organizations meet HIPAA (Health Insurance Portability and Accountability Act) compliance requirements. This includes robust security measures like data encryption, access controls, and audit trails to protect protected health information (PHI). While Salesforce provides tools to support HIPAA compliance, organizations must configure and manage their instance appropriately to ensure full compliance.

B. Health Cloud is HIPAA certified
Incorrect: Salesforce Health Cloud is not "HIPAA certified" as there is no formal certification for HIPAA compliance. Instead, Salesforce offers a Business Associate Agreement (BAA) and implements security controls to help customers achieve HIPAA compliance. The responsibility for compliance lies with the organization, not a certification of the platform itself.

C. Health Cloud is HITRUST certified
Correct: Salesforce Health Cloud is built on the Salesforce platform, which has achieved HITRUST CSF (Common Security Framework) certification. This certification demonstrates that the platform meets rigorous security and risk management standards, particularly relevant for healthcare organizations handling sensitive data.

D. Health Cloud is GDPR certified
Incorrect: There is no formal "GDPR certification" for software platforms like Health Cloud. While Health Cloud includes features to support General Data Protection Regulation (GDPR) compliance (e.g., data protection and consent management tools), GDPR compliance is the responsibility of the organization using the platform, and Salesforce provides tools to help meet those requirements rather than being certified itself.

E. Health Cloud is HL-7 Compliant
Correct: Health Cloud supports HL7 (Health Level Seven) standards, particularly through its integration capabilities with HL7-compliant systems like FHIR (Fast Healthcare Interoperability Resources). This allows Health Cloud to facilitate interoperability and data exchange in a standardized format commonly used in healthcare for clinical and administrative data.

References:
Salesforce documentation on Health Cloud security and compliance features, including support for HIPAA, HITRUST, and HL7 standards.
Salesforce Trust and Compliance documentation for HITRUST certification and GDPR support.

Explanation:

Why A is Correct:
This is a fundamental and unique consideration when working with Health Cloud. Health Cloud introduces a layer of business logic and specific processes through its Empower framework. To ensure this business logic is executed correctly and data integrity is maintained, Salesforce provides and recommends the use of Business APIs (also known as Connected APIs).
Purpose of Business APIs: These APIs are designed to understand the complex relationships and processes of Health Cloud data. For example, creating a CarePlan involves not just the plan itself but also its associated goals and tasks. Using a standard object-level API (like creating a CarePlan record) would miss this crucial context and likely result in an incomplete or invalid record.
Data Integrity: Using the standard REST or SOAP APIs (object-level) to directly create or update records in Health Cloud objects can bypass critical validation rules, automation (flows, processes), and other business logic built into the platform. This can lead to data corruption, errors, and a broken user experience.
Recommendation: Therefore, for any significant data operation, especially in a migration or integration scenario, the architect should use the purpose-built Business APIs to ensure all underlying Health Cloud logic is properly executed.

Why B is Incorrect:
This is the opposite of the recommended approach. While object-level APIs can technically be used, it is considered a bad practice for Health Cloud objects because it risks breaking the complex data model and business processes. Business APIs are absolutely used for record creation (e.g., the CarePlanDefinition API is used to create a Care Plan).

Why C is Incorrect:
This statement is false and dangerous. Significant unique considerations apply. Treating Health Cloud objects like standard or custom objects from an API perspective ignores the sophisticated layer of business logic that defines Health Cloud's functionality and will almost certainly lead to integration failures or data quality issues.

Why D is Incorrect:
While technically possible, using a combination is not the advised best practice. The guiding principle for Health Cloud integrations is to prefer Business APIs to ensure all necessary related records are created and all business logic is respected. Using object-level APIs should be a rare exception, not a standard part of the integration strategy.

Key Concepts/References:
Health Cloud Empower Framework: The underlying technology that provides the pre-built healthcare data model and logic.
Business APIs (Connected APIs): The suite of APIs specifically designed for Health Cloud to interact with objects like CarePlan, CareProgram, and CareProgramEnrollee while maintaining data integrity.
Data Model Complexity: Health Cloud objects have complex relationships (e.g., a Care Plan has associated Goals and Tasks). Business APIs are built to handle these relationships in a single API call.
Salesforce Documentation: The Health Cloud Implementation Guide strongly emphasizes the use of Connected APIs over standard Salesforce APIs for interacting with its specific objects.

Explanation:

✅ B. Create flow for the business process
Flows are essential in automating steps like:
Scheduling visits
Updating visit statuses
Notifying care teams or patients
They are especially useful for customizing the visit experience and integrating various actions in the process.

✅ D. Create an action plan template, add flow, and publish the template
Action Plans are used to orchestrate repeatable processes such as patient visits.
An Action Plan Template can:
Include standard tasks or flows (like pre-visit checklists)
Be published and reused for consistency across the care team
By adding a Flow to the template, you automate key steps during or after visit creation.

Why the other options are incorrect:
❌ A. Create a Task and add task to an action plan template
While technically valid in some contexts, this is not specific enough for automating a full patient visit process.
It only addresses a single task, not the broader flow or automation needed.
❌ C. Create a task and add the task to visit creation
Similar to A, this addresses just task creation, not the structured and repeatable visit management process expected in Health Cloud.

Explanation:

In Salesforce Health Cloud, when bringing in a Business Identifier (e.g., a patient ID or medical record number) from an external system like an Electronic Health Record (EHR), the most suitable entity to hold this information is the Identifier object. The Identifier object is specifically designed to store unique identifiers from external systems, ensuring that patient records in Health Cloud can be linked to corresponding records in external systems like EHRs for interoperability and data matching.

Here’s why the other options are less appropriate:
A. Sourcesystem Identifier:
There is no standard object named “Sourcesystem Identifier” in Health Cloud. This appears to be a distractor or misnomer, as the correct object is simply Identifier.
B. Contacts:
While Contacts (or Person Accounts in Health Cloud) represent patients, they are not designed to store external system identifiers directly. Instead, the Identifier object is linked to a Contact or Person Account to store external IDs, maintaining a clean separation of patient data and external identifiers.
C. Account:
The Account object (or Person Account for patients) represents the patient entity, but it is not the primary place to store external identifiers. The Identifier object is used to associate external system IDs (e.g., EHR patient IDs) with the Account or Person Account record.

How the Identifier Object Works:
The Identifier object captures details like the external system’s ID (e.g., EHR patient ID), the source system name, and the type of identifier.
It is linked to a Person Account or Contact via a lookup relationship, allowing Health Cloud to map external IDs to the patient record.
This supports interoperability (e.g., with FHIR or HL7 integrations) and ensures accurate record matching across systems.

Reference:
Salesforce Health Cloud documentation specifies the Identifier object as part of the Health Cloud Data Model for storing external system identifiers, such as patient IDs from EHRs, to enable data integration and matching (see help.salesforce.com, Health Cloud Data Model: Identifier Object).
The Health Cloud Implementation Guide emphasizes using the Identifier object for interoperability with external systems like EHRs to track unique identifiers (Health Cloud Developer Guide: Data Interoperability).

Explanation:

In Salesforce Health Cloud, a Care Request is a specific type of Case record. The Case object is a standard Salesforce object that can have multiple Record Types. This feature allows an organization to define different business processes, page layouts, and picklist values for different types of cases.

When a user creates a new Care Request in Health Cloud, they are essentially creating a new Case record. By selecting a specific Case Record Type, they are classifying that care request. For example, a healthcare provider might have different record types for:

Referral Request: A case for a patient needing to see a specialist.
Prior Authorization: A case to get approval from an insurance company for a procedure.
Appointment Request: A case for scheduling an appointment.

Each of these record types would represent a unique "care request type," and a single care request record can only be associated with one of these types at a time. This ensures data consistency and allows for different processes to be followed based on the nature of the request.

Why Other Options Are Incorrect
A. Any case record type can be chosen when creating care request.
This is not entirely true. While Care Request is a type of Case, the available Case Record Types are determined by the Health Cloud configuration and the specific user's profile. Only those record types that have been configured for the Care Request process will be available.
B. A care request type cannot be chosen when creating a new care request.
This is incorrect. The ability to choose a record type is fundamental to classifying the care request and is a key part of the setup process.
D. Multiple care request types can be chosen for a single care request.
This is incorrect. A single Case record (and therefore a single Care Request) can only have one Record Type assigned to it. This is a foundational principle of Salesforce Record Types.

Explanation

✅ A. FHIR Question Bank
Health Cloud supports FHIR-based question banks (like LOINC or custom questionnaires) for standardized clinical assessments.
Example: Reusing depression screening questions (PHQ-9) across assessments.

✅ B. Using Previously Submitted Responses
Discovery Framework can pre-populate answers from past assessments (e.g., patient history, allergies) to reduce redundant data entry.
Example: Auto-filling demographic data from prior intake forms.

✅ C. Digital Signature Capture
Native e-signature support for consent forms or assessment validation (via Salesforce Surveys or embedded tools like DocuSign).
Example: Patients signing telehealth consent before an assessment.

Why Not the Others?
❌ D. Adding a QR Code
While technically possible with custom code, QR codes aren’t an out-of-the-box feature of Discovery Framework.

❌ E. SMS Assessment Completion
SMS triggers require custom integrations (e.g., Twilio) or Marketing Cloud. Not native to Health Cloud assessments.

Explanation:

A. Migrate all existing leads to candidate leads.
Incorrect: While Health Cloud uses the concept of "candidate leads" for patient acquisition, migrating all existing leads to candidate leads is not a recommended prerequisite for transitioning from Service Cloud to Health Cloud. Leads in Service Cloud may not all represent patients, and this step would depend on the organization's specific use case rather than being a general requirement.

B. Migrate patient data to person accounts.
Correct: Health Cloud typically uses person accounts to represent patients, as they combine Account and Contact functionality to manage individual patient records effectively. Before migrating from Service Cloud to Health Cloud, it’s recommended to migrate relevant customer or patient data to person accounts to align with Health Cloud’s data model, ensuring seamless use of features like patient timelines, care plans, and health records. This step is critical for data consistency and functionality in Health Cloud.

C. Uninstall any Sales Cloud related packages.
Incorrect: Uninstalling Sales Cloud-related packages is not a necessary or recommended step before migrating to Health Cloud. Health Cloud builds on Salesforce platform capabilities, and many Sales Cloud features (e.g., standard objects like Accounts or Cases) may still be relevant. Instead, the focus should be on assessing compatibility and configuring Health Cloud-specific features.

D. Log a Salesforce support case.
Incorrect: While logging a Salesforce support case may be useful for specific issues during migration, it is not a recommended prerequisite step for migrating from Service Cloud to Health Cloud. The migration process primarily involves planning, data mapping, and configuration, which can be managed through standard implementation practices and documentation, with support contacted only if needed.

References:
Salesforce Health Cloud Implementation Guide, which emphasizes the importance of configuring person accounts for patient data management before enabling Health Cloud features.

Explanation:

The Individual Data Model is Salesforce's modern, scalable, and recommended architecture for representing people across all industries, and it is particularly well-suited for the complex relationships in healthcare.

Here’s why it is the recommended approach for representing both Members (payer term) and Patients (provider term):

Single Source of Truth:
The Individual object stores core biographical data about a person (e.g., Name, Date of Birth, Gender) exactly once. This record can then be linked to multiple Accounts and Contacts to represent the different roles that person plays.
Solves the "Member vs. Patient" Dilemma:
A person can be a Member of a health plan (an Account-Contact relationship under a Payer Account) and also a Patient at a hospital (an Account-Contact relationship under a Provider Account). The Individual object sits above these relationships, providing a unified view without duplicating the person's core data.
Foundation for Health Cloud:
Health Cloud's Clinical Data Model (CDM) is built on the Individual object. Features like the Patient Timeline and unified patient views rely on this architecture. For payers using Communications Cloud or Member Engagement, the Individual object is also central.
Avoids the Limitations of Person Accounts:
Person Accounts (Option A) are a legacy architecture that can create significant complexity in a B2B2C model like healthcare, where a person needs relationships with multiple business accounts (e.g., a Payer and a Provider). The Individual model is more flexible and scalable.

Why the other options are incorrect:
A. Leveraging Person Accounts is the recommended approach...:
This is not the recommended approach. Person Accounts are generally discouraged for new implementations in healthcare due to their inflexibility, especially in hybrid models where a person interacts with multiple organizations (e.g., as a member of an insurance plan and a patient of a hospital).
C. Salesforce recommends using Member Accounts to represent members...:
"Member Account" is not a standard Salesforce object type. Members are represented as Contacts (or Individuals) related to their health plan Account.
D. Leveraging Candidate Accounts are the recommended approach...:
"Candidate Account" is not a standard Salesforce object or recommended data model. This term is unrelated to representing members or patients.

Reference:
Salesforce Architecture: Data Model Guide: Individuals
Salesforce Help: How Health Cloud Works with the Individual Object

This resource explicitly states: "We recommend the individual object... Using the individual object future-proofs your organization against the deprecation of person accounts and lets you use the latest features from Salesforce."

Explanation:

Why C is Correct:
This is the most flexible and accurate statement. Health Cloud provides a pre-built, recommended Provider data model (using the Account and Related_Provider__c objects) to represent healthcare providers and their relationships. However, it is not mandatory.
Option 1: Use Health Cloud's Provider Model: If the administrator chooses to adopt Health Cloud's standard Provider data model, they can then use the out-of-the-box Health Cloud Provider Search component or they can build and use a custom Lightning component for searching providers.
Option 2: Use a Custom Data Model: The administrator is also free to keep their existing custom data model from Service Cloud (e.g., a custom Provider__c object) and continue using their existing custom search component. Migration to the Health Cloud data model is optional.
The key point is that the choice of data model and the choice of search component are decoupled. You are not forced to use the standard search component if you use the standard data model, and vice-versa.

Why A is Incorrect:
The Health Cloud Provider data model is not required. It is a best practice and highly recommended for its pre-built relationships and functionality, but an organization can choose to migrate to Health Cloud while maintaining a previously built custom provider model.

Why B is Incorrect:
This is false. While the standard Health Cloud Provider Search component is designed to work with the standard Provider data model, Salesforce would never prevent you from creating a custom search component. You can absolutely build a custom component to search the standard Provider data model, often to meet specific UI or functional requirements that the standard component doesn't cover.

Why D is Incorrect:
The standard Health Cloud Provider Search component is hardcoded to work with the specific objects and fields of the standard Health Cloud Provider data model (primarily the Account object with a specific record type and the Related_Provider__c object). It will not work correctly with a custom provider object (e.g., Custom_Provider__c) without significant and unsupported modification. If using a custom data model, you must use a custom search component.

References:
Health Cloud Data Model: The standard Provider model is based on the Account object (with a "Provider" record type) and the Related_Provider__c junction object to model hierarchical relationships.
Flexibility: Health Cloud provides recommended, pre-built models but does not force you to use them. You can leverage existing custom objects.
Components: Lightning components are built to query specific objects and fields. The standard component is built for the standard model. A custom component can be built for either a custom or the standard model.