HMS Reference Architecture#

Conceptual Explanation#

The HMS AI platform is organized around three principles that govern every architectural decision:

Clinical workflow primacy: AI must serve the clinical workflow, not require the workflow to adapt to AI. Every component that touches a clinician's daily workflow — CDS alerts, documentation tools, prior auth assistance — is designed around the clinical interaction pattern, not around the AI system's technical convenience.

Defense in depth for PHI: No single control is sufficient for PHI protection. The architecture layers HIPAA controls — network isolation, encryption at rest and in transit, access control, audit logging, BAA coverage — so that failure of any single control does not expose patient data.

Governance at every boundary: Every boundary in the architecture — between the clinical application and the AI gateway, between the AI gateway and the LLM vendor, between the AI output and the EHR medical record — is a governance control point. Governance is not a post-deployment review; it is embedded in the technical architecture.

Core Architecture#

Architecture Diagram#

The high-level architecture diagram is shown in the Core Architecture section above. Standalone .mmd files:

• architecture/mermaid/07-hms-full-architecture.mmd — Full system diagram
• architecture/mermaid/07-hms-ehr-integration-sequence.mmd — EHR integration sequence
• architecture/mermaid/07-hms-governance-flow.mmd — Governance decision flow

Common Mistakes#

Deploying the Platform in Full Before Any Use Case Is Live. Organizations that spend 9 months building the complete platform before deploying a single use case cannot validate platform design decisions against real clinical workflows. Build incrementally: the platform emerges from use case requirements, not from design documents.

FHIR API Rate Limit Discovery at Production Scale. Epic's FHIR API rate limits are not published; they are negotiated with the health system. Organizations that design AI systems without confirming API rate limits discover the constraint when they go to production with high-volume use cases. Confirm rate limits with the EHR vendor early.

Governance Without Accountability. A Model Review Board that approves use cases without defined accountability for post-deployment quality is governance theater. The MRB must own the monitoring responsibility: who reviews the quality dashboard weekly, who escalates override rate anomalies, who initiates incident response when a quality event occurs.

Best Practices#

• Build the AI gateway and prompt registry before the first use case — retrofitting governance infrastructure after use cases are live is significantly harder
• Register CDS Hooks services and SMART on FHIR applications with the EHR vendor before technical build — the registration process takes weeks and may require EHR vendor review
• Sign HIPAA BAAs with all LLM vendors before any clinical data is transmitted
• Maintain the clinical vector store as a shared resource — never allow individual use cases to maintain their own copies of institutional clinical knowledge
• Design the governance model around the CMIO, not the IT department — clinical AI governance requires clinical leadership to be credible

Alternatives#

The HMS reference architecture uses a custom AI gateway (LiteLLM-based) + independent LLM vendors. Alternative architectural approaches:

Trade-offs#

Interview Questions#

Q: A hospital CIO asks you to design the AI architecture for a hospital deploying 7 clinical AI use cases over the next 18 months. Walk me through your design.#

Category: System Design Difficulty: Principal Role: AI Architect / FDE

Answer Framework:

Start with the governance structure, because the technical architecture serves the governance requirements, not the other way around. The first deliverable is a risk tier classification of all 7 use cases: which are Tier 1 (directly influence patient care), which are Tier 2 (operational), which are Tier 3 (administrative). This classification determines what governance approval each use case requires, what evaluation criteria apply, and what the oversight model looks like post-deployment.

Then the shared infrastructure: AI gateway (before use case 1), prompt registry (before use case 1), HIPAA BAAs signed with all LLM vendors (before any clinical data is transmitted), EHR SMART on FHIR registration (weeks of lead time with Epic). These are the blocking infrastructure items that must precede use case development.

The EHR integration pattern depends on use case type: SMART on FHIR applications for workflow-embedded tools (discharge summary, clinical knowledge search); CDS Hooks services for in-workflow recommendations (medication safety, care gap alerts); HL7 v2 ADT feed via integration engine for event-driven background processing (admission event → discharge planning context enrichment).

Shared clinical infrastructure: a single clinical vector store serving all knowledge retrieval use cases (guidelines, formulary, prior auth criteria), populated and maintained by the AI platform team. Individual use cases query the shared store — they do not maintain their own knowledge bases.

Observability is not optional for clinical AI: OpenTelemetry tracing (metadata only — no PHI in traces), a quality scorer that evaluates AI outputs against golden datasets, and a clinical AI dashboard visible to the CMIO and Model Review Board. Override rate monitoring for all clinical use cases.

Key Points to Hit:

• Start with governance and risk tier classification
• Shared infrastructure first — gateway, prompt registry, BAAs, EHR registration
• EHR integration pattern depends on use case type — SMART vs. CDS Hooks vs. ADT
• Single shared clinical vector store
• Observability with no PHI in traces
• Override rate monitoring as the post-deployment quality signal

Key Takeaways#

• The HMS AI platform is not a single system — it is a set of shared infrastructure components that enable multiple clinical AI use cases without rebuilding foundational capabilities for each one
• Build order matters: AI gateway, prompt registry, and BAAs before the first use case; shared vector store and CDS Hooks before use case 3
• The CMIO and Model Review Board are governance requirements, not optional oversight — clinical AI governance needs clinical leadership to be credible
• PHI flows through the AI gateway under BAA coverage to LLM vendors; audit logs use hashed identifiers; observability traces contain no PHI
• FHIR R4, SMART on FHIR, and CDS Hooks are the integration standards that connect AI capabilities to the clinical workflow — standard-based integration is non-negotiable for EHR-embedded AI
• The platform pays for itself through use case delivery speed: use case 1 takes months; use case 7 takes weeks