Skip to content
SF CTA Study Hub

Solution 01: MedAssist Home Health

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: D2 Security, D3 Data | Difficulty: Beginner 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 is the target platform — HIPAA-compliant infrastructure, pre-built care plan objects, ONC-certified features out of the box
  2. Salesforce Shield is required — Platform Encryption for PHI at rest, Event Monitoring exported to external SIEM for long-term HIPAA retention, Field Audit Trail for 7-year field-level retention (Req 21)
  3. Experience Cloud for the patient portal — inherits the sharing model, supports authenticated access, integrates natively with Health Cloud
  4. Salesforce Mobile App with offline Briefcase — addresses 20% poor connectivity; reduces build time vs custom mobile app
  5. No MuleSoft — single integration target (MediBill Pro REST API); budget ($2.8M/18 months) does not justify middleware for one connection

Key Architectural Decisions

Decision 1: Team-Based Sharing Model (D2 Security — HEAVY)

Private OWD + Care Team sharing model maps exactly to the clinical access pattern. Clinicians see only their caseload (Req 24), coordinators see their region (Req 25), multi-discipline care teams share access to the same patient (Req 26).

  • OWD for Patient/Account: Private; Care Plan, Visit, Clinical Note: Controlled by Parent
  • Care Team object on each patient record. Apex-managed sharing creates/removes share records as clinicians are assigned/unassigned
  • Enterprise Territory Management for 9 regional territories — coordinators get territory-based sharing rules
  • Role hierarchy grants leadership and compliance read-only across all regions (Req 28)

Rejected criteria-based sharing rules because they cannot handle dynamic, patient-level access where individual clinicians gain/lose access as assignments change. Rejected manual sharing because 25K patients with rotating teams would be unmanageable.

Judge Signal

Security is the heaviest domain. Judges want to see WHY Private OWD is necessary, HOW care team access works mechanically, and that you considered performance implications of Apex-managed sharing on 25K+ records.

Decision 2: VIP Restriction + Data Archival (D2 Security + D3 Data — HEAVY)

VIP records: Restriction Rules + custom VIP flag hides flagged patients from all users except those in a VIP Access permission set. Runs AFTER the sharing model, so even coordinators with territory access cannot see VIP patients unless explicitly granted access.

3-tier archival for 6.2M historical records:

TierData AgeStorageAccess
HotActive + last 3 yearsHealth CloudImmediate
Warm3-7 years inactiveBig ObjectsAsync SOQL query
Cold7+ yearsExternal archive (BAA + FIPS encryption)Compliance only

Big Objects keep data within the Salesforce trust boundary (important for HIPAA) and support massive volumes at lower practical cost than standard objects.

Decision 3: Migration Strategy (D3 Data — HEAVY)

Phased migration with parallel-run period because CareTrack data has 12% duplicates, 8% missing fields, and proprietary CSV exports without referential integrity.

  • Phase 1 (Months 1-3) — Cleansing: Informatica Cloud deduplication on 31K patients using fuzzy matching (name + DOB + address). Survivorship: most-complete demographics win; all clinical history preserved under surviving record. Default region from address for missing fields.
  • Phase 2 (Months 4-6) — Load: Active patients + 3 years into Health Cloud (hot). Older records into Big Objects (warm). Preserve free-text clinical notes in Long Text Area with full-text search.
  • Phase 3 (Months 7-9) — Parallel run: Both systems operate simultaneously. Exit criteria: 30 consecutive days with zero discrepancies, all roles trained, billing integration validated.

Decision 4: Billing Integration (D5 — LIGHT)

Platform Events + Apex callout to MediBill Pro REST API. When a visit is finalized, a Platform Event fires; an Apex subscriber posts to MediBill Pro via Named Credential (OAuth 2.0). Nightly reconciliation batch compares transmitted records against confirmed receipts, flagging discrepancies. Volume (~5K records/day) is well within Salesforce callout limits.

Integration Error Handling

MedAssist has a single primary integration (MediBill Pro) plus the AD SSO connection. Error handling for the billing integration is critical because failed visit-to-claim transmissions directly impact the $45M/year revenue stream.

