Case Study 7: VitalGov Health Services - Worked Solution

Work in Progress

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

Reference Solution

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

Solution Snapshot

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

Only Open After Your Own Attempt

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

Assumptions

1. Single org on Salesforce Government Cloud Plus (on Hyperforce). FedRAMP High Provisional ATO authorized. Delivers unified constituent profile (Req 1), meets federal compliance for PHI, and avoids multi-org PHI synchronization. FedRAMP High unlocks Agentforce, Data 360, Einstein, and the Einstein Trust Layer inside the authorization boundary. Rejected multi-org because cross-program constituent matching across orgs creates HIPAA risk and data inconsistency.
2. Health Cloud + Experience Cloud + Shield + Data 360 + Agentforce + MuleSoft Government Cloud. Health Cloud provides the constituent/patient data model. Shield delivers encryption, Field Audit Trail, and Event Monitoring required for HIPAA. Data 360 handles cross-program identity resolution and unified profile (Req 1). Agentforce with Einstein Trust Layer grounds caseworker productivity agents on PHI safely. MuleSoft Government Cloud handles the protocol diversity (HL7, FHIR, EDI, SFTP, batch). MuleSoft Government Cloud and ID.me remain at FedRAMP Moderate; cross-tier flows are documented in an Interconnection Security Agreement (ISA) map.
3. MMIS stays untouched. MuleSoft with a 3270 terminal emulation adapter handles real-time screen reads; batch file integration handles bulk data. No mainframe modifications.
4. Microsoft Entra External ID as identity broker. Federate 62 county ADs through a single hub. Counties point their AD at the broker; Salesforce sees one IdP. Entra External ID is Microsoft’s next-generation CIAM product on the public Azure cloud at FedRAMP High; cross-cloud traffic is documented in the ISA map. Rejected 62 individual SAML configs (unmanageable).
5. Platform Events + AWS GovCloud for outbreak surge. Normal operations stay within Government Cloud Plus platform limits. Surge capacity via AWS GovCloud (FedRAMP High) absorbing 10x event volume, deduplicating and aggregating out-of-band, and writing to Salesforce asynchronously via Composite Graph API and Bulk API. Pub/Sub API is not available in Government Cloud, so event publishing from AWS GovCloud uses REST-based Platform Event publishing (Apex EventBus.publish() within Salesforce or the sObject REST API from external systems) rather than gRPC-based Pub/Sub API.

Key Architectural Decisions

Decision 1: Government Cloud Plus Single Org with Program Segmentation (D1)

Single Salesforce Government Cloud Plus org (on Hyperforce, FedRAMP High Provisional ATO) 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. FedRAMP High authorization covers Salesforce Platform, Health Cloud, Experience Cloud, Shield, Data 360, Agentforce, Einstein, and the Einstein Trust Layer within a single authorization boundary. 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)

Microsoft Entra External ID 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 Microsoft Entra External ID availability; mitigated by its 99.99% SLA and FedRAMP-authorized status.

Decision 3: MMIS Integration via 3270 Emulation + Batch (D5)

MuleSoft with a 3270 terminal emulation adapter performs screen reads for real-time caseworker lookups. Nightly batch files from MMIS feed Salesforce with bulk eligibility data. The sub-5-second target for live 3270 navigation is aggressive (each screen step takes 1-2 seconds across 3-4 screens), so a pre-fetch cache layer in MuleSoft anticipates caseworker lookups based on the daily work queue and caches recent eligibility snapshots. Cache hits serve at sub-second response; cache misses fall through to live screen navigation at 5-8 seconds. Trade-off: terminal emulation 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 Two-Layer Access Control (D2)

Cross-program access control operates at two distinct layers:

• Layer 1 — Field-Level Security (same record): FLS controls which fields a user can see on the shared Constituent (Person Account) record. A WIC nutritionist sees demographic and WIC-specific fields but not Medicaid claims detail fields. Medicaid caseworkers see enrollment status fields but not WIC clinical notes fields. Permission Set Groups per program define field-level visibility matrices on the Constituent record.
• Layer 2 — Record-Level Sharing (child objects): FLS cannot hide entire child object records (e.g., a WIC Assessment record) from a Medicaid worker. Hiding child records from other programs requires record-level controls: OWD Private on Case and program-specific child objects, with criteria-based sharing rules (evaluating a Program__c field on the record itself) or Apex Managed Sharing to grant access only to the correct program’s users.

Both layers are required. FLS alone would allow a Medicaid caseworker who has record access to a Case to see all fields on that Case, including WIC clinical notes. Record-level sharing alone would show users all fields on records they can access. The combination enforces HIPAA minimum necessary at both the record and field level.

Decision 5: Eligibility Determination Audit Trail (Req 13)

Every Medicaid eligibility determination creates an Eligibility_Audit__c record capturing: the caseworker (CreatedById + lookup to caseworker Contact), data sources consulted (multi-select picklist: MMIS, SSA, County SFTP, Manual Entry), decision rationale (long text field with structured template), determination outcome (Approved/Denied/Pending), and timestamp (CreatedDate, immutable). The object uses a Lookup relationship to the Medicaid Case (not master-detail) with a before-delete Apex trigger on Case that blocks deletion while audit records exist, preventing the federal audit chain from being destroyed by an accidental parent Case delete. Object-level permissions grant Create and Read only (no Edit, no Delete) to all users including administrators to preserve immutability. Shield Field Audit Trail is applied to the parent Medicaid Case object to track status changes over time; the audit object itself is append-only and does not benefit from Field Audit Trail. For the 10-year CMS retention window, records older than 2 years are archived to a Big Object (Eligibility_Audit_Archive__b) via a scheduled job, keeping the standard custom object at a manageable size.

At 15K determinations/day, this object reaches 16.5M records by year 3. Custom indexes on Determination_Date__c and Caseworker__c support auditor queries. CMS auditors receive a dedicated permission set with View All Records on Eligibility_Audit__c (scoped, not org-wide View All Data) to bypass sharing for cross-caseworker audit queries. Reports are pre-filtered to 90-day date ranges by default. For historical audits beyond 90 days, CRM Analytics provides pre-aggregated datasets refreshed nightly from the audit table.

Decision 6: Automated Outbreak Detection - Threshold Alerting + Einstein Prediction (Req 20, Req 34)

Outbreak detection combines deterministic threshold alerting (current surveillance volume) with predictive modelling (pattern recognition across historical surveillance, geographic clustering, and seasonal factors). Both layers run inside the FedRAMP High boundary.

Threshold alerting path (real-time + batch):

Configurable outbreak detection uses a Surveillance_Threshold__c custom metadata type storing: condition name, geographic scope (county/region/statewide), time window (24h/48h/7d), case count threshold, and alert recipients. Detection operates on a dual-path architecture:

• Real-time path: Each new eCR surveillance case triggers an Apex trigger that increments a running counter on County_Surveillance_Data__c. When the counter crosses the configured threshold, a Platform Event fires immediately to the Epidemiology Director with condition name, county, case count, and a direct link to the surveillance dashboard.
• Batch safety net: A scheduled Apex job runs every 4 hours, catches batch-imported county SFTP data and any missed real-time events, queries County_Surveillance_Data__c records within each configured time window, and fires Platform Event alerts when thresholds are breached.

