Capstone: NSA for a Healthcare System

Healthcare Scenario: MedAlliance Network

For this capstone, we design the NSA for MedAlliance — a regional healthcare network with 12 hospitals, 200+ clinics, and 3 million patient records across disparate legacy systems.

Key Challenges in Healthcare

Healthcare NSA Principles

Compliance Architecture

flowchart TD
    subgraph Access["Access Controls"]
        A1[Identity Provider
Azure AD / Okta]
        A2[Role-Based Access
Minimum Necessary]
        A3[Break-Glass
Emergency Override]
    end

    subgraph Data["Data Protection"]
        D1[Encryption at Rest
AES-256]
        D2[Encryption in Transit
TLS 1.3]
        D3[De-identification
Safe Harbor / Expert]
    end

    subgraph Audit["Audit & Accountability"]
        AU1[Immutable Audit Log]
        AU2[Access Monitoring]
        AU3[Breach Detection]
    end

    Access --> Data
    Data --> Audit

    style A1 fill:#e8f4f4,stroke:#3B9797
    style D1 fill:#f0f4f8,stroke:#16476A
    style AU1 fill:#fff5f5,stroke:#BF092F
                            

Target Architecture

flowchart TB
    subgraph L5["🏥 Patient Experience Layer"]
        direction LR
        E1[Patient Portal]
        E2[Clinician Workspace]
        E3[Mobile Health]
        E4[Telehealth]
    end

    subgraph L4["🤖 Clinical Intelligence Layer"]
        direction LR
        C1[Diagnostic AI]
        C2[Treatment Recommender]
        C3[Risk Predictor]
        C4[Clinical NLP]
    end

    subgraph L3["⚙️ Care Services Layer"]
        direction LR
        S1[Scheduling]
        S2[Orders & Results]
        S3[Medications]
        S4[Referrals]
    end

    subgraph L2["📊 Health Data Platform"]
        direction LR
        D1[FHIR Server]
        D2[Clinical Data Lake]
        D3[Real-time Events]
        D4[Consent Engine]
    end

    subgraph L1["☁️ Secure Infrastructure"]
        direction LR
        I1[HIPAA Cloud]
        I2[Network Isolation]
        I3[DR/HA Cluster]
        I4[Audit System]
    end

    L5 --> L4
    L4 --> L3
    L3 --> L2
    L2 --> L1

    style L5 fill:#e8f4f4,stroke:#3B9797
    style L4 fill:#f0f4f8,stroke:#16476A
    style L3 fill:#e8f4f4,stroke:#3B9797
    style L2 fill:#f0f4f8,stroke:#16476A
    style L1 fill:#e8f4f4,stroke:#3B9797
                            

Interoperability Layer

The critical challenge: connecting 3 different EHR systems into a unified data layer without replacing them. The FHIR Facade pattern wraps each legacy system with a standards-compliant API layer, allowing the rest of the architecture to interact with a single, consistent interface.

Integration Architecture

Rather than a point-to-point integration nightmare (N×N connections), MedAlliance uses a hub-and-spoke model with the FHIR server as the central hub. Each EHR connects once to the hub, and all consuming applications connect only to the hub:

• Epic (6 hospitals): Uses Epic's native FHIR R4 API — highest coverage (90% of clinical data exposed natively)
• Cerner (4 hospitals): Uses Cerner Millennium FHIR endpoints with custom extensions for proprietary fields (85% coverage)
• Legacy custom (2 rural clinics): Requires a custom HL7v2-to-FHIR transformation service that maps ADT, ORU, and ORM messages to FHIR Patient, Observation, and ServiceRequest resources (70% coverage, growing with each release)

Master Patient Index (MPI)

With 3M records across 3 systems, patient matching is critical. A single patient may have records in multiple systems under slightly different names, DOBs, or identifiers:

• Deterministic matching: Exact match on SSN (where available), MRN pairs, or insurance ID — handles ~60% of matches
• Probabilistic matching: Weighted scoring on name similarity, DOB, address, phone — handles remaining ~35%
• Manual review queue: Ambiguous matches (score between thresholds) flagged for human review — ~5% of cases
• Golden record: Once matched, a single authoritative patient identity is maintained; downstream systems reference this unified ID

