Case Study 2: CareBridge Health System - Worked Solution

Work in Progress

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

Reference Solution

This page compiles a worked answer for full-board study use. Compare the structure and trade-offs against your own attempt rather than treating it as the only acceptable design.

Solution Snapshot

Field	Detail
Open after	Scenario Paper
Difficulty	Advanced
Primary pressure areas	Security, Integration, Data, and Mobile
Study role	Worked solution and artifact reference
Core frameworks	9 Essential Artifacts + Five-Finger Method
Related pages	Case Study Overview, Presentation Notes, Q&A Preparation

Only Open After Your Own Attempt

If you have not yet worked through the scenario paper, stop here. Set a full 180-minute timer and build your own solution before reading this one.

Assumptions

1. Health Cloud licensing model. All 8,500 staff who touch patient workflows require Health Cloud Enterprise at ~$350/user/month list (Salesforce public pricing). Health Cloud Platform is not a real SKU: Care Plans, Care Teams, Health Timeline, and HealthcareProvider objects require a full CRM license plus the Health Cloud Permission Set License (PSL). To fit the $12M 24-month budget, internal Health Cloud usage is scoped to ~2,400 clinical users who actively manage care plans, referrals, and RPM: 1,200 physicians (not all 2,000 — many stay in Epic), 800 facility nurses involved in care coordination, 200 home health nurses, 100 care coordinators, 50 RPM nurses and clinical supervisors, 50 compliance and analytics power users. The remaining ~6,100 staff (Patient Access, Revenue Cycle, admin, IT not touching Health Cloud objects, and nurses who only chart in Epic) use standard Sales/Service Cloud or Platform licenses without Health Cloud PSL and see demographics, scheduling, and administrative data only. Service Cloud + custom objects was rejected for clinical users because Health Cloud provides care plan, care team, and timeline objects natively with BAA coverage.
2. Salesforce Shield. Req 8 mandates customer-managed encryption keys (Shield BYOK) and Req 9 mandates 7-year immutable audit trails (Field Audit Trail + Event Monitoring). EventLogFile retention is 30 days without Shield, extended to 1 year with Shield Event Monitoring. For 7-year HIPAA retention, Event Monitoring logs must be exported daily to external storage (MuleSoft to S3 or Snowflake) before they expire. The CCO’s 90-day access report runs as a CRM Analytics dashboard querying the externally archived log store via Salesforce Connect or a daily refresh to a reporting dataset.
3. Experience Cloud for patient portal. 400K users needing scheduling, messaging, results, bill pay. Customer Community (login-based) licenses at $2/login rather than Customer Community Plus ($6/login or $15/member/month), because patients only access their own records via sharing sets and do not need internal sharing model inheritance. At 400K users and ~18K DAU, login-based pricing is materially cheaper than member-based.
4. MuleSoft Anypoint. 5+ integration targets across FHIR R4, HL7v2, and REST protocols with HIPAA audit requirements on all data flows. Rejected point-to-point Apex callouts because the resulting technical debt is unmaintainable. MuleSoft Anypoint Platform and Anypoint MQ are covered by a separate MuleSoft BAA (distinct from the Salesforce Health Cloud BAA).
5. Salesforce Mobile with Mobile Offline for home health. Offline read/write on iPads using configurable offline record sets and offline data capture. Custom native app rejected due to timeline and budget constraints.
6. Disaster recovery (Req 7). Salesforce Hyperforce multi-AZ replication provides RPO = 0 for committed transactions and RTO = 4 hours per the public Salesforce Trust SLA for instance-level recovery. For regional failure, MuleSoft buffers outbound messages in Anypoint MQ (up to 14 days of persistence) and Epic remains independently available as the clinical continuity fallback — physicians can always chart directly in Epic without Health Cloud. Philips HealthSuite and Epic-native alert pathways remain independently operable.
7. Multilingual support (Req 21). Patient-facing content is delivered in English and Spanish via Translation Workbench for Experience Cloud labels, Knowledge articles with translated versions keyed on language code, and Flow/LWC screens using Custom Labels referenced via @salesforce/label/c.*. Patient language preference is stored on the Person Account (Preferred_Language__c) and sourced from Epic demographics. Education materials and post-discharge instructions are authored in English and Spanish by the clinical communications team, with version control on the Knowledge article.

Artifact 1: System Landscape

Figure 1. System landscape for CareBridge Health System showing Health Cloud as the clinical engagement platform, with MuleSoft handling Epic FHIR R4 bidirectional sync, HL7v2 MLLP lab results, Philips RPM polling, Kronos schedule sync, and DocuSign consent callbacks. Meditech and the legacy Java portal are being retired.

Artifact 2: Data Model

Figure 2. Health Cloud data model for CareBridge showing the 1.2M patient Person Account at the center, with LDV objects for RPM readings (5.5M/year) and referrals (4.5M migrated), and custom consent records supporting HIPAA-compliant patient authorization tracking. HealthcareProvider is the standard Health Cloud object for physician and external provider records.

Data Model Notes

• Person Accounts for patients with Health Cloud patient fields
• CarePlan / CareTeam / CareTeamMember / ClinicalEncounter / Referral are standard Health Cloud objects. HealthcareProvider is the standard object for provider identity
• RPM_Reading__c, RPM_Alert__c, RPM_Device__c, Consent_Record__c, Nurse_License__c are custom objects
• Health Timeline is a UI Lightning component reading from multiple objects, not a storage object
• Clinical notes from Epic are fetched on-demand via Salesforce Connect virtual FHIR adapter, NOT persisted in Salesforce (see Integration Architecture for the Epic decision: on-demand reads only — no FHIR Subscription push)
• Nurse_License__c (Req 12): per-state license records with expiration dates. Home health assignment logic reads the child records, not a multi-select picklist on User
• Entitlement + Milestone objects drive message response SLA tracking (Req 19); ERD includes them explicitly
• RPM_Device__c tracks device-to-patient assignment, firmware version, and device status for the $2.8M/year RPM CMS reimbursement program
• MPI mapping: implemented as MPI_Mapping__c custom object with lookup to the surviving Person Account and a multi-row history of legacy MRN values (Hospital A, Hospital B, Epic, Meditech)