Geographic clustering detection uses SOQL GROUP BY on county + condition + date range. Thresholds are maintained by epidemiologists via a custom Lightning app (no developer involvement to adjust).

Predictive path (Req 34 - outbreak prediction models):

Einstein Prediction Builder (FedRAMP High authorized on Government Cloud Plus) trains a supervised model on historical surveillance cases in Data 360, predicting the probability of an outbreak declaration per county per condition per 7-day window. Features: case count trends, weather anomalies, known seasonal patterns (influenza, RSV), prior outbreak history, county demographics. The model scores the predicted Outbreak_Risk__c field on County_Surveillance_Data__c nightly. High-risk scores flag the surveillance dashboard without sending automated alerts - Epidemiology Director reviews and decides whether to escalate. For deeper statistical modelling beyond Einstein Prediction Builder, the AWS GovCloud surge environment hosts an Amazon SageMaker notebook (FedRAMP High) that trains custom geo-temporal clustering models on de-identified case data exported from Data 360; scores are written back as a score feed into Outbreak_Risk_Score__c. This keeps prediction workloads on the stronger ML tooling while the decision and PHI stay on Government Cloud Plus. Both paths run in parallel to threshold alerting so that a model failure never silences the deterministic alerts.

Decision 7: Agentforce + Data 360 + Einstein Trust Layer for Caseworker Productivity (Req 8, Req 9, Req 12)

With Government Cloud Plus at FedRAMP High, Agentforce, Data 360, and the Einstein Trust Layer are inside the authorization boundary and available for the PHI workload. These directly address three requirements the solution would otherwise handle with custom Apex and cache layers.

Data 360 as the cross-program identity resolution and unified profile engine (Req 1):

Data 360 Data Streams ingest the 62-county surveillance feeds after MuleSoft normalization, the WIC MIS extract, and MMIS nightly snapshots into a single Unified Individual data model. Identity Resolution rulesets run deterministic matching on encrypted SSN plus probabilistic matching on name + DOB + address with configurable confidence thresholds; the output Unified Profile feeds back to Health Cloud Constituent (Person Account) as the master record. This replaces the custom Apex probabilistic-matching queue for the 35% WIC/Medicaid overlap problem. Calculated Insights in Data 360 support cross-program metrics (dual-enrollment rates, program overlap by county) without custom aggregation jobs.

Agentforce Eligibility Agent (Req 8, Req 9):

An Agentforce agent, grounded on the Data 360 Unified Profile and the Health Cloud Case record, handles the eligibility lookup workflow end-to-end for the 15K/day caseworker determinations. The agent navigates prior batch MMIS data, SSA death verification, county demographic context, and program history to produce a proposed determination with cited sources. Every proposed determination is human-in-the-loop: the caseworker approves, rejects, or modifies the agent’s suggestion in the Lightning record page, and both the agent’s proposal and the human decision land in the Eligibility_Audit__c record (with a new Ai_Assisted__c flag and Ai_Proposal_Summary__c text). The 4-minute-to-30-second target in Req 9 becomes achievable through agent-assisted navigation rather than fragile pre-fetch cache heuristics. Legacy pre-fetch cache remains as a fallback path for agent unavailability.

Einstein Trust Layer (mandatory for PHI grounding):

The Einstein Trust Layer enforces zero data retention with the model provider, dynamic grounding on allow-listed Salesforce objects only, PII masking of SSN and DOB in prompts leaving the authorization boundary, toxicity and prompt-injection detection, and full audit logging of every prompt and response. Every Agentforce interaction with PHI passes through the Trust Layer. The audit log is retained in Shield Event Monitoring and exported to AWS S3 GovCloud (Moderate crossing documented in the ISA) for the 7-year HIPAA window.

AI governance at the CoE:

Every agent definition, prompt template, and tool binding goes through a CISO review gate before deployment, captured in the Health IT Governance Board (HITGB) agenda. Agent behaviour is tested in a dedicated sandbox with synthetic PHI before promotion. Caseworkers receive mandatory Trust Layer and agent-handling training as part of Phase 1 rollout. If the Trust Layer detects a new failure mode (hallucination rate spike, prompt injection, PII leak), the agent is disabled through Setup and caseworkers revert to the manual workflow. This is a conservative baseline - Agentforce augments human decisions rather than replacing them.

Artifact 1: System Landscape

Figure 1. System landscape for VitalGov Health Services showing Salesforce Government Cloud Plus (FedRAMP High) as the unified platform for four public health programs, with Health Cloud plus Data 360 identity resolution, Agentforce grounded on the Einstein Trust Layer, Shield, and Salesforce Scheduler for WIC clinic scheduling. MuleSoft Government Cloud (FedRAMP Moderate) brokers protocol translation across eleven external systems spanning legacy mainframes (MMIS via 3270 terminal emulation), on-premises Oracle and Java systems, four federal reporting endpoints (CDC, CMS, SSA, USDA), 62 county SFTP feeds normalized from 42 formats. AWS GovCloud (FedRAMP High) runs the 10x eCR surge processor plus a SageMaker environment for outbreak prediction scoring.

Artifact 2: Data Model

Figure 2. Data model for VitalGov Health Services with Constituent as the Health Cloud Person Account hub for 2.1M state residents, Case polymorphically covering four program types via record types, Program Enrollment tracking 2.5M active participations across Medicaid, WIC, surveillance, and vital records, and County Surveillance Data staging daily submissions from 62 counties normalized from 42 distinct county-specific formats.

• 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

Figure 3. Role hierarchy for VitalGov Health Services with four program-aligned branches under the State CIO plus a CISO branch for HIPAA breach investigation and continuous monitoring, and a Deputy CIO branch for Integration Admin and Salesforce System Admin roles. The CISO branch does not use “Grant Access Using Hierarchies” upward through the program branches; instead, CISO receives scoped View All Records on audit objects (Eligibility_Audit__c, Shield Event Monitoring Big Objects, Case) via a dedicated permission set for breach investigation, with every access logged. Constituent (Person Account) access uses criteria-based sharing rules evaluating stamped fields on the Constituent record (a Flow stamps Has_Active_Medicaid__c, Has_Active_WIC__c, etc. as standard Checkbox fields on parent change - criteria-based sharing does not support Formula or Roll-Up Summary fields). Child object isolation uses criteria-based sharing on each child’s own Program__c field or Apex Managed Sharing where cross-object criteria are needed. FLS via Permission Set Groups controls which program-specific fields each role sees.

