Solution: WellPath Clinics

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Architecture Decisions

AD-1: Health Cloud with Person Accounts as the Patient Record Foundation

Decision: Implement Salesforce Health Cloud using Person Accounts to represent patients, with the standard Health Cloud data model for clinical objects (Care Plans, Episodes, Clinical Data).

Rationale: Health Cloud is built on Person Accounts and extends the standard Salesforce platform with pre-built clinical objects including medication summaries, allergy lists, and care team assignments. Building on Person Accounts avoids a custom object model and keeps the solution within the Health Cloud license entitlement. The standard objects are HIPAA-ready and integrate with Shield encryption.

Alternatives considered: Custom object model with a standalone Patient object. Rejected because it requires rebuilding what Health Cloud already provides, increases maintenance burden on a two-person IT team, and may not satisfy HIPAA audit controls without additional engineering.

Trade-offs: Person Accounts have known limitations in how they appear in reports and list views compared to standard contacts, and they cannot be converted back to business accounts. The team must understand this before launch.

Decision: Set the Person Account OWD to Private. Grant same-site access using criteria-based sharing rules that target per-site public groups, not user field comparisons. Each clinic site has a Public Group containing all clinicians, MAs, and nurses assigned to that site; a front-end provisioning Flow maintains membership as users are onboarded or transferred. Cross-clinic access (Req 9) is handled via Apex-managed sharing on an encounter check-in Platform Event: when a clinician opens an encounter for a patient whose primary site differs from the clinician’s home site, an Apex trigger creates a temporary AccountShare and Visit__Share row, and the same trigger revokes the share when the encounter is closed.

Rationale: The scenario presents a direct tension: clinicians should only see their own site’s patients (Req 8), but any clinician may view any patient presenting at their site from another site (Req 9). Criteria-based sharing rules in Salesforce compare record fields to static values, public groups, roles, territories, or owner criteria; they cannot compare a record field to a user field dynamically (for example, Patient.PrimaryClinicSite__c = Running_User.Clinic_Site__c). The correct pattern is to pre-build the grouping on the user side (public group per site) and then have the sharing rule grant access to that group when Patient.PrimaryClinicSite__c equals the site identifier the group represents. One sharing rule per site, each targeting its matching public group, satisfies Req 8 cleanly.

For Req 9, permission sets alone cannot grant record-level access when OWD is Private; sharing records (AccountShare and Visit__Share __Share rows) are required. Triggering on encounter check-in (rather than on a static “cross-clinic viewer” designation) keeps the grant scoped to the specific patient and the specific encounter, matching the requirement’s intent and mirroring the pattern ClearView uses. A Cross-Clinic Encounter permission set group controls field-level visibility for cross-site encounters but does not itself grant record access.

Permission set group alternative for general read-all roles: Compliance, CMO, and Network Administrator users need cross-site visibility continuously, not encounter-scoped. These populations sit at the top of the role hierarchy and inherit record access without any additional sharing configuration. This keeps Apex-managed sharing focused on the clinician cross-site exception case only.

Alternatives considered:

Criteria-based sharing rule using Patient.PrimaryClinicSite__c matching a user’s site field directly. Rejected because Salesforce criteria-based sharing rules cannot compare record fields to dynamic user attributes.
Territory Management to model sites. Rejected because territories are designed for sales hierarchies, not clinical site structures, and add complexity the IT team cannot maintain.
Manual sharing rules per site pairing. Rejected because 12 sites produce 132 possible pairs, making rule management unscalable.
Sharing Sets. Rejected because Sharing Sets require the user to be an Experience Cloud external user and WellPath clinicians are internal Salesforce users.

Trade-offs: The public group per site must be maintained as clinicians move between sites. A Flow on the User object (triggered by Clinic_Site__c changes) adds and removes group members automatically, but the maintenance Flow is an additional moving part that must be tested and monitored. The encounter-scoped cross-site grant requires a reliable encounter-close trigger; a nightly cleanup Apex job revokes any stale cross-site shares for closed encounters as a compensating control.

AD-3: Salesforce Platform Events + Named Credential for the BrightClaim Integration

Decision: Trigger the BrightClaim claim submission using a Platform Event published when a visit record is set to “Finalized” status. An Apex subscriber consumes the event and calls the BrightClaim REST API v2 using a Named Credential for OAuth 2.0. Failures create tasks against the visit record for the billing team.

