Case Study 02: CareBridge Health System (Solution)

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.

Solution Context

Heavy domains: D1 System Arch, D2 Security, D3 Data, D5 Integration | Difficulty: Advanced Time budget: 180 minutes | Key frameworks: 9 Essential Artifacts, Five-Finger Method

Attempt the Scenario First

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

Assumptions

1. Health Cloud — care plans, care teams, health timelines, and HIPAA requirements map directly to Health Cloud’s standard data model. Rejected Service Cloud + custom objects because Health Cloud provides these out of the box with BAA coverage.
2. Salesforce Shield — Req 6 mandates customer-managed encryption keys (Shield BYOK) and Req 7 mandates 7-year immutable audit trails (Field Audit Trail + Event Monitoring).
3. Experience Cloud for patient portal — 400K users needing scheduling, messaging, results, bill pay. Inherits Salesforce sharing model, supports Customer Community Plus licensing.
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 due to unmaintainable technical debt.
5. Salesforce Mobile with Mobile Offline for home health — offline read/write on iPads using configurable offline record sets and offline data capture. Rejected custom native app due to timeline and budget constraints.

Artifact 1: System Landscape

graph TB
    subgraph Legend["Legend"]
        L1["🟢 NEW system"]
        L2["⚪ KEEPING as-is"]
        L3["🔴 RETIRING"]
        L4["🟠 INTEGRATION LAYER"]
    end

    subgraph SF["Salesforce Health Cloud"]
        HC[Health Cloud<br/>Patients · Care Plans<br/>Care Teams · Referrals]
        Shield[Shield<br/>BYOK + FAT + Event Mon]
        EC[Experience Cloud<br/>Patient Portal 400K]
        Mobile[Mobile Offline<br/>Home Health iPads]
        Analytics[CRM Analytics]
        Flows[Flow + Apex<br/>RPM Alert Engine]
    end

    subgraph MW["MuleSoft Anypoint"]
        API_GW[API Gateway — mTLS + OAuth]
        FHIR[FHIR R4 Connector]
        HL7[HL7v2 MLLP Adapter]
        REST[REST Connectors]
        DLQ[Error Hospital + DLQ]
    end

    subgraph Clinical["Clinical Systems"]
        Epic[Epic EHR]
        Labs[LabCorp + Quest]
    end

    subgraph Ops["Operational Systems"]
        Kronos[Kronos WFM]
        DocuSign[DocuSign]
        Philips[Philips RPM]
    end

    subgraph ID["Identity"]
        Entra[Entra ID]
        PatAuth[EC Identity]
    end

    subgraph RET["Retiring"]
        Meditech[Meditech EHR]
    end

    HC <-->|"REST / Bulk API"| API_GW
    API_GW <--> FHIR
    FHIR <-->|"FHIR R4 mTLS — 3.5M encounters/yr"| Epic
    API_GW <--> HL7
    HL7 <-->|"HL7v2 MLLP — 3,300 results/day"| Labs
    API_GW <--> REST
    REST -->|"REST batch daily — 200 schedules"| Kronos
    REST <-->|"REST webhook — 50K docs/yr"| DocuSign
    REST -->|"REST polling 5-min — 15K readings/day"| Philips
    Entra -->|"SAML 2.0 SSO + JIT"| HC
    PatAuth -->|"MFA + self-registration"| EC
    Meditech -.->|"Flat file extract via Informatica CDQ"| HC

    classDef newSystem fill:#d4edda,stroke:#28a745,color:#000
    classDef keepSystem fill:#f8f9fa,stroke:#6c757d,color:#000
    classDef retireSystem fill:#f8d7da,stroke:#dc3545,color:#000,stroke-dasharray:5 5
    classDef integrationLayer fill:#fff3cd,stroke:#fd7e14,color:#000
    classDef sfSystem fill:#cce5ff,stroke:#0d6efd,color:#000

    class SF,HC,Shield,EC,Mobile,Analytics,Flows sfSystem
    class MW,API_GW,FHIR,HL7,REST,DLQ integrationLayer
    class Epic,Labs keepSystem
    class Kronos,DocuSign,Philips keepSystem
    class Entra,PatAuth keepSystem
    class Meditech retireSystem
    class L1 newSystem
    class L2 keepSystem
    class L3 retireSystem
    class L4 integrationLayer

Artifact 2: Data Model