Object	OWD	Mechanism	Volume
Constituent (Person Account)	Private	Criteria-based sharing on stamped checkbox fields (Has_Active_Medicaid__c, Has_Active_WIC__c, Has_Active_Surveillance_Case__c, Has_Vital_Records__c) maintained by record-triggered Flow from Program Enrollment child; sharing rules evaluate stamped fields directly (not Formula or Roll-Up Summary - both unsupported in criteria-based sharing)	~2.5M - LDV
Program Enrollment	Controlled by Parent (Master-Detail to Constituent)	Inherits from Constituent; master-detail required to enable Flow-driven stamping on parent	~3.2M active - LDV
Case	Private	Assignment rules + criteria-based sharing on Program__c (4 rules); Apex Managed Sharing for county worker access when county-worker count requires program × county rule permutations	~200K/yr, ~600K by Y3
Case Investigation	Controlled by Parent	Inherits from Case	~200K/yr
Immunization Record	Controlled by Parent	Inherits from Constituent	Read-only from IIS
Vital Event	Private	Vital Records team only + legal override	~205K/yr
County Surveillance Data	Private	Apex Managed Sharing keyed on county public group; see rule-count analysis below	Daily from 62 counties
Provider	Private	Sharing Set via External Account Hierarchy (provider sees only their own patients); profile does not scope records, sharing mechanism does	~4.5K
Provider Enrollment	Controlled by Parent	Inherits from Provider	~4.5K
Eligibility_Audit__c	Controlled by Parent via Lookup + trigger-enforced immutability (not master-detail - prevents cascade delete)	CMS auditor permission set grants View All Records scoped to this object	~16.5M by Y3
Program	Public Read Only	Reference data - 4 programs	4

Criteria-based sharing rule count analysis (Req 38, Req 39, Req 40): Criteria-based sharing rules have a default limit of 50 per object, raisable to 500 via Salesforce support case. For VitalGov the counts are:

Object	Criteria-based rules needed	Approach
Case	4 (one per Program__c value: Medicaid, Surveillance, WIC, VitalRecords)	Fits within 50 default; no raised limit required
Constituent	4 (one per stamped checkbox: Has_Active_Medicaid__c etc.)	Fits within 50 default
County_Surveillance_Data__c	62 counties × 4 programs = 248 potential combinations	Exceeds 50 default; would need raised limit to 500, but still creates sharing recalc risk at 2.5M+ rows

County_Surveillance_Data__c does not use criteria-based sharing. Instead, it uses Apex Managed Sharing keyed on the county public group (VHS-County-[FIPS]) with a single Apex trigger that computes the correct public group ID from the County_FIPS__c field on insert and updates sharing on county change. This scales O(n) with records rather than O(counties × programs) with rules, avoids the 50/500 rule cap entirely, and drives the recalc path through the Apex trigger rather than the sharing recalculation engine.

Sharing table size projection (Constituent): 2.5M Person Accounts × 4 program-stamp sharing rules, each matching a subset of records based on stamped checkbox values. Worst-case share rows ~2M for the Medicaid stamp (largest overlap), decreasing for the other programs, so the Constituent sharing table is estimated at 4-6M share rows at Y3. Async sharing recalc fires on (a) stamped-field changes driven by Flow when a Program Enrollment is inserted, updated to Active, or expires, and (b) sharing rule changes. Realistic recalc time on the Full Copy sandbox at this volume is 15-45 minutes per rule change, validated during the Phase 1 performance test window.

Cross-program access (HIPAA minimum necessary): Two layers work together. On the shared Constituent (Person Account) record, FLS via Permission Set Groups per program controls which fields each role can see: a WIC nutritionist sees demographics and WIC fields but not Medicaid claims fields; a Medicaid caseworker sees enrollment status but not WIC clinical notes fields. For child object records (Cases, Assessments, Clinical Notes), FLS alone is insufficient because it controls field visibility on a record, not whether the record itself is visible. Child records are isolated via OWD Private on Case and program-specific objects, with criteria-based sharing rules that evaluate the Program__c field on each record to grant access only to that program’s users. Where criteria-based sharing is insufficient (cross-program eligibility lookups, County_Surveillance_Data scaling), Apex Managed Sharing provides programmatic record-level grants.

County scoping: County health workers see only records where County__c matches their assignment, enforced through Apex Managed Sharing with the VHS-County-[FIPS] public group. Profile does NOT scope records - a profile controls object/field permissions but never restricts which records a user sees. Statewide aggregate dashboards (de-identified) available to all county leads through a separate dataset in Data 360.

CISO access pattern: The CISO branch of the hierarchy is for organizational reporting only - hierarchy does not grant upward access into the program branches. For HIPAA breach investigation, the CISO and Security Analysts use a dedicated VHS-Security-Investigator permission set that grants View All Records scoped to Eligibility_Audit__c, Shield EventLogFile, and Case (breach-under-investigation flag only). This grants cross-caseworker record access without the blunt View All Data permission, and every access is logged to Shield Event Monitoring with a mandatory “reason code” Apex trigger capturing the breach investigation ticket number.

Artifact 4: Integration Architecture

Figure 4. Integration architecture for VitalGov Health Services with MuleSoft Government Cloud (FedRAMP Moderate, with documented ISA to the Government Cloud Plus FedRAMP High tier) handling protocol translation across five distinct formats: 3270 terminal emulation with a 40-concurrent-session pool and pre-fetch cache for MMIS mainframe screen reads, HL7 FHIR R4 via Composite Graph API for nested CDC BioSense and eCR inbound bundles (Bulk API cannot ingest hierarchical FHIR), X12 EDI for CMS MITA weekly batch, HL7 2.5.1 for immunization registry queries, and Data 360 Data Streams ingesting 62 county feeds with YAML-based mapping (DataWeave reserved for the few counties with exotic legacy formats).