Rationale: Platform Events provide asynchronous, reliable event delivery. Decoupling the submission trigger from the record save means the visiting clinician does not wait for the HTTP call to complete. Named Credentials handle OAuth 2.0 token management natively, keeping credentials out of code and out of reach of the two-person IT team. The 15-minute SLA (Req 16) is comfortably met because Platform Event delivery is near real-time and the async Apex queue processes within seconds under normal load.

Alternatives considered: Flow with HTTP callout action. Rejected because Flow callouts are synchronous on save and introduce save latency for clinicians. A middleware platform. Rejected explicitly by the $900K budget constraint (no standalone middleware platform).

Trade-offs: Async Apex is subject to a limit of 250,000 or (number of user licenses × 200) per 24 hours, whichever is greater. At 530 claims per business day, this is well within capacity. The team must monitor async Apex execution in Apex Jobs and set up email alerts for failures.

AD-4: Salesforce Shield with External Archive for HIPAA Compliance

Decision: Enable Shield Platform Encryption on all PHI fields (name, date of birth, address, insurance IDs, clinical notes, diagnosis codes, allergy and medication text). Enable Shield Event Monitoring and Field Audit Trail. Add a nightly EventLogFile export to customer-managed cloud storage (an S3 bucket maintained by the IT team) to satisfy the 6-year access-log retention requirement.

Rationale: HIPAA requires encryption at rest and in transit (Req 14), access logging with user, record, action, and timestamp (Req 12), and field-level change history (Req 25). Shield Platform Encryption covers encryption. Field Audit Trail covers field change history for up to 10 years. Shield Event Monitoring captures the access events, but native EventLogFile retention is 30 days by default and a maximum of 1 year with the Shield Event Log File Storage add-on; neither reaches the 6-year HIPAA retention bar. A scheduled Apex job extracts EventLogFile content via the Analytics API, pushes it to an S3 bucket through a thin AWS Lambda worker, and applies a 6-year lifecycle policy. Compliance reports pull recent data from EventLogFile in Salesforce and older data from the S3 archive via a CRM Analytics external connector or Athena.

Encryption scheme considerations: Shield deterministic encryption supports text, email, phone, URL, and text area fields only. Standard Date, DateTime, number, and long text area fields support probabilistic encryption only. The WellPath data model has several implications:

Date of birth (standard Birthdate Date field on Person Account) can only be probabilistically encrypted and cannot be used in SOQL WHERE clauses after encryption is enabled.
To preserve DOB-based deduplication after go-live, a companion DOB_Hash__c text field stores a deterministic hash of the DOB (SHA-256 of yyyy-MM-dd produced by Apex before insert/update). Deterministic encryption is applied to the hash field, so it remains queryable.
SSN and MRN are stored in custom text fields and use deterministic encryption so billing queries work directly.

Alternatives considered: Custom encryption using Apex with a KMS. Rejected because it is not maintainable by a two-person IT team and does not satisfy the platform-level audit log requirement without significant additional work. Probabilistic encryption with DOB removed from all search flows. Rejected because duplicate prevention across 38,000 patients needs a DOB match alongside first name and last name.

Trade-offs: Shield adds cost to the license budget. The PM must confirm Shield is within the $900K envelope. The DOB_Hash approach adds a before-save trigger or Flow formula to maintain the hash, which is simple to implement but must be documented so future admins understand why DOB is not searched directly. The external EventLogFile archive adds one more scheduled Apex job and one AWS Lambda component but reuses patterns the IT team already understands.

AD-5: Phased Migration with Pre-Load Deduplication in a Scratch Org

Decision: Run deduplication and data quality remediation in a staging environment using anonymized/synthetic data mirroring the CliniBase export structure. Use Salesforce Data Loader + a Python deduplication script to merge records before loading into production. No patient data enters any sandbox.

Rationale: The constraint prohibiting PHI in sandbox (Constraint 6) means the team cannot run deduplication directly in a sandbox against real records. Synthetic data built to match the structural profile of the CliniBase export (same field distributions, same error patterns) allows the deduplication and load scripts to be tested without PHI. The final merge run executes against a pre-production staging environment and then loads merged records into production.

Alternatives considered: Salesforce Duplicate Rules for post-load dedup. Rejected as a primary strategy because 2,280 known duplicates would produce that many merge tasks for the front desk, and the survivorship logic (most complete demographics + consolidated visit history) cannot be expressed purely in Duplicate Rules. Duplicate Rules are kept as the ongoing prevention mechanism (Req 23) after migration.