Artifact 3: Role Hierarchy and Sharing Model

Figure 3. Role hierarchy for CareBridge showing department-based physician trees, unit-based nurse branches for hospital settings, and a geographic zone branch for home health nurses whose offline briefcase pre-loading depends on zone assignment. Portal users sit outside the internal hierarchy with separate identity.

OWD Settings:

Object	OWD	Rationale
Account (Patient)	Private	8 user types each see different patient populations
CarePlan (standard Health Cloud object)	Private	Standard Health Cloud CarePlan object (API v55.0+), not the legacy Case-based model. Apex-managed sharing on referral acceptance and care coordinator assignment
ClinicalEncounter	Private	Uses Lookup to Account, not Master-Detail. Criteria-based sharing rules by department and unit
Care Team	Controlled by Parent	Inherit from Account
Referral	Private	External providers see only their referrals
RPM Reading	Controlled by Parent	Inherit from Account
Consent Record	Controlled by Parent	Inherit from Account

Sharing mechanisms:

• Physicians: Criteria-based sharing rule per department (e.g., Department__c = 'Cardiology' to Public Group ‘Cardiologists’). Chiefs see all via role hierarchy.
• Specialists: Apex-managed sharing on Account triggered by the Referral lifecycle. When a Referral record transitions to Accepted, an Apex trigger inserts an AccountShare row (RowCause = Manual or a custom Apex sharing reason) granting the referred-to specialist Read/Write access to the patient Account and cascading Read access to child CarePlan and ClinicalEncounter records. On episode close (Status = Completed), the same trigger deletes the share row. This supports dynamic, event-driven access that criteria-based rules cannot model because no static field on the patient maps to current active referrals.
• Hospital nurses: Criteria-based sharing rule per unit (e.g., Current_Unit__c = 'ICU').
• Home health nurses: Apex-managed sharing driven by the daily Kronos schedule sync. At 5 AM, the Kronos integration delivers each nurse’s assigned patient list for the day. An Apex queueable deletes the prior day’s nurse-patient share rows and inserts new share rows for the current day’s assignments (one AccountShare row per nurse-patient pair, RowCause = HomeHealthDailyAssignment__c). This is per-patient assignment-level sharing, not zone-level, so nurses see only their specific assigned patients and the offline briefcase respects Req 26 (“assigned patients only”). Reassignments during the day trigger the same Apex logic synchronously on the updated schedule record.
• RPM nurses (team of 8): Criteria-based sharing rule RPM_Enrolled__c = true grants Read/Write to all 5,000 (growing to ~7,400) enrolled RPM patients. RPM_Reading and RPM_Alert records inherit via Controlled by Parent. The RPM team functions as a pooled resource across enrolled patients, so per-nurse assignment is not required.
• Care coordinators: Criteria-based sharing on Care_Program__c field.
• Patient Access: FLS restricts to demographics and scheduling fields; clinical fields hidden. Sharing rule grants Read on accounts with upcoming appointments at the user’s facility.
• Revenue Cycle: FLS restricts to encounter details and Dx codes; clinical notes hidden.
• External referral providers: Experience Cloud partner portal with sharing set scoped to their referrals only.
• VIP restriction: Apex-managed sharing cleanup pattern. Private OWD on Account provides no default access. All criteria-based sharing rules (Physician department, Hospital Nurse unit, Care Program) include an explicit exclusion clause (AND VIP_Flag__c = false) so they never create AccountShare rows for VIP patients in the first place. A VIP_Flag__c trigger runs on Account insert/update: when VIP_Flag = true is set, the trigger deletes all existing AccountShare rows where RowCause is Manual or an Apex sharing reason (criteria-based sharing rule rows cannot be deleted via Apex — they are system-managed), except for rows belonging to directly assigned CareTeamMember users. The trigger then re-evaluates the Care Team and inserts Apex-managed share rows only for users who have a direct CareTeamMember record. The combination of criteria exclusion clauses and Apex cleanup of manual/Apex-managed shares enforces least privilege. Users with the VIP_Override permission set (CCO delegates and break-glass access) receive an Apex-managed share row regardless. Every VIP share insert, delete, and break-glass access is logged to Shield Event Monitoring and replicated to the external audit archive for the 90-day CCO report. Restriction Rules are not supported on the Account standard object, so this Apex-managed pattern is the correct alternative.

Judge Signal

Judges will probe VIP access restriction, specialist dynamic access (referral-driven Apex-managed sharing on the standard Account object), and home health offline sync (how records pre-load before nurses go offline). Prepare to explain criteria-based sharing rules vs. Apex-managed sharing and when each applies. For VIP: be ready to explain why Restriction Rules cannot be used on Account (Restriction Rules support custom objects, external objects, Contracts, Events, Quotes, Tasks, Time Sheets, and Time Sheet Entries — not Account) and why the Apex-managed cleanup pattern enforces least privilege.

Sharing model performance (Req 58): With 1.2M Account records, 200 home health nurses averaging 15-20 daily assignments, and Apex-managed sharing triggered by Kronos sync plus referral lifecycle, the AccountShare table grows to millions of rows at projected 5-year volumes. Capacity planning artifact produced during UAT: (1) full-copy sandbox loaded with 5-year projected record counts (1.76M patients, 22M encounters cumulative), (2) sharing recalculation benchmarks run for representative user profiles, (3) home-health daily share rebuild measured against the 6 AM schedule-ready deadline, (4) VIP trigger impact measured at bulk update. Optimizations: bulk Database.insert/delete via Queueable chains, share row pruning for closed episodes, and quarterly AccountShare cleanup. If the daily rebuild approaches the schedule deadline, the fallback is to move home health to a territory-based model managed via Salesforce Territory Planning on the Health Cloud data model.

Artifact 4: Integration Architecture

Figure 4. Integration architecture for CareBridge showing all clinical data flows through MuleSoft into Salesforce Platform Events, with Change Data Capture pushing demographic updates outbound to Epic and the RPM alert engine triggering care team tasks on Philips threshold breaches.

