Case Study 7: VitalGov Health Services - Presentation Notes

Work in Progress

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

Presentation Guide

This page turns the worked solution into a boardroom delivery outline. Use it after you have completed the case study and reviewed the reference solution.

Presentation Snapshot

Field	Detail
Open after	Worked Solution
Format	45-minute presentation + 45-minute Q&A
Study role	Rehearse structure, timing, and transitions
Related pages	Case Study Overview, Scenario Paper, Q&A Preparation

Presentation Focus

Go deep on three high-risk decisions and keep six supporting artifacts at summary level.

Opening (3 min)

Show Figure 1 (System Landscape).

“VitalGov Health Services must unify four public health programs serving 8 million residents while meeting FedRAMP High and HIPAA simultaneously. The three decisions that determine success: federating 62 county identity providers through a single broker, integrating a 20-year-old mainframe that cannot be modified, and enforcing HIPAA minimum necessary across programs sharing the same constituent record.”

Frame the scale: 3,200 state employees, 4,800 county workers across 62 independent agencies, 2.1M Medicaid beneficiaries, $45M over 36 months. State the Salesforce Government Cloud Plus single-org decision on Hyperforce with FedRAMP High Provisional ATO, which puts Agentforce, Data 360, and the Einstein Trust Layer inside the authorization boundary. Why multi-org was rejected: cross-program constituent matching across orgs creates HIPAA risk and data inconsistency. Why the 2024 assumption of “no AI in GovCloud” no longer holds: Salesforce achieved FedRAMP High on Government Cloud Plus, bringing Agentforce and Data 360 into the authorized footprint.

Deep Dive 1: 62-County Identity Federation (8 min)

Show Figure 5 (Identity Architecture) and Figure 9 (County Federation Sequence).

“62 counties, each with their own Active Directory. Configuring 62 individual SAML connections in Salesforce is operationally impossible. A single misconfiguration during a county AD migration takes down access for that county.”

Microsoft Entra External ID as federation hub. Each county federates their AD with the broker - one trust relationship per county. Salesforce sees a single SAML IdP. County code travels in the SAML assertion, drives JIT provisioning and sharing assignment. Onboarding a new county: one Entra trust + one Salesforce public group, no code deployment. The trade-off is a dependency on Microsoft Entra External ID availability, mitigated by the 99.99% SLA, FedRAMP High (public Azure) authorization, and a documented ISA for the cross-cloud traffic from Azure public cloud into Government Cloud Plus. Break-glass fallback: 62 pre-provisioned local login accounts (disabled by default) for declared identity outages.

State employees bypass the broker entirely - direct Okta SAML (Figure 8). Healthcare providers use Salesforce Identity as the IdP with mandatory TOTP MFA (Figure 10); NPPES is queried once during provider registration only for NPI verification, not on every login. Public uses ID.me at NIST IAL2 for vital records (ID.me is FedRAMP Moderate - cross-tier ISA to Government Cloud Plus); anonymous access for Medicaid pre-screening; basic auth for WIC booking (Figure 11).

Likely judge pushback: “Why not Azure AD B2C directly?” Answer: Microsoft Entra External ID is Microsoft’s next-generation CIAM product. It is not a rebrand of Azure AD B2C - Microsoft explicitly documents them as separate products with separate capability sets. Azure AD B2C continues to exist through at least 2030, but External ID is the current CIAM direction with modern token protection, passkeys, and phishing-resistant MFA. The architectural point is the federation hub pattern, not the specific Microsoft product. “What about counties with no IT staff?” Answer: two options - join a shared VHS-managed Entra External ID tenant where VHS provisions accounts directly, or receive local Experience Cloud login credentials for that county bypassing federation. “Are you aware ID.me is at FedRAMP Moderate while Salesforce is at FedRAMP High?” Answer: yes - the ISA map documents the Moderate-to-High flow with AO risk acceptance, and ID.me only passes identity assertions (not PHI).

Deep Dive 2: MMIS Mainframe Integration (8 min)

Show Figure 4 (Integration Architecture).

“The MMIS mainframe processes 15,000 eligibility determinations per day. It has no API. It runs COBOL. And we cannot touch it.”

Dual-path pattern: MuleSoft with a 3270 terminal emulation adapter for real-time caseworker lookups using a 40-concurrent-session pool against the mainframe, and nightly batch file extracts for bulk data refresh. Caseworker opens a constituent record - Salesforce shows last-known batch data immediately via Agentforce grounding on the Data 360 Unified Profile, and triggers the terminal emulation lookup for real-time confirmation only if the data is stale. If the lookup fails, caseworker sees batch data with a “last refreshed” timestamp.