Trade-offs: Synthetic data generation requires upfront effort. The team must validate that synthetic data is structurally representative enough to reveal edge cases in the merge script.

System Landscape

Legend

Retiring: CliniBase 3.1 and per-clinic scheduling spreadsheets decommissioned after go-live. Keeping: BrightClaim (no changes to BrightClaim; integration is outbound only from Salesforce). New: Salesforce Health Cloud org with Shield add-on.

Data Model

Core Objects

Object	Type	Purpose
Patient	Person Account	Demographics, PCP assignment, primary clinic site
Visit	Custom Object	Historical and current visits; finalized trigger for billing
MemberPlan	Standard Health Cloud	Policy identity: one record per patient per insurance plan, with subscriber, group number, effective dates, and primary/secondary ranking
CoverageBenefit	Standard Health Cloud	Benefit-level detail attached to a MemberPlan (copay, deductible, covered services); used only when WellPath needs to store benefit specifics for a plan
Clinic Site	Custom Object	Master list of 12 sites; lookup target for sharing rules
Clinician	User + Contact	Linked to site; drives care team and sharing
Claim Transmission Log	Custom Object	Tracks each BrightClaim API call, status, and acknowledgement
Data Quality Flag	Custom Object	Tracks missing DOB/insurance records for front desk remediation

Key Relationships

Field Highlights

Patient.PrimaryClinicSite__c: lookup to Clinic Site; drives criteria-based sharing rule
Patient.PrimaryCareProvider__c: lookup to User (clinician); drives care team membership
Visit__c.TransmissionStatus__c: picklist: Pending / Transmitted / Acknowledged / Failed; drives reconciliation report
Visit__c.ClinicalNotes__c: Shield-encrypted; FLS blocks Billing and Front Desk profiles
MemberPlan.PrimarySecondary__c: picklist: Primary / Secondary; enforces Req 6 multi-insurance support. CoverageBenefit child records are used only if WellPath needs to store per-plan benefit detail (copay, deductible, limits)
Claim_Transmission_Log__c: append-only child record; provides full audit trail per Req 17

Integration Architecture

BrightClaim Claim Submission

Attribute	Detail
Trigger	Visit__c.Status__c set to “Finalized” by clinician
Event	Platform Event: Visit_Finalized__e published on record save via Flow or Record-Triggered Automation
Consumer	Async Apex subscriber
Direction	Salesforce outbound to BrightClaim
Protocol	HTTPS REST POST
Auth	OAuth 2.0 Client Credentials via Named Credential
Payload	VisitDate, CPT codes, ICD-10 codes, clinician NPI, patient insurance ID
SLA	Within 15 minutes of finalization (Req 16)
Success path	BrightClaim returns 200 + claim reference; update Transmission Log status to Acknowledged
Failure path	Non-200 or timeout: set status to Failed, create Task on Visit assigned to billing queue, log full response in Transmission Log
Retry	Scheduled Flow runs every 15 minutes to retry Failed records up to 3 times before escalating to billing manager
Reconciliation	Daily report on Claim_Transmission_Log__c showing counts by status (Req 18)
End-of-day rule	Scheduled job at 9 PM checks for any Pending/Failed records with same-day VisitDate; creates urgent task for billing team (Req 17)

OWD Settings

Object	OWD
Person Account (Patient)	Private
Visit__c	Private
Clinic_Site__c	Public Read Only
Claim_Transmission_Log__c	Private
Data_Quality_Flag__c	Private

Role Hierarchy

WellPath Network (top)
├── Compliance Officer (full visibility)
├── CMO (read-only across all sites)
├── Billing Manager
│   └── Billing Staff
└── Clinic Manager [one per site]
    ├── Clinician [per site]
    └── Front Desk [per site]

The hierarchy gives Compliance Officer and CMO record access through role-based visibility, eliminating the need for sharing rules at the top level.

Profiles and Permission Sets

Profile	Intended Population	Key Access
Clinical User	Clinicians, MAs, nurses	Read/write Visit; read Patient; FLS blocks billing-only fields
Billing User	Billing staff (30)	Read Visit (billing fields only); FLS blocks ClinicalNotes, allergies, meds
Front Desk	Front desk staff (72)	Read/write Patient demographics; FLS blocks clinical notes, diagnoses, billing details
Compliance Read-Only	Compliance officer	Read-all via role hierarchy; access to audit reports
System Admin	IT (2 staff)	Full org access