System	Pattern	Protocol	Volume
MMIS	3270 terminal emulation + cache (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
State ERP (PeopleSoft)	Batch (bidirectional)	SOAP	Monthly

County data normalization: MuleSoft brokers the 62 county SFTP feeds, but the heavy-lift normalization lands in Data 360 Data Streams with YAML-based mapping per source. Data 360 provides built-in provenance lineage, out-of-the-box DLQ, schema drift detection, and zero-code ingestion. Custom DataWeave transforms handle the few counties with genuinely exotic formats (less than 10 of the 42). New format = new Data 360 mapping, no MuleSoft code changes.

MMIS 3270 concurrency and session pool: The 3270 terminal emulation adapter navigates MMIS screens for individual beneficiary lookups. A single synchronous lookup takes 5-8 seconds across 3-4 screen transitions. Handling 15,000 daily lookups (many surfaced during caseworker interactive use) requires a pooled concurrent terminal session design: the MuleSoft 3270 adapter maintains 40 concurrent sessions against MMIS (the documented MMIS concurrency ceiling negotiated with the mainframe operations team). At 40 concurrent sessions × 6 seconds per lookup × 8 active hours, the pool serves roughly 190K interactive lookups per workday - well above the 15K target. A secondary 10-session pool runs an overnight pre-fetch job (23:00-05:00) that warms the Data 360 cache with the next day’s work-queue caseload. Cache hits serve at sub-second response via Agentforce grounding on cached Data 360 records; cache misses fall through to an on-demand live 3270 lookup. Nightly batch extracts eligibility snapshots (full 2.1M records) for Salesforce refresh. If terminal emulation fails mid-session, caseworker sees “MMIS temporarily unavailable” with last-known data from the batch extract.

eCR hierarchical FHIR ingestion: eCR bundles are deeply nested FHIR structures (Patient → Condition → Encounter → Observation). Bulk API flattens CSV/JSON arrays to a single object and cannot ingest a nested FHIR bundle atomically. The ingestion path uses the Composite Graph API, which supports up to 500 nodes per payload in a single REST call with a single transaction boundary and atomic rollback. Failed graph submissions are retried individually from the Amazon RDS buffer. Bulk API is reserved for the nightly MMIS flat-file refresh where the source is already flat.

Outbreak surge (pivoted justification - see API and Platform Event analysis below): Normal daily volume ~50K transactions. During a public health emergency, eCR volume can spike to 20K+/day and Platform Event fan-out can reach 60-100K/hour at peak. AWS GovCloud (FedRAMP High) absorbs the surge via Lambda functions, deduplicates and aggregates events in Amazon RDS PostgreSQL, and writes to Salesforce via Composite Graph API (for hierarchical FHIR) and Bulk API (for flat record sets) at throttled rates. The AWS buffer exists not because Bulk API has a separate daily pool (it does not - see the API Limit Analysis section) but because of concurrent-request limits, record lock contention on shared child tables, the 250K/hour Platform Event publishing cap, and elastic scale-out that Salesforce write capacity cannot match second-by-second during a public health emergency.

Artifact 5: Identity & SSO

Figure 5. Identity architecture for VitalGov Health Services with four distinct authentication paths: Okta SAML 2.0 with SCIM lifecycle for 3,200 state employees; Microsoft Entra External ID acting as a single federation hub aggregating 62 county Active Directories so Salesforce maintains only one SAML connection; Salesforce Identity with mandatory TOTP for 4,500 healthcare providers (NPPES registry is queried once during provider registration for NPI verification - it is not a runtime IdP); and tiered public access ranging from anonymous Medicaid pre-screening to ID.me NIST IAL2 identity proofing for vital records requests.

• 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): Microsoft Entra External ID 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 Entra External ID, one public group in Salesforce. Entra External ID runs on the public Azure cloud at FedRAMP High; the cross-cloud SAML flow is captured in the Interconnection Security Agreement (ISA) map below as an explicitly approved cross-environment traffic path.
• Healthcare providers (4,500): Salesforce Identity is the provider portal IdP. NPI verification against the NPPES registry happens once during registration only, not on every login; NPPES is not an IdP. After registration approval, providers log in with Salesforce Identity username/password plus mandatory TOTP MFA. Credentialing approval required before data access.
• Public/beneficiaries: Experience Cloud public portal with ID.me for identity verification (NIST IAL2 for vital records requests). ID.me runs at FedRAMP Moderate; the cross-tier flow into Government Cloud Plus (FedRAMP High) is documented in the ISA map with an Authorizing Official (AO) risk acceptance. Medicaid pre-screening does not require identity verification. WIC appointment booking requires basic authentication.

FedRAMP Authorization Boundary and ISA Map

FedRAMP High workloads that accept data from FedRAMP Moderate services require a documented Interconnection Security Agreement (ISA) per NIST SP 800-47 Rev 1 and AO risk acceptance. The VitalGov architecture has five cross-boundary flows that require ISA documentation:

Component	FedRAMP Level	Cloud Environment	Crossing Into	ISA Requirement
Salesforce Government Cloud Plus	High	Salesforce Hyperforce Gov	Primary authorization boundary for PHI	Baseline SSP
AWS GovCloud (US)	High	AWS Gov	Salesforce Gov Cloud Plus	Gov-High to Gov-High; ISA documents data types, authentication, incident response
MuleSoft Government Cloud	Moderate	MuleSoft Gov	Salesforce Gov Cloud Plus	Moderate-to-High ISA with AO risk acceptance; data types restricted to what MuleSoft must see; PHI payloads encrypted in transit with Salesforce-managed keys wherever feasible
ID.me Identity Gateway	Moderate	ID.me FedRAMP Moderate	Salesforce Gov Cloud Plus (via Experience Cloud OIDC)	Moderate-to-High ISA; ID.me returns identity assertions, not PHI; AO risk acceptance documents the one-way flow
Microsoft Entra External ID	High (public cloud)	Azure Public Cloud	Salesforce Gov Cloud Plus	Cross-environment (Public-High to Gov-High) ISA; AO risk acceptance documents county worker authentication flowing through Microsoft’s public cloud before reaching Gov-High Salesforce

The CISO owns the ISA package per FedRAMP continuous-monitoring requirements. ISAs are reviewed annually and after any material change to any connected component.

JIT provisioning: County workers provisioned on first login via SAML JIT with a custom Auth.SamlJitHandler Apex class. Standard SAML JIT maps user fields only (name, email, profile, Federation ID) and cannot assign Permission Sets or Permission Set Groups. The custom JIT handler reads the county code, role, and program access claims from the SAML assertion, creates the user record, programmatically assigns the correct Permission Set Group (e.g., VHS-WIC-Nutritionist), adds the user to the county-specific Public Group for data scoping, and sets County__c on the user record.

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 and is not migrated. Salesforce queries MMIS via the 3270 terminal emulation adapter 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
Gov Cloud Plus Production	Live system	N/A
Gov Cloud Plus Full Copy	UAT + security testing	Monthly
Gov Cloud Plus Partial Copy	Program-level UAT	Bi-weekly
Gov Cloud Plus Dev Sandbox (x3)	Medicaid / Surveillance / WIC-VR teams	Sprint start
Gov Cloud Plus Dev Pro	SI partner	Sprint start