Integration	Pattern	Protocol	Direction	Volume
Epic EHR	Request-Reply + Event-Driven	FHIR R4 / HTTPS (mTLS)	Bidirectional	3.5M encounters/yr
LabCorp/Quest	Event-Driven	HL7v2 via MLLP	Inbound	3,300 results/day
Philips RPM	Polling	REST / OAuth 2.0	Inbound	15,000 readings/day
Kronos	Batch	REST / OAuth 2.0	Inbound	200 schedules/day
DocuSign	Event-Driven (webhook)	REST / OAuth 2.0	Inbound	50,000 docs/year

Epic FHIR detail — on-demand virtualization, not persistence: CarePoint chooses a clean split between the data Salesforce masters and the data Epic serves. Outbound demographics changes flow via Change Data Capture / Pub/Sub API to MuleSoft, mapped to the FHIR Patient resource, and persist in Epic. Inbound clinical data (Encounter, Observation, MedicationRequest, DiagnosticReport, Condition) is not pushed into Salesforce and not persisted. The Health Timeline component calls Salesforce Connect external objects backed by a custom FHIR adapter; each component load issues a MuleSoft FHIR read against Epic, returns the resources for display only, and drops them from memory. This avoids the 3.5M encounters/year PHI duplication surface, keeps Epic as the uncontested clinical SOR, and eliminates reconciliation work during parallel run. The trade-off is a 1-3 second timeline load; Lightning spinner + progressive disclosure hides latency for the typical physician flow. If Epic is unreachable, the timeline displays “clinical data refresh pending” rather than stale cached content. Epic FHIR Subscriptions are not used — subscription push and on-demand read would create duplicate state. The HL7v2 Interconnect feed for critical lab value alerts still reaches clinicians through Epic directly (not through Salesforce), preserving clinical safety.

Lab integration path (LabCorp/Quest): LabCorp and Quest continue to deliver HL7v2 ORU messages to Epic Interconnect as their primary destination — Epic remains the clinical lab result system of record for critical value alerts. A dual-delivery arrangement routes a second copy of each HL7v2 message to MuleSoft’s MLLP listener at the Interconnect forwarding layer (configured at LabCorp/Quest or at the Interconnect proxy, per CareBridge’s existing commercial agreement with each lab). MuleSoft parses each ORU, matches the patient identifier against the Health Cloud MPI, and writes a lab result record via Platform Events. The 2% mismatch rate from the paper is routed to a manual reconciliation queue. If the MuleSoft listener fails, Epic continues to receive the feed independently and clinical workflow is unaffected; Health Cloud shows “lab results temporarily unavailable — view in Epic” until the feed recovers.

Change Data Capture backfill (beyond 72 hours): CDC and Platform Events retain messages for 72 hours per Salesforce documentation. If MuleSoft or Epic is unavailable longer than 72 hours, a scheduled reconciliation job runs nightly: Apex extracts demographic changes from Shield Field Audit Trail (or the Field History Tracking retention store, extended to 10 years with Shield) for the outage window, serializes them as FHIR Patient PUT operations, and replays them into MuleSoft’s inbound queue. The same job runs on Epic recovery, detecting missed window coverage from MuleSoft Anypoint Monitoring and triggering the replay automatically. Replay is idempotent — FHIR PUT is safe to retry.

RPM alert flow: MuleSoft polls Philips every 5 minutes, writes RPM_Reading records via Platform Events. Platform Events use at-least-once delivery semantics; subscribers handle duplicates via idempotent processing keyed on reading timestamp + device ID. If delivery fails, the subscriber throws EventBus.RetryableException to replay the event (up to platform retry limits). Apex trigger evaluates against patient thresholds; if breached, creates RPM_Alert, assigns task to care team, sends push notification.

Platform Event volume validation: The inbound Platform Event volume is ~28,200/day at year-one projection (3,300 lab results + 15,000 RPM readings + 200 Kronos schedules + ~9,600 CDC backfill and DocuSign events, minus the Epic on-demand reads which do not use Platform Events in the new design). Salesforce Health Cloud Enterprise includes 250K Platform Event delivery allocation per 24-hour period on top of the Enterprise Edition allowance, plus additional allocations per licensed user. Year-one volume consumes ~11% of allocation. To protect against burst load (e.g., lab batch backlog replay), MuleSoft throttles Platform Event publish to Salesforce and batches RPM readings where possible. Capacity planning monitors event publish count via the PlatformEventUsageMetric object; if sustained load exceeds 60% of allocation, the team purchases Event Delivery add-on SKUs or switches the high-volume RPM feed to Pub/Sub API with batched reads.

Message response SLA tracking: Patient portal messages use Entitlements and Milestones on the Case object. Urgent messages (flagged by patient or keyword detection) trigger a 4-hour milestone; routine messages trigger a 48-hour milestone. Milestone violations fire an escalation action assigning the message to a supervisor queue and sending a push notification to the assigned care team member. CRM Analytics tracks SLA compliance rates by department and provider.

Home health route optimization: Daily Kronos schedule data (patient addresses, appointment windows, estimated durations) feeds into Salesforce Maps for geographic route sequencing. Salesforce Maps calculates the optimal visit order minimizing drive time across the nurse’s assigned geographic coverage (~3,800 sq mi). The optimized route pushes to the nurse’s mobile device as part of the 5 AM schedule sync. Salesforce Maps is licensed for 200 home health nurses at $75/user/month list ($180K/year) and is included in the budget breakdown.

Referral auto-routing: Flow-based assignment rules evaluate referral reason, patient insurance network, patient home location (county), and provider availability. The flow checks provider specialty match, insurance panel membership, geographic proximity, and current referral backlog. If multiple providers qualify, the flow assigns to the provider with the lowest open-referral count. External referrals to community physicians route through the partner portal with automated status notifications. Referral priority (routine/urgent/emergent) sets differentiated SLA targets (routine: 2 days, urgent: 4 hours, emergent: immediate page to on-call specialist).

Multilingual patient content (Req 21): Translation Workbench provides English and Spanish translations for all Experience Cloud UI labels, email templates, and validation messages. Knowledge articles supporting patient education and post-discharge instructions are authored with a language code on each version; the portal surfaces the article that matches Preferred_Language__c on the Person Account (derived from Epic demographics during registration). Patient-facing Flow screens and LWCs reference Custom Labels via @salesforce/label/c.* so text flows through Translation Workbench. A bilingual clinical communications editor (contracted, month 3-18) validates translated content before publication.