Permission Set	Purpose
Cross-Clinic Encounter	Controls FLS for clinicians actively working a cross-site encounter (field visibility only; record access is granted by the encounter-scoped Apex-managed AccountShare and Visit__Share rows, not this permission set); tied to Event Monitoring for audit (Req 9)
Data Quality Remediator	Allows front desk to edit flagged records and close Data Quality Flag records

Criteria-based rules on Patient (one per clinic site): Twelve site-specific sharing rules; each rule shares Patient records where PrimaryClinicSite__c equals a specific site’s ID with that site’s public group. Criteria-based sharing rules cannot compare a record field to a dynamic user attribute, so the user grouping is pre-built as a public group per site and each sharing rule targets its matching group.
Criteria-based rules on Visit: Mirror of Patient rules; twelve site-specific rules sharing Visit records to the matching site’s public group.
Site public group maintenance: A record-triggered Flow on the User object adds or removes members from the site public group whenever Clinic_Site__c on the User record changes, keeping the groups in sync with staff assignments.
Cross-site access: Apex-managed sharing fires on an encounter check-in Platform Event, creating temporary AccountShare and Visit__Share rows. The same Apex revokes the share rows on encounter close, and a nightly cleanup job removes stale shares for any encounters in Closed status longer than 24 hours.
The Cross-Clinic Encounter permission set controls only field-level visibility; it does not grant record access. Record access is always driven by the AccountShare / Visit__Share rows.

HIPAA Controls

Shield Platform Encryption on all PHI fields (name, DOB, address, insurance IDs, clinical notes, diagnoses, allergy text, medication text): satisfies Req 14 and Req 10
Shield Event Monitoring captures access events (URI, Login, Report, etc.) via EventLogFile, a separate Shield capability from Field Audit Trail. These logs must be ingested into CRM Analytics or a SIEM to produce per-record audit trails satisfying Req 12 and Req 15
Field Audit Trail on Patient demographics fields (name, DOB, address, insurance fields): provides previous value, new value, changed-by, timestamp (Req 25); retention configured for 10 years
FLS on Visit__c.ClinicalNotes__c, Visit__c.DiagnosisCodes__c, allergy and medication fields: hidden for Billing User and Front Desk profiles at both UI and API layer (Req 10, Req 11)

Terminated Employee Access Revocation (Req 13)

A scheduled Flow polls a custom HR Notification object (written by the HR system webhook) every 30 minutes and deactivates any user whose HR status has moved to Terminated. User deactivation in Salesforce immediately revokes all active sessions and API tokens. The 4-hour SLA is met by the 30-minute polling interval, with margin to spare. No manual runbook is used; the requirement explicitly requires operation without manual steps from IT.

Migration Strategy

Phases

Phase 1: Prepare (Weeks 1-4)

Export CliniBase data as CSV files (patients, visits, insurance records)
Generate synthetic data matching CliniBase field distributions for testing
Build and test deduplication script against synthetic data in an isolated environment (no PHI)
Define survivorship rule: retain record with most complete demographics (fewest null fields); consolidate all visit history under surviving record ID; capture losing record IDs in a reference table for audit

Phase 2: Remediation Prep (Weeks 5-6)

Run deduplication script against actual export in a secure staging environment
Produce merged patient file (~35,720 unique records after merging ~2,280 duplicates)
Flag ~1,520 records with missing DOB or insurance; load as Patient records with Data Quality Flag children set to Open
Assign flags to front desk queues by clinic site for remediation before go-live

Phase 3: Data Load (Weeks 7-10)

Load order: Clinic Sites → Clinicians/Users → Patients (Person Accounts) → MemberPlan records → CoverageBenefit records (where benefit detail is captured) → Visits → Data Quality Flags
Use Data Loader for bulk inserts; external ID field (CliniBase_ID__c) on each object maintains referential integrity across files
Validate row counts and spot-check 200 records per load step

Phase 4: Validation and Cutover (Weeks 11-14)

IT and compliance officer perform UAT against production data
Compliance officer approves all FLS and sharing configurations before go-live (Constraint 6)
Parallel run: CliniBase remains read-only for 2 weeks post go-live
Cutover date must be at least 2 months before CliniBase end-of-support

Deduplication Survivorship Rule

