SfSkills Domains Docs GitHub

Home / admin / health-cloud-consent-management

health-cloud-consent-management

Use this skill when configuring Health Cloud patient consent management: setting up HIPAA authorization forms, consent templates, consent tracking per patient, and withdrawal handling. NOT for querying the AuthorizationFormConsent object hierarchy or its required field values — use data/consent-data-model-health. NOT for GDPR/CCPA marketing opt-out on ContactPointTypeConsent — use security/gdpr-data-privacy.

Open the skill folder on GitHub

Health Cloud Consent Management

Use this skill when configuring patient consent in Health Cloud: HIPAA authorization forms, form text per language, consent records per patient, and withdrawal. It covers the authorization form lifecycle: template creation, enrollment-linked capture, and status management. It does NOT cover marketing consent (ContactPointTypeConsent, ContactPointConsent), general Experience Cloud consent flows, or consent for non-clinical purposes.

Licence and feature gate: the authorization form objects are standard objects that are "available if Data Protection and Privacy is enabled" (Object Reference). Health Cloud adds IndustriesSettings.enableAuthorizationCustomSharingPCU for portal sharing of consent forms.

Before Starting

Questions to Ask Before Configuring

Ask these before creating a single form. Each one traces to a gotcha in references/gotchas.md.

QuestionWhy it mattersWhat a good answer addsWhat proper configuration adds over just doing it
"Who can turn Data Protection and Privacy off, and is that change controlled?"Turning enableConsentManagement off purges stored consent forms (gotcha 1)A named owner and a change-control rule for the settingConsent evidence that cannot vanish through a settings deploy
"Which languages must each form be shown in, and which is the fallback?"DefaultAuthFormTextId on the form is the fallback when no text matches (gotcha 2)A text record per language and a chosen defaultEvery patient sees a form, in their language where one exists
"How do we record a withdrawal, and how do we prove the earlier signature?"Status allows only Rejected, Seen, Signed (gotcha 3)A withdrawal design that keeps the signed record and historyAn audit trail that shows when consent was given and when it ended
"How is consent captured: in person, phone, web, email?"ConsentCapturedSourceType is a restricted picklist and ConsentCapturedSource is a required free-text field (gotcha 4)The source type per channel and what goes in the source textConsent records that load and report cleanly
"Do we need IP, browser, email, or location evidence for e-signatures?"PrivacySettings can capture these during authorization consent (gotcha 6)The capture settings to enableStronger evidence without custom code
"Will portal users or caregivers manage consent forms?"Custom sharing for consent forms is a separate setting (gotcha 7)The external audience and what they may seePortal consent without opening records too widely

What a proper consent configuration adds over "just creating records": consent that renders in the patient's language, a withdrawal trail that survives audits, and a settings model that cannot silently erase evidence.

Core Concepts

ObjectRoleKey fields (Object Reference)
DataUsePurposeWhy PHI is used (treatment, research)Name (required), CanDataSubjectOptOut (required), Description, LegalBasisId
AuthorizationFormThe form and its versionName, DefaultAuthFormTextId (required in description), IsSignatureRequired, RevisionNumber, EffectiveFromDate, EffectiveToDate
AuthorizationFormTextForm text in one languageAuthorizationFormId (required), Locale or LocaleSelection (same function), SummaryAuthFormText, DetailAuthorizationFormText, FullAuthorizationFormUrl, ContentDocumentId
AuthorizationFormDataUseLinks a form to a purposeAuthorizationFormId, DataUsePurposeId (both required)
AuthorizationFormConsentOne person's consent to one form textAuthorizationFormTextId, ConsentGiverId, ConsentCapturedDateTime, ConsentCapturedSource, ConsentCapturedSourceType (all required), Status, RelatedRecordId, DocumentVersionId

ConsentGiverId is polymorphic: Account, Contact, Individual, Lead, or User. Status values are Rejected, Seen, and Signed. ConsentCapturedSourceType values are Email, InPerson, MailingAddress, Phone, Social, Video, and Web.

AuthorizationFormConsent records consent to a specific form text, with its capture time and source. ContactPointConsent and ContactPointTypeConsent record communication channel preferences. Using channel consent objects for HIPAA authorization records the wrong thing.

Withdrawal

Do not delete consent records. There is no Withdrawn status value. Two designs keep the trail; choose one and document it:

