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.

AI-Assisted Reference Solution

This page is the spoiler side of the mini-scenario package. Use it to compare architecture choices, trade-offs, and artifact quality only after your own attempt.

Solution Snapshot

Field	Detail
Start here	Question page
Difficulty	Beginner
Heavy domains	Security and Data
Page role	Worked reference solution
Best used for	Comparing your own answer against a complete architecture recommendation
Coverage available	Question page + this solution page

Why This Solution Matters

• Use this page to compare your own approach against a full reference answer without losing the context of what the scenario was testing.

Only Open After Your Own Attempt

If you have not yet worked through the question page, stop here. Finish your timed mini-board attempt first, then use this solution with the 9 Essential Artifacts as your comparison checklist.

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 Plus with Briefcase Builder — addresses 20% poor connectivity; Mobile App Plus add-on license enables full offline CRUD with Briefcase (standard Mobile App offline is read-only, 210-record limit). 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:

Tier	Data Age	Storage	Access
Hot	Active + last 3 years	Health Cloud	Immediate
Warm	3-7 years inactive	Big Objects	Standard SOQL (subset operators) or Bulk API 2.0
Cold	7+ years	External 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.

Migration Strategy Diagram

flowchart LR
    subgraph P1["Phase 1: Cleansing<br/>Months 1-3"]
        P1A["Export CSVs from<br/>CareTrack v4.2"]
        P1B["Informatica Cloud<br/>dedup 31K patients<br/>(fuzzy: name+DOB+address)"]
        P1C["Survivorship rules<br/>+ missing field defaults"]
        P1D["Validation reports<br/>+ data steward review"]
        P1A --> P1B --> P1C --> P1D
    end

    subgraph P2["Phase 2: Load<br/>Months 4-6"]
        P2A["Hot tier: Active +<br/>3yr records →<br/>Health Cloud"]
        P2B["Warm tier: 3-7yr<br/>records →<br/>Big Objects"]
        P2C["Cold tier: 7yr+ →<br/>External archive<br/>(BAA + FIPS)"]
        P2D["Rebuild referential<br/>integrity lost in<br/>CSV exports"]
        P2A --> P2D
        P2B --> P2D
        P2C --> P2D
    end

    subgraph P3["Phase 3: Parallel Run<br/>Months 7-9"]
        P3A["CareTrack + Salesforce<br/>run side-by-side"]
        P3B["Exit criteria:<br/>30 days zero discrepancies"]
        P3C["All roles trained<br/>+ billing integration validated"]
        P3A --> P3B --> P3C
    end

    subgraph GL["Go-Live<br/>Month 10"]
        GLA["CareTrack<br/>decommissioned"]
        GLB["Data center<br/>lease ends Mo 16"]
        GLA --> GLB
    end

    P1 --> P2 --> P3 --> GL

Phase	Key Disablements	Validation Criteria
Phase 1	N/A (cleansing occurs outside SF)	<10 unresolved duplicates, all required fields populated, data steward sign-off
Phase 2	Disable triggers, validation rules, and Flows during bulk load; disable sharing recalculation	Record counts match source; referential integrity rebuilt; OWD and sharing verified post-load
Phase 3	N/A (both systems active)	30 consecutive days zero discrepancies; all user roles validated; MediBill integration confirmed
Go-Live	CareTrack read-only, then decommissioned	Compliance sign-off; data center lease timeline met (Month 16)

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.

Integration	Pattern	Retry	DLQ	Monitor	Fallback
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 count	Email alert to billing integration team on 3rd failure; daily digest of all failed transmissions	Queue in Platform Events (72-hour replay window); manual resubmission UI for billing team after outage
MediBill Pro (nightly reconciliation)	Scheduled Apex batch	1 automatic re-run at T+2 hours	Discrepancy records flagged on Visit__c with Billing_Status__c = Discrepancy	Morning email report to billing manager listing all unreconciled visits	Billing team reviews discrepancies manually; resubmit individual records via UI action
Active Directory SSO	SAML 2.0 (SP-initiated)	N/A (browser redirect)	N/A	Shield Event Monitoring for failed login attempts; alert on >5 failures per user in 1 hour	Fallback: 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 (NEW)"]
        EC["🟢 Experience Cloud Portal (NEW)"]
        Mobile["🟢 Mobile App Plus + Briefcase Builder (NEW)"]
    end

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

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

    subgraph Retiring["Retiring Systems"]
        CT["🔴 CareTrack v4.2 (RETIRING)"]
        PS["🔴 Paper Scheduling (RETIRING)"]
    end

    subgraph Storage["Data Tiers"]
        Hot["🟢 Hot: Health Cloud (NEW)"]
        Warm["🟢 Warm: Big Objects (NEW)"]
        Cold["⚪ Cold: External Archive (KEEPING)"]
    end

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

    Mobile -->|"Briefcase Offline Sync"| HC
    HC -->|"Platform Event trigger"| PE
    PE -->|"REST, OAuth 2.0<br/>~5K records/day"| MB
    MB -->|"Nightly reconciliation batch"| PE
    AD -->|"SAML 2.0 SSO"| HC
    EC -->|"Authenticated portal"| HC
    HC --> Hot
    HC -->|"SOQL / Bulk API 2.0"| Warm
    Warm -->|"Aged-off records"| Cold
    CT -.->|"Data migrated to SF<br/>Months 1-9"| HC
    PS -.->|"Replaced by SF Scheduling"| HC