Score each duplicate cluster: +1 point per non-null field in the standard demographic set (first name, last name, DOB, address, insurance ID, phone, email)
Highest-scoring record becomes the survivor
All visit records from losing records re-parented to the survivor via the Patient__c lookup update
Losing record IDs stored in Merged_From_ID__c field on the survivor for traceability
Ties broken by earliest created date (oldest record survives)

Sandbox Data Strategy

No PHI in sandbox. Synthetic data generation uses the structural profile extracted from CliniBase (field cardinality, null rates, value distributions) to create 50,000 synthetic patient records and 250,000 synthetic visit records. This volume exceeds production to surface performance issues in the load scripts and dedup logic.

Reporting Approach

Clinic Manager Daily Dashboard (Req 19)

Built on Salesforce Reports and Dashboards. Components: appointments scheduled today (Activities), appointments completed today (Visit__c with same-day date), no-show count (Visit__c status = No-Show), open data quality flags for the site. Filtered by the viewing user’s clinic site using the standard running user filter. Refreshed every hour via scheduled refresh.

CMO Monthly Network Summary (Req 20)

Custom report type joining Visit__c and Person Account. Three report components: top 10 diagnosis codes by visit count (summary report grouped by DiagnosisCodes__c), average visits per active patient (formula field), patients with zero visits in past 12 months (cross-filter on Visit__c date). Scheduled to run first business day of each month and email to CMO.

Compliance Audit Report (Req 21)

Powered by Shield Event Monitoring event log files. A custom Analytics (CRM Analytics) dataset ingests event log files nightly. The compliance officer can filter by patient record ID and date range, see all access events (user, action, timestamp), and export to CSV. Alternatively, the compliance officer can query the EventLogFile object via Reports if CRM Analytics is outside budget.

Billing Weekly Exception Report (Req 22)

Report on Claim_Transmission_Log__c filtered by Status__c IN ('Failed', 'Pending') and TransmittedAt__c older than 24 hours. Scheduled weekly email to the billing manager every Monday morning.

Requirements Addressed

Risk Assessment

Risk	Impact	Probability	Mitigation
Shield license cost exceeds budget allocation	High	Medium	Confirm Shield SKU pricing early in discovery; if over budget, evaluate Health Cloud compliance add-ons or negotiate license bundle
CliniBase CSV export has undocumented encoding or referential gaps causing load failures	High	Medium	Run load scripts against full synthetic data volume before migration week; build a reconciliation script that counts source rows vs. loaded rows per object
Async Apex claim submission queue backs up during high-volume periods (Monday morning surge)	Medium	Low	Monitor Apex queue depth in production; if queue depth exceeds 10K pending jobs, add a second retry mechanism using Scheduled Flows as a fallback path
Criteria-based sharing rules fail to re-evaluate after patient site transfer, leaving stale access	Medium	Low	Document patient site transfer process; add a Flow that forces record save (and therefore sharing rule re-evaluation) after any PrimaryClinicSite__c change

Domain Scoring Notes

Domain 3: Data Architecture (heavy domain)

Judges will probe whether you know Health Cloud’s standard object model vs. what you customized. Be ready to name the specific Health Cloud objects you use (MemberPlan for policy identity, CoverageBenefit for benefit-level detail, Care Team Member for the care team) and explain why you did not build custom objects. Expect a question on deduplication at scale: “How would you handle 2,280 duplicates if the survivorship script misidentifies a survivor?” Have an answer for rollback (the Merged_From_ID__c reference table allows manual correction).

Domain 2: Security (heavy domain)

The sharing model tension between Reqs 8 and 9 is the most likely probe. Walk through exactly how a cross-clinic access event flows: which permission set is assigned, what the user sees, and exactly how that access event appears in the audit log. Judges will ask how you prevent billing staff from seeing clinical notes at the API layer. The answer: FLS enforced by platform for all API access, not just UI.

Domain 5: Integration

Judges will press on what happens if BrightClaim is down for 4 hours. Walk through the retry logic: 3 retries at 15-minute intervals, then a task to billing, then the end-of-day check. Explain how the Claim_Transmission_Log__c gives the billing team a traceable record of every attempt.

What Would Fail

1. Using a Public OWD with manual sharing rules to solve Req 8. A candidate who sets Person Account OWD to Public Read-Only and tries to restrict access through manual sharing rules will fail. Manual sharing rules grant access but do not restrict it. The only way to enforce site isolation is Private OWD with sharing rules that grant access to same-site users.