All sandboxes must be Government Cloud Plus instances (FedRAMP High 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: Government Cloud Plus provides built-in geo-redundancy across Hyperforce regions within the FedRAMP boundary. RPO 4 hours met by platform replication. RTO 8 hours met by documented failover runbook. The annual DR drill satisfies NIST SP 800-53 Rev 5 control CP-4 (Contingency Plan Testing) required at the FedRAMP High baseline. CP-4 High requires an annual functional exercise (not just tabletop), so the drill must actually fail over Salesforce platform, MuleSoft connections, AWS GovCloud surge processor, county SFTP endpoints, and all four identity paths - and capture a post-exercise lessons-learned feeding the POA&M tracker. Outages of less than 10 minutes during the drill are acceptable; anything longer is a POA&M finding.

Shield Encryption Operational Considerations

Shield Platform Encryption introduces several operational constraints that the architecture must account for:

1. Query limitations on encrypted fields. Deterministic encryption on SSN supports exact-match equality and works with the Data 360 identity resolution pipeline. Probabilistic encryption is incompatible with ORDER BY, aggregate functions (SUM, COUNT, MAX, MIN), LIKE, or range queries - so any batch job that needs to range-query DOB (e.g. “find all constituents born in a given year”) must either use deterministic encryption on DOB (accepted trade-off) or maintain a separate non-encrypted derived field (Year_Of_Birth__c) specifically for range queries. For the eligibility renewal 90-day lookahead (Req 10), ExpirationDate on Program Enrollment is not encrypted, so range queries are unaffected.

2. Sandbox refresh key mismatch. Production and sandbox use separate Shield tenant secrets by design - encrypted values in production ciphertext cannot be decrypted by a freshly-refreshed sandbox. The post-refresh Apex masking batch runs after the refresh completes and writes synthetic plaintext to the sandbox, which is then re-encrypted by Shield using the sandbox tenant secret. The masking job does not attempt to decrypt production ciphertext. This means the masking batch must regenerate all encrypted fields (SSN, DOB, clinical text) from scratch rather than transforming existing values.

3. Data 360 encryption interop. Data 360 does not automatically inherit Shield Platform Encryption from the source Salesforce org. The architecture enables Shield Platform Encryption for Data 360 (Hyperforce-native encryption) as a separate configuration step and documents the key management chain. PHI flowing from Health Cloud into Data 360 transits over internal Salesforce infrastructure (encrypted at rest and in transit on both sides) but is re-encrypted on ingest rather than decrypted, making PHI visible to Data 360 compute nodes only transiently for identity resolution.

4. Einstein Trust Layer and encrypted fields. When Agentforce grounds on Health Cloud records containing encrypted fields, the Einstein Trust Layer applies PII masking to prompts leaving the model provider’s zero-data-retention boundary. SSN is masked before the prompt is sent; DOB is masked where not required by the agent’s reasoning. The agent sees what it needs to operate; the model provider never sees unmasked PHI.

Artifact 9: Phased Delivery Roadmap

Figure 6. Phased delivery roadmap for VitalGov Health Services with FedRAMP High authorization as a 14-month cross-cutting workstream running in parallel with the Phase 1 Government Cloud Plus build, Medicaid first to validate the MMIS 3270 integration pattern with 2.1M constituents and stand up the Agentforce Eligibility Agent with human-in-the-loop review, disease surveillance and county federation rollout in Phase 2 starting with 10 high-volume counties, and WIC cross-enrollment and vital records with ID.me public portal completing the 36-month program.

Sequencing rationale: FedRAMP High 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 3270 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

Figure 7. Environment promotion flow for VitalGov Health Services with all Salesforce environments as Government Cloud Plus (FedRAMP High) instances within the FedRAMP authorization boundary, four program-team sandboxes promoting through a Partial Copy for cross-program UAT to a Full Copy with mandatory CISO sign-off before every production deployment, plus a parallel AWS GovCloud Dev to Staging to Production track for the surge processor, with automated PHI masking running after every sandbox refresh.

FedRAMP Boundary

All environments - including sandboxes - must reside within the FedRAMP High authorization boundary (Government Cloud Plus instances). No PHI is permitted in non-Gov Cloud Plus 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	Gov Cloud Plus Developer	Medicaid team - caseworker app, eligibility flows, MMIS 3270 integration	Sprint start	Synthetic: 5,000 constituents, 2,000 Medicaid enrollments, 500 providers. All PII synthetic (no production PHI)
VHS-DEV-SURV	Gov Cloud Plus 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	Gov Cloud Plus 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	Gov Cloud Plus Developer Pro	SI partner team - portal development, integration adapters, AWS GovCloud surge processor	Sprint start	Combined synthetic dataset from all three dev sandboxes
VHS-INT	Gov Cloud Plus 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	Gov Cloud Plus 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.

AWS GovCloud environments: AWS GovCloud has its own Dev > Staging > Production promotion path. Amazon RDS PostgreSQL serves two roles: (1) the surge processor metadata store holds only event metadata (counts, timestamps, county codes) with no PHI, and (2) the dead letter queue (DLQ) store holds failed eCR FHIR eICR payloads that do contain PHI. The DLQ RDS instance is therefore within the BAA boundary, encrypted at rest with AWS KMS (FIPS 140-2 validated), and subject to the same access controls and audit logging as other PHI-bearing systems. Surge processor code deploys via AWS CodePipeline with GitHub integration.

AWS GovCloud FedRAMP Status

AWS GovCloud (US) is FedRAMP High authorized, matching Salesforce Government Cloud Plus at the same FedRAMP High tier. Lambda, RDS, SageMaker, and all services used in the surge and prediction architecture are within the FedRAMP authorization boundary. Gov-High to Gov-High data flow between AWS GovCloud and Salesforce Government Cloud Plus is documented in the ISA map and does not require cross-tier risk acceptance.

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 3270 terminal emulation (mock mainframe screens), 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 enforced via WITH USER_MODE / stripInaccessible() / WITH SECURITY_ENFORCED in Apex - note that Apex runs in system mode by default and bypasses FLS unless one of these enforcement keywords is used). WIC nutritionist cannot see Medicaid claims (FLS). County worker sees only their county’s records (Apex Managed Sharing via county public group; profiles do not scope records). Provider sees only their own patients (Sharing Set via External Account Hierarchy). Shield encryption verified on SSN, DOB, clinical fields	Automated Apex test suite that runs queries in each program user context using WITH USER_MODE (or the equivalent) to force FLS enforcement and assert zero unauthorized field visibility. Run on every PR that touches sharing, FLS, or permission sets
Performance tests	Sub-5s beneficiary lookup (Req 9); 15K determinations/day throughput; 10x surge capacity	MMIS terminal emulation lookup latency (cache hit vs. miss), bulk eligibility processing throughput, eCR ingestion at 10x volume (5,000-20,000/day), county data normalization at scale (42 formats concurrent), AWS GovCloud surge processor under load	k6 load tests against Full Copy sandbox. AWS GovCloud surge tested with synthetic 500K event/day load
Surge / DR tests	10x normal volume; RPO 4h, RTO 8h (Req 37)	AWS GovCloud Lambda 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, Microsoft Entra External ID, AWS GovCloud)

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 Microsoft Entra External ID broker, (2) county data format mapped in Data 360 Data Streams (or MuleSoft DataWeave for the few counties with exotic formats), (3) county public group created in Salesforce with Apex Managed Sharing wiring, (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)

Figure 8. State employee SSO sequence for VitalGov using SP-initiated Okta SAML 2.0 with SCIM 2.0 lifecycle management, where mandatory YubiKey or Okta Verify push MFA satisfies both the Salesforce MFA requirement and FedRAMP IA-2 control. Permission Set Group assignments are handled by SCIM provisioning (not at SAML login time), with Okta group membership driving program-specific PSG assignment for cross-program HIPAA data separation.

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 (Microsoft Entra External ID Hub)

Figure 9. County health worker federation sequence showing Microsoft Entra External ID as the single broker between Salesforce Government Cloud Plus and 62 county Active Directories, where the broker identifies the county from the user’s email domain, routes authentication to that county’s AD, enriches the resulting claims with FIPS county code and program access attributes, and delivers a single SAML assertion to Salesforce where a custom Auth.SamlJitHandler Apex class provisions a county-scoped user record on first login (standard SAML JIT cannot assign Permission Set Groups or Public Group membership).

