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.
| Attribute | Details |
|---|---|
| Scale | 12 hospitals, 200+ clinics, 45K employees |
| Patients | 3M active records, 500K annual admissions |
| Current EHRs | 3 different EHR systems (Epic, Cerner, legacy custom) |
| Pain Points | No unified patient view, manual referrals, no clinical AI, slow lab results |
| Regulations | HIPAA, HITECH, state privacy laws, FDA (for clinical AI) |
| Goal | Unified patient experience + clinical AI augmentation + operational efficiency |
Key Challenges in Healthcare
Healthcare-Specific Architecture Constraints:
- Regulatory compliance — HIPAA requires encryption at rest and in transit, minimum necessary access, audit trails
- Patient safety — Clinical AI must be explainable and never override physician judgment
- Interoperability mandates — HL7 FHIR, CDA, DICOM required for data exchange
- Availability requirements — Clinical systems require 99.99% uptime; lives depend on it
- Legacy coexistence — Cannot rip-and-replace EHRs; must integrate alongside them
Healthcare NSA Principles
MedAlliance Architectural Principles:
- Patient-Centric — Single longitudinal patient record across all facilities
- FHIR-Native — All data exchange uses HL7 FHIR R4; proprietary formats translated at edge
- Zero-Trust + Consent-Driven — Every access authenticated, authorized, and audited; patient consent governs data flow
- AI-Augmented, Clinician-Controlled — AI suggests, clinicians decide; all AI outputs explainable
- Event-Driven Real-Time — Lab results, alerts, and status changes flow in real-time; no batch delays for clinical data
- Fault-Tolerant by Default — Graceful degradation; clinical systems operate even during partial outages
Compliance Architecture
HIPAA 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
MedAlliance North Star 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:
{
"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"
}
}
}Clinical AI Platform
Clinical AI Design Constraints:
- Explainability required — Every AI recommendation must cite evidence (papers, guidelines, patient data points)
- Clinician-in-the-loop — AI never auto-acts on clinical decisions; always presents as suggestion with confidence score
- FDA considerations — Diagnostic AI classified as Software as Medical Device (SaMD); requires validation pipeline
- Bias monitoring — Continuous monitoring for demographic disparities in AI predictions
- Audit trail — Every AI inference logged: input, output, model version, clinician action taken
| Use Case | Input | Output | Risk Level |
|---|---|---|---|
| Sepsis Early Warning | Vitals stream + labs | Risk score + alert | High |
| Radiology Assist | CT/MRI images | Findings + regions of interest | High |
| Clinical Documentation | Visit notes (audio) | Structured SOAP notes | Medium |
| Appointment No-Show | Patient history | Likelihood score | Low |
| Drug Interaction Check | Medication list | Alerts + alternatives | High |
Health Data Governance
Consent Management
Patient consent is not just a checkbox — it's a runtime enforcement mechanism:
Consent-Driven Data Access Flow
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
Consent Model:
- Granular consent: patients control which providers, which data types, which purposes
- Consent is enforced at the data platform layer — not individual applications
- Research data access requires separate consent + IRB approval + de-identification
- Emergency "break-glass" access for life-threatening situations — fully audited, time-limited
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.
Key Takeaway: In healthcare, the North Star is constrained by "first, do no harm." Every architectural decision must consider patient safety, regulatory compliance, and clinical workflow integration. The best architecture is one that clinicians barely notice — it just makes their work easier and safer.