2. Relying on profile object permissions alone to enforce field restrictions for billing staff. Object permissions control CRUD on the whole object. A candidate who says “billing staff have read-only access to the Visit object” has not addressed Req 10. FLS must explicitly hide ClinicalNotes__c, allergy fields, and medication fields from the Billing User profile at both the profile and permission set level. Judges will ask about API access specifically.

3. Building a synchronous HTTP callout on the Visit record save trigger. A callout in a before/after-save trigger blocks the entire save transaction. If BrightClaim is slow or down, the clinician’s record save fails or times out. The correct answer is asynchronous: Platform Event published on save, Apex subscriber processes the call outside the transaction. A candidate who does not separate the callout from the save transaction demonstrates a gap in integration architecture fundamentals.

Scoring Rubric

Criterion	Weight	What Passing Looks Like
Security and Sharing Model	25%	Private OWD correctly applied; per-site public group + criteria-based sharing rule pattern (one rule per site) because dynamic user attribute comparison is not supported; encounter-scoped Apex-managed sharing for cross-clinic access; Cross-Clinic Encounter permission set for FLS only; Event Monitoring audit via EventLogFile with external S3 archive for 6-year retention; FLS per profile at both UI and API layer; with/without sharing distinction clarified
Data Model and Health Cloud Usage	20%	Person Accounts for patients; Health Cloud MemberPlan for insurance policy identity (with CoverageBenefit for benefit detail where needed); custom Visit object with correct fields; Claim Transmission Log as audit trail; ER relationships correct
Integration Architecture	20%	Async pattern (Platform Event + Apex); Named Credential for OAuth 2.0; failure path creates Task; retry mechanism; end-of-day reconciliation check
Migration Strategy	20%	No PHI in sandbox; survivorship rule defined; load order correct; Data Quality Flags tracked; rollback mechanism for merge errors
Requirements Coverage	15%	All 25 requirements addressed; implicit requirements called out; constraints respected (no middleware, PHI sandbox rule, CliniBase deadline)

Self-Assessment Checklist

Does your sharing model produce Private OWD on Person Account? If you used Public or Public Read-Only, reconsider.
Did you address the FLS requirement for billing staff at the API layer, not just the UI?
Is your BrightClaim integration asynchronous? If you placed the callout in a trigger, rework the design.
Does your migration plan address the PHI-in-sandbox constraint explicitly?
Did you include the Claim Transmission Log as a separate object (not just a field on Visit)?
Is Field Audit Trail called out for the demographic change history requirement (Req 25)?
Did you define a survivorship rule for deduplication with a tiebreaker, not just “keep the most complete record”?

Q&A Prep

Q: Requirements 8 and 9 seem to contradict each other. How do you resolve both?

Req 8 establishes the default: clinicians only see their site’s patients. Req 9 is the exception: any clinician may view any patient presenting at their site from another site, and that access must be audited.

Req 8 is solved with Private OWD and criteria-based sharing rules — but the rules cannot compare a record field to a dynamic user attribute, so the user grouping is pre-built as a public group per site. There is one sharing rule per site, each matching Patient.PrimaryClinicSite__c = {that site ID} to the site’s public group. A record-triggered Flow on User maintains group membership as clinicians are onboarded or transferred, so the grouping is always current.

Req 9 is handled with encounter-scoped Apex-managed sharing, not a persistent “cross-clinic viewer” role. When a clinician opens an encounter for a patient whose primary site is different, a Platform Event fires; an Apex subscriber creates temporary AccountShare and Visit__Share rows for that clinician and that patient. When the encounter is closed, the same Apex revokes the rows. A Cross-Clinic Encounter permission set controls field-level visibility; it does not grant record access (permission sets cannot grant record access when OWD is Private). A nightly cleanup job removes any stale cross-site shares for encounters in Closed status longer than 24 hours as a compensating control. Shield Event Monitoring captures access events via EventLogFile regardless of how access was obtained, and those logs flow into CRM Analytics for the recent window and to an S3 archive for the full 6-year retention window.

The key point is that the two requirements do not contradict; they operate at different layers and on different time horizons. Sharing rules set the default boundary (permanent). Encounter-scoped Apex-managed sharing handles the exception (temporary). Event Monitoring handles the audit across both.

Q: How do you block billing staff from accessing clinical notes through the Salesforce API?