DesignHowTrade-off
New record per eventKeep the Signed record; insert a new AuthorizationFormConsent for the same giver and text with Status = Rejected and the withdrawal timeFull trail in data; queries must take the latest record per giver and form
Update with historyChange Status to Rejected and ConsentCapturedDateTime on the existing record, with field history tracking on AuthorizationFormConsent (and a Field Audit Trail policy where available)One record per giver and form; the trail lives in history

Common Patterns

When to use: A patient enrolls in a care program and HIPAA authorization must be recorded first.

How it works:

  1. Create a DataUsePurpose per clinical use (for example Treatment), with CanDataSubjectOptOut set deliberately.
  2. Create the AuthorizationForm, then one AuthorizationFormText per language, then set the form's DefaultAuthFormTextId to the fallback text.
  3. Create the AuthorizationFormDataUse linking the form to its purpose.
  4. In the enrollment flow, create an AuthorizationFormConsent with Status = Seen when the form is shown, filling the required capture fields.
  5. On signature, set Status = Signed (or insert the signed record, per the chosen design).
  6. Mark the CareProgramEnrollee active only after every required authorization is Signed.

Withdrawal processing

When to use: A patient revokes an authorization.

How it works:

  1. Find the patient's consent records by ConsentGiverId and the form text for the purpose.
  2. Record the withdrawal with Status = Rejected, using the chosen design (new record, or update with history).
  3. Set ConsentCapturedSourceType to the channel used (for example Phone) and ConsentCapturedSource to the source detail (for example the staff member or address).
  4. Update the related enrollment if the withdrawal restricts it.
  5. Never delete consent records, and exclude them from cleanup jobs.

Decision Guidance

SituationRecommended ApproachReason
Form shows no text for some patientsSet AuthorizationForm.DefaultAuthFormTextId; add text for the missing languageThe default is the fallback when no language matches
Patient withdrawsRecord Status = Rejected; keep the Signed record or its historyNo Withdrawn value exists; deletion destroys evidence
Marketing email opt-outContactPointTypeConsent, not AuthorizationFormConsentDifferent regulatory purpose and object
Several languagesOne AuthorizationFormText per language, one default on the formLocale and LocaleSelection select the text
E-signature evidence neededPrivacySettings authorization capture fieldsCaptures IP, email, browser, location during consent
Portal users manage consentenableAuthorizationCustomSharingPCU and sharing designCustom sharing for consent forms is opt-in
  1. Secure the feature switch. Confirm Data Protection and Privacy is on, and put PartyDataModelSettings.enableConsentManagement under change control (deployable settings in references/metadata-examples.md).
  2. Inventory purposes and forms. One DataUsePurpose per clinical use; one form per authorization; the languages each form needs.
  3. Build the hierarchy. Form, then texts, then set DefaultAuthFormTextId, then AuthorizationFormDataUse.
  4. Build capture into enrollment. Create consent records with all required capture fields, set Seen then Signed, and gate enrollment activation on Signed.
  5. Build withdrawal. Choose the new-record or update-with-history design, record Rejected, and exclude consent objects from every deletion job.
  6. Test per language and per channel. Show each form in each language, record consent through each channel, and confirm reporting finds the latest status per patient and form.

Review Checklist

Salesforce-Specific Gotchas

The deep versions, with sources, live in references/gotchas.md.

#GotchaOne-line consequence
1Turning off consent management purges stored consent formsOne settings deploy can erase evidence
2The default text is a lookup on the form, not a flag on the textForms render nothing for unmatched languages
3Status has no Withdrawn valueWithdrawal flows fail or overwrite the signature
4Capture source type is a restricted picklist; source text is requiredLoads fail on "Verbal" or "Written"
5DataUsePurpose has no PurposeId fieldScripts copied from old examples fail
6Evidence capture is a settings decisionIP and browser are not recorded unless enabled
7Portal sharing of consent forms is opt-inPortal users cannot see forms they must sign
8Consent records do not enforce access to PHISharing must be designed separately

Output Artifacts

ArtifactDescription
Consent settingsPartyDataModel and Privacy settings files under change control
Authorization form hierarchyPurposes, forms, language texts, default text, data-use links
Enrollment flow with consent captureRequired capture fields, Seen and Signed, enrollment gate
Withdrawal designRejected recording with preserved history, no deletion

Dependencies

Package files