Skip to content

Case Study 02: CareBridge Q&A Prep

AI-Generated Content — Use for Reference Only

This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.

Q&A Context

Format: 30-minute Q&A following 45-minute presentation Strategy: Answer in 60-90 seconds. State your decision, give one reason, name one alternative you rejected and why.

Security Questions

Q1: Why Private OWD instead of Public Read Only with restriction rules?

Private OWD is necessary because the access pattern is additive, not subtractive. Eight distinct user types each see a different patient slice. Starting with Public Read Only and restricting down would require restriction rules for every user-type/data combination — fragile and error-prone. Private OWD with targeted sharing rules (criteria-based for static groupings, Apex-managed for dynamic patterns) is cleaner and auditable.

Q2: How does the VIP restriction work with the sharing model?

Restriction Rules run AFTER sharing rules in Salesforce’s access evaluation order. Even if a physician has department-level access to a VIP patient, the restriction removes visibility. Only users with the VIP_Access permission set bypass it. The CCO’s team administers VIP_Access assignments, and Event Monitoring logs every access to VIP-flagged records for the 90-day report.

Q3: How do you handle specialist access? They only see referred patients.

Apex-managed sharing triggered by the referral lifecycle. When a referral is accepted, an Apex trigger creates a share record on the patient Account. When the episode closes, a second trigger removes it. This is dynamic and event-driven. Criteria-based sharing cannot model this because no static field on the patient maps to which specialists currently have active referrals.

Q4: How do you prevent Patient Access staff from seeing clinical data?

Three layers. First, Private OWD means no default access. Second, criteria-based sharing grants Read Only to accounts with upcoming appointments at their facility. Third, FLS hides all clinical fields (diagnosis, notes, medications, labs, vitals). Even if sharing inadvertently grants record access, FLS prevents clinical field visibility. Defense-in-depth.

Integration Questions

Q5: Why MuleSoft instead of point-to-point?

Three reasons. Protocol diversity: FHIR R4, HL7v2 MLLP, REST — parsing HL7v2 in Apex is unmaintainable. Volume and reliability: 3,300 lab results plus 15,000 RPM readings per day requires proper queueing and retry. HIPAA audit: centralized logging of every PHI data flow. Retrofitting audit logging later is harder than building it in.

Q6: Health Timeline does on-demand reads from Epic. What about latency?

The FHIR read through MuleSoft takes 1-3 seconds. I accepted this because persisting clinical data creates three problems: PHI duplication doubles compliance surface, sync lag means clinicians see stale data, and storage costs for 3.5M encounters/year are substantial. A 2-second load in a Lightning component satisfies the CMO’s quote. If latency becomes an issue, Platform Cache with short TTL can mitigate.

Q7: Walk through the RPM alert flow.

MuleSoft polls Philips every 5 minutes. New readings become RPM_Reading records via Platform Events. An Apex trigger evaluates against patient-specific thresholds. If breached: creates RPM_Alert, assigns high-priority Task to care team, sends push notification. For critical alerts (e.g., systolic >200), also pages the on-call physician. Worst-case latency: ~6 minutes end-to-end. Dr. Patel’s team validated this as clinically acceptable.

Q8: How do you ensure no PHI leaks through the integration layer?

Four controls. All transport encrypted (mTLS for Epic, TLS for MLLP, HTTPS for REST). MuleSoft deployed with BAA coverage. Every message logged with timestamp, source, destination, patient ID, and payload hash — but not full payload. Named Credentials with certificate-based auth so no keys stored in code.

Data Questions

Q9: How do you handle the 40% patient overlap between Meditech and Epic?

Composite matching key: normalized last name + DOB + gender + last 4 SSN, with Informatica fuzzy matching for edge cases. Survivorship: Epic wins for clinical data, Meditech wins for administrative data not in Epic. Both legacy MRNs preserved as alternate identifiers on the surviving record for audit lineage. The MPI mapping table is the single source of truth for which records merged into which.

Q10: What is your storage strategy for 8% annual growth?

Three-tier strategy. Hot tier (active + 3 years) in Health Cloud standard objects. Warm tier (3-7 years) in Big Objects via async SOQL. Cold tier (7+ years) in external storage via Data Cloud for compliance retrieval. Annual archival job moves aging data between tiers. At 8% growth, hot tier gains ~100K patients and ~280K encounters per year; older data continuously moves to warm storage.

Q11: What is your rollback plan if migration goes wrong?

The parallel run IS the rollback mechanism. During months 9-11, both systems operate. All new data enters Health Cloud; Meditech stays read-only. If critical integrity issues surface, extend the parallel run and revert affected workflows to Meditech while remediating. Exit criteria: 30 consecutive days zero discrepancies, all users trained, all integrations stable. If not met by month 12, 4 months of buffer remain before vendor support ends at month 16.

Architecture and Governance Questions

Q12: Why not use Epic MyChart for the patient portal?

MyChart is excellent for clinical interactions but CareBridge needs a unified portal spanning clinical AND non-clinical: scheduling, bill pay, insurance verification, care plan tracking, referral status, RPM enrollment, consent management, and education. Building all of that in MyChart requires extensive Epic customization. Experience Cloud pulls clinical data from Epic via MuleSoft while providing native access to Health Cloud data and self-service capabilities.

Q13: How do you handle offline for home health nurses?

Three pieces. First, Kronos sync at 5 AM writes daily patient assignments; Apex trigger creates share records per nurse-patient. Second, offline briefcase pre-loads assigned patients’ records (demographics, care plan, visit history) on morning WiFi sync. Third, nurses document in offline mode; data syncs on connectivity return. Conflict resolution: last-write-wins for most fields; clinical documentation uses create-only (never overwritten, only appended).

Q14: How do you handle the union 90-day notice for home health mobile?

The 90-day notice must go out by month 10 for a month-13 go-live. It requires demonstrating that the technology does not negatively impact working conditions. I invite union reps to UAT during mobile testing, proactively address tracking/surveillance concerns (the app tracks visit documentation, not nurse location), and include union-negotiated training in the rollout. Factored into Phase 3 timeline.

Q15: If you had to cut scope, what would you defer?

I would defer Phase 4: RPM integration, external referral portal, DocuSign consent. RPM nurses have a functional Philips dashboard workflow today. External referrals use phone and fax — not ideal but functional. DocuSign can continue as standalone. What I would NOT cut: Meditech decommission (hard deadline), patient portal (security risk), Epic integration (core physician value). Phase 2 clinical core + Phase 3 portal are the minimum viable transformation.

Question Categorization

QuestionPrimary DomainSecondary Domain
Q1-Q4D2 SecurityD1 System Arch
Q5-Q8D5 IntegrationD1 System Arch
Q9-Q11D3 DataD6 Dev Lifecycle
Q12-Q13D4 Solution ArchD3 Data
Q14-Q15D6 Dev LifecycleD1 System Arch

Q&A Strategy

If asked a question you did not prepare for: pause, restate to confirm understanding, state what you know, and if uncertain say “I would need to validate this, but my approach would be…” Never bluff on clinical or compliance topics.