{
  "interoperability_model": {
    "standard": "HL7 FHIR R4",
    "integration_pattern": "FHIR Facade",
    "approach": "Each legacy EHR gets a FHIR adapter that translates proprietary data to/from FHIR resources",
    "adapters": [
      { "system": "Epic", "method": "Epic FHIR API (native)", "coverage": "90%" },
      { "system": "Cerner", "method": "Cerner Millennium FHIR", "coverage": "85%" },
      { "system": "Legacy Custom", "method": "Custom HL7v2-to-FHIR transformer", "coverage": "70%" }
    ],
    "unified_patient_id": {
      "method": "Master Patient Index (MPI)",
      "matching": "Probabilistic + deterministic",
      "standard": "IHE PIX/PDQ"
    },
    "real_time_sync": {
      "method": "FHIR Subscriptions + Kafka event bus",
      "latency_target": "<5 seconds for critical clinical data",
      "fallback": "Polling every 60s if subscription fails"
    }
  }
}

Clinical AI Platform

Clinical AI in healthcare operates under fundamentally different constraints than AI in other industries. A wrong recommendation from a writing assistant is inconvenient; a wrong recommendation from a clinical AI could harm a patient. This shapes every architectural decision.

AI Model Governance Pipeline

Unlike enterprise AI where deployment speed is paramount, clinical AI requires rigorous validation before any patient-facing use:

• Development: Train on de-identified retrospective data; validate against known outcomes (sensitivity/specificity targets)
• Validation: Prospective silent evaluation — model runs alongside clinical workflow, predictions logged but not shown to clinicians; compare against actual outcomes
• Clinical trial: Controlled rollout to selected units; clinicians see AI suggestions; measure impact on outcomes, workflow disruption, alert fatigue
• FDA submission: For SaMD-classified models: prepare 510(k) or De Novo submission with clinical validation evidence
• Production monitoring: Continuous performance tracking with automated alerts on model drift, demographic disparity, or declining accuracy

Alert Fatigue Prevention

The biggest failure mode of clinical AI isn't inaccuracy — it's alert fatigue. If clinicians receive too many irrelevant alerts, they start ignoring all of them (including critical ones). MedAlliance's architecture includes:

• Tiered alerts: Critical (interrupts workflow), Informational (sidebar display), Background (logged only)
• Context-aware suppression: Don't re-alert for known conditions already being treated
• Configurable thresholds: ICU clinicians have higher alert tolerance than outpatient; specialty-specific tuning
• Override tracking: If >80% of a specific alert type is dismissed, trigger review for threshold adjustment

Health Data Governance

Healthcare data governance goes far beyond typical enterprise data management. Patient data has unique characteristics: it's highly sensitive, legally protected, generated across dozens of systems, and must be available in milliseconds when a patient arrives at an ER.

Health Data Platform Architecture

The Health Data Platform serves three distinct audiences with different access patterns:

• Clinical operations (real-time): Current patient state, medications, allergies, recent labs — sub-second access via FHIR server + Redis cache
• Analytics & population health (batch): Aggregated outcomes, cohort analysis, quality metrics — accessed via clinical data lake (Delta Lake)
• Research & AI training (de-identified): Large retrospective datasets for model training — accessed via de-identification pipeline with IRB approval

Consent Management

Patient consent is not just a checkbox — it's a runtime enforcement mechanism that governs every data access in real-time:

flowchart LR
    R[Data Request] --> CE[Consent Engine]
    CE --> |Allowed| DS[Data Service]
    CE --> |Denied| Block[Access Denied + Audit]
    CE --> |Partial| Filter[De-identified View]
    DS --> Audit[Audit Log]
    Filter --> Audit

    style CE fill:#3B9797,stroke:#3B9797,color:#fff
    style Block fill:#BF092F,stroke:#BF092F,color:#fff
    style Audit fill:#16476A,stroke:#16476A,color:#fff
                            

Gap Analysis: Current vs Target

Migration Strategy

Healthcare transformation must be incremental — there is no "shut down and rebuild" option when patients depend on systems daily:

• Phase 1 (Months 1-6): Deploy FHIR facade for Epic (largest system); implement MPI; build audit infrastructure
• Phase 2 (Months 7-12): Extend FHIR to Cerner + legacy; deploy consent engine; launch unified patient portal (read-only initially)
• Phase 3 (Months 13-18): Deploy first clinical AI (low-risk: scheduling optimization); build clinical data lake; enable real-time event streaming
• Phase 4 (Months 19-24): Launch high-risk clinical AI (sepsis, radiology) after validation; full bi-directional portal; population health analytics

Conclusion

Healthcare North Star Architecture is uniquely constrained by regulation, patient safety, and legacy system realities. The key insight: build an interoperability layer (FHIR Facade) over existing systems rather than replacing them, then layer clinical intelligence and patient experience on top. The consent engine and audit system aren't afterthoughts — they're foundational architectural components that govern all data flow.