IntegrationPatternRetryDLQMonitorFallback
MediBill Pro (visit finalization)Platform Event → Apex callout (REST/OAuth 2.0)3x exponential backoff (1s, 10s, 60s)Integration_Error_Log__c custom object with full payload, error code, and retry countEmail alert to billing integration team on 3rd failure; daily digest of all failed transmissionsQueue in Platform Events (72-hour replay window); manual resubmission UI for billing team after outage
MediBill Pro (nightly reconciliation)Scheduled Apex batch1 automatic re-run at T+2 hoursDiscrepancy records flagged on Visit__c with Billing_Status__c = DiscrepancyMorning email report to billing manager listing all unreconciled visitsBilling team reviews discrepancies manually; resubmit individual records via UI action
Active Directory SSOSAML 2.0 (SP-initiated)N/A (browser redirect)N/AShield Event Monitoring for failed login attempts; alert on >5 failures per user in 1 hourFallback: Salesforce-native login for break-glass emergency access (disabled by default, enabled by sysadmin)

Reconciliation Detail

The nightly reconciliation batch compares all visits finalized that day against confirmed MediBill Pro receipts. Any visit where the MediBill confirmation ID is missing after 24 hours is flagged as a discrepancy. This catches silent failures where the API returns success but MediBill does not persist the record — a scenario that manual re-entry would have caught but automated integration can miss.

Critical Diagrams

System Landscape

graph TB
    subgraph Salesforce["Salesforce Health Cloud"]
        HC[Health Cloud + Shield]
        EC[Experience Cloud Portal]
        Mobile[Mobile App + Offline Briefcase]
    end

    subgraph Integration["Integration Layer"]
        PE[Platform Events + Apex Callouts]
    end

    subgraph External["External Systems"]
        MB[MediBill Pro REST API]
        AD[Active Directory SSO]
    end

    subgraph Storage["Data Tiers"]
        Hot[Hot: Health Cloud]
        Warm[Warm: Big Objects]
        Cold[Cold: External Archive]
    end

    subgraph Legend
        direction LR
        NEW[🟢 NEW - Being Built]
        KEEP[⚪ KEEPING - No Changes]
        RETIRE[🔴 RETIRING - Decommissioning]
        INT[🟠 INTEGRATION LAYER]
    end

    Mobile -->|Offline Sync| HC
    HC -->|Platform Event trigger| PE
    PE -->|REST OAuth 2.0| MB
    MB -->|Nightly reconciliation batch| PE
    AD -->|SAML 2.0 SSO| HC
    EC -->|Authenticated portal| HC
    HC --> Hot
    HC -->|Async SOQL| Warm
    Warm -->|Aged-off records| Cold

    style HC fill:#cce5ff,stroke:#0d6efd
    style EC fill:#cce5ff,stroke:#0d6efd
    style Mobile fill:#cce5ff,stroke:#0d6efd
    style PE fill:#fff3cd,stroke:#fd7e14
    style MB fill:#e9ecef,stroke:#6c757d
    style AD fill:#e9ecef,stroke:#6c757d
    style Hot fill:#d4edda,stroke:#28a745
    style Warm fill:#d4edda,stroke:#28a745
    style Cold fill:#e9ecef,stroke:#6c757d

Sharing Model

graph TB
    VP["VP Clinical Ops (All Regions Read)"]
    subgraph Regions["9 Regional Territories via ETM"]
        RC["Regional Coordinators (Territory Access)"]
    end
    subgraph Teams["Dynamic Care Team Sharing"]
        RN[Nurses]
        PT[PTs / OTs]
        SW[Social Workers]
    end

    VP --> RC
    RC -.->|Apex Managed Sharing| RN
    RC -.->|Apex Managed Sharing| PT
    RC -.->|Apex Managed Sharing| SW

    style Teams fill:#e8f4e8,stroke:#2d6a2d
    style Regions fill:#e8e8f4,stroke:#2d2d6a

Identity & SSO Flow

sequenceDiagram
    participant Clinician as Internal User<br/>(Nurse / PT / Coordinator)
    participant Browser as Browser / Mobile App
    participant AD as Active Directory<br/>(3rd-Party Managed)
    participant SF as Salesforce Health Cloud

    Clinician->>Browser: Navigate to Salesforce
    Browser->>AD: Redirect (SP-initiated SAML 2.0)
    AD->>AD: Authenticate (MFA — push or TOTP)
    AD->>Browser: SAML Assertion (Federation ID = employee ID)
    Browser->>SF: POST SAML to ACS URL
    SF->>SF: Match Federation ID → User record
    SF->>SF: Assign profile + permission sets (care team role)
    SF->>Browser: Session Cookie + Redirect to Home
sequenceDiagram
    participant Patient as Patient / Family Member
    participant Browser as Browser
    participant SF as Experience Cloud Portal

    Patient->>Browser: Navigate to Patient Portal
    Browser->>SF: Login page (username / password)
    SF->>SF: Authenticate (MFA — email or SMS OTP)
    SF->>SF: Verify External User license + portal profile
    SF->>SF: Apply sharing: patient sees only own records
    SF->>Browser: Session Cookie (15-min timeout) + Portal Home