Architecture: Microsoft Entra External ID 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 Microsoft Entra External ID, (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, a custom Auth.SamlJitHandler Apex class processes the SAML assertion from Microsoft Entra External ID. Standard SAML JIT maps user fields only and cannot assign Permission Sets or Groups, so the custom handler is required. It creates the user record, reads the county_code (FIPS code) from the assertion, assigns the program-specific Permission Set Group, and adds the user to the county-specific Public Group (VHS-County-[FIPS_Code]) 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 Microsoft Entra External ID 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

Figure 10. Healthcare provider portal authentication sequence for VitalGov with NPI-based registration triggering NPPES registry verification and a mandatory credentialing review gate before any patient data is accessible, ensuring 4,500 providers handle PHI only after identity and professional credential verification, with mandatory TOTP MFA on all subsequent logins meeting HIPAA authentication requirements.

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

Figure 11. Public and beneficiary portal authentication sequence for VitalGov using three tiers matched to PHI sensitivity: anonymous Medicaid pre-screening stores no PII and requires no login, WIC appointment booking uses basic email and password authentication, and vital records requests require ID.me NIST IAL2 identity proofing with government ID and biometric verification before Salesforce delivers legally sensitive birth or death certificate documents.

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

Figure 12. System-to-system integration authentication for VitalGov showing three distinct auth paths: outbound federal systems using agency-specific certificates and API keys governed by formal Interconnection Security Agreements, inbound county SFTP submissions validated via per-county SSH key fingerprints, and MuleSoft to Salesforce OAuth 2.0 JWT Bearer flow through four program-scoped External Client Apps (ECAs) each bound to its own dedicated Integration User. Object-level isolation is enforced by the Integration User’s profile and permission set group, not by the ECA itself - the ECA is an OAuth client identity, not an authorization boundary.

Spring ‘26 Connected Apps are disabled: As of Spring ‘26 Salesforce disables Connected App creation by default for all orgs. All new integrations use External Client Apps (ECAs), which are packaged via second-generation packaging and support modern OAuth flows (JWT Bearer, Client Credentials) but not the legacy username-password flow. VitalGov is green-field on Spring ‘26+ and cannot create legacy Connected Apps.

Per-program isolation via Integration Users (not OAuth scopes): Each ECA binds to a dedicated Integration User: integration.medicaid@vhs.gov, integration.surveillance@vhs.gov, integration.wic@vhs.gov, integration.vitalrecords@vhs.gov. Each Integration User holds a profile plus a scoped Permission Set Group granting Create/Read on exactly the objects its program needs. For example, the Medicaid Integration User has CRUD on Constituent, Program Enrollment (with record type filter = Medicaid via Apex trigger), and Case (Eligibility type only). The Surveillance Integration User has CRUD on Case (Surveillance type only) and County Surveillance Data. OAuth scopes on the ECA control API categories (REST, Bulk, Connect) and refresh behaviour, not object access - object access is always profile plus permission set on the user the ECA authenticates as. This is the correct mental model; describing “Connected App scopes granting object access” is a common misunderstanding of Salesforce auth.

Token lifetime: Access tokens follow the policy configured on each ECA (default 2 hours, configurable up to 24 hours via Session Settings and token exchange policy). VitalGov sets 2-hour tokens with refresh token rotation for system-to-system flows and 30-minute tokens for high-sensitivity Vital Records integration.

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 (3270 Emulation)	Terminal emulation + cache (real-time) + batch file (bulk)	Emulation: 2 retries with 3s interval per screen navigation step. If screen layout changes detected, adapter halts immediately (no blind retries). Batch: full retry next nightly cycle	Emulation failures logged to MMIS_Integration_Log__c with screenshot capture of unexpected screen. Batch failures stored in MuleSoft DLQ with full record payload	Alert to integration lead on any screen layout change detection (potential mainframe update). Batch failure alerts to Medicaid Director if nightly load fails. MMIS integration availability dashboard on State CIO portal	Emulation 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 access 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 16) 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), AWS GovCloud Lambda deduplicates and buffers events, then writes to Salesforce via Composite Graph API for hierarchical FHIR bundles and Bulk API for already-flattened records, at throttled rates that respect concurrent-request and Platform Event limits	Failed eCR reports stored in Amazon RDS PostgreSQL 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. AWS CloudWatch queue depth dashboard	Normal volume: Failed reports reprocessed from DLQ within 4 hours. Surge volume: AWS GovCloud buffers up to 500K events/day. If Lambda reaches concurrency limits, providers see “Report received - processing delayed” acknowledgment. Reports queued in Amazon RDS PostgreSQL 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 (formerly Tableau CRM) 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).

Automated Renewal Processing (Req 10)

Expiring Medicaid enrollments require proactive outreach 90 days before expiration. A scheduled Apex batch job runs nightly against Program Enrollment records where ExpirationDate falls within the 90-day window and RenewalOutreachStatus__c is null. The job creates a Renewal Case (record type: Medicaid Renewal) and triggers outreach via the constituent’s preferred notification channel (SMS via MuleSoft Twilio connector, email via Salesforce email service, or portal notification). Caseworkers see the renewal pipeline on their productivity dashboard with aging buckets (90-60-30 days). If the constituent completes self-service renewal via the portal, the Case auto-closes and MMIS is updated via the next nightly batch. If no response within 30 days, the Case escalates to a caseworker for manual follow-up.

Contact Tracing Workflows (Req 17)

Outbreak investigations require tracking exposure relationships between confirmed cases and potentially exposed contacts. A Contact Exposure junction object links a source Case (confirmed) to exposed Constituent records with fields for exposure date, location, exposure type (household, workplace, healthcare facility, community), risk level, and follow-up status. When a surveillance Case is confirmed as a reportable condition, a Flow generates Contact Exposure records from case investigation data. County health workers assigned to the investigation update follow-up status (contacted, tested, cleared, confirmed). During outbreak surge, the contact tracing workflow scales through the AWS GovCloud buffer - new exposure records are queued and written to Salesforce via Bulk API. Real-time outbreak dashboards show contact tracing completion rates by county.

WIC Program Workflows (Req 3, Req 22)

WIC clinic operations require scheduling, nutrition assessment, and benefit issuance in a single visit. The WIC workflow uses Salesforce Scheduler with Health Cloud Intelligent Appointment Management - the correct product for patient-facing clinic scheduling. Salesforce Scheduler provides provider availability, patient self-scheduling via Experience Cloud, multi-resource scheduling for co-located clinic staff, no-show risk scoring, and integration with Health Cloud. This directly satisfies Req 3 (WIC appointment scheduling via web and mobile) and Req 22 (clinic scheduling and nutrition assessment workflows). Nutrition Assessment is a custom object (child of Constituent) capturing anthropometric measurements, dietary recall, nutrition risk factors, and breastfeeding status - these are the HIPAA-sensitive clinical fields hidden from non-WIC Permission Set Groups. Benefit issuance uses a WIC Benefit object tracking monthly food package allocation, EBT card assignment, and redemption status. The mobile clinic worker interface (Phase 3) is built on Field Service Mobile with Briefcase Builder for offline priming and High Volume Priming for clinics that pre-load their next-day caseload overnight; these are now supported for offline appointment data and offline custom object capture. Nutrition assessment entry is cached on device and synced within 5 minutes of connectivity restoration via the Field Service sync engine. USDA FNS-798 reporting pulls from these objects via a scheduled report that maps to the flat-file format required by MuleSoft’s USDA integration.

Court-Ordered Amendments (Req 27)

