AI Platform (HORUS & Cowork)

medOS-ultra runs AI as a first-class, governed layer across the whole organization — clinical floor and back office alike. It is built on one non-negotiable stance: AI proposes, humans dispose. Every model output is a recommendation that a person accepts, edits, or rejects; there are no autonomous clinical writes, every capability is off by default with a per-tenant kill switch, and data access is fenced into three planes enforced at the database grant level.

The platform has four cooperating capabilities:

• HORUS Decision Twin — a strategic simulator whose signed decisions can be turned into real, tracked work.
• Cowork AI coworkers — named, role-scoped agents that draft work and hand it to a human at a gate.
• Configurable CDS — a clinical decision-support rule engine tuned by hospital staff, not by a release.
• Patient-trajectory prediction — a learned model that simulates plausible patient futures for cohort planning and gated clinical recommendation.

3

Data planes

Recommender

Default mode

Off

Default state

Accept / Edit / Reject

The label

Audited

Every action

The recommender-first invariants

These rules hold across every AI capability on the platform. They are the safety spine, not a policy bolted on afterward.

Invariant	What it means
AI proposes, humans dispose	A capability produces a proposal; a person accepts, edits, or rejects it.
No autonomous clinical writes	Nothing reaches the chart without an explicit human disposition through an existing write path.
Off by default	Each agent / rule / model ships disabled, behind a per-tenant flag and a kill switch.
Accept / Edit / Reject is the label	The human's gesture is captured to the audit log as the training signal — never written to the chart.
Plane confinement	Data access is fenced by plane and enforced at the DB grant level, not just app logic.
Everything is audited	Every action lands in an audit log under the acting agent's identity with its reasoning trace.
Recommender to actor is earned	Promotion from "suggests" to "acts" is per-tenant, evidence-based, and reversible.

The three data planes

Same substrate, three different data-access contracts. A growth-plane agent's database role has no grant on clinical tables — the wall is in the database, not the prompt.

Plane	Touches	Write contract
Clinical	PHI, diagnoses, orders, results	Recommender-first, draft-until-signed, structured-only model payloads, full PHI audit.
Operational	Scheduling, beds, queues, claims, supply, staffing	Lower clinical risk, still audited, rides existing workflow gates.
Growth	Acquisition, campaigns, CRM, referral	Hard-walled from PHI; reads only consented, de-identified / aggregate audiences; per-read audit.

Capability map

Strategy

HORUS Decision Twin

Simulates initiatives, runs a multi-role sign-off gate, and — only after sign-off — fans the decision out into real tasks, acknowledgements, and rule changes.

DraftSimulateSign-off gateExecuteReversible

action planscompensation / rollbackaudit to initiative

Agents

Cowork coworkers

Named, role-scoped agents that draft work and post a proposal to a human's inbox or team board. They never mutate records directly.

proposalinboxrecommender

Safety net

Configurable CDS

A DB-backed, versioned rule engine. Thresholds and alerts are edited by staff — no release needed.

rules as dataversionedaudited

Foresight

Trajectory prediction

A learned model that simulates patient futures for cohort planning and gated clinical recommendation.

cohort riskin-regionrecommender

Discipline

Recommender-first

Off by default · per-tenant kill switch · plane-confined · fully audited.

human-in-the-loop

target 95%

HORUS Decision Twin

The twin lets leadership model an initiative — "open a cardiac step-down unit", "require pre-authorization before closing a surgical case", "re-triage patients waiting too long" — and walk it through a governed lifecycle: draft → analyze → simulate → review → decide → monitor.

The review → decide step is gated by a four-role sign-off (medical, nursing, revenue-cycle, and compliance leads). A decision that is merely recorded is a museum exhibit; the platform turns a signed decision into real work through an action plan whose rows fan out to primitives the hospital already operates.

Decision flow (UI)
   │ apply
   ▼
Decision service
   1. advance initiative status
   2. reconcile sign-offs (4 roles)
   3. append immutable decision event
   4. GATED: only if signed + decided ─▶ Initiative Executor
                                           ├─ load action plan + ready rows
                                           ├─ order by dependencies
                                           └─ fan each row out to an EXISTING primitive
                                                create task        → team board / "My tasks"
                                                request ack        → acknowledgement inbox
                                                notify role        → role inbox
                                                flip workflow rule → live rule engine (with rollback)
                                                register routine   → job registry (disabled, human enables)
                                                record capacity    → planning calibration fact
                                                propose flow change→ ack to a workflow admin
                                                mirror to PM tool  → optional external task system

Three properties make this safe to run on real operations:

• No write before sign-off. The executor re-checks the gate server-side and never trusts the caller.
• Only existing primitives. Each action maps to a production primitive that already has a board, inbox, or enforcer. The executor invents no new write path and never touches the chart.
• Reversible and attributable. Every rule change records a before-snapshot to an append-only ledger, every action carries an undo, and everything links back to the initiative that produced it.

A decision can run in a lite envelope (every action lands on the internal boards and inboxes staff already use — no external dependency) or a synced envelope (additionally mirrored to an external project-management tool, opt-in, with PHI stripped on the way out). The companion Twin Data Advantage page covers how the twin is calibrated against real outcome and document data.

Cowork AI coworkers

A coworker is an agent with a skill, an identity, a data plane, a role binding, and a mode (recommender by default). It sits in the workflow, picks up work, does background drafting, and hands a decision back to a human at a gate. The substrate reuses primitives the platform already ships — a skill registry, a delegation inbox, a task board, and a model runtime.

trigger (schedule or event)
   │
   ▼
backend runner ──reads (plane-scoped views only)──▶ skill loop  [no-hallucination guard]
   │                                                     │
   │                                  draft + reasoning trace + confidence
   ▼                                                     ▼
proposal record ───────────────▶  acknowledgement request (from: agent, to: role)
                                                         │
                                            human inbox (Accept / Edit / Reject)
                                                         │
                              Accept ──▶ existing human write path + label to audit

The coworker never mutates the chart. It produces a proposal and asks a human to dispose of it. On Accept the platform calls the same write path a human would use, through the same gates; on Edit the human's version goes through that path; on Reject nothing is written. The disposition itself becomes the training label — captured to the audit log, never to the record.

Coworkers are mapped to real teams across the hospital:

Team	Coworker	Plane
Coding / Health Info	Drafts diagnosis and procedure codes for review	Clinical
Nursing	Drafts shift handoff, alerts, and care-plan suggestions	Clinical
Pharmacy	Compounding worksheet + interaction second opinion	Clinical
Revenue cycle	Claim drafts, revenue-at-risk, prior-auth prep	Operational
Patient access	Admission coordination and journey planning	Operational
Marketing / CRM	Segment summaries + bilingual content from consented, aggregate audiences only	Growth

Configurable clinical decision support

CDS rules — "heart rate above threshold", "oxygen saturation below threshold" — used to be hardcoded, fired only when a form remembered to call them, and left no audit trail. The platform replaces that with a rules-as-data engine that a hospital tunes itself.

Layer	Role
Rule table	Editable, scoped, versioned rule rows with a safe, token-based condition grammar (no executable code).
Unified dispatcher	Every observation write — from a form, a device feed, a lab result, or an external interface — fires CDS automatically.
Surfaces	A fired rule fans out to inline badges, a global alert drawer, a blocking modal, a toast, an acknowledgement request, a webhook, or a role notification.
Evaluation log	Every fired, skipped, or errored evaluation is recorded with its inputs, outputs, and acknowledgements.

Conditions are expressed against standard clinical codes and compared with simple operators, so a threshold change is a config edit, not a code change. An admin console lets staff search rules, toggle them, publish versions (with rollback), and simulate a rule against synthetic values before it goes live — seeing the exact alert it would raise without persisting anything. CDS is fire-and-forget: an observation write never fails because of CDS, and a fired alert that warrants explicit attention can escalate to a forced modal or an acknowledgement request that cannot be silently missed.

Patient-trajectory prediction

The platform already has retrieval ("patients like this one — what happened next") and narration (turning numbers into plain language). The learned tier adds generation: a model that, given a patient's coded history, simulates plausible futures and reads risk, time-to-event, and "what-if" outcomes off the simulated trajectories.

Two design choices keep it sound and deployable:

• Population-calibrated and in-region. The model is trained on the deployment's own consented, de-identified data rather than inheriting a foreign cohort's bias — better calibrated and kept in-region for data-protection compliance. Because it reasons over codes (which are language-agnostic), one model serves every locale; only the narration shell localizes.
• The device line. Population and cohort outputs — bed counts, predicted length-of-stay distributions, deterioration risk for a ward — calibrate the Decision Twin's planning agents and ship first. Any individual, named-patient risk output is treated as software-as-a-medical-device: it stays on the separately governed, recommender-only clinical track with human sign-off and fail-safe escalation, and never drives an autonomous write.

A classical or mechanistic estimate always remains as a floor, so a degraded model never leaves a surface blank — it falls back to a sane default and abstains honestly when it has no signal.

See also

• Architecture overview — backend, frontend, and projection layers
• Twin Data Advantage — calibrating the twin on outcome + document data
• LLM service — the model runtime, retrieval, and audit
• Task service — the team board and delegation primitive
• Backend overview — services and the message bus
• FHIR integration — standards-based external exchange
• Security & compliance — data planes, consent, and audit