Artifact 5: Identity and Access Management

• Employees (8,500): SAML 2.0 SSO with Entra ID. JIT provisioning creates/updates users on login. Department, role, and permission sets derived from Entra group membership. MFA enforced at Entra.
• Patients (400,000): Salesforce Customer Identity (External Identity license) with self-registration, email + password + MFA (SMS/authenticator). Customer Community (login-based) licenses at $2/login; patients access only their own records via sharing sets, so member-based pricing tiers are unnecessary and budget-prohibitive at this scale. Social login subject to HIPAA BAA review.
• External providers (390): Partner Community licenses, username + password + MFA. Sharing set limits view to their referral records only.
• Device management (Req 20): iPads enrolled in corporate MDM (Intune/Jamf). Salesforce Mobile deployed as managed app enabling selective container wipe. Offline data encrypted at rest.

Disaster recovery targets (Req 7):

Tier	Component	RPO	RTO
Tier 0 — Clinical continuity	Epic EHR (clinical SOR, independently operable)	0	0 (always available; Salesforce is the engagement layer, not clinical continuity)
Tier 1 — Transactional Health Cloud data	Patients, Care Plans, Referrals, Encounters, RPM Readings	0 (multi-AZ synchronous replication on Hyperforce)	4 hours (Salesforce Trust SLA for instance-level recovery)
Tier 1 — Integration middleware	MuleSoft Anypoint Runtime Fabric	0 (MQ persistence)	4 hours
Tier 2 — Warm-tier historical records	Archived standard objects for 3-7 year history (Privacy Center archive + Salesforce Backup)	24 hours	24 hours (backed by Salesforce Backup)
Tier 2 — Cold-tier archive	Data 360 + external storage for 7+ year retention	24 hours	48 hours
Tier 3 — Analytics	CRM Analytics datasets	24 hours	24 hours (rebuildable from source)

Regional failure fallback: MuleSoft Anypoint MQ persists outbound messages up to 14 days; Epic remains independently available so care teams can always chart in Epic directly. Philips-native alert pathways remain independently operable. Annual DR drill validates the restore procedure against each tier.

Artifact 6: Data Migration Strategy

Source: Meditech - 850K patients, 2.1M encounters, 4.5M referrals.

Phase 1 - Profiling and cleansing (Months 1-4): Extract via flat-file exports. Profile with Informatica Cloud Data Quality. Dedup strategy: composite key (Last Name + DOB + Gender + Last 4 SSN) with fuzzy matching. Survivorship: Epic wins for clinical data, Meditech wins for administrative data not in Epic. Create Master Patient Index mapping table; legacy MRNs preserved as alternate identifiers.

Phase 2 - Historical load (Months 5-8):

Tier	Records	Target	Access	PHI Controls
Hot (Active + 3 years)	400K patients, 1.2M encounters	Health Cloud standard objects	Immediate SOQL	Shield Platform Encryption (deterministic + probabilistic), FLS, sharing model
Warm (3-7 years)	300K patients, 600K encounters	Archived standard objects (Privacy Center archive) or Salesforce Backup + Data 360	Rehydration to hot tier on demand	Shield Platform Encryption, FLS, sharing rules — Big Objects were considered and rejected because custom Big Objects do not support Shield Platform Encryption, sharing rules, or triggers, which breaks PHI least-privilege for Req 10
Cold (7+ years)	150K patients, 300K encounters	External lake (S3 + Salesforce Connect OData) with Data 360 federation	Compliance retrieval only	External storage encrypted at rest (AWS KMS), separate BAA with AWS, read-only access via CCO delegate

Load sequence: Accounts (Patients) -> HealthcareProvider -> Care Plans -> ClinicalEncounter -> Referrals. Hot tier via Bulk API 2.0. Validation: record count reconciliation, referential integrity checks, 500-record clinical SME spot-check.

Warm-to-hot rehydration (Req 44): When a previously archived patient is readmitted, an Apex Queueable triggered by new encounter creation pulls the archived records from Salesforce Backup (or the Data 360 federated dataset) back into the standard object layer for active use. Target rehydration latency: under 30 seconds for the patient’s demographic and active problem list, under 5 minutes for full historical encounters. A Rehydration_Status__c field tracks in-progress, completed, and failed rehydration events for audit.

Demographics mastering (Salesforce as SoR): Salesforce Health Cloud becomes the system of record for patient demographics and insurance after the Meditech decommission — a deliberate architectural choice that requires defense. Epic remains the clinical SoR. The rationale: (1) Meditech was historically the demographics SoR and is being retired; Epic’s registration module is used inconsistently across CareBridge facilities with known data quality gaps, so moving the master to Epic would inherit the same problems in a more expensive system. (2) Patient portal self-service registration and updates need a writable CRM-grade system with sharing, auditing, and workflow — Epic’s registration module does not expose this surface. (3) The unified patient view (Req 1) and Master Patient Index (Req 39) both live in Salesforce. The stewardship model: VP Patient Access owns demographic data quality, a weekly stewardship queue surfaces conflicts between Epic inbound and Health Cloud master, and a defined conflict resolution matrix (most recent update wins for portal self-service fields; registrar-keyed updates win for insurance) governs merges. MPI cleanup runs monthly via Informatica CDQ against the Hospital A/Hospital B/Epic/Meditech legacy identifier set.

Storage capacity planning:

• File storage for consent PDFs (Req 13): 50K signed PDFs per year, 10-11 year retention per state mandate yields ~550K files at steady state. Assuming ~1MB per signed consent PDF (including PKI envelope), total file footprint is ~550GB. Health Cloud Enterprise’s base file storage (10GB org + 2GB per full CRM user × ~2,400 Health Cloud users) provides ~4.8TB, which accommodates consent PDFs with headroom. As a hedge, consent PDFs older than 3 years are archived to S3 via Files Connect / Content Version archive policy (paid Salesforce Files Archive SKU), with the in-org record retaining only metadata and a signed URL back to S3.
• Data storage for historical records: Hot tier standard objects at 5-year projection (~1.76M patients, 22M encounters, 35M cumulative RPM readings) are sized against Health Cloud Enterprise data storage (standard allocation + per-user increments). Monitoring via the Storage Usage page; archive policies trigger warm-tier moves when any object approaches 80% of its allocation.