Latency reality check: The sub-5-second target for 3270 screen navigation is aggressive. Each screen navigation step takes 1-2 seconds, and a full eligibility lookup may traverse 3-4 screens (5-8 seconds per lookup). At 15,000 daily lookups, a single-session adapter would take over 30 hours of continuous execution - not feasible. Mitigation: 40 concurrent sessions (negotiated with MMIS operations as the mainframe concurrency ceiling) serves ~190K interactive lookups per 8-hour workday, well above the target. A secondary 10-session overnight pool (23:00-05:00) pre-warms the Data 360 cache with the next day’s work-queue caseload so caseworkers hit cached data through Agentforce at sub-second latency rather than falling through to live 3270 on every lookup. Cache misses fall through to live navigation at 5-8 seconds. This is an explicitly temporary bridge until the planned MMIS replacement in 5-7 years.

Risk: MMIS screen changes break the terminal emulation adapter. Mitigation is screen change detection in MuleSoft, with alerting within 5 minutes of a field layout change. Weekend maintenance windows: graceful degradation to batch-only mode. Claims data is not persisted in Salesforce - displayed in a read-only Lightning component and discarded after session, reducing HIPAA scope.

Likely judge pushback: “Why not build a proper API layer on the mainframe?” Answer: Constraint 1 explicitly prohibits modifying the mainframe. An API layer (CICS web services or z/OS Connect) requires mainframe-side code changes. Terminal emulation via MuleSoft is the only non-invasive option. “With Agentforce in the picture, why not let the agent call the 3270 directly?” Answer: the agent grounds on the Data 360 cache, not on a direct 3270 session. The 3270 session pool sits behind the MuleSoft adapter with its own concurrency limits and screen-change detection; exposing it to arbitrary agent invocations would break concurrent-session budgets and create a non-deterministic load pattern on the mainframe.

Deep Dive 3: HIPAA Minimum Necessary Across Programs (7 min)

Show Figure 3 (Role Hierarchy and Sharing Model).

“Four programs share one constituent record, but HIPAA says each program can only access what it needs. A WIC nutritionist should not see Medicaid claims. A Medicaid caseworker should not see WIC clinical notes.”

Field-Level Security (FLS) via Permission Set Groups per program is the enforcement mechanism. The Constituent record is visible to all authorized staff, but field visibility varies by program role. This is an FLS problem, not a record-visibility problem - the same Person Account record is shared, but each program’s Permission Set Group controls which fields are visible. Medicaid caseworkers see all enrollment statuses across programs (needed for eligibility determination) but not clinical detail. WIC staff see demographic data and WIC fields only. Surveillance epidemiologists see de-identified aggregate data from all programs for outbreak analysis.

Record-level scoping is handled separately via sharing mechanisms. County workers see records where County__c matches their assignment through Apex Managed Sharing keyed on the VHS-County-[FIPS] public group - profiles do not scope records, the sharing mechanism does. Providers see only their own patients through a Sharing Set on an External Account Hierarchy. These are sharing model concerns distinct from the HIPAA field-level minimum necessary enforcement.

Audit: Shield Event Monitoring captures the defined event types (login, URI, API, Apex, Report, record view) relevant to PHI interaction. Shield Field Audit Trail separately retains field change history on Case, Constituent, and Vital Event for up to 10 years. Native EventLogFile retention is up to 1 year (Summer ‘24+), so a daily MuleSoft extract pipeline archives log files to AWS S3 GovCloud for the 7-year HIPAA compliance window. Event Monitoring does not universally log “every field read on every PHI field” - that’s an overstatement to avoid; the coverage is the documented event set plus the Field Audit Trail change history.

Likely judge pushback: “How do you test that FLS is actually working?” Answer: automated Apex test suite runs queries in each program user context using WITH USER_MODE, stripInaccessible(), or WITH SECURITY_ENFORCED to force FLS enforcement - Apex runs in system mode by default and bypasses FLS unless one of these keywords is explicitly used. Tests assert zero unauthorized field visibility and run on every PR that touches sharing, FLS, or permission sets.

Supporting Artifacts (10 min)

Data Model (1.5 min): Show Figure 2. Health Cloud Person Account as Constituent (4 KB per record - 10 GB at 2.5M constituents, not 5 GB; custom objects at 2 KB each; Eligibility_Audit__c is the top storage driver at 33 GB by Y3, archived to Big Object past 2 years). Program Enrollment master-detail child object tracks multi-program participation. Case object polymorphic across programs via record types. Shield encryption on SSN and DOB with deterministic encryption for matching. Contact Exposure object for contact tracing workflows linking Cases to exposed Constituents. Data 360 Unified Individual holds the cross-program identity resolution output.

Integration (2 min): Show Figure 4. MuleSoft Government Cloud (FedRAMP Moderate) handles protocol diversity - HL7 2.5.1 for IIS, FHIR R4 for CDC via Composite Graph API for hierarchical bundles (Bulk API flattens arrays and can’t ingest nested FHIR), X12 EDI for CMS, flat files for USDA. Data 360 Data Streams handles the 62-county 42-format ingest with zero-code mapping. MMIS 3270 emulation uses a 40-concurrent-session pool against the mainframe. Integration error handling table covers all 12 endpoints with pattern, retry, DLQ, monitoring, and fallback. Spring ‘26 note: all system-to-system integrations authenticate via External Client Apps (ECAs) with dedicated Integration Users - Connected Apps are blocked by default in Spring ‘26.