Field-level security (FLS) in Salesforce is enforced at the platform layer for all access: Salesforce UI and REST/SOAP API calls. Note that with sharing and without sharing in Apex control record-level access only; they do not enforce FLS; to enforce FLS in Apex code, use Security.stripInaccessible() or queries with WITH USER_MODE. A field hidden via FLS in a profile is not returned in API query responses for users assigned that profile. The Billing User profile has ClinicalNotes__c, allergy fields, and medication fields set to hidden. A billing staff member cannot retrieve those fields via the REST API even if they know the field API name. This is a platform guarantee for direct API calls; custom Apex must explicitly enforce FLS via Security.stripInaccessible() or WITH USER_MODE to uphold the same guarantee.

Q: What happens if BrightClaim is unavailable for several hours?

The async Apex subscriber attempts the call and receives a timeout or error. It logs the failure in Claim_Transmission_Log__c, sets the status to Failed, and creates a Task assigned to the billing queue. A scheduled retry Flow runs every 15 minutes and re-queues Failed records, up to 3 attempts. After 3 failures, the status moves to Escalated and an additional task is created for the billing manager. The end-of-day scheduled job at 9 PM catches any same-day visit records still in Pending or Failed status and generates an urgent task. The billing manager’s morning dashboard shows open exceptions with counts, so nothing falls through unnoticed overnight.

Q: How does the compliance officer query access logs for a specific patient?

Shield Event Monitoring captures access events (URI, Login, Report, and other event types) via the EventLogFile object. Event Monitoring and Field Audit Trail are separate Shield capabilities: Event Monitoring covers who accessed what and when; Field Audit Trail covers what field values changed.

For the recent window (up to 1 year with Shield Event Log File Storage), a CRM Analytics dataset ingests EventLogFile records nightly and surfaces a report filtered by record ID and date range, with export to CSV. For anything older, the compliance officer queries an S3 archive via a CRM Analytics external connector (or Athena / Tableau connection). A nightly Apex job extracts EventLogFile content to the archive, which has a 6-year lifecycle policy and covers the HIPAA retention window. The compliance officer selects a patient, picks a date range, and downloads the full access history showing user, action, and timestamp from whichever tier holds the data. All access events (clinical, front desk, compliance officer’s own access) appear in the same dataset because Event Monitoring captures events regardless of the user’s role.

Q: A patient changes their primary site from Clinic A to Clinic B. What happens to access?

Criteria-based sharing rules re-evaluate when a record is saved. When the PrimaryClinicSite__c field is updated and the record is saved, Salesforce re-evaluates all sharing rules for that record. The Clinic A rule no longer matches, so the Clinic A public group loses access; the Clinic B rule now matches, so the Clinic B public group gains access. The re-evaluation is asynchronous but typically completes within a few minutes. To make this reliable, a record-triggered Flow forces an additional save on site change to trigger immediate re-evaluation, and the process is documented in the admin runbook. Clinician-to-site reassignments work the same way: the User-object Flow updates public group membership, and Salesforce recalculates group-based sharing automatically.

Q: Why not use Territory Management to model clinic sites?

Territory Management is optimized for sales hierarchies where accounts are assigned to territories based on geographic or product criteria, and territories roll up through a hierarchy for forecasting. WellPath’s requirement is about data isolation between clinical sites, not sales forecasting. Territory Management adds complexity that a two-person IT team with no prior Salesforce experience cannot maintain. Criteria-based sharing rules are simpler, directly supported by Salesforce Help documentation, and adequate for 12 fixed sites.

Q: How do you handle the 6% duplicate rate without exposing PHI in a sandbox?

The actual deduplication work is done on a secure staging environment that holds production data temporarily before migration. No PHI enters any sandbox. For testing the deduplication script and validating the survivorship logic, we generate synthetic data that mirrors the structural profile of the CliniBase export: same field cardinality, same null rates (approximately 4% missing DOB, 6% duplicate rate), same approximate record volume. This synthetic dataset is loaded into a developer sandbox to test the script, validate edge cases, and measure load performance. The real merge run happens in the staging environment and outputs a clean merged file that goes directly into production.

Q: The IT team has no Salesforce experience. How do you make this maintainable?

