Healthcare AIOS: From Architecture to Running Platform

TL;DR

Healthcare AIOS is no longer just an architecture diagram—it has been demonstrated as a working intelligence layer.

The focus is not on replacing EHRs, FHIR servers, labs, or other healthcare systems. Instead, Healthcare AIOS orchestrates them to answer one critical question: “What should happen next?”

The platform demonstrates an end-to-end flow:

Clinical Event → API Gateway → Multi-Agent Reasoning → Knowledge + FHIR → Policy & Guardrails → Durable Workflow → Clinician Recommendation → Audit & Observability

A live synthetic clinical scenario validated the complete loop, while a Docker Compose stack demonstrated how the architecture is materialized through services such as LangGraph, Neo4j, Weaviate, HAPI FHIR, Kafka, Temporal, OPA, Keycloak, PostgreSQL, Redis, and OpenTelemetry.

The key architectural principle is governed intelligence: recommendations are evidence-backed and confidence-scored, high-risk actions require clinician approval, workflows can run longitudinally, and every important decision is auditable.

The result: Healthcare AIOS moves from raw clinical events → reasoning → governed decisions → actionable next steps, while keeping humans and existing healthcare systems in control.

How a Full Docker compose Stack and Live Clinical Simulation Demonstrate Proof-of-Concept Success

Introduction

There is a difference between designing a Healthcare AI Operating System and making it operational as a containerized and observable system that delivers value by answering “What should happen next?” in a concrete clinical scenario.

We have done both.

This article demonstrates the achievement of our goal to design and implement a Healthcare AI Operating System as a coordinated set of microservices and supporting infrastructure.

We present two lines of evidence:

A live clinical scenario that fully exercised the system’s capabilities, a representative Docker Compose stack that demonstrates how the system would be deployed to production.

Together, these evidence points confirm that Healthcare AIOS has been realized as an intelligence layer that orchestrates rather than replaces existing healthcare information systems.

The Operating System Standard

Our standard for a Healthcare AI Operating System remains the same:

• Healthcare AIOS is an intelligence layer that operates above existing healthcare systems.
• It orchestrates People, Agents, Knowledge, Memory, Workflows, Policies, Compliance, and Decisions within an ecosystem of supporting systems.
• It seeks to answer the question those systems cannot answer on their own: “What should happen next?”

Any demonstration of concept must be measured against this standard.

Proof Point #1: Simulation of Clinical Scenario

As proof that our system could successfully operate according to this standard, we executed a complete end-to-end scenario using a synthetic patient (SYNTHETIC-001).

The following trigger events were used in the simulation:

• ADT Discharge
• Lab result (HbA1c = 9.2% / LOINC 4548-4)

Below is the evidence that our system correctly responded to this scenario according to the OS standard.

Stage 1: Ingestion of Clinical Events

Clinical events were published to Kafka topic aios.clinical.events via the Integration Gateway. No events were written to source systems of record.

Stage 2: Recommendation Request

A recommendation request was submitted to the API Gateway:

POST /api/v1/recommendations
{
"patient_id": "SYNTHETIC-001",
"encounter_id": "ENC-49021",
"trigger_event": "clinical.adt.discharge",
"recommendation_types": ["care_gap_alert", "clinical_reasoning"]
}

Stage 3: Multi-Agent Reasoning

The LangGraph-based Agent Runtime was invoked and a Supervisor Agent was created that evaluated the scenario and invoked the Clinical Reasoning Agent.

This agent then performed the following steps:

• Retrieved patient summary (active conditions and medications)
• Retrieved relevant guidelines (ADA 2024, KDIGO 2023)
• Performed knowledge search for “HbA1c 9.2% management in T2DM with CKD”
• Calculated 30-day readmission risk (0.18 – low)

Stage 4: Policy and Guardrail Evaluation

The proposed recommendations were evaluated by the Open Policy Agent:

• High-risk medication check ✅
• Confidence threshold (≥ 0.70) ✅ (actual: 0.89)
• Governance decision: ALLOWED (Requires Clinician Approval)

Stage 5: Durable Workflow Creation

A 30-day PostDischargeFollowupWorkflow was created in Temporal.io containing outreach, adherence verification, and outcome capture steps.

Stage 6: Clinician Recommendations

Two clinician recommendations were created and sent to the Clinician Cockpit:

• HIGH: Annual diabetic dilated eye exam due in 14 months
  • Confidence: 95%
  • Evidence: ADA 2024
  • Action: Ophthalmology referral
• MEDIUM: Consider SGLT2 inhibitor for dual glycemic and renal protection
  • Confidence: 89%
  • Evidence: KDIGO 2023
  • Action: Empagliflozin 10 mg daily (requires clinician approval)

An audit log was created that captured all actions taken. All six stages were successfully completed.

Mapping to the OS Model

OS Component	Evidence in Simulation	Result
People	Clinician Cockpit as the decision surface	✓
Agents	Supervisor + Clinical Reasoning Agent with tool use	✓
Knowledge	ADA / KDIGO guidelines + semantic evidence retrieval	✓
Memory	Patient context and longitudinal signals used	✓
Workflows	30-day Temporal post-discharge workflow	✓
Policies	OPA medication and confidence gates	✓
Compliance	“Requires Clinician Approval” + full audit trail	✓
Decisions	Prioritized, confidence-scored, evidence-backed actions	✓