Integration Architecture

flowchart LR
    subgraph SF["Salesforce Health Cloud"]
        VF["Visit Finalized<br/>(Platform Event)"]
        NC["Named Credential<br/>(OAuth 2.0)"]
        RB["Reconciliation<br/>Batch (Nightly)"]
        EL["Integration_Error_Log__c<br/>(DLQ)"]
        SM["Shield Event<br/>Monitoring"]
    end

    subgraph MB_SYS["MediBill Pro (KEEPING)"]
        MBAPI["REST API v2.3"]
    end

    subgraph AD_SYS["Active Directory (KEEPING)"]
        ADSAML["SAML 2.0 IdP"]
    end

    subgraph HIE_SYS["Future: HIE Connection"]
        HIEAPI["HL7 FHIR API<br/>(Phase 2 — out of scope)"]
    end

    VF -->|"REST, OAuth 2.0<br/>Real-time, ~5K/day<br/>Visit + diagnosis + clinician ID"| NC
    NC -->|"POST /claims"| MBAPI
    MBAPI -->|"Confirmation ID returned"| NC
    RB -->|"GET /claims/status<br/>Nightly batch<br/>Reconcile all day's visits"| MBAPI
    MBAPI -.->|"Discrepancy flagged"| EL
    ADSAML -->|"SAML 2.0, SP-initiated<br/>MFA mandatory<br/>Federation ID = employee ID"| SF
    SM -->|"Login monitoring<br/>Alert >5 failures/hr"| ADSAML
    SF -.->|"Future: HL7 FHIR<br/>(no re-architecture needed)"| HIEAPI

Sharing Model

Role Hierarchy

graph TB
    CEO["CEO / Executive Leadership<br/>Read-All across all regions"]
    CCO["Chief Compliance Officer<br/>Read-All + Audit Access"]
    CClin["Chief Clinical Officer<br/>Read-All clinical data"]
    CFO["CFO<br/>Read-All financial + billing"]
    VP["VP Clinical Ops<br/>All Regions Read"]

    subgraph Regions["9 Regional Territories (ETM)"]
        direction TB
        RD_NY["Regional Director — NY<br/>Territory Roll-Up (3 territories)"]
        RD_NJ["Regional Director — NJ<br/>Territory Roll-Up (3 territories)"]
        RD_CT["Regional Director — CT<br/>Territory Roll-Up (3 territories)"]
    end

    subgraph Coordinators["Care Coordinators"]
        CC_NY["Coordinators — NY Territories<br/>Territory-Based Access"]
        CC_NJ["Coordinators — NJ Territories<br/>Territory-Based Access"]
        CC_CT["Coordinators — CT Territories<br/>Territory-Based Access"]
    end

    subgraph Clinicians["Clinicians (Apex Managed Sharing)"]
        RN["Nurses (200)<br/>Own Caseload Only"]
        PT_OT["PTs / OTs (50)<br/>Own Caseload Only"]
        SW["Social Workers<br/>Own Caseload Only"]
    end

    subgraph Billing["Billing Team"]
        BM["Billing Manager<br/>All visit + diagnosis data"]
        BA["Billing Analysts<br/>Visit records — no clinical notes"]
    end

    subgraph PortalUsers["Portal Users (External — Outside Hierarchy)"]
        PAT["Patients / Family Members<br/>Own records only via Experience Cloud"]
        REF["Referral Sources<br/>Referral status only — no clinical data"]
    end

    CEO --> CCO
    CEO --> CClin
    CEO --> CFO
    CClin --> VP
    VP --> RD_NY
    VP --> RD_NJ
    VP --> RD_CT
    RD_NY --> CC_NY
    RD_NJ --> CC_NJ
    RD_CT --> CC_CT
    CC_NY -.->|"Apex Managed Sharing<br/>(Care Team)"| RN
    CC_NY -.->|"Apex Managed Sharing<br/>(Care Team)"| PT_OT
    CC_NY -.->|"Apex Managed Sharing<br/>(Care Team)"| SW
    CFO --> BM --> BA