Phase 3 - Parallel run (Months 9-11): Both systems operate; new data in Health Cloud. Meditech is placed in controlled read-only mode via database user role changes and a backup of the writable schema is retained. Daily automated reconciliation. Exit criteria: 30 days zero critical discrepancies, all users trained, all integrations live. Reversible rollback procedure: if critical integrity issues surface during parallel run, the team restores Meditech writable access (documented DBA runbook, tested in a staging instance before go-live), reverses the MuleSoft outbound sync direction so Health Cloud changes push back into Meditech via a reverse-sync flow (built during Phase 1 but held inactive), and routes affected workflows back to Meditech until remediation. The reverse-sync flow is exercised at least twice during Phase 3 to prove it works. If remediation is not complete by month 12, up to 4 months of buffer remain before vendor support ends at month 16.

Phase 4 - Decommission (Months 12-14): Final extract, Meditech powered down, database backup retained 7 years. Completes month 14 - 2 months before vendor deadline.

Artifact 7: Governance Framework

Data Domain	Owner	System of Record
Clinical encounters, orders, meds	CMO	Epic
Patient demographics, insurance	VP Patient Access	Health Cloud
Care plans, care teams	CNO	Health Cloud
Referrals	CMO + CNO (joint)	Health Cloud
RPM vitals	Director RPM	Philips (raw) / Health Cloud (alerts)
Compliance and audit	CCO	Salesforce Shield

• CAB: CIO (chair), CMO rep, CNO rep, CCO rep, IT Director, 2 clinical SMEs. Biweekly during implementation, monthly post-go-live.
• Change classification: Emergency (<4hr), Standard (CAB approval), Major (CAB + executive sign-off)
• Clinical impact assessment required for every change affecting clinical workflows (CMO sign-off)
• Release cadence: 2-week sprints during implementation; monthly post-go-live with full regression, clinical UAT, CCO compliance review, 48-hour hypercare

Artifact 8: Environment Strategy

Environment	Purpose	Refresh
Production	Live system	N/A
Full Sandbox	Staging / UAT	Monthly
Partial Sandbox	Training (Data Mask applied)	Quarterly
Partial Sandbox	Integration testing	Bi-weekly
Developer Pro (x4)	Feature development	On-demand
Developer Pro (x1)	Hotfix / emergency	On-demand

CI/CD: Git (GitHub) with branch protection. Salesforce CLI via GitHub Actions. Pipeline: feature branch -> dev sandbox -> PR review -> integration sandbox -> Full sandbox (UAT) -> production. 80% Apex test coverage enforced.

PHI in non-production — pre-mask window controls: Full Copy sandboxes contain full production data from the moment of refresh until Data Mask completes; masking is a post-refresh process, not a pre-copy filter. During this window, the sandbox holds real PHI and must be treated as production-equivalent. CareBridge controls the window explicitly: (1) Full Copy refresh runs overnight outside business hours, (2) a gated automation triggers Data Mask immediately after refresh completes, (3) the sandbox login is restricted to an “SF Refresh Operator” profile (2 named admins) until masking completes and a verification script passes, (4) all access during the refresh window is logged to Shield Event Monitoring and reviewed by the CCO delegate, (5) the full-copy sandbox Access is revoked for all other user profiles via IP restriction at the org level during the window, and (6) if Data Mask fails or verification does not pass, the sandbox is deleted immediately and rebuilt. Training uses Partial Copy only (never Full Copy for trainer access). The BAA with Salesforce covers production and sandboxes equally, but operational controls enforce least-privilege during the pre-mask window.

Artifact 9: Phased Delivery Roadmap

Figure 5. 24-month delivery roadmap for CareBridge with Meditech decommission as the critical path, requiring two months of buffer before the vendor end-of-support deadline. The portal and home health mobile phases are sequenced after core clinical workflows are stable, reducing risk to 400,000 patient users.

Sequencing rationale: Phase 1 is foundational (cannot integrate without the platform). Phase 2 delivers clinical value first (physicians are hardest to win over). Phase 3 addresses highest-risk external-facing component (400K-user portal). Phase 4 handles advanced capabilities building on the core. Meditech decommission has 2 months of buffer before vendor end-of-support.

Phase	Go-Live Gate
Phase 1	Shield encryption verified, SSO working, data model validated
Phase 2	Epic integration stable 14 days, sharing model UAT passed by CCO, hot-tier migration validated
Phase 3	Portal load-tested to 50K concurrent, offline sync field-validated, 99.9% uptime for 30 days
Phase 4	RPM alerts validated by Dr. Patel, referral SLA tracking confirmed, external provider UAT

Identity & SSO Flow

Figure 6. Identity and SSO flow for CareBridge showing four independent authentication paths: Entra ID SAML with department and zone-based JIT provisioning for staff, separate Experience Cloud identity for patients, Partner Community credentials for external referral providers, and OAuth 2.0 for integration users. No authentication path overlaps between populations.

Identity architecture rationale:

• Entra ID SAML 2.0 for all 8,500 employees. JIT provisioning maps Entra group membership (department, clinical unit, geographic zone) to Salesforce Permission Set Groups. Physicians receive department-specific access on login; nurses receive unit- or zone-based access. Home health nurses’ Entra groups include geographic zone assignment, which JIT maps to the correct permission set for offline briefcase pre-loading. 8-hour session timeout for desktop; 4-hour for mobile (iPad).
• Patient portal (Salesforce Customer Identity with External Identity license) with self-registration, email + password + MFA. Customer Community (login-based) licenses at $2/login; patients only view their own records via sharing sets, so member-based pricing tiers (e.g., $6/login or $15/member for Customer Community Plus) are unnecessary. Social login (Google, Apple) subject to HIPAA BAA review — initially disabled, evaluated in Phase 3 after legal review. 400,000 existing credentials from the legacy Java portal require a migration strategy: bulk import hashed credentials with forced password reset on first portal login via a custom self-service flow.
• External provider portal using Partner Community licenses with username + password + MFA. Each external provider sees only referrals where they are the referring or referred-to provider (sharing set scoped via provider Contact lookup). 350 community physicians + 40 specialty practices = ~390 portal users. No access to full patient records - referral status and basic demographics only.
• System-to-system authentication via OAuth 2.0 Client Credentials. Because Connected App creation is disabled by default starting in Spring ‘26, each integration target (Epic, LabCorp/Quest, Philips, Kronos, DocuSign) is created as its own External Client App with scoped permissions. The outbound policy on each ECA limits API scope and integration user profile. Named Credentials on the Salesforce side manage token lifecycle for outbound callouts; MuleSoft’s OAuth 2.0 client manages tokens for inbound calls. No shared or interactive service accounts. The HIPAA Security Rule requires unique identification for all system access, and the audit trail must trace every API call to a specific integration context.
• iPad device management (Req 20): iPads enrolled in corporate MDM (Intune or Jamf). Salesforce Mobile deployed as a managed app with selective container wipe capability. Offline data encrypted at rest on device. If device reported lost/stolen, MDM triggers remote wipe within 15 minutes. MFA re-required after any offline period exceeding 8 hours.

BAA coverage scope (Req 34 and HIPAA implicit callout): CareBridge executes Business Associate Agreements with every vendor that stores, processes, or transmits PHI. The BAA inventory is maintained as a governance artifact and reviewed annually:

Vendor	Product / Service	PHI Scope	BAA Required
Salesforce	Health Cloud + Shield + Hyperforce + Experience Cloud	Production and sandbox PHI	Yes — Salesforce Healthcare BAA
MuleSoft (Salesforce)	Anypoint Platform + Anypoint MQ + Anypoint Monitoring	Integration payloads, DLQ messages, logs containing patient IDs	Yes — separate MuleSoft BAA
Informatica	Cloud Data Quality (migration only, months 1-8)	Meditech extract including demographics	Yes — Informatica BAA
DocuSign	eSignature + webhook delivery	Signed consent forms and envelope metadata	Yes — DocuSign BAA
Philips	HealthSuite RPM platform + Philips-native alerts	Device readings, patient identifiers	Yes — Philips BAA
AWS (for external archive)	S3 + KMS for 7+ year cold tier and EventLogFile archive	Long-term audit logs and archived records	Yes — AWS HIPAA BAA

LabCorp, Quest, Epic, Kronos, and Entra ID are existing vendor relationships with BAA coverage already in place under CareBridge’s pre-existing agreements. The integration design does not introduce any new PHI handler outside this list. PHI flowing into MuleSoft’s Anypoint MQ DLQ is explicitly covered under the MuleSoft BAA, as is the structured logging that records patient IDs with payload hashes (never full payloads) for integration trace.

Integration Error Handling

Error handling for each integration is tailored to clinical urgency, HIPAA compliance requirements, and data volume.

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring & Alerts	Fallback (Extended Outage)
Epic EHR (FHIR R4: outbound demographics + on-demand clinical read)	Request-Reply + Event-Driven for outbound; Request-Reply on-demand for inbound clinical display	Outbound demographics: exponential backoff (30s, 2m, 10m), max 5 retries; messages beyond 72-hour CDC retention are replayed nightly from Shield Field Audit Trail. Inbound clinical: on-demand read timeout at 5 seconds, graceful timeline degradation if Epic unavailable	Anypoint MQ DLQ for failed demographic updates. Correlation ID links SF record to Epic FHIR resource ID	MuleSoft Anypoint Monitoring: sync lag dashboard, error rate by resource type. PagerDuty alert if outbound sync gap >30 min or on-demand read p95 latency exceeds 5 seconds	Demographics: Health Cloud is authoritative — Epic shows stale until sync restores. Clinical: physicians use Epic directly (always available); Health Timeline shows “clinical data refresh pending” banner. No patient care impact — Epic is the clinical SOR
LabCorp / Quest (HL7v2 MLLP)	Event-Driven (dual delivery to Epic Interconnect primary and MuleSoft listener)	MuleSoft MLLP adapter retries connection 3x at 1-min intervals on socket failure. Message-level: ACK/NAK per HL7 spec — NAK triggers retry up to 3x. Kronos licensure validation produces exception records and supervisor tasks rather than hard-rejecting schedule messages	Failed messages written to DLQ with HL7 segment detail. 2% patient ID mismatches routed to reconciliation queue for manual resolution	Dashboard: results received vs. expected (baseline ~3,300/day). Alert if volume drops >20% from rolling average. Alert on reconciliation queue depth >50	Epic Interconnect is the primary destination and continues uninterrupted during any MuleSoft outage. Health Cloud shows “lab results temporarily unavailable — view in Epic” until dual delivery resumes. Critical value alerts are already Epic-native (no disruption)
Philips RPM (polling 5-min)	Polling	MuleSoft polls Philips REST API every 5 min. On poll failure: retry 3x at 1-min intervals. On throttle (429): respect Retry-After header (1,000 req/min rate limit)	Failed readings written to DLQ with patient ID and reading type. Alert thresholds require readings to be present - DLQ entries trigger “stale reading” alert to RPM nurse team	Dashboard: readings received per 5-min window vs. expected (~50/window). Alert if reading volume drops >30%. Alert if any patient has no readings for >30 min (device or connectivity issue)	RPM nurses revert to Philips dashboard directly (always available). Salesforce RPM_Alert records paused - no false alerts generated from missing data. Catch-up load runs on restoration to backfill missed readings
Kronos WFM (daily batch)	Batch	MuleSoft retrieves schedules via REST API. Retry 3x at 15-min intervals if Kronos unavailable at 5 AM sync. Record-level: failed schedule records logged individually	DLQ for individual schedule records that fail validation (invalid patient ID, missing address). Ops team reviews before nurse dispatch	Alert if schedule sync not complete by 6:30 AM (nurses need schedules by 7 AM). Alert on DLQ depth >10 records. Dashboard: schedule count vs. expected (~200/day)	Home health nurses use prior-day schedule as fallback (most visits are recurring). Dispatchers manually pull Kronos schedule and communicate via phone/SMS to affected nurses. Offline briefcase uses last-synced patient list
DocuSign (webhook)	Event-driven	DocuSign retries webhook delivery per their policy (up to 24 hours). MuleSoft acknowledges idempotently. On processing failure: retry 3x from DocuSign status API	Failed consent linkages written to DLQ with envelope ID, patient ID, and document type. Compliance team reviews weekly	Alert if >5 unsigned consent forms pending >72 hours (state-mandated consent timelines). Dashboard: consent completion rates by type and facility	Consent forms can be printed and wet-signed as fallback (paper process). Scanned copies uploaded manually to patient record. Electronic signing resumes on restoration

