Platform
An event mesh, a live read model,
and an AI substrate
Most hospital software is a database with forms bolted on. medOS ultra is built like the systems that actually scale — events flow across a service mesh, project into realtime read models, and drive rules that live as data, not code. The same architecture behind modern infrastructure, pointed at the hardest domain there is.
Devices · LIS · RIS
HL7v2 / FHIR / DICOM
16 microservices
NATS event mesh
Read models
realtime projections
AI coworkers
recommender-first
16 microservices
NestJS/Moleculer on NATS mesh
Realtime read-models
Supabase projections, zero polling
Rules as data rows
CDS, policy gates, facility billing
Recommender-first AI
propose → human inbox, always
HORUS Atlas
The hospital as a living 3D model
Drill from country → province → facility → campus → building → floor. Towers are extruded data glyphs — height encodes catchment, color encodes facility type. Floors stack as selectable slabs with live occupancy, queues, alerts and RTLS movers (porters, AGVs, tracked equipment) pulsing in place.
TH › Bangkok › Riverside Campus › Tower A
Floor stack — click to drill down
3
In queue
2
Alerts
4
RTLS movers
Signature room — IPD Wards
Data as architecture
The building shape encodes operational reality — occupancy heat, ward states, mover positions. One geography, many lenses: Atlas, Capacity, Queue, Disease, FP&A, Twin.
RTLS-ready
BLE/UWB/RFID-agnostic ingestion via HMAC edge functions. Tracked tags resolve to zones on the same floor plans the bed board uses.
Same data, every scale
The 2D floor plan, the 2.5D extrusion and the full network atlas all render one bridge model — floor_plan_locations + entity_locations. 3D is a rendering, never a separate data model.
Live Floor Plan
Rooms, beds and movers — the real geometry
Rendered straight from the floor_plan_locations + entity_locations bridge — the same tables the bed board reads. 3D is a rendering of the same data, never a separate model.
Bot Extension Substrate
One engine, four domains
The shipped automation bot engine is already domain-neutral —trigger → bot-executor (Deno) → medos.* SDK → actions + audit.Nothing in that pipeline is clinical. Only three seams need extending.
Seam 1 — Trigger sources
Today: hospital_events, cron, manual, questionnaire. Extended with twin_signal (band crossed or scenario breach), crm_event (lead/no-show/lapsed), coverage_event (eligibility change mid-encounter), connector_event (sync delivered/failed), ack_event (cowork_proposals decided).
Seam 2 — medos.* SDK capabilities
New namespaces: medos.twin (metric, readiness, runScenario — read-only), medos.crm (Growth plane + consent), medos.coverage (insurance_context), medos.connector (push/pull a registered connector), medos.propose — the linchpin.
Seam 3 — Identity + governance
Every bot binds to a cowork_agents identity carrying an allowedPlane. Clinical / Operational / Growth enforced at the DB-grant level and re-checked in the capability layer. A Growth bot physically cannot read a chart.
medos.propose() — the universal safety output
Every outward-facing or cross-plane action funnels through it: the bot writes acowork_proposalsrow that lands in the Acknowledgement Inbox as Accept / Edit / Reject. So a marketing or insurance bot is exactly as safe as a clinical one. Accept/Edit/Reject is also the training label.
Four domains — all data, not new engines
| Domain | Trigger | Proposes | Plane |
|---|---|---|---|
| PRM | crm_event (no-show/lapsed) | recall outreach on a consented channel | Growth |
| Marketing | twin_signal (OR utilization low) | targeted campaign | Growth |
| Insurance | coverage_event (eligibility lapsed) | re-bind / preauth task for AR | Operational |
| Intelligence | twin_signal (forecast breach) | grounded recommendation → HORUS 4-role sign-off | Operational |
SINGLE ENGINE
trigger → bot-executor (Deno) → medos.* SDK → medos.propose() → Ack Inbox
recall outreach
→ medos.propose
OR utilization low
→ medos.propose
eligibility lapsed
→ medos.propose
forecast breach
→ medos.propose
Invariant: every outward action funnels through medos.propose — human Accept/Edit/Reject. No autonomous send. No clinical write.
P0–P3 ROLLOUT
P0 — Demo-ready
medos.twin (sensor) + medos.propose, twin_signal trigger, one end-to-end 'Cardiac step-down capacity' bot
P1 — PRM/Marketing kit
crm_event + medos.crm, Growth plane, consent gate
P2 — Insurance kit
coverage_event + medos.coverage, Operational plane
P3 — Auto-chaining
automation_bot_edges drives downstream bot fan-out — the graph becomes runtime
Open step-down unit (12→10 beds, budget-capped)
optimizedRenegotiate NHSO scheme — denial rate 18%→9%
4 sign-offs pendingIn-source blood supply — 3 scenario runs
decidedHITL gate · 4 sign-offs release optimized → decided
HORUS Decision Twin
Stochastic ops research on your data
The hospital translation of "Innovera for hospitals": stochastic programming applied to real operational data (bed-state logs, vitals hypertables, OR costing, claims facts). More defensible than Innovera because inputs are structured, not qualitative.
The device line is an asset, not a tax
Outputs are population/resource-level only — beds, staff, supply, schemes, capital thresholds. Never "what to do for this named patient." Clinical signals feed in as inputs (acuity, EWS, pathway adherence); they never appear in a patient-directed output. This buys speed (no device clearance on the critical path), adoption, and liability containment.
7 agents on a shared clock
Calibrated by live twin_metric_* RPCs (nurse FTE, cost-per-case, contribution margin, OR utilization). Fail-soft to seed when data is not yet live.
Two products, one engine
Initiative Workbench
Capture → Analyze → Model → Guide for one decision. Buyer: department head / service line.
Portfolio Command
All initiatives by status/readiness/value-at-risk. Actuals vs forecast. Buyer: C-suite / board.
HITL gate — the SaMD firewall
4 role sign-offs (COO, Service Lead, Finance, Clinical Director) required to move optimized → decided. The LLM writes narrative and second-opinion commentary — it never decides a number and never gates a decision.
Clinical Decision Support
Every observation fires the engine
The CDS rule engine evaluates every observation write — from the frontend via recordObservation, backend via the encounter-orchestrator (HL7v2 ORU, lab feeds, devices, FHIR write API). No separate CDS pipeline.
Configurable rule library
NEWS2, MEWS, qSOFA, hypoxia, HTN, fever, hypoglycemia, sepsis ship in the baseline. Add rules at /admin/cds-rules — predicate JSONB, same shape as policy_gates.
Global alert surface
CdsAlertSurface mounted globally in App.tsx. FAB + drawer + modal + toast. InlineCdsAlertBadge for any form cell.
Severity-aware snooze policy
Critical: no snooze (ack-with-reason or escalate). Warning: max 2h + structured reason picklist. Info: until end of shift. All snoozed alerts re-surface to oncoming shift via shift_alert_log.
AI re-rank, never suppress
AI annotation arrives T+1-3s and patches display_rank/cluster_id only. AI cannot hide alerts, cannot demote severity, is never synchronous in the alert path.
| NEWS2 aggregate ≥ 7 | CRITICAL | 2 today |
| Hyperkalemia K+ ≥ 5.5 | CRITICAL | 1 today |
| qSOFA ≥ 2 (sepsis screen) | WARNING | 3 today |
| NPO violation — oral order | WARNING | 0 today |
| Antibiotic timing 1h window | INFO | 4 today |
Every vitals write auto-fires CDS. Alerts surface via global FAB + drawer + inline badge. Rules are data rows — editable live, no code deploy.
ADT/ORM/ORU
read/write/sub
NM/CT/PET
OData connector
HR/finance feed
lab instrument
claims rail
NHSO 16-file
Interoperability
Speaks every dialect of healthcare
FHIR R4 read/write + subscription-based delivery, HL7v2 ADT/ORM/ORU over MLLP (2575/TCP), DICOM MWL/MPPS for NM scanners (PET/CT, SPECT/CT, gamma camera), and 48 connectors across 13 categories.
FHIR R4
Read/write with SMART on FHIR. Subscription-based delivery via fhir-subscription-matcher (Deno). CapabilityStatement at GET /fhir/metadata. HMAC-signed bundle dispatch.
HL7v2 MLLP
ADT A01-A08, ORM O01, ORU R01. ACK/NAK builder. TCP server with 0x0B/0x1C framing. NM-RIS: ORM + ZRI custom segment, ORU with SUV/uptake OBX.
Radiopharmacy (NM)
RDE^O11 dispense request, RAS^O17 admin record, inbound RDS^O13 confirmation. Isotope coding map: Tc-99m, I-131, F-18, Ga-68, Lu-177 → SNOMED+LOINC.
Connector Store
48 connectors: EHR/HIS adapters, LIS HL7v2, RIS/PACS DICOM, ERP (Odoo, SAP OData), HRM-generic, claims rails (NHSO E-Claim, ECLIPSE/AU Medicare), identity OIDC, messaging SMTP/SMS. Per-connector liveness strip + tamper-evident hash-chain.
Security & Identity
Zero-trust from badge to bedside
RUDS — Rogue User Detection System — consolidates 4 audit-log silos (auth, public-api, LLM, patient) into a unified user_action_events hypertable with a detection_rules engine (JSON predicates, same shape as policy_gates/cds_rules).
Two-tier scoring
Inline scorer <50ms (blocks/step-up in real time). Nightly batch scorer for complex pattern detection. Per-user user_baselines fingerprint.
17 seed rules
Credential stuffing, bulk record export, off-hours API spike, concurrent sessions, workflow tampering, API abuse, LLM abuse patterns, privilege escalation.
AI second opinion — with hard constraints
Haiku/Sonnet for novel-pattern promotion. AI cannot block, cannot push to red tier, no PHI in prompts. Humans own the call.
Biometric sign-off
Face + voice modalities for AI order sign-off. WeSpeaker/TitaNet speaker verification. RUDS VOICE_SIGNOFF_* rules. Per-tenant feature flag.
Row-level security
RLS on every read model. Three data planes enforced at the DB-grant level — Clinical, Operational, Growth. Marketing bots have zero clinical grant.
AI second-opinion (Haiku/Sonnet) for novel patterns — AI cannot block, cannot push to red tier. Inline scorer <50ms.
COMPLIANCE POSTURE PER REGION
United States
HIPAA, DEA + state license compliance, Cures Act CDS carve-out
UK / Europe
GDPR, MDR Rule 11 alignment
Japan
APPI data residency, PMDA boundary
Southeast Asia
PDPA (Thailand), PhilHealth data rules
Live Floor Plan · 2D
Rooms, beds and inventory — top-down
The same floor_plan_locations + entity_locations bridge, rendered as a 2D plan with realtime per-department stock status. Click a room to inspect its inventory usage. Pulsing dots are RTLS-tagged movers.
INVENTORY USAGE · PHARMACY · ห้องยา
On-hand vs par level streamed from the realtime stock cache. Consume-to-charge posts every issue to the billable ledger — leakage (used but never charged) surfaces in the same view.