Vital records amendments are the highest-risk workflow because they change legal identity documents. A Vital Record Amendment object (child of Vital Event) tracks: requestor identity (verified via ID.me NIST IAL2), court order reference number and jurisdiction, original field values, requested amended values, and approval chain status. The workflow requires three sequential approvals: Vital Records Clerk (data entry), Vital Records Manager (verification against court order), and Vital Records Registrar (final authorization). Each approval step captures the approver, timestamp, and notes. Amendment history is retained permanently alongside the original record. Shield Event Monitoring captures login, URI, API, Apex execution, Report, and other defined event types relevant to amendment records; the RecordViewEvent stream captures who opened an amendment record page and when, and Shield Field Audit Trail retains all field changes on Vital Event and Vital Record Amendment for up to 10 years. (Note: Event Monitoring does not universally log “every field read” on every PHI field - the coverage is the documented event set, not a universal field-read capture.) The original certificate is never overwritten - amended certificates are issued as new documents referencing the original, and both versions are preserved in the system of record.

Licensing, API Limits, and Storage Analysis

License Model

User Population	Count	License Type	Rationale
State employees - caseworkers and program staff	~2,500	Health Cloud	Full constituent data model, case management, program workflows, access to Person Account clinical objects
State employees - admin and management	~700	Salesforce (Enterprise Edition)	Platform licenses exclude several standard objects (Account, Contact, Case, Opportunity, Lead) by default; admin/management staff need Case access for governance dashboards, so a full Salesforce license (EE) is the correct fit. Rejected Platform because the cost saving doesn’t survive the object-access gap
County health workers	4,800	Experience Cloud - Customer Community Plus Login	External users performing writes on Case and County_Surveillance_Data (Req 15) plus role-hierarchy-based sharing; Customer Community Plus is the only external license supporting role-based sharing. Login-based pricing (county workers average 15-20 logins per month, well below the login cost breakeven vs. member-based)
Healthcare providers	4,500	Experience Cloud - Customer Community Login	Portal access for eCR submission, immunization queries, credentialing; read-mostly with occasional writes. Login-based aligns with typical provider usage (5-10 logins/month)
Public portal - authenticated	~300K projected Year 1	Experience Cloud - Customer Community Login	WIC booking and vital records requests are authenticated sessions. Login-based pricing (not MAU) - cost scales with monthly logins consumed per month
Public portal - unauthenticated (guest users)	Variable	None - unauthenticated guest user	Medicaid pre-screening, clinic locator, general information. Guest users are unauthenticated by definition; there is no “authenticated guest” license type in Salesforce

Government Cloud Plus pricing carries a premium over commercial Salesforce. CMS federal match covers 60% of Medicaid-related license costs. Experience Cloud login-based licensing scales with monthly logins consumed, not monthly active users - the distinction matters in contract negotiation because a single user may consume multiple logins per month, and unused provisioned logins can be repooled. Rejected member-based licensing for the public portal because the 300K projected active-user population would exceed the breakeven login volume.

API Limit Analysis

Req 54 requires 20,000 API calls per hour normal operations and 200,000 per hour during declared surge. Translating to a working-day window (10 hours of peak caseworker and provider activity plus light background batch), the expected daily budget is approximately 200K during normal operations and up to 2M during a sustained surge - not the 45K and 120K figures in the prior draft, which undercounted portal traffic, internal UI API calls, and inter-component callouts. The table below reconciles to the hourly requirement:

Integration category	Hourly API (Normal)	Hourly API (Surge)	Pattern
Caseworker Lightning / Agentforce UI API	~6,000	~6,000	Internal REST from UI
Provider portal traffic (4,500 providers)	~2,500	~3,000	Experience Cloud API
Public portal (constituent)	~4,000	~5,000	Experience Cloud API
MMIS 3270 emulation → SF writes	~1,500	~1,500	Inbound from MuleSoft
IIS immunization queries	~800	~800	Outbound callout
eCR provider reports	~200	~10,000+ (buffered via AWS)	Inbound via MuleSoft
County SFTP ingest via Data 360	~500 (burst)	~5,000 (burst)	Bulk API ingest
CDC BioSense outbound	~50	~500	Outbound callout
All other integrations	~1,500	~1,500	Mixed
Total per hour	~17,000-20,000	~33,000 (Salesforce-bound) + 200K+ absorbed by AWS buffer

Daily API Request Limit is a single shared pool. REST, SOAP, Bulk, and Connect API all consume the same Salesforce Daily API Request Limit - there is no separate “Bulk API daily allocation” (a common misconception). The Daily API Request Limit at Enterprise Edition is 100,000 base + 1,000 per Salesforce full license (capped). With 3,200 full licenses: 100,000 + (3,200 × 1,000) = 3.3M calls per 24-hour period. Normal-day traffic at 200K/day consumes roughly 6% of the limit. A declared surge sustained at 200K/hour × 24h = 4.8M exceeds the daily limit, which is why the AWS buffer is architectural, not optional.

Bulk API has a separate batch count limit (15,000 batch submissions per 24 hours, each batch up to 10,000 records) but its API requests still count against the shared pool.

Why the AWS GovCloud surge buffer exists (pivoted from “Bulk API separate pool” claim): The AWS buffer absorbs surge capacity for five concrete platform reasons, not because Bulk API has its own pool:

1. Concurrent long-running API request limits. Salesforce enforces concurrent Apex-callout and async request caps (25 concurrent long-running async Apex requests; 10 concurrent Bulk V1 batches per Bulk job). A 10x surge hits these caps before it hits the daily limit.
2. Row-lock contention. 10x inbound eCR writes land on shared parent Constituent/Case rows and generate sharing recalc cascades. Lock contention causes retries, timeouts, and back-pressure to MuleSoft. AWS buffering deduplicates and aggregates events before they reach Salesforce to reduce parent-row contention.
3. Platform Event publishing ceiling (see Platform Event Allocation Analysis below) - 250K events/hour hard cap.
4. Elastic scale-out. Lambda and RDS scale horizontally in seconds; Salesforce write capacity is bounded by storage I/O and cannot match second-by-second surge burst velocity during a public health emergency.
5. Storage governance. Buffering outside Salesforce lets the AWS layer apply deduplication and aggregation before records land, reducing LDV pressure on the main org.

Platform Event Allocation Analysis

Platform Events have two distinct limits that Bulk API does not:

• Hourly publishing limit: 250,000 events per hour baseline on Performance/Unlimited editions, raisable to 275K with an add-on.
• Daily delivery allocation: External subscriber deliveries are counted per subscriber; the same event delivered to N external subscribers counts as N deliveries.

Outbreak surge modelling:

During a declared outbreak, eCR volume can spike to 500K events/day (Req 18 target) with peak concentration not uniform across the day. Realistic epidemiologic surge concentration yields peak-hour rates of 3-5x the daily average:

• 500,000 events/day ÷ 24h = ~21K events/hour average
• Peak hour at 4x average = ~84K events/hour
• Downstream Platform Event fan-out: each eCR case creation triggers four downstream events (threshold check, Contact Exposure fan-out, county notification, dashboard refresh). At 84K peak-hour eCR cases × 4 events = 336K events/hour - exceeds the 250K/hour baseline