Clinical Safety Note

For all integrations, the design ensures that no integration failure prevents clinical care delivery. Epic is the clinical system of record and remains independently accessible. All Salesforce integration failures result in “data temporarily unavailable” states, never in incorrect or misleading clinical information. RPM alerts pause rather than generate false alerts from missing data.

Governance & DevOps

Environment Topology

Figure 7. Environment topology for CareBridge with five developer sandboxes progressing through integration testing and full-copy UAT, with a combined CAB approval, clinical impact assessment, and CCO sign-off gate that must clear before each production deployment.

Branching Strategy

Adapted for a healthcare environment where changes affect clinical workflows and patient safety:

• main: mirrors production. Only release manager deploys after CAB approval. Protected branch with required reviews.
• develop: integration branch. Feature branches merge here via PR. Auto-deploys to Integration Testing (Partial Copy) on merge.
• feature/* - one branch per work item. Developer validates in Developer Pro sandbox before PR. Minimum 80% Apex test coverage enforced at PR gate.
• release/* - cut from develop for UAT cycle. Deployed to Full Copy sandbox. Bug fixes only after release branch is cut. Clinical impact assessment required for any change affecting clinical workflows.
• hotfix/* - emergency path from main. Requires CIO + IT Director approval. Must include rollback plan. Merged to main and develop. 48-hour post-hoc CAB review.

Sandbox Strategy

Sandbox	Type	Purpose	Data	Refresh
DEV 1-4	Developer Pro (x4)	Feature development by team	Metadata only - no PHI	On-demand
HOTFIX	Developer Pro (x1)	Emergency fixes	Metadata only	On-demand
Integration Test	Partial Copy	MuleSoft end-to-end testing, Epic FHIR staging	Masked PHI (Data Mask applied)	Bi-weekly
Training	Partial Copy	Role-specific training per phase go-live	Masked PHI (Data Mask applied) with synthetic patient scenarios	Quarterly
UAT / Staging	Full Copy	Compliance review, performance testing, load testing	Full production clone with Data Mask applied post-refresh	Monthly

HIPAA data masking (mandatory for all non-production):

• Salesforce Data Mask applied immediately after every sandbox refresh. Full Copy refreshes are gated behind a pre-mask access window controlled by IP restriction and the “SF Refresh Operator” profile (2 named admins only); the sandbox is not released to the broader team until Data Mask completes and a verification script confirms no PHI remains in the masked fields
• Masked fields: patient name, DOB, SSN, MRN, address, phone, email, insurance ID, diagnoses, medication names
• Training environment uses synthetic patient data sets validated by clinical SMEs — never real PHI
• BAA with Salesforce covers production and all sandboxes (Full Copy included), so the pre-mask window is a control layer on top of BAA coverage, not a substitute
• Developer Pro sandboxes contain metadata only (no data copied) — HIPAA safe by design
• Sandbox access during refresh windows is logged to Shield Event Monitoring and reviewed weekly by the CCO delegate

Testing Strategy

Test Type	Target	Environment	Gate
Unit tests (Apex)	>= 80% coverage (Salesforce standard)	Developer sandbox	PR merge to develop
Integration tests	MuleSoft + Salesforce + external system stubs (Epic FHIR, HL7v2, RPM, Kronos, DocuSign)	Integration Test (Partial Copy)	Sprint completion
Regression tests	Full test suite: sharing model, VIP restriction, department-based access, referral-driven sharing	Integration Test	Release branch cut
Performance tests	2,200 concurrent internal users, nightly processing (3,300 lab results + 15K RPM readings), portal 5,000 concurrent	UAT (Full Copy)	Release to production
Security / compliance UAT	VIP access restriction, department-based physician access, home health nurse zone isolation, external provider referral scoping, audit trail completeness	UAT with CCO + clinical SMEs	CCO sign-off
Clinical UAT	Care plan workflows, referral lifecycle, RPM alerting, Epic data display, offline home health visit documentation	UAT with physicians, nurses, care coordinators	CMO/CNO sign-off
Offline sync testing	Home health iPad: load patient list, go offline, document visits, restore connectivity, verify sync	Field testing with 3-5 nurses in controlled environment	CNO sign-off

Clinical impact assessment (required for every production change):

• Any change affecting clinical workflows requires CMO delegate sign-off before production promotion
• Assessment form: what clinical workflows are affected, what is the risk of patient care disruption, what is the rollback plan, has the change been validated by clinical SMEs
• Changes during December freeze (last 2 weeks + first week January) require CIO + CMO emergency approval

CoE & Ongoing Governance

Internal team (8 FTEs + clinical SMEs):

Role	Count	Responsibility
IT Director (CoE Lead)	1	Release management, CAB coordination, vendor oversight
Salesforce Administrators	2	Configuration, user management, declarative automation
Salesforce Developers	2	Apex, LWC, integration development, code review
Integration Specialist	1	MuleSoft development, HL7v2/FHIR mapping, Epic interface
Data Migration Specialist	1	Meditech extraction, dedup, load, validation
Clinical SMEs (part-time)	4	Requirements validation, UAT, workflow sign-off (physician, nurse, coordinator, patient access)

Legacy portal team transition: 3 Java developers retrained into Salesforce roles. Training plan: Trailhead fundamentals (months 1-2), shadowing existing SF admins (months 3-4), hands-on portal development in DEV-3 sandbox (months 5+). Target: 2 developers productive on Experience Cloud by month 6, 1 as LWC specialist by month 9.

CAB (Change Advisory Board):

• Composition: CIO (chair), CMO representative, CNO representative, CCO representative, IT Director, 2 clinical SMEs
• During implementation: biweekly meetings reviewing upcoming sprint deployments
• Post-go-live: monthly CAB with full regression and clinical UAT before every release
• Emergency changes: CIO + IT Director can approve with mandatory 48-hour post-hoc CAB review

Release cadence:

• During implementation: 2-week sprints; production deployments every 4 weeks after clinical UAT
• Post-go-live: Monthly releases with full regression. 48-hour hypercare after each deployment with on-call clinical liaison
• Change freeze: Last 2 weeks of December + first week of January (per constraint). Also frozen 48 hours before and after any Joint Commission survey notification
• Union notice: 90-day advance notice before any change affecting daily nursing workflows (home health). Phase 3 mobile rollout triggers this notice

Ongoing operations:

• MuleSoft Anypoint Monitoring for integration health - alerting on Epic FHIR sync lag, lab result volumes, RPM reading rates
• Shield Event Monitoring reviewed weekly by CCO delegate for inappropriate patient record access
• Quarterly platform health: storage trending, API consumption, sharing model performance
• Annual security assessment: HIPAA Security Rule compliance review, BAA renewals, penetration testing

Reporting Approach

CRM Analytics delivers clinical dashboards (care plan adherence, readmission rates, referral turnaround against 2-day SLA, RPM alert response times), compliance dashboards (VIP access audits from Shield Event Monitoring, consent completion rates, nurse license expiration alerts), and operational dashboards (portal usage, home health visit completion from Kronos sync, integration health from MuleSoft Anypoint Monitoring). RPM CMS billing reports (CPT 99453/99454/99457/99458) pull precise time-tracking data from RPM_Reading and Care_Plan_Task objects for accurate reimbursement documentation. CRM Analytics for Health Cloud is priced separately at ~$165/user/month and is licensed for the ~80 analytics power users in the CoE and compliance team, not the full Health Cloud user base.

Budget Model

$12M over 24 months must cover licensing, implementation, migration, integration build, training, and 12 months of managed support. The breakdown uses Salesforce public list pricing as the anchor; real-world negotiated discounts typically reduce Salesforce SKUs by 15-30% for enterprise healthcare deals, and the plan assumes a 20% enterprise discount on Salesforce line items.

Category	Sizing	List Price	Discounted 24-month Cost
Health Cloud Enterprise (scoped clinical users)	~2,400 users (see Assumption 1)	$350/user/month	~$16.1M at list; ~$12.9M at 20% discount — reduced further by ramping users across 24 months (Phase 2+). Net 24-month cost after ramped deployment: ~$4.2M
Sales/Service Cloud + Platform licenses (non-clinical)	~6,100 users (Patient Access, Revenue Cycle, admin, IT)	~$165/user/month blended	~$3.2M at 20% discount over 24 months, ramped. Net 24-month cost: ~$1.6M
Shield (Platform Encryption + FAT + Event Monitoring)	Org-wide	~20% uplift on Health Cloud + Platform	~$0.6M
Customer Community (login-based)	400K users, ~18K DAU	$2/login/month	~$18K × 24 = $432K. Net 24-month cost: ~$0.43M
Partner Community	390 external providers	~$25/member/month	~$0.23M over 24 months
CRM Analytics for Health Cloud	~80 power users	$165/user/month	~$0.32M over 24 months
Data 360 (federated cold tier)	Base + connector	~Base $108K/year + connector	~$0.25M over 24 months
Salesforce Maps (Req 19 route optimization)	200 home health nurses	$75/user/month	~$0.36M over 24 months
MuleSoft Anypoint (5 connectors, runtime, MQ, Monitoring)	Enterprise tier	—	~$1.2M over 24 months
Implementation partner (SI)	24 months, blended rate	—	~$2.2M
Informatica Cloud Data Quality (migration only)	Months 1-8	—	~$0.25M
Training (Trailhead Academy + clinical UAT)	Role-specific across phases	—	~$0.2M
Managed support (months 13-24)	Internal + vendor blend	—	~$0.35M
Contingency	—	—	~$0.15M
Total	—	—	~$12.1M — fits within $12M budget with minor contingency risk

The budget is aggressive but fits because Health Cloud Enterprise is scoped to the ~2,400 clinicians who actively manage care plans, referrals, and RPM — not the full 8,500 headcount. Staff who only need demographics, scheduling, or revenue-cycle data use standard Sales/Service Cloud or Platform licenses. The alternative of giving all 8,500 staff full Health Cloud Enterprise at ~$30M list ($24M at 20% discount) would break the budget by ~2.5× and is explicitly rejected. Customer Community login-based pricing (not member-based) is the single largest leverage point for the 400K patient portal at $2/login vs. $6/login or higher for member tiers.

Scoring Rubric

Criterion	Weight	What Judges Look For
Security & HIPAA Compliance	25%	HIPAA mapped to specific controls (Shield encryption, BAA, data masking, Event Monitoring). VIP patient restriction. Consent management workflow. PHI handling across all integration points. 7-year audit trail retention
Integration Architecture	25%	Epic EHR integration via FHIR R4 (not generic “API”). Lab system HL7 integration. RPM IoT data handling. Home health mobile sync. Each endpoint with specific pattern, protocol, volume, and error handling. MuleSoft justification for multi-system landscape
Data Architecture	20%	Patient data model across hospital, clinic, and home health. EHR data residency (Epic stays SoR for clinical data). RPM data volumes and storage strategy. Migration plan for legacy systems. LDV handling for historical records
System Architecture	15%	Health Cloud justification. Multi-facility org strategy. Patient portal via Experience Cloud. Home health mobile with offline capability. Licensing across facility types and user populations
Communication & Presentation	15%	Boardroom-ready diagrams. Clear defense of key decisions. Phased delivery aligned to clinical priorities. Stakeholder concerns addressed (CNO, CMO, CCO each have different priorities)

---

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.