Three decisions protect long-term maintainability. First, declarative-first design: sharing rules, FLS, validation rules, and Flows are preferred over Apex wherever the requirements are met. Apex is used only for the BrightClaim callout because Flows cannot handle complex error logging and retry logic at the same fidelity. Second, minimal custom objects: only the objects that Health Cloud does not provide are custom (Visit, Clinic Site, Claim Transmission Log, Data Quality Flag). The rest is standard Health Cloud. Third, a documented admin runbook covering: user provisioning and deactivation, adding a new clinic site, updating sharing rules, and monitoring the BrightClaim async queue. The compliance officer approval gate (Constraint 6) acts as a second pair of eyes on any change to access configuration.

Q: How do you meet the 7-year retention requirement while also handling inactive patient records?

Three layers. First, Salesforce data is retained indefinitely unless explicitly deleted or archived, so patient and visit records remain in the org with the same sharing model. The compliance officer’s role-based access keeps those records visible regardless of activity. Second, Shield Field Audit Trail is configured for 10-year retention on Agent__c, Policy__c, and demographic fields, which exceeds the 7-year field change history requirement. Third, EventLogFile access telemetry is exported nightly to an S3 archive with a 6-year lifecycle policy to satisfy the access-log retention bar, because Field Audit Trail does not cover record access events. If storage costs become a concern, Salesforce Big Objects can archive historical visit records while keeping them queryable by authorized users.

Q: What validation prevents a visit record with missing billing fields from being submitted to BrightClaim?

Two layers. First, validation rules on Visit__c require that VisitDate__c, CptCodes__c, DiagnosisCodes__c, and the attending clinician’s NPI are populated before status can be set to “Finalized.” This blocks the Platform Event from firing on an incomplete record. Second, the Apex subscriber performs a pre-flight check before building the HTTP payload: if any required billing field is null, it sets TransmissionStatus__c to “Validation Failed” and creates a task rather than attempting a malformed API call. This satisfies Req 24 for integration-sourced records and protects BrightClaim from partial payloads.

Q: How does the daily reconciliation report work mechanically?

The Claim_Transmission_Log__c object has one child record per BrightClaim API call, with fields for VisitDate__c (denormalized from the parent Visit), TransmittedAt__c, Status__c, and BrightClaimRef__c. The daily reconciliation report is a standard Salesforce summary report filtered to the prior business day, grouped by Status__c. It shows: total rows (visits finalized), count of Acknowledged rows (successful transmissions), count of Failed rows (rejections), and count of Pending rows (no response received). The billing manager subscribes to a scheduled report email delivered at 8 AM each business day.

Presentation Notes

Recommended Diagram Order

System landscape (current state and future state, 2 minutes): establishes scope immediately
Security and sharing model (4 minutes): lead with the OWD/sharing rule design, then walk through FLS per population; this is the heaviest domain
Data model (3 minutes): call out Health Cloud standard objects first, then custom additions
Integration design (4 minutes): walk the happy path, then the failure path; show the Claim Transmission Log
Migration plan (3 minutes): lead with the PHI-in-sandbox constraint and how you resolve it; state the phased timeline

Key Talking Points

State the core tension early: “Requirements 8 and 9 are in direct tension, and the sharing model resolves both.”
Name specific Salesforce features rather than categories: say “Shield Platform Encryption, probabilistic scheme on DOB because Date fields do not support deterministic encryption, plus a deterministic DOB_Hash field for deduplication queries” not just “encryption.”
Quantify the integration risk: 530 claims per day, 9% error rate, $1.98M at risk. Then explain how the async pattern and Transmission Log eliminate manual transcription and provide traceability.
Acknowledge the constraint proactively: “The no-middleware constraint rules out MuleSoft. The Platform Event and Named Credential pattern meets the BrightClaim REST requirement within the platform budget.”
Call out the 6-year audit log retention gap: “EventLogFile retention is 30 days native and 1 year maximum with Shield; the nightly export to S3 with a 6-year lifecycle closes the HIPAA retention gap.”

Time Allocation

The scenario format allocates a 30-minute presentation block and a separate 30-minute Q&A block. Do not reserve presentation minutes for clarifying questions; clarifying questions belong to the Q&A block.

Section	Suggested Time
System landscape	2 min
Security and sharing model	7 min
Data model	5 min
Integration	6 min
Migration	5 min
Risks and constraints	3 min
Assumptions recap and handoff to Q&A	2 min
Total presentation	30 min

A separate 30-minute Q&A block follows the presentation. Rehearse answers to the Req 8 / Req 9 sharing model, BrightClaim failure path, and DOB encryption trade-off so each can be delivered in under 90 seconds during Q&A.

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.