WIC Program (1 min): Phase 3 builds WIC workflows on the constituent foundation from Phase 1. Cross-program enrollment (Req 21) uses Data 360 Identity Resolution to auto-identify WIC-eligible Medicaid beneficiaries across the 35% overlap. Clinic scheduling uses Salesforce Scheduler with Health Cloud Intelligent Appointment Management - the correct product. Clinic worker mobile interface runs on Field Service Mobile with Briefcase Builder offline priming for rural locations with intermittent connectivity. USDA FNS-798 reporting automated through MuleSoft flat-file integration with audit trail.

Vital Records (1 min): Also Phase 3. Public portal with ID.me NIST IAL2 (FedRAMP Moderate, ISA documented) for birth/death certificate requests. SSA integration targets same-day death verification (down from 72-hour lag). Court-ordered amendments tracked with full audit history - requestor identity, court order reference, original and amended values, approval chain. Death-to-benefit cross-reference flags active Medicaid/WIC enrollments for the deceased. Oracle 11g is past end-of-life - migration priority is high due to staff attrition risk.

Data Migration (1 min): Medicaid 2.1M beneficiaries first - establishes constituent master. WIC cross-matches against existing records through Data 360 Identity Resolution (35% overlap, deterministic SSN + probabilistic name/DOB/address rulesets). Vital records load metadata only; images stay in legacy storage. No production PHI in sandboxes (different Shield tenant secrets between prod and sandbox; post-refresh masking batch writes synthetic plaintext rather than attempting to decrypt production ciphertext).

Governance (1 min): Health IT Governance Board monthly. Program directors own program changes; cross-program changes require board approval. FedRAMP continuous monitoring: quarterly assessments, monthly vulnerability scans, CISO gate before every production deploy. Separation of duties enforced through branching strategy and role-based deployment permissions. AI governance gate: CISO reviews every Agentforce agent definition, prompt template, and tool binding before deployment.

Environments (1 min): All sandboxes within Government Cloud Plus FedRAMP High boundary. PHI masking mandatory in all non-production environments via automated post-refresh Apex batch. GitHub Enterprise (FedRAMP) for CI/CD. Parallel AWS GovCloud environment track (FedRAMP High) for surge processor and SageMaker prediction scoring.

Roadmap (1.5 min): Show Figure 6. 36 months. Medicaid first (months 1-14) to validate MMIS integration, build constituent master, and stand up the Agentforce Eligibility Agent with human-in-the-loop audit capture. Surveillance second (months 10-24) to prove county federation and Einstein Prediction Builder outbreak scoring. WIC and vital records last, using existing constituent data. FedRAMP High authorization runs parallel for 14 months. County onboarding: 10 pilot counties, then rolling waves of 52.

Transitions

• Opening to Identity: “The first challenge is: who are all these users? 62 counties, each with their own identity system.”
• Identity to MMIS: “Once users can authenticate, the next question is: what data do they see? The most critical data lives on a 20-year-old mainframe.”
• MMIS to HIPAA: “With mainframe data flowing in alongside four programs, the compliance question becomes: who sees which fields from which program?”
• HIPAA to Supporting: “With the three highest-risk decisions covered, let me walk through the remaining artifacts.”
• Supporting to Close: “Before I wrap up, the three risks that keep me up at night and how this architecture addresses them.”

Closing (3 min)

Three risks and mitigation:

1. MMIS fragility: Terminal emulation with 40-session concurrent pool, pre-fetch cache and batch fallback; screen change detection; explicit bridge pattern with 5-7 year replacement horizon; Agentforce grounding on cached Data 360 records for sub-second caseworker experience while 3270 lookups serve as confirmation
2. Outbreak surge (10x): AWS GovCloud Lambda (FedRAMP High) absorbs spike, deduplicates and aggregates events; Composite Graph API writes nested FHIR to Salesforce at throttled rates respecting concurrent request and 250K/hour Platform Event limits; annual CP-4 functional exercise validates. Rationale is concurrent-limit and lock-contention driven, not a fictional separate Bulk API pool
3. County adoption: Pilot with 10 willing counties; identity broker minimizes county-side changes; standardization incentive program in year 2; elected county health officers kept informed through quarterly stakeholder briefings

“This is a government modernization where the architect must balance federal compliance mandates with the reality of 62 independent agencies, a mainframe that cannot be touched, and the possibility that a public health emergency will test every architectural decision at 10x scale.”

Timing Checkpoints

Segment	Duration	Cumulative
Opening	3 min	3 min
Identity Deep Dive	8 min	11 min
MMIS Deep Dive	8 min	19 min
HIPAA Deep Dive	7 min	26 min
Supporting Artifacts	10 min	36 min
Closing	3 min	39 min
Risk and Trade-offs	3 min	42 min
Buffer	3 min	45 min

Related Topics

• Case Study 07 Solution
• Q&A Preparation
• Presentation Structure
• Q&A Strategies

---

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.