#Salesforce Health Cloud15 diskutieren mit

Hi all, 

A quick update on this, as we have since found a better approach.

Salesforce now documents a Discovery Framework-specific option for this: Multi-Language Data Translation for Discovery Framework. This is enabled from Setup under Discovery Framework settings:

https://help.salesforce.com/s/articleView?id=ind.discovery_framework_turn_on_multi_language_data_translation.htm&type=5

The broader documentation is here:

https://help.salesforce.com/s/articleView?id=ind.discovery_framework_data_translation.htm&type=5

This appears to be a relatively new and/or recently documented area, and it was not obvious from the earlier OmniStudio multilingual documentation. Which is why we were originally moving toward a one-form-per-language design. 

After enabling and testing this, we validated that Discovery Framework can support multilingual assessments without the use of Custom Labels for Assessment Questions.

The key translation object is:

AssessmentQuestionVersionDataTranslation

Translations are linked to the Assessment Question Version by:

AssessmentQuestionVersionDataTranslation.ParentId = AssessmentQuestionVersion.Id

The translation child record uses Salesforce language codes, for example:

German = de 

French = fr 

We used API v67 during validation. 

For the Assessment / Summary API context, our testing showed that c__LanguageCode must use the full language name, for example:

c__LanguageCode = German 

 c__LanguageCode = Japanese

I have not found it clearly described in the Summary API documentation:

https://developer.salesforce.com/docs/atlas.en-us.industries_reference.meta/industries_reference/actions_obj_get_assessment_response_summary.htm

Great question, Sanjana — this distinction trips up a lot of people.

The short answer: Health Cloud is built for care delivery organizations (hospitals, clinics, payers). Life Science Cloud is built for manufacturers — pharma, biotech, and medtech companies. They share a foundation, but the patient journey looks completely different depending on which side you're on.

Why the same features exist in both but aren't the same

Benefits verification, care program enrollment, and financial assistance do exist in Health Cloud — but they're modeled for a care team coordinating a patient's overall health. In Life Science Cloud, those same concepts are redesigned for a manufacturer running a Patient Support Program (PSP) on behalf of a specific drug or therapy. The manufacturer isn't the patient's doctor — they're a company helping patients access and stay on their treatment.

What's unique to Life Science Cloud Patient Services

• Copay assistance and Patient Assistance Programs (PAPs) — manufacturer-funded programs (free drug, co-pay cards, foundation referrals) with their own enrollment and fulfillment workflows
• Prior authorization management scoped to a specific therapy — tracking PA status, appeals, and resubmissions for one drug
• Hub services coordination — the specialty pharmacy / hub model that exists in rare disease and specialty pharma doesn't exist in standard Health Cloud
• REMS program support — Risk Evaluation and Mitigation Strategies are a regulatory requirement unique to certain drugs; LSC has objects and workflows to manage patient enrollment in REMS programs
• Therapy-specific adherence programs — structured outreach tied to a medication, not general care management
• Intelligent Document Automation — processing enrollment forms, prescription forms, and prior auth documents at scale

The framing that makes it click

In Health Cloud, the Care Program is centered on the patient's health. In Life Science Cloud, the Care Program is centered on the therapy — it's a manufacturer-sponsored support structure that exists only for patients on that specific product.

Resources to dig into

• Trailhead: Life Sciences Cloud Basics module
• Salesforce Help: Patient Services in Life Sciences Cloud (search "Patient Services" in Salesforce Help filtered to Life Sciences Cloud)
• The Life Sciences Cloud data model documentation — looking at how Patient, Enrollment, Financial Assistance, and Prior Authorization objects relate is the fastest way to see what's different from Health Cloud equivalents

Hope that helps frame where to start!

Hi Khushi, 

Having worked on a few Health Cloud implementations, my advice is to start with the data model

first and understand the use case,  everything else builds on it. 

Key areas to focus on:

• Patients (Person Accounts / Patient 360)
• HCPs & Care Teams (Healthcare Providers -> Doctor , Nurse, Facilities -> Hospital, Clinics)
• Clinical Data (Encounters, Conditions, Medications, Medication Requests)
• Care Programs & Care Plans
• Caregivers & Care Team Members
• Adverse Events (especially if you're working in Life Sciences / Patient Services)

Best starting resources:

• Health Cloud Data Models – Trailhead
• Health Cloud Object Reference

For hands-on learning, try mapping out this patient journey end-to-end:

Patient → Caregiver → HCP → Clinical Encounter → Care Program → Adverse Event

This single exercise will clarify how this work and how all the objects connect better than any documentation did for me.

Happy to answer any specific questions if you get stuck. Feel free to reach out🙂

Hello @Jesus David Sosa Miranda

Please go through it--> 

Hi @RYAN ROY GALVEZ SANTOS

The LSC Mobile app is available on the Apple App Store — iPad only, no Android version exists:  

Thanks!