The simulation was successful in demonstrating that our system can fulfill the Healthcare AIOS standard.

Proof Point #2: Production Docker Compose Stack

The file describing the system as a set of services that could be deployed to production is also compelling evidence that we have achieved our goal. Below are the services that were defined in the Docker compose file:

Infrastructure Services

Service	Role	Technology
PostgreSQL	Primary relational store	PostgreSQL 16
Redis	Caching & short-term state	Redis 7
Kafka + Zookeeper	Clinical event backbone	Confluent 7.6
Neo4j	Medical knowledge graph	Neo4j 5.20 Enterprise
Weaviate	Vector store for RAG	Weaviate 1.25
HAPI FHIR	FHIR R4 server	HAPI FHIR
Temporal + Temporal UI	Durable workflow engine	Temporal 1.24
Keycloak	Identity & SMART on FHIR foundation	Keycloak 24
OPA	Policy-as-code engine	Open Policy Agent 0.66

Observability Stack Service Description

• OpenTelemetry Collector
• Prometheus
• Grafana

AIOS Microservices

Service	Responsibility	Port
API Gateway	Unified entry point and orchestration hub	8000
Agent Runtime	LangGraph multi-agent execution	8001
FHIR Gateway	Bidirectional FHIR + Kafka bridge	8002
Knowledge Service	Neo4j + Weaviate knowledge access	8003
Policy Engine	OPA client and clinical guardrails	8004
Audit Service	Immutable event and decision logging	8005
Notification Service	Alerting and outreach	8006
Workflow Engine	Temporal client and long-running processes	8007
Clinician Cockpit	Clinician experience layer (Next.js)	3000

Architecture Fidelity

The compose file correctly reflects the architecture in which the system was intended to operate:

Experience Layer →  clinician-cockpit

Intelligence Layer →  agent-runtime, knowledge-service, policy-engine, workflow-engine, audit, notification

Integration Layer →  fhir-gateway, api-gateway, Kafka

Foundation Systems →  Neo4j, Temporal, HAPI FHIR, Postgres, Redis, Observability

Cross-cutting Concerns →  Keycloak, OPA, OTEL, Prometheus, Grafana

It is not simply a collection of interesting technologies – it is an operating system that defines clear responsibilities for individual services and supports the intended workflows.

What This Evidence Shows

1. Orchestration vs Replacement

Events were ingested from multiple sources. Recommendations were created and workflows initiated. None of this replaced the existing source systems of record. The system observed and orchestrated.

2. “What Should Happen Next?” Has Been Demonstrated

A discharge event plus an abnormal lab finding resulted in two specific clinical recommendations with supporting evidence and confidence scores.

3. Safety Is Structural

Policies were evaluated before any recommendations were released. High-risk actions remained gated. Everything was auditable.

4. Longitudinal Care Is Native

Multi-week workflows were used to perform post discharge follow up.

5. The Stack Was Actually Used

Every step in the scenario was executed on the stack represented by the Docker compose file.

6. Observability and Governance Are First-Class Features

Metrics collection, log aggregation, and policy evaluation were all present and contributed to the safety and effectiveness of the system.

Current Capability Assessment

Dimension	Status	Notes
Core intelligence loop	Operational	Proven in simulation
Multi-agent reasoning	Operational	Supervisor + specialist pattern
Knowledge hybrid (graph + vector)	Operational	Neo4j + Weaviate
Policy enforcement	Operational	OPA with clinical rules
Durable workflows	Operational	Temporal post-discharge pathway
FHIR interoperability	Present	HAPI FHIR + dedicated gateway
Identity foundation	Present	Keycloak with realm import
Observability	Present	Full OTEL + metrics + dashboards
Clinician experience	Present	Cockpit streaming recommendations
Production hardening	In progress	Secrets, resource limits, health checks still being refined

The system has crossed the threshold from concept to reality.

Implications

With this threshold crossed, we can now proceed to the next phase of development, which includes:

• Expanding the set of specialized agents to include prior authorizations, documentation generation, and capacity management
• Enhancing FHIR bidirectional exchange capabilities
• Defining additional longitudinal care pathways
• Evaluating recommendation acceptance rates, care-gap resolution rates, and safety outcomes in larger scenarios
• Carefully relaxing policy constraints inside guardrails to allow limited autonomy
• Preparing the system for multi-tenant, regulated deployment

The foundation has been laid for this next phase. We have demonstrated that an intelligence layer can be built that fulfills the Healthcare AIOS standard, orchestrating rather than replacing existing healthcare information systems.

Conclusion

Healthcare AIOS is no longer an architectural concept.

It has been demonstrated as an operating system that:

• Ingests clinical events
• Reasons about them using specialized agents
• Imposes policy and confidence constraints
• Initiates durable workflows
• Delivers actionable recommendations to clinicians
• Captures everything in an immutable audit trail
• It has been demonstrated using a representative Docker Compose stack that reflects this architecture.

It has been shown to successfully answer the question “What should happen next?” for a patient with uncontrolled DM2 and an overdue eye exam. It has demonstrated that it can operate as an intelligence layer that orchestrates rather than replaces existing healthcare systems.

Original Case Study – Case Study 011: Healthcare AIOS — From Architecture to Running Platform