Case Study 07: VitalGov Health Services — Worked 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 Architecture, D2 Security, D3 Data, D5 Integration | Difficulty: Advanced (Hardest) Time budget: 180 minutes | Key frameworks: 9 Essential Artifacts

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. Single org on Salesforce Government Cloud (GovCloud) — FedRAMP Moderate authorized. Delivers unified constituent profile (Req 1), meets federal compliance, and avoids multi-org PHI synchronization. Rejected multi-org because cross-program constituent matching across orgs creates HIPAA risk and data inconsistency.
2. Health Cloud + Experience Cloud + Shield + MuleSoft Government Cloud — Health Cloud provides the constituent/patient data model. Shield delivers encryption, audit trail, and event monitoring required for HIPAA. MuleSoft GovCloud handles the protocol diversity (HL7, FHIR, EDI, SFTP, batch).
3. MMIS stays untouched — MuleSoft Robotic Process Automation (RPA) for real-time screen reads; batch file integration for bulk data. No mainframe modifications.
4. Azure AD B2C as identity broker — Federate 62 county ADs through a single hub. Counties point their AD at the broker; Salesforce sees one IdP. Rejected 62 individual SAML configs (unmanageable).
5. Platform Events + Heroku for outbreak surge — Normal operations within GovCloud platform limits. Surge capacity via Heroku Private Space (FedRAMP) absorbing 10x event volume and writing to Salesforce asynchronously.

Key Architectural Decisions

Decision 1: GovCloud Single Org with Program Segmentation (D1)

Single GovCloud org with program-level segmentation via record types, permission sets, and sharing rules. Each program (Medicaid, Surveillance, WIC, Vital Records) operates as a logical partition within the same org, sharing the unified Constituent record. Trade-off: more complex sharing model versus the elimination of cross-org data sync for constituents who participate in multiple programs (estimated 35% overlap between Medicaid and WIC).

Decision 2: Identity Broker for 62 Counties (D2)

Azure AD B2C as a federation hub. Each county configures their existing AD to trust the broker. Salesforce has a single SAML connection to the broker. County onboarding: one AD trust configuration per county, not a Salesforce-side change. Trade-off: introduces a dependency on Azure AD B2C availability; mitigated by its 99.99% SLA and GovCloud-authorized status.

Decision 3: MMIS Integration via RPA + Batch (D5)

MuleSoft RPA performs 3270 screen reads for real-time caseworker lookups (sub-5s target). Nightly batch files from MMIS feed Salesforce with bulk eligibility data. Trade-off: RPA is fragile (screen changes break it); mitigated by screen change detection alerts and a batch-file fallback. This is explicitly a bridge pattern until the planned MMIS replacement in 5-7 years.

Decision 4: HIPAA Minimum Necessary via Field-Level Security (D2)

Cross-program visibility uses field-level security, not record-level hiding. A WIC nutritionist sees the constituent record and WIC fields but not Medicaid claims detail. Medicaid caseworkers see enrollment status but not WIC clinical notes. Implemented via permission set groups per program with field-level visibility matrices.

Artifact 1: System Landscape

graph TB
    subgraph LEGEND["Legend"]
        L1["🟢 NEW — being built"]
        L2["⚪ KEEPING — no changes"]
        L3["🔴 RETIRING — decommission"]
        L4["🟠 INTEGRATION LAYER"]
    end

    subgraph GOV["Salesforce GovCloud"]
        HC[Health Cloud]
        SC[Service Cloud]
        EC[Experience Cloud<br/>Constituent Portal]
        Shield[Shield — Encryption + Audit]
    end

    subgraph MW["MuleSoft Government Cloud"]
        EXP[Experience APIs]
        PROC[Process APIs]
        SYS[System APIs]
        RPA[MuleSoft RPA<br/>MMIS Screen Reads]
    end

    subgraph SURGE["Heroku Private Space — FedRAMP"]
        HK[Surge Event Processor]
        HDB[Heroku Postgres]
    end

    subgraph LEGACY["Legacy Systems — On-Premises"]
        MMIS[MMIS Mainframe<br/>IBM z/OS COBOL]
        VR[Vital Records<br/>Oracle 11g]
        WIC[WIC MIS<br/>Custom Java]
        IIS[Immunization Registry<br/>HL7 Connected]
    end

    subgraph FED["Federal Systems"]
        CDCFED[CDC BioSense<br/>HL7 FHIR R4]
        CMSFED[CMS MITA Hub<br/>X12 EDI]
        SSA[SSA Death Verification]
        USDA[USDA FNS<br/>WIC Reporting]
    end

    subgraph COUNTY["62 County Health Departments"]
        CH[County Systems<br/>SFTP + Portal]
    end

    subgraph ID["Identity"]
        OKTA[Okta — State Employees]
        BROKER[Azure AD B2C<br/>County Federation Hub]
        IDME[ID.me — Public NIST IAL2]
    end

    GOV -->|Platform Events + CDC| MW
    EC -->|REST real-time| EXP
    EXP --> PROC
    PROC --> SYS
    RPA -->|3270 screen reads real-time| MMIS
    SYS -->|DB connector batch nightly| VR
    SYS -->|REST 12K/month| WIC
    SYS -->|HL7 2.5.1 request-reply| IIS
    SYS -->|HL7 FHIR R4 real-time + daily| CDCFED
    SYS -->|X12 EDI batch weekly| CMSFED
    SYS -->|SFTP batch nightly| SSA
    SYS -->|FNS-798 flat file monthly| USDA
    SYS -->|SFTP 42 formats daily| CH
    HK -->|Bulk API async writes| GOV
    OKTA -->|SAML 2.0| GOV
    BROKER -->|SAML 2.0| GOV
    IDME -->|OIDC| EC
    SURGE -.->|Outbreak surge only| MW

    style HC fill:#2e7d32,color:#fff
    style SC fill:#2e7d32,color:#fff
    style EC fill:#2e7d32,color:#fff
    style Shield fill:#2e7d32,color:#fff
    style EXP fill:#e65100,color:#fff
    style PROC fill:#e65100,color:#fff
    style SYS fill:#e65100,color:#fff
    style RPA fill:#e65100,color:#fff
    style HK fill:#2e7d32,color:#fff
    style HDB fill:#2e7d32,color:#fff
    style MMIS fill:#9e9e9e,color:#000
    style VR fill:#9e9e9e,color:#000
    style WIC fill:#9e9e9e,color:#000
    style IIS fill:#9e9e9e,color:#000
    style CDCFED fill:#9e9e9e,color:#000
    style CMSFED fill:#9e9e9e,color:#000
    style SSA fill:#9e9e9e,color:#000
    style USDA fill:#9e9e9e,color:#000
    style CH fill:#9e9e9e,color:#000
    style OKTA fill:#9e9e9e,color:#000
    style BROKER fill:#2e7d32,color:#fff
    style IDME fill:#9e9e9e,color:#000