SSO Design Rationale

Internal users: SAML 2.0 SP-initiated SSO via Active Directory. AD is currently managed by a third-party provider whose contract may not be renewed — the SAML federation is IdP-agnostic, so if MedAssist switches to Azure AD or Okta, only the IdP metadata changes; no Salesforce reconfiguration required. MFA is mandatory for all internal users per HIPAA best practices.

Patient portal users: Username/password with MFA (email or SMS one-time passcode). Patients do not have AD accounts. 15-minute session timeout enforced for PHI protection. No social SSO — healthcare portal requires verified identity.

Governance & DevOps

Environment Strategy

flowchart LR
    DEV1[Developer Sandbox 1<br/>Admin Config] --> QA[QA / Integration<br/>Partial Copy]
    DEV2[Developer Sandbox 2<br/>Apex + Flows] --> QA
    DEV3[Developer Pro Sandbox<br/>Integration Dev] --> QA
    QA --> UAT[UAT<br/>Full Copy]
    UAT --> CCO{Compliance<br/>Officer<br/>Sign-Off}
    CCO -->|Approved| PROD[Production]
    CCO -->|Rejected| DEV1

    style QA fill:#e3f2fd,stroke:#1565c0
    style UAT fill:#fff3cd,stroke:#fd7e14
    style PROD fill:#fce4ec,stroke:#c62828
    style CCO fill:#f8d7da,stroke:#dc3545

Sandbox Strategy

SandboxTypePurposeData Policy
DEV-1DeveloperAdmin config, declarative builds, care plan objectsNo patient data; seed data only
DEV-2DeveloperApex development, Flow building, unit testingNo patient data; synthetic records
DEV-3Developer ProIntegration development against MediBill Pro sandboxNo patient data; mock API responses
QAPartial CopyIntegration testing, regression, QA validationData-masked — all PHI fields (names, DOB, SSN, addresses, clinical notes) replaced with synthetic equivalents via Salesforce Data Mask
UATFull CopyBusiness stakeholder acceptance, parallel-run validationData-masked — full production schema with all PHI anonymized. Compliance officer verifies masking before UAT begins

HIPAA Data Masking — Non-Negotiable

No real patient data in ANY non-production environment (Req 45). Salesforce Data Mask is applied to the Partial Copy and Full Copy sandboxes immediately after refresh. PHI fields (Patient Name, DOB, SSN, Address, Clinical Notes, Diagnoses, Medications) are replaced with realistic but synthetic data. Compliance officer must sign off on masking completeness before any sandbox is used for testing.

Branching Strategy

  • main — production-ready code; deploys to Production after compliance approval
  • develop — integration branch; deploys to QA sandbox
  • feature/[ticket-id]-description — individual feature work in Developer sandboxes
  • All merges to develop require peer code review + passing Apex unit tests
  • Merges to main require QA pass + UAT acceptance + Compliance Officer sign-off

Testing Strategy

Test TypeEnvironmentScopeCriteria
Apex Unit TestsDeveloper sandboxesAll custom Apex classes and triggers>75% code coverage; all assertions pass
Integration TestsQA (Partial Copy)MediBill Pro API callouts, Platform Event flowsMock callouts in Apex tests; end-to-end validation in QA with MediBill sandbox
Regression TestsQACare plan workflows, sharing model, visit documentationAutomated Flow tests + manual regression checklist
UATFull CopyReal clinical workflows with masked dataClinicians, coordinators, billing team validate with realistic scenarios
Parallel-Run ValidationUAT + ProductionCareTrack vs Salesforce side-by-side30 consecutive days, zero discrepancies (exit criteria per Decision 3)
Security TestingQAHIPAA controls, sharing model, VIP restrictionsVerify cross-role data isolation; test VIP flag enforcement; audit log completeness

CoE / Post-Go-Live Governance

Center of Excellence (CoE): Led by the sysadmin (expanding to Platform Admin role) with the 2 new developers and BA. The 18-month implementation includes a 3-month knowledge transfer window (Months 16-18) where the SI partner pairs with internal staff on every change.

Change Management:

  • 2-week sprint cadence for enhancements; emergency hotfix path for critical defects
  • All changes affecting data access, security, or patient-facing features require Compliance Officer approval (Req 46) — enforced via a mandatory approval step in the deployment pipeline
  • Monthly release notes distributed to clinical leadership and care coordinators
  • Quarterly architecture review with CTO, Compliance Officer, and IT lead