erDiagram
    ACCOUNT_PATIENT ||--o{ CARE_PLAN : has
    ACCOUNT_PATIENT ||--o{ CARE_TEAM : assigned
    ACCOUNT_PATIENT ||--o{ ENCOUNTER : participates_in
    ACCOUNT_PATIENT ||--o{ REFERRAL : subject_of
    ACCOUNT_PATIENT ||--o{ RPM_READING__C : generates
    ACCOUNT_PATIENT ||--o{ CONSENT_RECORD__C : signs
    CARE_PLAN ||--o{ CARE_PLAN_GOAL : includes
    CARE_PLAN ||--o{ CARE_PLAN_TASK : contains
    CARE_PLAN }o--|| CARE_TEAM : managed_by
    CARE_TEAM ||--o{ CARE_TEAM_MEMBER : comprises
    CARE_TEAM_MEMBER }o--|| CONTACT_PROVIDER : is_a
    REFERRAL }o--|| CONTACT_PROVIDER : referred_by
    REFERRAL }o--|| CONTACT_PROVIDER : referred_to
    RPM_READING__C }o--|| RPM_DEVICE__C : from_device
    RPM_READING__C ||--o{ RPM_ALERT__C : triggers

    ACCOUNT_PATIENT {
        string MRN "Master Patient Index"
        boolean VIP_Flag "Restriction Trigger"
        string Home_State "NC or SC"
    }
    CARE_PLAN {
        string Status "Active / Completed"
        string Owning_Department "Access Routing"
    }
    RPM_READING__C {
        string Reading_Type "BP / Glucose / SpO2 / Weight"
        decimal Value "Measured Value"
        boolean Threshold_Breached "Alert Trigger"
    }
    REFERRAL {
        string Referral_Type "Internal / External"
        string Status "Pending / Accepted / Completed"
        string Priority "Routine / Urgent"
    }

Data Model Notes

• Person Accounts for patients with Health Cloud patient fields
• CarePlan / CareTeam / CareTeamMember / Encounter / Referral are standard Health Cloud objects
• RPM_Reading__c, RPM_Alert__c, RPM_Device__c, Consent_Record__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 FHIR, NOT persisted in Salesforce

Artifact 3: Role Hierarchy and Sharing Model

OWD Settings:

Object	OWD	Rationale
Account (Patient)	Private	8 user types each see different patient populations
Care Plan / Encounter / Care Team	Controlled by Parent	Inherit from Account
Referral	Private	External providers see only their referrals
RPM Reading / Lab Result	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 via Care Team Member — share created on referral acceptance, removed on episode close. Dynamic and event-driven.
• Hospital nurses: Criteria-based sharing rule per unit (e.g., Current_Unit__c = 'ICU').
• Home health nurses: Apex-managed sharing from daily Kronos schedule sync. Offline briefcase pre-loads assigned patients.
• Care coordinators: Criteria-based sharing on Care_Program field.
• Patient Access: FLS restricts to demographics and scheduling fields; clinical fields hidden.
• 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: Restriction Rule on Account where VIP_Flag = true. Runs AFTER all sharing rules. Only VIP_Access permission set bypasses it.

Judge Signal

Judges will probe VIP restriction, specialist dynamic access (referral-driven, not department-based), and home health offline sync (how records pre-load before nurses go offline). Prepare to explain criteria-based vs. Apex-managed sharing.

Artifact 4: Integration Architecture

graph LR
    subgraph Legend["Legend"]
        L1["🟢 NEW"]
        L2["⚪ KEEPING"]
        L3["🟠 INTEGRATION LAYER"]
    end

    subgraph SF["Health Cloud"]
        PE[Platform Events — Inbound]
        CDC[Change Data Capture — Outbound]
        Apex[RPM Alert Engine]
    end

    subgraph Mule["MuleSoft Anypoint"]
        FHIR_API[FHIR R4 System API]
        HL7_L[HL7v2 MLLP Listener]
        RPM_P[RPM Poller — 5 min]
        K_Sync[Kronos Sync — Daily 5 AM]
        DS_Hook[DocuSign Webhook Listener]
        ErrH[Error Hospital + DLQ]
    end

    subgraph Ext["External Systems"]
        Epic[Epic EHR]
        LC[LabCorp]
        QD[Quest]
        Phil[Philips RPM]
        Kron[Kronos WFM]
        DS[DocuSign]
    end

    CDC -->|"Pub/Sub API — demographics changes"| FHIR_API
    FHIR_API <-->|"FHIR R4 mTLS — bidirectional clinical data"| Epic
    FHIR_API -->|"Platform Event — clinical data inbound"| PE
    LC -->|"HL7v2 MLLP — lab results"| HL7_L
    QD -->|"HL7v2 MLLP — lab results"| HL7_L
    HL7_L -->|"Platform Event — 3,300 results/day"| PE
    RPM_P -->|"REST OAuth polling — 15K readings/day"| Phil
    RPM_P -->|"Platform Event — RPM readings"| PE
    K_Sync -->|"REST OAuth batch — 200 schedules/day"| Kron
    K_Sync -->|"Platform Event — schedule sync"| PE
    DS_Hook -->|"REST webhook — 50K docs/yr"| DS
    DS_Hook -->|"Platform Event — consent status"| PE

    classDef keepSystem fill:#f8f9fa,stroke:#6c757d,color:#000
    classDef integrationLayer fill:#fff3cd,stroke:#fd7e14,color:#000
    classDef sfSystem fill:#cce5ff,stroke:#0d6efd,color:#000
    classDef newSystem fill:#d4edda,stroke:#28a745,color:#000

    class SF,PE,CDC,Apex sfSystem
    class Mule,FHIR_API,HL7_L,RPM_P,K_Sync,DS_Hook,ErrH integrationLayer
    class Epic,LC,QD,Phil,Kron,DS keepSystem
    class L1 newSystem
    class L2 keepSystem
    class L3 integrationLayer

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: Outbound demographics changes flow via CDC/Pub/Sub API to MuleSoft, mapped to FHIR Patient resource. Inbound clinical data via Epic FHIR Subscriptions for Encounter, Observation, MedicationRequest, DiagnosticReport. Health Timeline uses on-demand FHIR read — data displayed but NOT persisted (avoids PHI duplication).

RPM alert flow: MuleSoft polls Philips every 5 minutes, writes RPM_Reading records via Platform Events. Apex trigger evaluates against patient thresholds; if breached, creates RPM_Alert, assigns task to care team, sends push notification.

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): Experience Cloud Identity with self-registration, email + password + MFA (SMS/authenticator). Customer Community Plus licenses. 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.

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
Hot (Active + 3 years)	400K patients, 1.2M encounters	Health Cloud objects	Immediate SOQL
Warm (3-7 years)	300K patients, 600K encounters	Big Objects	Async SOQL
Cold (7+ years)	150K patients, 300K encounters	External lake via Data Cloud	Compliance retrieval

Load sequence: Accounts (Patients) -> Providers (Contacts) -> Care Plans -> Encounters -> Referrals. Hot tier via Bulk API 2.0; Big Objects via Apex batch DML. Validation: record count reconciliation, referential integrity checks, 500-record clinical SME spot-check.

Phase 3 — Parallel run (Months 9-11): Both systems operate; new data in Health Cloud, Meditech read-only. Daily automated reconciliation. Exit criteria: 30 days zero critical discrepancies, all users trained, all integrations live.

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: Data Mask applied to all non-production environments. Training uses Partial Copy (never Full Copy for trainer access — HIPAA violation). Only production contains real patient data.

Artifact 9: Phased Delivery Roadmap

gantt
    title CareBridge — 24-Month Delivery
    dateFormat YYYY-MM
    axisFormat %b %Y

    section Phase 1: Foundation
    Platform + Shield + SSO + data model  :p1a, 2026-04, 3M
    MuleSoft setup                        :p1b, 2026-05, 2M
    Data profiling + cleansing            :p1c, 2026-04, 4M

    section Phase 2: Core Clinical
    Epic FHIR integration                 :p2a, 2026-07, 4M
    Lab results integration               :p2b, 2026-08, 3M
    Role hierarchy + sharing model        :p2c, 2026-07, 3M
    Care plan + care team config          :p2d, 2026-08, 2M
    Historical data migration (hot)       :p2e, 2026-08, 4M

    section Phase 3: Portal + Mobile
    Experience Cloud patient portal       :p3a, 2026-11, 4M
    Patient identity + registration       :p3b, 2026-11, 2M
    Home health mobile + offline          :p3c, 2027-01, 3M
    Kronos schedule integration           :p3d, 2027-01, 2M
    Legacy portal migration               :p3e, 2027-02, 2M

    section Phase 4: Advanced
    RPM integration (Philips)             :p4a, 2027-04, 3M
    RPM alerting engine                   :p4b, 2027-05, 2M
    DocuSign consent integration          :p4c, 2027-04, 2M
    Referral management + partner portal  :p4d, 2027-04, 3M

    section Migration + Cutover
    Meditech parallel run                 :crit, p5a, 2027-01, 3M
    Meditech decommission                 :crit, p5b, 2027-04, 2M

    section Cross-Cutting
    Training (role-specific, per phase)   :p6a, 2026-10, 14M
    Hypercare + stabilization             :p6b, 2027-07, 5M

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

sequenceDiagram
    participant EmpBrowser as Employee Browser
    participant Entra as Microsoft Entra ID
    participant HC as Health Cloud
    participant PatBrowser as Patient Browser
    participant ECID as EC Identity
    participant Portal as Patient Portal
    participant ExtDoc as External Provider
    participant PartnerPortal as Referral Portal
    participant MuleSoft as MuleSoft (System-to-System)

    rect rgb(230, 240, 255)
    Note over EmpBrowser,HC: Internal Employee SSO (8,500 users)
    EmpBrowser->>Entra: Navigate to Salesforce (SP-initiated)
    Entra->>Entra: Authenticate (password + MFA enforced)
    Entra->>Entra: Evaluate group membership<br/>(department, role, unit/zone)
    Entra->>EmpBrowser: SAML 2.0 Assertion (Federation ID + attributes)
    EmpBrowser->>HC: POST Assertion to ACS URL
    HC->>HC: JIT Provisioning — create/update User<br/>(Profile, Permission Sets from Entra groups)
    HC->>EmpBrowser: Session (role-appropriate access)
    end

    rect rgb(230, 255, 230)
    Note over PatBrowser,Portal: Patient Portal Authentication (400,000 users)
    PatBrowser->>ECID: Self-registration or login
    ECID->>ECID: Verify email + password
    ECID->>ECID: Enforce MFA (SMS or authenticator app)
    ECID->>Portal: Authenticated session (Customer Community Plus)
    Portal->>Portal: Sharing model scopes to own records
    Portal->>PatBrowser: Patient dashboard (own data only)
    end

    rect rgb(255, 240, 230)
    Note over ExtDoc,PartnerPortal: External Provider Access (390 providers)
    ExtDoc->>PartnerPortal: Login (username + password + MFA)
    PartnerPortal->>PartnerPortal: Partner Community license<br/>Sharing set: own referrals only
    PartnerPortal->>ExtDoc: Referral status view (no full patient record)
    end

    rect rgb(255, 245, 230)
    Note over MuleSoft,HC: System-to-System Integration Auth
    MuleSoft->>HC: OAuth 2.0 Client Credentials (per Connected App)
    HC->>MuleSoft: Access token (integration user)
    MuleSoft->>HC: API calls (REST / Platform Events / Bulk)
    end

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 (Experience Cloud native identity) with self-registration, email + password + MFA. Customer Community Plus licenses support sharing model inheritance. 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 EC 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. Each integration target (Epic, LabCorp/Quest, Philips, Kronos, DocuSign) has its own Connected App with scoped permissions. Named Credentials manage token lifecycle. No shared or interactive service accounts (HIPAA Security Rule requires unique identification for all system access — 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.

Integration Error Handling

Each integration has error handling 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 bidirectional)	Request-Reply + Event-Driven	Outbound demographics: exponential backoff (30s, 2m, 10m), max 5 retries. Inbound clinical via FHIR Subscriptions: Epic resends per subscription retry policy; MuleSoft acknowledges idempotently	Anypoint MQ DLQ for failed demographic updates and unprocessable clinical events. Correlation ID links SF record to Epic FHIR resource ID	MuleSoft Anypoint Monitoring: sync lag dashboard, error rate by resource type. PagerDuty alert if sync gap >30 min for demographics or >2 hours for clinical	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	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	Failed messages written to DLQ with HL7 segment detail. 2% patient ID mismatches (per paper) 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	Lab results continue flowing to Epic via Interconnect (parallel path). Health Cloud shows “lab results temporarily unavailable — view in Epic.” Critical value alerts remain through Epic (no disruption to clinical workflow)
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

flowchart LR
    subgraph DevEnvs["Developer Sandboxes"]
        DEV1["DEV 1\n(Developer Pro)\nCore team"]
        DEV2["DEV 2\n(Developer Pro)\nIntegration"]
        DEV3["DEV 3\n(Developer Pro)\nPortal"]
        DEV4["DEV 4\n(Developer Pro)\nMobile"]
        HOTFIX["HOTFIX\n(Developer Pro)\nEmergency only"]
    end

    subgraph TestEnvs["Test Environments"]
        INT["Integration Test\n(Partial Copy)\nMuleSoft endpoints"]
        TRAIN["Training\n(Partial Copy)\nMasked PHI — HIPAA"]
        UAT["UAT / Staging\n(Full Copy)\nCompliance + performance"]
    end

    DEV1 -->|"PR merge to develop"| INT
    DEV2 -->|"PR merge to develop"| INT
    DEV3 -->|"PR merge to develop"| INT
    DEV4 -->|"PR merge to develop"| INT
    INT -->|"Release candidate"| UAT
    UAT -->|"CAB approval +\nClinical impact assessment\n+ CCO sign-off"| PROD["PRODUCTION"]
    HOTFIX -->|"CIO + IT Director\nEmergency path"| PROD

    style PROD fill:#d4edda,stroke:#28a745,color:#000
    style INT fill:#fff3cd,stroke:#fd7e14,color:#000
    style UAT fill:#cce5ff,stroke:#0d6efd,color:#000
    style TRAIN fill:#e8daef,stroke:#8e44ad,color:#000
    style HOTFIX fill:#f8d7da,stroke:#dc3545,color:#000

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 to all non-production environments immediately after refresh
• Masked: 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
• Only production contains real patient data — BAA with Salesforce covers production only
• Developer Pro sandboxes contain metadata only (no data copied) — HIPAA safe by design

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.