Mitigation:

1. Batch publishing via Composite API. Pub/Sub API is not available in Government Cloud. Instead of one Platform Event per downstream action, the AWS GovCloud surge processor batches event creation requests using the Composite API (up to 25 subrequests per call) and the Bulk API for high-volume writes, cutting the hourly publish count significantly.
2. Selective downstream publish. Threshold check events are suppressed once an outbreak is declared (the threshold is already breached; no point re-evaluating). County notification is published once per county per hour instead of per case. Dashboard refresh uses Change Data Capture for the county aggregate table, not a per-case Platform Event.
3. Purchase the Platform Event High-Volume add-on during declared outbreak if mitigations above prove insufficient; the add-on raises the hourly cap to 275K and is priced for burst purchase.
4. AWS buffer deduplication. The AWS Lambda surge processor aggregates eCR writes from multiple providers reporting the same case within a dedup window before publishing to Salesforce, reducing the event count at source.

The CoE maintains a live Platform Event consumption dashboard during declared outbreak, with an alert at 200K events/hour (80% of baseline).

Storage Projection

Salesforce per-record storage sizing per official docs: Person Accounts = 4 KB each (2 KB Account + 2 KB Contact), standard custom objects and most standard objects = 2 KB each. Prior drafts that treated Person Accounts as 2 KB were off by a factor of 2.

Object	Year 1 Records	Year 3 Records	Per-record Size	Estimated Storage (Y3)
Constituent (Person Account)	2.1M (Medicaid) + 120K (net new WIC)	2.5M	4 KB	10 GB
Program Enrollment (custom)	2.5M	3.2M active + 2M historical	2 KB	10.4 GB
Case (all types)	200K	600K	2 KB	1.2 GB
Eligibility_Audit__c (custom, year 3 only standard custom; older records archive to Big Object)	5.5M	16.5M (unarchived at steady state)	2 KB	33 GB (primary storage driver)
Contact Exposure (junction) - normal	50K	200K	2 KB	0.4 GB
Contact Exposure (junction) - major outbreak scenario	-	Up to 2M during pandemic-scale outbreak	2 KB	Up to 4 GB additional during outbreak
County Surveillance Data	100K	300K	2 KB	0.6 GB
Vital Event	205K	615K	2 KB	1.2 GB
Vital Record Amendment (child of Vital Event)	2.4K	7.2K	2 KB	Negligible
Nutrition Assessment (WIC clinical child)	0 Y1	600K	2 KB	1.2 GB
WIC Benefit	0 Y1	2.4M (12,000/month × 36 months)	2 KB	4.8 GB
Shield Event Monitoring (Big Object)	High volume	High volume	N/A (Big Object separate allocation)	10+ GB (Big Object)
Total standard data storage (Y3)				~62 GB + outbreak surge buffer
Projection under major outbreak				~66+ GB

Government Cloud Plus storage allocation: 10 GB base + per-license additions. With 3,200+ full Salesforce licenses, total data storage allocation exceeds 130 GB, leaving a healthy buffer. Eligibility_Audit__c is the dominant storage driver at 33 GB (year 3) - this must be tracked on the monthly CoE storage dashboard. Mitigation: records older than 2 years move to a Big Object (Eligibility_Audit_Archive__b) via a scheduled job, keeping the standard custom object at ~10 GB steady state. Big Objects are in a separate storage allocation from standard data storage.

EventLogFile retention: EventLogFile is retained natively for up to 1 year with the Event Monitoring Event Log File Storage feature (Summer ‘24+). HIPAA’s 7-year retention still requires archival outside the 1-year window, so a MuleSoft scheduled extract pipeline pulls EventLogFile data daily and writes to AWS S3 GovCloud (FedRAMP High authorized) for long-term archival. Shield Field Audit Trail (a separate Shield component) retains record field change history in Big Objects for up to 10 years and is applied to the parent Medicaid Case and Vital Event objects.

File storage: Vital record certificate images stay in legacy Oracle system (metadata-only migration). Caseworker attachments for eligibility determinations (supporting documents scanned or uploaded) flow to Salesforce Files, projected at ~200 GB by Year 3 - tracked separately from data storage.

Presentation Strategy

In 45 minutes, go deep on three decisions: (1) 62-county identity federation via broker - the most novel architectural challenge, (2) MMIS mainframe integration (3270 emulation + batch) - highest fragility risk, (3) HIPAA minimum necessary via two-layer access control (FLS for field visibility + record-level sharing for child object isolation) across programs - demonstrates compliance depth. Cover remaining artifacts at summary level.

Scoring Rubric

Criterion	Weight	What Judges Look For
Security & Compliance	25%	FedRAMP High (Salesforce Gov Cloud Plus) + HIPAA dual compliance mapped to specific controls. Interconnection Security Agreement (ISA) map with AO risk acceptance documented for cross-tier flows. HIPAA minimum necessary via two-layer access control (FLS for fields + record-level sharing for child objects) across 4 programs. 62-county identity federation architecture. HIPAA-compliant audit logging with up to 1-year native EventLogFile retention (Summer ‘24+) extended to 7 years via MuleSoft extract to S3 AWS GovCloud. Einstein Trust Layer controls for PHI grounding in Agentforce
Integration Architecture	25%	MMIS mainframe integration (3270 emulation + concurrent session pool + batch - highest fragility risk). CDC BioSense FHIR R4 reporting via Composite Graph API for hierarchical payloads. 62-county SFTP feeds via Data 360 Data Streams (42 formats). HL7 2.5.1 immunization registry. Platform Event hourly publishing limit analysis for surge modelling. Shared-pool API limit math. Each endpoint with pattern, retry, DLQ, monitoring, and fallback. AWS GovCloud surge buffer with correct pivot justification (concurrent limits, lock contention, Platform Events, elastic scale-out)
System Architecture	20%	Government Cloud Plus single-org justification with FedRAMP High. Agentforce, Data 360, Einstein Trust Layer inside authorization boundary. AWS GovCloud for surge buffering and SageMaker-hosted outbreak prediction scoring. Microsoft Entra External ID broker for 62 county IdPs (recognizing External ID is not rebranded B2C). Salesforce Scheduler with Health Cloud Intelligent Appointment Management for WIC clinics. Phased delivery across 4 programs. Licensing for state employees + county workers + public portal users (login-based, no “authenticated guest” fiction)
Data Architecture	15%	Cross-program participant identity resolution via Data 360. Correct per-record storage sizing (Person Account 4 KB, custom object 2 KB). Eligibility_Audit__c as primary storage driver with Big Object archival. Mainframe data migration strategy. Data residency and retention per program (Medicaid, surveillance, WIC, vital records). De-identification for reporting. County data quality normalization
Communication & Presentation	15%	Three deep-dive decisions clearly presented and defended. Novel 62-county federation architecture explained accessibly. Mainframe fragility risk acknowledged with mitigation. Regulatory compliance articulated with specifics, not generalities. 2026 product landscape awareness (Spring ‘26 ECA migration, FedRAMP High AI stack, MITA 4.0 / MES framework)

---

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.