Release Cadence:

  • Standard releases: Bi-weekly, aligned with sprint boundaries
  • Compliance-impacting changes: Deployed only after formal compliance review (may span multiple sprints)
  • Emergency patches: Same-day path with post-deployment compliance review within 48 hours

Requirements Addressed

  1. ✅ Patient intake and referral routing — Flow-based intake with regional territory assignment (Reqs 1-5)
  2. ✅ Clinician-only caseload visibility — Private OWD + Care Team Apex-managed sharing (Reqs 23, 25)
  3. ✅ Multi-discipline care plans — Health Cloud care plan objects with discipline-specific FLS (Reqs 6-10)
  4. ✅ Mobile visit documentation with offline — Salesforce Mobile + Offline Briefcase for 20% poor connectivity (Reqs 7, 13)
  5. ✅ VIP record restriction — Restriction Rules + VIP permission set (Req 30)
  6. ✅ 7-year audit trail + archival — Shield Field Audit Trail (hot), Big Objects (warm), external archive (cold) (Reqs 20-22)
  7. ✅ Billing integration — Platform Events + Apex callout to MediBill Pro REST API with nightly reconciliation (Reqs 40-41)
  8. ✅ Patient portal — Experience Cloud with authenticated access, 15-min timeout, MFA (Reqs 15, 29)
  9. ✅ Data migration with dedup — Informatica Cloud fuzzy matching on 31K duplicates, phased load (Reqs 16-19)
  10. ✅ HIPAA compliance — Shield encryption, BAA, data masking in sandboxes, Event Monitoring to SIEM (Reqs 20, 31, 45)

Risk Assessment

RiskImpactProbMitigation
Offline data loss (20% poor connectivity)HIGHHIGHOffline Briefcase + conflict resolution rules; auto-save; sync queue on reconnect
Data migration quality (12% dupes, 8% missing)HIGHCERTAIN3-month cleansing phase; Informatica fuzzy matching; validation reports before go-live
Apex sharing performance at scale (25K x 4+ team members)MEDMEDBatch recalculation off-peak; monitor sharing row counts; optimize if >2M rows
HIPAA breach via patient portalHIGHLOWAuthenticated-only access; MFA; 15-min session timeout; Shield Event Monitoring

Domain Scoring Notes

  • D2 Security (HEAVY): Explain how a clinician gains AND loses access as they are assigned/unassigned from a care team. Cover VIP restriction, field-level security (billing sees visits but not clinical notes), HIPAA specifics (encryption, BAA, 7-year audit trail).
  • D3 Data (HEAVY): Migration with quality remediation, archival tiering with specific mechanisms, episode-of-care data model, CareTrack CSV limitation (no referential integrity) and how you rebuild relationships.
  • D1 System Arch (MED): Justify Health Cloud licensing vs building from scratch on Service Cloud.
  • D6 Dev Lifecycle (LIGHT): Even though light, mention data masking for HIPAA compliance in sandboxes — judges will notice if you forget.

Reporting Approach

Standard Salesforce reports and dashboards cover most needs: CCO clinical dashboard (daily refresh via scheduled report), regional coordinator real-time views, and billing team weekly reports. Compliance audit reports (Req 36 — who accessed which patient record, when) leverage Shield Event Monitoring data exported to the SIEM with custom report views. If the CFO’s monthly revenue analysis or the ad-hoc reporting demand grows beyond standard reporting capabilities, consider CRM Analytics for cross-object trending and predictive readmission models.

What Would Fail

  1. “We’ll use Sharing Rules for everything” — Criteria-based rules cannot handle dynamic patient-level access where individual clinicians are added/removed from care teams. You need Apex-managed sharing for care teams AND territory-based rules for regional access.
  2. Ignoring the 12% duplicate problem — Saying “we’ll migrate the data” without a specific deduplication strategy (matching algorithm, survivorship rules, validation gates) is a guaranteed deduction.
  3. No offline story — The scenario explicitly states 20% poor connectivity. If your solution requires constant internet, you have ignored a stated constraint. Judges will ask: “What happens when the nurse is in a patient’s home with no signal?”

Self-Scoring Checklist

  • Did I articulate the sharing model mechanics (not just “Private OWD”)?
  • Did I address data quality remediation before migration?
  • Did I handle the offline requirement with a specific mechanism?
  • Did I include a VIP restriction beyond standard sharing?
  • Did I mention HIPAA-specific items: Shield, BAA, data masking, 7-year audit trail?