Artifact 2: Data Model

erDiagram
    CONSTITUENT ||--o{ PROGRAM_ENROLLMENT : enrolled_in
    CONSTITUENT ||--o{ CASE : has
    CONSTITUENT ||--o{ IMMUNIZATION_RECORD : receives
    CONSTITUENT ||--o{ VITAL_EVENT : registered
    PROGRAM_ENROLLMENT }o--|| PROGRAM : belongs_to
    CASE ||--o{ CASE_INVESTIGATION : investigated_by
    CASE_INVESTIGATION }o--|| COUNTY_DEPT : assigned_to
    PROVIDER ||--o{ CASE : reports
    PROVIDER ||--o{ PROVIDER_ENROLLMENT : credentialed

    CONSTITUENT {
        string ConstituentID "State-assigned"
        string MedicaidID
        string WIC_ParticipantID
        date DateOfBirth
        string EncryptedSSN "Shield encrypted"
    }
    PROGRAM_ENROLLMENT {
        picklist Program "Medicaid WIC Surveillance"
        picklist Status "Active Pending Expired"
        date EffectiveDate
        date ExpirationDate
    }
    CASE {
        picklist CaseType "Eligibility Surveillance VitalRecord"
        picklist ReportableCondition
        string CDCReportID
        datetime ReportedDate
    }
    VITAL_EVENT {
        picklist EventType "Birth Death"
        string CertificateNumber
        picklist AmendmentStatus
    }

• Constituent is the central object (Health Cloud Person Account model). Single record per resident linked across programs via state-assigned ID.
• Program Enrollment tracks participation in each program with dates and status. A constituent can have multiple active enrollments.
• Case is polymorphic: Medicaid eligibility cases, disease surveillance investigations, WIC assessments, and vital record requests all use Case with record types.
• Shield Platform Encryption on SSN, date of birth, and clinical fields. Deterministic encryption on SSN to allow matching without decryption.

Artifact 3: Role Hierarchy & Sharing Model

graph TB
    CIO[State CIO] --> MedDir[Medicaid Director]
    CIO --> EpiDir[Epidemiology Director]
    CIO --> WICDir[WIC Director]
    CIO --> VRReg[Vital Records Registrar]
    MedDir --> MedMgr[Medicaid Regional Mgrs x4]
    MedMgr --> MedCW[Medicaid Caseworkers]
    EpiDir --> EpiMgr[Surveillance Managers]
    EpiMgr --> EpiInv[Epidemiologists]
    EpiMgr --> CountyLead[County Surveillance Leads]
    WICDir --> WICMgr[WIC Clinic Managers]
    WICMgr --> WICStaff[WIC Nutritionists]
    VRReg --> VRMgr[Vital Records Managers]
    VRMgr --> VRClerk[Vital Records Clerks]

Object	OWD	Mechanism
Constituent (Person Account)	Private	Criteria-based sharing by program enrollment
Program Enrollment	Controlled by Parent	Inherits from Constituent
Case	Private	Assignment rules + program-based sharing
Immunization Record	Controlled by Parent	Inherits from Constituent
Vital Event	Private	Vital Records team only + legal override
County Surveillance Data	Private	County-scoped sharing (county ID criteria)

Cross-program access: A WIC nutritionist sees Constituent demographics and WIC enrollment but not Medicaid claims (field-level security). Medicaid caseworkers see enrollment status for all programs (needed for eligibility) but not WIC clinical notes. Field-Level Security (FLS) via Permission Set Groups enforces HIPAA minimum necessary — same Constituent record visible, but program-specific fields hidden from unauthorized users.

County scoping: County health workers see only records where County__c matches their assignment. Statewide aggregate dashboards (de-identified) available to all county leads.

Artifact 4: Integration Architecture

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

    subgraph SF["Salesforce GovCloud"]
        PE[Platform Events]
        API[REST API]
    end

    subgraph Mule["MuleSoft Government Cloud"]
        EXP["Experience APIs"]
        PROC["Process APIs"]
        SYS["System APIs"]
        RPA["RPA — MMIS"]
        DLQ[Dead Letter Queue]
    end

    subgraph Proto["Protocol Translation"]
        HL7[HL7 2.5.1 Adapter]
        FHIR[FHIR R4 Adapter]
        EDI[X12 EDI Adapter]
        SFTP_A[SFTP Adapter<br/>42 County Formats]
    end

    subgraph EXT["External Systems"]
        MMIS_EXT[MMIS Mainframe]
        CDC_EXT[CDC BioSense]
        CMS_EXT[CMS MITA]
        SSA_EXT[SSA]
        USDA_EXT[USDA FNS]
        VR_EXT[Vital Records Oracle]
        WIC_EXT[WIC MIS]
        IIS_EXT[IIS Registry]
        COUNTY_EXT[62 County Systems]
    end

    PE -->|Platform Events| Mule
    Mule -->|REST/Bulk API| SF
    EXP --> PROC --> SYS
    SYS --> Proto
    SYS --> RPA
    PROC --> DLQ
    RPA -->|3270 screen reads real-time| MMIS_EXT
    FHIR -->|HL7 FHIR R4 real-time + daily| CDC_EXT
    EDI -->|X12 EDI 837/835 batch weekly| CMS_EXT
    SFTP_A -->|SFTP batch nightly| SSA_EXT
    SFTP_A -->|FNS-798 flat file monthly| USDA_EXT
    SYS -->|DB connector batch nightly| VR_EXT
    SYS -->|REST 12K/month| WIC_EXT
    HL7 -->|HL7 2.5.1 request-reply 8K/day| IIS_EXT
    SFTP_A -->|SFTP 42 formats daily| COUNTY_EXT

    style PE fill:#1a73e8,color:#fff
    style API fill:#1a73e8,color:#fff
    style EXP fill:#e65100,color:#fff
    style PROC fill:#e65100,color:#fff
    style SYS fill:#e65100,color:#fff
    style RPA fill:#e65100,color:#fff
    style DLQ fill:#e65100,color:#fff
    style HL7 fill:#e65100,color:#fff
    style FHIR fill:#e65100,color:#fff
    style EDI fill:#e65100,color:#fff
    style SFTP_A fill:#e65100,color:#fff
    style MMIS_EXT fill:#9e9e9e,color:#000
    style CDC_EXT fill:#9e9e9e,color:#000
    style CMS_EXT fill:#9e9e9e,color:#000
    style SSA_EXT fill:#9e9e9e,color:#000
    style USDA_EXT fill:#9e9e9e,color:#000
    style VR_EXT fill:#9e9e9e,color:#000
    style WIC_EXT fill:#9e9e9e,color:#000
    style IIS_EXT fill:#9e9e9e,color:#000
    style COUNTY_EXT fill:#9e9e9e,color:#000

System	Pattern	Protocol	Volume
MMIS	RPA screen read (real-time) + batch file (bulk)	3270 + SFTP	15K/day
CDC BioSense	Event-Driven (outbound)	HL7 FHIR R4	Real-time + daily
CMS MITA	Batch (outbound)	X12 EDI 837/835	Weekly
SSA	Batch (bidirectional)	SFTP	Nightly
USDA FNS	Batch (outbound)	FNS-798 flat file	Monthly
Vital Records (Oracle)	Change Data Capture	DB extract via MuleSoft DB connector	Nightly
WIC MIS	Request-Reply	REST	12K enrollments/month
IIS	Request-Reply	HL7 2.5.1 via adapter	8K queries/day
eCR (providers)	Event-Driven (inbound)	HL7 FHIR eICR	500-2K/day
62 County SFTP	File-based ingest	SFTP (42 formats normalized)	Daily

County data normalization: MuleSoft DataWeave transforms 42 county formats into a single Canonical Surveillance Event schema. County-specific mapping files stored in MuleSoft object store. New format = new mapping file, zero code changes.

MMIS integration detail: RPA navigates MMIS 3270 screens for individual beneficiary lookups (caseworker-initiated, sub-5s target). Nightly batch extracts eligibility snapshots (full 2.1M records) for Salesforce refresh. If RPA fails mid-session, caseworker sees “MMIS temporarily unavailable” with last-known data from batch.

Outbreak surge: Normal daily volume ~50K transactions. During a public health emergency, eCR volume can spike 10x. Heroku Private Space (FedRAMP authorized) absorbs surge, buffers events in Postgres, and writes to Salesforce via Bulk API at throttled rates. No Salesforce API limit breaches during surge.

Artifact 5: Identity & SSO

graph LR
    subgraph USERS["User Populations"]
        STATE[State Employees<br/>3,200]
        COUNTY[County Workers<br/>4,800]
        PROV[Healthcare Providers<br/>4,500]
        PUB[Public / Beneficiaries]
    end

    subgraph IDP["Identity Providers"]
        OKTA[Okta<br/>State IdP]
        BROKER[Azure AD B2C<br/>Federation Hub]
        NPI[NPI Registry<br/>Provider Verification]
        IDME[ID.me<br/>NIST IAL2]
    end

    subgraph SF["Salesforce GovCloud"]
        INT[Internal Users]
        COMM[Community — Provider Portal]
        CPUB[Community — Public Portal]
    end

    STATE --> OKTA -->|SAML 2.0| INT
    COUNTY --> BROKER -->|SAML 2.0| INT
    PROV --> NPI --> COMM
    PUB --> IDME -->|OIDC| CPUB

• State employees (3,200): Okta via SAML 2.0. SCIM for lifecycle management. Okta groups map to program-specific permission set groups.
• County workers (4,800 across 62 counties): Azure AD B2C federation hub. Each county’s AD federates with the broker. Salesforce has one SAML connection to the broker. County claim in SAML assertion maps to county-specific public group. Onboarding a new county: one AD trust in Azure, one public group in Salesforce.
• Healthcare providers (4,500): Experience Cloud with NPI-based registration. Provider submits NPI; system verifies against NPPES registry. MFA required. Credentialing approval before data access.
• Public/beneficiaries: Experience Cloud public portal with ID.me for identity verification (NIST IAL2 for vital records requests). Medicaid pre-screening does not require identity verification. WIC appointment booking requires basic authentication.

JIT provisioning: County workers provisioned on first login via SAML JIT. Azure AD B2C SAML assertion includes county code, role, and program access. Salesforce creates user, assigns permission set group, and sets county sharing.

Artifact 6: Data Migration Strategy

Phase 1 — Medicaid (Months 1-14):

1. Constituent master record creation: Extract 2.1M Medicaid beneficiaries from MMIS batch export. Deduplicate (SSN + DOB + Name fuzzy). Load as Health Cloud Person Accounts.
2. Historical eligibility data: 5 years of enrollment history (~10M records) loaded via Bulk API. Older data archived in Salesforce data archive (read-only access for compliance).
3. Claims data stays in MMIS — not migrated. Salesforce queries MMIS via RPA for real-time claims lookup.
4. Provider records: 4,500 providers loaded from MMIS + NPPES registry cross-reference.

Phase 2 — Surveillance (Months 10-24): 5. Disease case records: 3 years of surveillance data (~200K cases) migrated from legacy databases. 6. County data normalization: First 10 counties (highest volume) onboarded in months 10-14; remaining 52 counties in rolling waves through month 24. 7. IIS immunization data: Read-only integration, not migration. Salesforce queries IIS; records stay in IIS.

Phase 3 — WIC + Vital Records (Months 18-32): 8. WIC participants: 180K active records + 3 years history from WIC MIS. Match against existing Constituent records from Phase 1 (estimated 35% overlap with Medicaid). 9. Vital records: 5 years of birth/death registrations (~1M records) from Oracle export. Certificate images remain in legacy storage; Salesforce stores metadata with links.

Data quality: Government data has high duplicate rates (name variations, address changes, multiple program IDs for same person). Master matching uses SSN (deterministic, encrypted) + probabilistic matching (name + DOB + address). Matches above 90% confidence auto-merge; 70-90% flagged for manual review; below 70% treated as separate records.

Artifact 7: Governance

Health IT Governance Board (HITGB): Monthly. State CIO (chair), program directors, CISO, SI lead, CMS liaison (quarterly). Reviews architecture changes, compliance status, and cross-program decisions.

Program-Level Change Authority: Each program director approves program-specific changes within guardrails. Cross-program changes (constituent model, shared integrations) require HITGB.

Change Type	Approval	Lead Time
Constituent data model	HITGB	2 sprints
Program-specific config	Program director	1 sprint
Integration changes	HITGB + integration lead	2 sprints
Security / compliance	CISO + HITGB	2 sprints
Emergency (outbreak response)	State CIO	Same day

FedRAMP continuous monitoring: Quarterly security assessments. Monthly vulnerability scans. Annual penetration testing. POA&M (Plan of Action and Milestones) tracking for all findings. CISO reviews before every production deployment.

Naming conventions: VHS_[Program]_[Object]_[Purpose]. All Apex requires 85% code coverage. PMD static analysis on every PR. No direct production deployments.

Artifact 8: Environment Strategy

Environment	Purpose	Refresh
GovCloud Production	Live system	N/A
GovCloud Full Copy	UAT + security testing	Monthly
GovCloud Partial Copy	Program-level UAT	Bi-weekly
GovCloud Dev Sandbox (x3)	Medicaid / Surveillance / WIC-VR teams	Sprint start
GovCloud Dev Pro	SI partner	Sprint start

All sandboxes must be GovCloud instances (FedRAMP boundary). PHI in sandboxes must be masked or synthetic — no production PHI in non-production environments. Data masking via Informatica or custom Apex batch post-refresh.

CI/CD: Salesforce CLI + GitHub (FedRAMP-authorized GitHub Enterprise) + GitHub Actions. Promotion: Dev -> Partial Copy -> Full Copy -> Production. CISO sign-off gate before production deploy. Automated SAST scan (PMD + Checkmarx) on every PR.

DR: GovCloud provides built-in geo-redundancy. RPO 4 hours met by platform replication. RTO 8 hours met by documented failover runbook. Annual DR drill required by FedRAMP.

Artifact 9: Phased Delivery Roadmap

gantt
    title VitalGov — 36-Month Delivery
    dateFormat  YYYY-MM
    axisFormat  %b %Y

    section Phase 1 — Foundation + Medicaid
    GovCloud setup + FedRAMP prep          :p1a, 2026-07, 4M
    Health Cloud data model + Shield       :p1b, 2026-07, 5M
    MuleSoft GovCloud + MMIS RPA           :p1c, 2026-09, 6M
    Medicaid caseworker app                :p1d, 2026-12, 5M
    Provider portal (Experience Cloud)     :p1e, 2027-01, 4M
    Medicaid Go-Live                       :milestone, m1, 2027-08, 0d

    section Phase 2 — Surveillance + Counties
    eCR inbound integration                :p2a, 2027-03, 4M
    County federation (Azure AD B2C)       :p2b, 2027-03, 5M
    Surveillance workflows + dashboards    :p2c, 2027-05, 5M
    County onboarding (10 initial)         :p2d, 2027-06, 4M
    CDC BioSense integration               :p2e, 2027-07, 3M
    County rollout (remaining 52)          :p2f, 2027-10, 6M
    Surveillance Go-Live                   :milestone, m2, 2028-06, 0d

    section Phase 3 — WIC + Vital Records + Portal
    WIC MIS integration                    :p3a, 2027-12, 4M
    WIC-Medicaid cross-enrollment          :p3b, 2028-02, 3M
    Vital records integration (Oracle)     :p3c, 2028-02, 4M
    Public portal + ID.me                  :p3d, 2028-04, 4M
    Full Program Complete                  :milestone, m3, 2029-02, 0d

    section Cross-Cutting
    FedRAMP authorization process          :cc1, 2026-07, 14M
    Heroku surge capacity build            :cc2, 2027-06, 4M
    Outbreak response drill                :cc3, 2028-01, 1M

Sequencing rationale: FedRAMP authorization runs parallel to Phase 1 build (12-18 month process). Medicaid first because it touches the most constituents (2.1M) and validates the MMIS integration pattern. County onboarding starts with 10 high-volume counties to prove the federation model before scaling to 62. WIC last because it depends on Medicaid constituent records for cross-program matching.

Governance & DevOps

Environment Promotion Flow

flowchart LR
    DEV1[GovCloud Dev Sandbox\nMedicaid Team] --> PC[GovCloud Partial Copy\nProgram-Level UAT]
    DEV2[GovCloud Dev Sandbox\nSurveillance Team] --> PC
    DEV3[GovCloud Dev Sandbox\nWIC + Vital Records] --> PC
    DEVPRO[GovCloud Dev Pro\nSI Partner] --> PC
    PC --> FC[GovCloud Full Copy\nUAT + Security Testing]
    FC -->|CISO Sign-Off Gate| PROD[GovCloud Production]

    FB1[Feature: MMIS\nRPA Integration] --> DEV1
    FB2[Feature: County\nData Normalization] --> DEV2
    FB3[Feature: WIC-Medicaid\nCross-Enrollment] --> DEV3
    FB4[Feature: eCR\nFHIR Inbound] --> DEVPRO

    HEROKU_DEV[Heroku Private Space\nDev] --> HEROKU_STG[Heroku Private Space\nStaging]
    HEROKU_STG --> HEROKU_PROD[Heroku Private Space\nProduction]

FedRAMP Boundary

All environments — including sandboxes — must reside within the FedRAMP authorization boundary (GovCloud instances). No PHI is permitted in non-GovCloud sandboxes. Post-refresh data masking is mandatory: SSN, DOB, and clinical fields are replaced with synthetic data using an automated Apex batch job.

Branching Strategy

VitalGov operates on a 36-month program with three overlapping phases, multiple teams, and strict separation of duties (Req 35). The branching model enforces auditability and compliance review gates.

Branch	Purpose	Merge Target
main	Production — CISO-approved deployments only	N/A
release/phase-1-medicaid, release/phase-2-surveillance, release/phase-3-wic-vr	Release stabilization per program phase	main (after CISO gate)
develop	Integration branch for all program teams	release/*
feature/VHS-[ticket]-[description]	Individual feature work	develop
hotfix/VHS-[ticket]-[description]	Production emergency fixes (outbreak response)	main + develop

Separation of duties (Req 35): Developers create feature branches and PRs. QA team merges to develop after testing. Release manager (infrastructure team) promotes release/* to production after CISO sign-off. No single individual can develop, test, and deploy the same change. Git branch protection rules enforce these gates.

Merge cadence: Feature branches merge to develop via PR with 2 required reviewers (1 developer + 1 security team member for any PHI-touching change). develop merges to release/* at sprint boundaries (3-week sprints — longer than typical due to compliance overhead). Release branches undergo CISO review before production promotion.

Outbreak emergency: Hotfix branches bypass normal sprint cycle. State CIO can authorize same-day production deployment for outbreak response features. Hotfix still requires 1 security reviewer and automated SAST scan — no exceptions.

Sandbox Strategy

Sandbox	Type	Purpose	Refresh Cadence	Data Seeding
VHS-DEV-MED	GovCloud Developer	Medicaid team — caseworker app, eligibility flows, MMIS integration	Sprint start	Synthetic: 5,000 constituents, 2,000 Medicaid enrollments, 500 providers. All PII synthetic (no production PHI)
VHS-DEV-SURV	GovCloud Developer	Surveillance team — eCR processing, county data normalization, CDC reporting	Sprint start	Synthetic: 1,000 surveillance cases, 10 county data feeds (mock 42-format samples), 500 immunization records
VHS-DEV-WIC	GovCloud Developer	WIC + Vital Records — cross-enrollment, vital records portal, ID.me integration	Sprint start	Synthetic: 2,000 WIC participants, 1,000 vital events, Medicaid-WIC overlap scenarios
VHS-SI	GovCloud Developer Pro	SI partner team — portal development, integration adapters, Heroku surge processor	Sprint start	Combined synthetic dataset from all three dev sandboxes
VHS-INT	GovCloud Partial Copy	Program-level UAT, cross-program data sharing validation, integration testing	Bi-weekly	Partial copy with post-refresh masking: 50,000 constituents, 20,000 enrollments, 5,000 cases, 500 providers. PHI fields masked via automated Apex batch
VHS-UAT	GovCloud Full Copy	Full UAT, security testing, FedRAMP continuous monitoring scans, penetration testing	Monthly	Full copy with post-refresh masking: all constituent records masked, all clinical fields replaced with synthetic data. Vulnerability scanning runs post-refresh

PHI masking protocol: Every sandbox refresh triggers an automated post-refresh Apex batch job that: (1) replaces all SSN fields with synthetic SSNs following valid format rules, (2) randomizes DOB within +/- 2 years, (3) replaces names with synthetic names preserving demographic distribution, (4) replaces addresses with synthetic addresses preserving state/county mapping, (5) clears all clinical notes and replaces with “[MASKED]”. This job must complete before any user accesses the refreshed sandbox.

Heroku environments: Heroku Private Space has its own Dev > Staging > Production promotion path. Heroku Postgres contains no PHI — only event metadata (counts, timestamps, county codes). Surge processor code deploys via Heroku CI/CD pipeline with GitHub integration.

Verify Heroku FedRAMP Status

As of 2025, Heroku Private Spaces are NOT listed as FedRAMP authorized on Salesforce’s compliance site (compliance.salesforce.com). Heroku holds SOC, PCI, HIPAA, and ISO certifications but not FedRAMP. For a government scenario requiring FedRAMP, verify current authorization status before assuming Heroku qualifies. An alternative surge architecture could use AWS GovCloud directly or Salesforce Functions (if available in GovCloud). The case study assumes Heroku FedRAMP authorization for the surge pattern — treat this as an area requiring validation with Salesforce’s public sector team.

Testing Strategy

Test Type	Coverage Target	Scope	Automation
Unit tests (Apex)	85% minimum (VHS standard)	Constituent matching logic, program enrollment workflows, HIPAA field-level security enforcement, cross-program visibility rules, county scoping logic	Apex tests run on every PR via GitHub Actions. PMD static analysis + Checkmarx SAST on every PR
Integration tests	All 12 external system connections	MMIS RPA screen reads (mock 3270), CDC FHIR R4 outbound, CMS EDI batch, SSA SFTP, USDA flat file, Vital Records Oracle extract, WIC MIS REST, IIS HL7 2.5.1, eCR FHIR inbound, 62-county SFTP normalization (10 format samples), ID.me OIDC, PeopleSoft SOAP	MuleSoft MUnit tests with mock services. Run before release branch merge
Security / HIPAA tests	All 4 program boundaries verified	Medicaid caseworker cannot see WIC clinical notes (FLS). WIC nutritionist cannot see Medicaid claims (FLS). County worker sees only their county data. Provider sees only their patients. Restriction Rules enforced. Shield encryption verified on SSN, DOB, clinical fields	Automated Apex test suite that runs queries in each program user context and asserts zero unauthorized field visibility. Run on every PR that touches sharing, FLS, or restriction rules
Performance tests	Sub-5s beneficiary lookup (Req 7); 15K determinations/day throughput; 10x surge capacity	MMIS RPA lookup latency, bulk eligibility processing throughput, eCR ingestion at 10x volume (5,000-20,000/day), county data normalization at scale (42 formats concurrent), Heroku surge processor under load	k6 load tests against Full Copy sandbox. Heroku surge tested with synthetic 500K event/day load
Surge / DR tests	10x normal volume; RPO 4h, RTO 8h (Req 37)	Heroku Private Space absorbs 500K events/day and writes to Salesforce via Bulk API at throttled rates without API limit breaches. Annual DR drill validates failover runbook. Backup/restore timing validated against RPO/RTO targets	Annual DR drill (FedRAMP requirement). Quarterly surge simulation. Documented in FedRAMP POA&M
UAT	All 4 programs + county onboarding	Medicaid caseworker eligibility workflow end-to-end, surveillance case from eCR to CDC report within 24h, WIC-Medicaid cross-enrollment, vital records request with ID.me verification, county data submission via SFTP, outbreak dashboard real-time refresh	Manual test scripts with program directors and county health officers (pilot counties)
Accessibility (508)	WCAG 2.1 AA compliance (Req 28)	All public-facing portals (constituent portal, provider portal), all internal caseworker interfaces	Automated axe-core scans on every portal page. Manual keyboard navigation testing quarterly

Center of Excellence & Ongoing Governance

VHS Health IT Center of Excellence (established Phase 1, month 3):

• Executive sponsor: State CIO (Dr. Angela Torres)
• CoE lead: Deputy CIO — Infrastructure (Kevin O’Brien)
• Members: 2 Salesforce admins, 3 developers (internal), SI lead architect, integration lead, CISO representative, program liaison from each directorate (Medicaid, Epidemiology, WIC, Vital Records)
• Responsibilities: Architecture decisions (via HITGB), FedRAMP continuous monitoring compliance, cross-program data sharing approvals, integration change management, county onboarding coordination, vendor management (SI partner, Azure AD B2C, Heroku)

Release cadence:

• Standard releases: Every 3 weeks (sprint boundaries). CISO sign-off required before production deployment. Automated SAST scan (PMD + Checkmarx) must pass. No production deployment on Fridays or during MMIS maintenance windows.
• Emergency releases (outbreak response): State CIO authorizes same-day deployment. Still requires 1 security reviewer and automated SAST. Post-deployment security review within 48 hours.
• FedRAMP quarterly gates: Every 90 days, a formal security assessment reviews all changes deployed since last gate. Findings enter POA&M tracker. Critical findings must be remediated before next production deployment.

Change management with separation of duties (Req 35):

Role	Can Develop	Can Test/Approve	Can Deploy
Developers (8)	Yes	No	No
QA / Program testers	No	Yes	No
Release manager (infrastructure)	No	No	Yes (with CISO sign-off)
CISO team (4 security staff)	No	Yes (security review)	No

County onboarding governance: Each county goes through a standardized onboarding process: (1) AD trust configured with Azure AD B2C broker, (2) county data format mapped in MuleSoft DataWeave, (3) county public group created in Salesforce, (4) pilot data submission validated, (5) county health officer trained. Target: 10 counties in Phase 2 initial wave, remaining 52 in rolling waves of 10-15 per quarter.

Post-program maintenance: SI partner retainer reduces from 25-person team to 10-person managed services team for 12 months post-program. State hires 4 additional internal Salesforce developers during Phase 2 (months 12-18) to reduce SI dependency. Knowledge transfer formalized with documentation requirements for every integration adapter and county mapping file.

Identity & SSO Flow

State Employee SSO (Okta SAML 2.0)

sequenceDiagram
    participant User as State Employee (3,200)
    participant Browser as Browser
    participant Okta as Okta<br/>(State IdP)
    participant SF as Salesforce GovCloud

    User->>Browser: Navigate to VHS Salesforce
    Browser->>SF: Request login page
    SF->>Browser: Redirect to Okta (SP-Initiated SSO)
    Browser->>Okta: SAML AuthnRequest
    Okta->>Okta: Authenticate (password + MFA)
    Note over Okta: MFA: YubiKey or Okta Verify push<br/>(state security policy)
    Okta->>Browser: SAML Response with Assertion
    Note over Okta,Browser: Assertion contains: email, program<br/>(Medicaid/Surveillance/WIC/VR),<br/>region (HQ/Regional 1-4),<br/>Federation ID
    Browser->>SF: POST SAML Assertion to ACS URL
    SF->>SF: Match Federation ID to User record
    SF->>SF: Assign program-specific<br/>Permission Set Group
    SF->>Browser: Session established

IdP: Okta (existing state identity provider for all 3,200 state employees). SCIM 2.0 provisioning syncs user lifecycle: new hires receive Salesforce access automatically based on Okta group assignment. Terminations deactivated same-day via SCIM deprovisioning.

MFA: Mandatory at Okta level. State security policy requires hardware key (YubiKey) or Okta Verify push notification — no SMS-based MFA (considered insufficient for PHI access). Satisfies both Salesforce MFA requirement and FedRAMP MFA control (IA-2).

Permission mapping: Okta groups map to Salesforce Permission Set Groups per program: VHS-Medicaid-Caseworker, VHS-Surveillance-Epidemiologist, VHS-WIC-Nutritionist, VHS-VitalRecords-Clerk, VHS-Admin, VHS-Executive. Cross-program access (e.g., Medicaid director viewing WIC enrollment status) handled via additional permission set assignments, not group changes.

County Health Worker Federation (Azure AD B2C Hub)

sequenceDiagram
    participant CW as County Health Worker (4,800)
    participant Browser as Browser
    participant Broker as Azure AD B2C<br/>(Federation Hub)
    participant CountyAD as County Active Directory<br/>(1 of 62)
    participant SF as Salesforce GovCloud

    CW->>Browser: Navigate to VHS Salesforce
    Browser->>SF: Request login page
    SF->>Browser: Redirect to Azure AD B2C<br/>(SP-Initiated SSO)
    Browser->>Broker: SAML AuthnRequest
    Broker->>Broker: Identify county from<br/>user email domain
    Broker->>Browser: Redirect to County AD
    Browser->>CountyAD: Authenticate with<br/>county credentials
    CountyAD->>CountyAD: County-level authentication<br/>(MFA varies by county)
    CountyAD->>Browser: Authentication token
    Browser->>Broker: Return to broker with token
    Broker->>Broker: Enrich claims: add county_code,<br/>county_name, program_access
    Broker->>Browser: SAML Assertion to Salesforce
    Note over Broker,Browser: Assertion: email, county_code,<br/>role, program_access,<br/>Federation ID (county-prefixed)
    Browser->>SF: POST SAML to ACS URL
    SF->>SF: JIT Provisioning on first login:<br/>create user, assign permission set,<br/>set County__c sharing
    SF->>Browser: Session established<br/>(scoped to county data)

Architecture: Azure AD B2C serves as a single federation hub between Salesforce and 62 county Active Directories. Salesforce maintains one SAML connection to the broker (not 62 individual connections). County email domains route authentication to the correct county AD.

County onboarding: Adding a new county requires: (1) one AD trust configuration in Azure AD B2C, (2) one public group created in Salesforce (VHS-County-[FIPS_Code]), (3) county-specific claims mapping in the broker. No Salesforce-side SSO configuration changes per county.

JIT provisioning: On first login, Salesforce creates the county worker user via SAML JIT. The Azure AD B2C assertion includes county_code (FIPS code), which maps to the county-specific public group for data scoping. County workers see only their county’s data plus statewide de-identified aggregate dashboards.

MFA challenge: County MFA policies vary (some require hardware tokens, others use SMS, a few have no MFA). The broker accepts whatever authentication the county AD provides. VHS mitigates this by: (1) requiring Azure AD B2C Conditional Access to enforce minimum authentication strength for counties with weak MFA, (2) restricting county workers to surveillance data only (no Medicaid PII, no vital records), (3) logging all county access via Shield Event Monitoring for audit.

Healthcare Provider Portal Authentication

sequenceDiagram
    participant Provider as Healthcare Provider (4,500)
    participant Browser as Browser
    participant EC as Experience Cloud<br/>Provider Portal
    participant SF as Salesforce GovCloud
    participant NPI as NPPES Registry

    Provider->>Browser: Navigate to Provider Portal
    Browser->>EC: Registration / Login page
    alt New Provider Registration
        Provider->>EC: Submit NPI number + identity info
        EC->>NPI: Verify NPI against NPPES registry
        NPI->>EC: NPI verification result
        EC->>SF: Create Provider Contact<br/>(Status: Pending Credentialing)
        SF->>Provider: Email with temp credentials
        Note over EC,SF: Credentialing review required<br/>before data access granted
    else Existing Provider Login
        Provider->>EC: Email + Password
        EC->>SF: Verify credentials
        SF->>SF: MFA challenge (TOTP required)
        Provider->>SF: TOTP code
        SF->>SF: Verify MFA
        SF->>Browser: Portal session<br/>(scoped to provider's patients)
    end

NPI verification: Providers register with their NPI (National Provider Identifier). System validates against the NPPES (National Plan and Provider Enumeration System) registry via API. Credentialing approval required before provider gains data access — prevents unauthorized access during registration window.

MFA: Mandatory TOTP for all provider portal users. Providers handle PHI (patient reports, immunization queries) and must meet HIPAA authentication requirements.

Public / Beneficiary Portal Authentication

sequenceDiagram
    participant Citizen as Public User / Beneficiary
    participant Browser as Browser
    participant EC as Experience Cloud<br/>Constituent Portal
    participant IDme as ID.me<br/>(NIST IAL2)
    participant SF as Salesforce GovCloud

    alt Vital Records Request (High Assurance Required)
        Citizen->>Browser: Navigate to Vital Records portal
        Browser->>EC: Request birth/death certificate
        EC->>Browser: Redirect to ID.me
        Browser->>IDme: Identity verification flow
        IDme->>IDme: NIST IAL2 verification<br/>(government ID + biometric)
        IDme->>Browser: OIDC token with verified identity
        Browser->>EC: Return with OIDC token
        EC->>SF: Match verified identity to<br/>Vital Event records
        SF->>Browser: Secure document delivery
    else Medicaid Pre-Screening (No ID Required)
        Citizen->>Browser: Navigate to Medicaid portal
        Browser->>EC: Pre-screening questionnaire
        Citizen->>EC: Submit anonymous pre-screening
        EC->>SF: Evaluate eligibility criteria
        SF->>Browser: Eligibility estimate<br/>(no PII stored)
    else WIC Appointment Booking (Basic Auth)
        Citizen->>Browser: Navigate to WIC portal
        Browser->>EC: Login / Register
        Citizen->>EC: Email + Password (basic auth)
        EC->>SF: Verify credentials
        SF->>Browser: WIC session<br/>(appointment booking, benefit balance)
    end

Tiered authentication: Public-facing services use three authentication tiers based on PHI sensitivity: (1) No authentication for Medicaid pre-screening (anonymous, no PII stored), (2) Basic email/password for WIC appointment booking and benefit inquiries, (3) ID.me NIST IAL2 identity proofing for vital records requests (birth/death certificates require legal identity verification). This tiered approach maximizes constituent access while meeting security requirements for each service type.

System-to-System Integration Auth

sequenceDiagram
    participant EXT as External System<br/>(MMIS / CDC / WIC MIS)
    participant MW as MuleSoft GovCloud
    participant SF as Salesforce GovCloud

    alt Outbound to Federal Systems (CDC, CMS, SSA, USDA)
        MW->>EXT: Protocol-specific auth<br/>(certificates, API keys per agency)
        Note over MW,EXT: Each federal system has its own<br/>auth requirements documented<br/>in interconnection agreements
    else Inbound from County Systems (SFTP)
        EXT->>MW: SFTP with county-specific<br/>SSH key pair
        MW->>MW: Validate source county<br/>via SSH key fingerprint
        MW->>SF: OAuth 2.0 Client Credentials<br/>+ dedicated Connected App
    else MuleSoft to Salesforce
        MW->>SF: OAuth 2.0 Client Credentials Flow
        SF->>SF: Validate Connected App<br/>(program-scoped permissions)
        SF->>MW: Access token (2h expiry)
        Note over MW,SF: Separate Connected Apps per program:<br/>VHS-Medicaid-Integration<br/>VHS-Surveillance-Integration<br/>VHS-WIC-Integration<br/>VHS-VitalRecords-Integration
    end

Connected App segmentation: Each program has its own Connected App with scoped API permissions. The Medicaid integration Connected App can access Constituent, Program Enrollment (Medicaid only), and Case (Eligibility type only). The Surveillance integration Connected App can access Case (Surveillance type only) and County Surveillance Data. This limits blast radius and supports HIPAA minimum necessary principle at the integration layer.

Federal interconnection agreements: Each federal system (CDC, CMS, SSA, USDA) requires a formal Interconnection Security Agreement (ISA) documenting: data types exchanged, encryption requirements, authentication method, authorized personnel, and incident response procedures. These are FedRAMP requirements managed by the CISO team.

Integration Error Handling

Integration	Pattern	Retry Strategy	Dead Letter Queue	Monitoring & Alerts	Fallback (Extended Outage)
MMIS Mainframe (RPA)	RPA screen reads (real-time) + batch file (bulk)	RPA: 2 retries with 3s interval per screen navigation step. If screen layout changes detected, RPA halts immediately (no blind retries). Batch: full retry next nightly cycle	RPA failures logged to MMIS_Integration_Log__c with screenshot capture of unexpected screen. Batch failures stored in MuleSoft DLQ with full record payload	PagerDuty alert to integration lead on any RPA screen layout change detection (potential mainframe update). Batch failure alerts to Medicaid Director if nightly load fails. RPA availability dashboard on State CIO portal	RPA down: Caseworkers see banner “Real-time MMIS lookup unavailable — showing data from last batch.” Last-known eligibility data from nightly batch serves as fallback. Caseworkers can use legacy 3270 terminal emulation as manual backup. Batch down: Salesforce operates with stale data (last successful batch). Medicaid Director notified. No eligibility determinations processed until batch restored or manual override authorized
CDC BioSense (FHIR R4)	Event-driven outbound (real-time + daily batch)	3 retries with exponential backoff (1min, 5min, 30min). CDC BioSense has its own retry expectations documented in interconnection agreement	Failed CDC reports stored in MuleSoft DLQ with full FHIR bundle payload. Each failed report tagged with cdc_report_due_date for compliance tracking	PagerDuty alert to Epidemiology Director if any reportable condition fails to transmit within 12 hours (half of 24-hour deadline). Daily CDC transmission compliance dashboard	Critical: 24-hour CDC reporting deadline (Req 12) is regulatory. If automated transmission fails for >12 hours, manual fallback: Epidemiology team exports case data and uploads directly to CDC BioSense web portal. State CIO notified if manual fallback activated
CMS MITA Hub (X12 EDI)	Batch outbound weekly	Full retry next weekly cycle. Individual EDI transaction failures: 2 retries with 1-hour interval	Failed EDI transactions stored in MuleSoft DLQ. Each transaction tagged with reporting period for compliance	Email alert to Medicaid Director and CMS liaison if weekly batch fails. Monthly EDI compliance report tracks successful vs. failed transactions	Weekly batch delayed to next cycle. CMS liaison notified per interconnection agreement. If 2 consecutive weekly batches fail, manual EDI file preparation and submission via CMS secure portal
SSA Death Verification (SFTP)	Batch bidirectional nightly	Full retry next nightly cycle. SFTP connection failures: 3 retries with 10-minute interval	Failed death record matches stored in MuleSoft DLQ. Records flagged for manual vital records review	Alert to Vital Records Registrar if nightly batch fails. Weekly SSA sync health report	Death verification delayed by 24 hours per missed batch. Vital Records team processes pending death certificates manually against SSA web portal. Same-day target (Req 19) reverts to legacy 72-hour SLA during outage
USDA FNS (Flat File)	Batch outbound monthly	Full retry within 48-hour window (USDA deadline is end of month + 5 business days). 3 retries with 4-hour interval	Failed FNS-798 file stored in MuleSoft DLQ with validation errors from USDA response	Email alert to WIC Director if monthly file rejected by USDA. Validation error details forwarded to WIC data team	Manual FNS-798 file preparation from WIC MIS data and direct upload to USDA portal. WIC Director authorizes manual submission
Vital Records Oracle (DB Extract)	Change data capture via MuleSoft DB connector nightly	Full retry next nightly cycle. DB connection failures: 3 retries with 5-minute interval	Failed record extracts stored in MuleSoft DLQ with Oracle row IDs for targeted re-extraction	Alert to Vital Records Registrar if nightly extract fails. Missing birth/death registrations visible via daily reconciliation count check	Salesforce vital records data stale by 24 hours per missed batch. Vital Records clerks access legacy Oracle web application for real-time data during outage. No public portal impact — vital records requests processed from last successful extract
WIC MIS (REST)	Request-reply for enrollment operations	3 retries with exponential backoff (5s, 30s, 5min). Timeout: 30s per request	Failed enrollment operations stored in MuleSoft DLQ. WIC participant notified of processing delay via SMS (Twilio)	Alert to WIC Director if WIC MIS unavailable for >30 minutes during clinic hours. Real-time WIC MIS availability dashboard	WIC enrollment processing paused. WIC clinics revert to paper-based enrollment with manual data entry when system recovers. Cross-program auto-identification (Req 15) delayed until WIC MIS connection restored
IIS Immunization Registry (HL7 2.5.1)	Request-reply for provider queries	2 retries with 3s interval per query. Connection pool with 50 concurrent connections	Failed queries logged to IIS_Query_Log__c. Provider sees “Immunization data temporarily unavailable”	Alert to Epidemiology Director if query failure rate exceeds 10% in any 1-hour window. Daily IIS query success rate report	Providers see message “Immunization records temporarily unavailable.” Surveillance workflows continue without immunization data — flagged for manual enrichment when IIS returns. No patient safety impact (immunization data is supplementary for surveillance)
eCR Provider Reports (FHIR eICR)	Event-driven inbound	3 retries at MuleSoft layer (1s, 10s, 60s). During surge (10x volume), Heroku Private Space buffers events and writes to Salesforce at throttled Bulk API rates	Failed eCR reports stored in Heroku Postgres with full FHIR eICR payload. Aged DLQ reports (>4h) escalated automatically	PagerDuty alert to Epidemiology Director if eCR processing backlog exceeds 500 reports. During declared outbreak, alert threshold drops to 100 reports. Heroku queue depth dashboard	Normal volume: Failed reports reprocessed from DLQ within 4 hours. Surge volume: Heroku buffers up to 500K events/day. If Heroku reaches capacity, providers see “Report received — processing delayed” acknowledgment. Reports queued in Heroku Postgres and processed in order when capacity frees
62 County SFTP Feeds	File-based ingest daily (42 formats)	Per-county retry: failed files re-processed next daily cycle. Format validation failures: file rejected with error report to county	Failed county files stored in MuleSoft DLQ per county. County-specific error reports generated with field-level validation details	Weekly county data quality dashboard for Epidemiology Director. Individual county alerts if a county misses 3 consecutive daily submissions	Missing county data for 1+ days visible on statewide surveillance dashboard as data gap. County health officers contacted directly. Large counties (population >200K) missing >2 days triggers escalation to State CIO

Reporting Domain Note

Reporting is a cross-cutting concern across all four programs with distinct compliance requirements. Medicaid reporting must align with CMS MITA standards (X12 EDI). Surveillance reporting must meet CDC BioSense 24-hour timeliness requirements. WIC reporting follows USDA FNS-798 specifications. Vital records reporting connects to SSA and state courts. Each reporting pipeline has its own error handling, retry, and compliance tracking as documented in the integration error handling table above. Executive dashboards use CRM Analytics with cross-program data (de-identified for county-level aggregation and identified for program directors within their authorized scope). All report access is logged via Shield Event Monitoring for HIPAA audit compliance (7-year retention per Req 27).

Presentation Strategy

In 30 minutes, go deep on three decisions: (1) 62-county identity federation via broker — the most novel architectural challenge, (2) MMIS mainframe integration (RPA + batch) — highest fragility risk, (3) HIPAA minimum necessary via field-level security across programs — demonstrates compliance depth. Cover remaining artifacts at summary level.