OWD Summary

Object	OWD	Sharing Mechanism
Account (Patient)	Private	Role hierarchy + ETM territory sharing rules + Apex-managed care team sharing
Care Plan	Controlled by Parent	Inherits from Account; multi-discipline access via care team
Visit (Episode Visit)	Controlled by Parent	Inherits from Account; clinician access via care team assignment
Clinical Note	Controlled by Parent	Inherits from Account; FLS restricts billing team from clinical content
Physician Order	Controlled by Parent	Inherits from Account; expiration tracking via Flow
Referral	Private	Ownership-based sharing; external referral sources see status only via portal
VIP Patient records	Private + Restriction Rule	Hidden from all users except VIP Access permission set holders

Multi-Discipline Care Team Access

When multiple disciplines serve a patient (Req 25), all assigned clinicians are added to the Care Team object on the patient record. Apex-managed sharing creates share records for each team member. When a clinician is unassigned, the share record is immediately deleted — no stale access persists. This handles the dynamic, patient-level access pattern that criteria-based sharing rules cannot address.

Data Model

erDiagram
    ACCOUNT ||--|{ CARE_PLAN : "has (M-D)"
    ACCOUNT ||--o{ REFERRAL : "has (Lookup)"
    ACCOUNT ||--o{ CARE_TEAM_MEMBER : "has (Lookup)"
    CARE_PLAN ||--|{ EPISODE_OF_CARE : "has (M-D)"
    EPISODE_OF_CARE ||--|{ VISIT : "has (M-D)"
    VISIT ||--|{ CLINICAL_NOTE : "has (M-D)"
    VISIT ||--o{ BILLING_CLAIM : "linked to (Lookup)"
    CARE_PLAN ||--|{ PHYSICIAN_ORDER : "has (M-D)"
    ACCOUNT }|--o{ CARE_TEAM_MEMBER : "assigned clinician (Lookup)"
    CONTACT ||--o{ ACCOUNT : "clinician assignment (Lookup)"

    ACCOUNT {
        string Name "Patient demographics"
        string OWD "Private"
        string Volume "25K active"
        string VIP_Flag "Restriction Rule applied"
    }
    CARE_PLAN {
        string Name "Individualized care plan"
        string OWD "Controlled by Parent"
        string Volume "30K active"
        string Disciplines "Nursing PT OT Social Work"
    }
    EPISODE_OF_CARE {
        string Name "Episode per patient"
        string OWD "Controlled by Parent"
        string Volume "60K active episodes"
    }
    VISIT {
        string Name "Point-of-care documentation"
        string OWD "Controlled by Parent"
        string Volume "1.25M per year - LDV"
        string Billing_Status "Pending Transmitted Confirmed Discrepancy"
    }
    CLINICAL_NOTE {
        string Name "Structured and narrative notes"
        string OWD "Controlled by Parent"
        string Volume "1.25M per year - LDV"
        string Locked "Finalized notes are immutable"
    }
    PHYSICIAN_ORDER {
        string Name "Orders with signature status"
        string OWD "Controlled by Parent"
        string Volume "50K active"
        string Expiry_Alert "Flag at 14 days before expiration"
    }
    REFERRAL {
        string Name "Intake referral tracking"
        string OWD "Private"
        string Volume "10K per year"
        string Source "Hospital Physician Self"
    }
    BILLING_CLAIM {
        string Name "Linked to MediBill Pro"
        string OWD "Private"
        string Volume "1.25M per year - LDV"
        string Audit_Trail "7-year retention"
    }
    CARE_TEAM_MEMBER {
        string Name "Dynamic assignment junction"
        string OWD "Private"
        string Volume "100K active assignments"
        string Drives_Sharing "Apex-managed share records"
    }
    CONTACT {
        string Name "Clinicians and staff"
        string OWD "Private"
        string Volume "450 internal plus portal users"
    }

LDV Strategy

Three objects exceed the LDV threshold (>100K records) and require specific handling:

Object	Current Volume	Annual Growth (15% YoY)	3-Year Projection	Strategy
Visit	6.2M historical + 1.25M/year	~1.44M by Year 3	~10M total	3-tier archival: Hot (active + 3yr), Warm (Big Objects 3-7yr), Cold (7yr+ external archive). Skinny tables for reporting. Custom indexes on Patient + Date
Clinical Note	~6.2M historical + 1.25M/year	~1.44M by Year 3	~10M total	Paired with Visit archival tiers. Long Text Area with full-text search for free-text notes. Original notes preserved immutably (Req 10)
Billing Claim	~6.2M historical + 1.25M/year	~1.44M by Year 3	~10M total	Indexed on Visit + Payer + Status for reconciliation queries. 7-year Field Audit Trail retention via Shield

LDV Performance Considerations

With 25K active patients and 5K new visit records per business day (Monday peaks of 1,200 in a 2-hour window), the Visit and Clinical Note objects will exceed 10M records within 3 years. Skinny tables on frequently queried fields (Patient, Date, Status, Clinician) are essential. Standard SOQL (with subset operators: =, <, >, <=, >=, IN) or Bulk API 2.0 is required for querying Big Object warm-tier data (Async SOQL was retired in Spring ‘23). Batch processes for archival tier movement should run during off-peak hours (weekends).

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

Sandbox Strategy

Sandbox	Type	Purpose	Data Policy
DEV-1	Developer	Admin config, declarative builds, care plan objects	No patient data; seed data only
DEV-2	Developer	Apex development, Flow building, unit testing	No patient data; synthetic records
DEV-3	Developer Pro	Integration development against MediBill Pro sandbox	No patient data; mock API responses
QA	Partial Copy	Integration testing, regression, QA validation	Data-masked — all PHI fields (names, DOB, SSN, addresses, clinical notes) replaced with synthetic equivalents via Salesforce Data Mask
UAT	Full Copy	Business stakeholder acceptance, parallel-run validation	Data-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 Type	Environment	Scope	Criteria
Apex Unit Tests	Developer sandboxes	All custom Apex classes and triggers	>75% code coverage; all assertions pass
Integration Tests	QA (Partial Copy)	MediBill Pro API callouts, Platform Event flows	Mock callouts in Apex tests; end-to-end validation in QA with MediBill sandbox
Regression Tests	QA	Care plan workflows, sharing model, visit documentation	Automated Flow tests + manual regression checklist
UAT	Full Copy	Real clinical workflows with masked data	Clinicians, coordinators, billing team validate with realistic scenarios
Parallel-Run Validation	UAT + Production	CareTrack vs Salesforce side-by-side	30 consecutive days, zero discrepancies (exit criteria per Decision 3)
Security Testing	QA	HIPAA controls, sharing model, VIP restrictions	Verify 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 App Plus + Briefcase Builder 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

Risk	Impact	Prob	Mitigation
Offline data loss (20% poor connectivity)	HIGH	HIGH	Mobile App Plus Briefcase + conflict resolution rules; auto-save; sync queue on reconnect
Data migration quality (12% dupes, 8% missing)	HIGH	CERTAIN	3-month cleansing phase; Informatica fuzzy matching; validation reports before go-live
Apex sharing performance at scale (25K x 4+ team members)	MED	MED	Batch recalculation off-peak; monitor sharing row counts; optimize if >2M rows
HIPAA breach via patient portal	HIGH	LOW	Authenticated-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. Mobile App Plus with Briefcase Builder provides full offline CRUD (unlike the standard Mobile App, which is read-only with a 210-record limit). 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?

Scoring Rubric

Criterion	Weight	What Judges Look For
Security Model Depth	30%	Care team sharing mechanics explained (not just “Private OWD”), VIP restriction rules, FLS for billing vs clinical data, HIPAA controls (Shield, BAA, data masking, 7-year audit trail)
Data Architecture & Migration	25%	3-tier archival strategy with specific mechanisms, deduplication approach for 31K duplicates (matching algorithm, survivorship rules), data quality remediation plan, episode-of-care data model
Architecture Completeness	20%	Health Cloud justification, mobile offline story (Briefcase Builder for 20% poor connectivity), patient portal design, all major components addressed
Integration & Error Handling	15%	MediBill Pro integration pattern, reconciliation mechanism, retry and DLQ strategy, HIE future-proofing
Communication & Trade-offs	10%	Clear articulation of WHY this approach over alternatives (e.g., why Apex sharing over criteria-based rules, why no middleware for single integration, why Big Objects over external archive for warm tier)