Supervisory platform for the operating room and ICU
Supervisor for the Operating Room and ICU
This is not an AI black box. It is a supervisor: a deterministic supervisory control system that keeps every recommendation and command traceable to a specific rule approved by an experienced physician.
Who it is for
Clinical Institutions
Bedside use and phased rollout
Learn more →OEM Partners
Embedding ready-made modules into your equipment or software
Learn more →Research Organisations
Transparency and reproducible episode review
Learn more →Medical Science
Knowledge refinement, algorithm traceability from citation to signal, multicenter studies
Learn more →What the platform does
HealthOS ICU works at the bedside: it assesses patient state and issues equipment-control commands. Behind it a knowledge cycle — the domain is formalised, stabilised into an approved graph snapshot, compiled into deterministic modules, embedded into equipment and refined by application materials.
- A formal domain description for state assessment and command synthesis;
- Deterministic supervisor compute modules for discrete and continuous patient-state assessment;
- Supporting materials — outputs from use that improve the system.
Confirmed. Rospatent, patents granted: a method of machine-readable representation of medical knowledge (26 May 2026) · a method of semantically correct ECG interpretation (3 August 2026).
Bedside loop
In the OR and ICU this becomes a loop over immutable components and the compiled module: data from monitors, pumps and equipment passes through adapters, the module forms a recommendation, and an approved command reaches execution through the safety kernel. Every recommendation, check, decision and command is logged.
Knowledge graph
The knowledge graph is a formal, machine-readable domain description: rules, triggers, parameters, evidence, device capabilities, constraints and governance roles. Compilation uses a stable snapshot; operational materials feed the triage path that prepares a refined one.
| Object type | Quantity |
|---|---|
| Clinical rule | 142 |
| Condition / trigger | 89 |
| Evidence reference | 310 |
| Device capability profile | 24 |
| Monitor parameter | 58 |
| SHACL constraint | 19 |
| Governance role and policy | 6 |
| Bundle version and signature | 12 |
| MedBench criteria (acceptance flags) | 26 groups, 202 flags |
| Triplestore composition | 10 dialect graphs, 11 general-purpose graphs; ~73.5k triples |
| Test ECGs with pathology labels | 9 nosology groups; 3,620 labelled cases of 4,133 |
Where each number comes from — on the sources page →
Place of trusted AI in the platform
Trusted AI works not at the bedside but in the knowledge-preparation path: agents analyse sources and draft the graph. The draft passes review, SHACL validation and approval, then becomes a stable snapshot.
| Stage | What the agent layer does | What the platform does next |
|---|---|---|
| Knowledge prep | Collects sources and drafts the knowledge graph | Moves the draft into review |
| Review | Not used | Assists review, SHACL validation and approval |
| Runtime | Not used | Compiles and packages the module from the approved snapshot |
| Improvement | Reviews application materials, drafts the next graph | Decides what goes into the next snapshot |
The agent layer does not replace the knowledge author or approving expert, does not change the snapshot and does not issue equipment commands. Its usefulness and trustworthiness are measured on the “Why Not AI” page →
Boundaries of responsibility
The safety kernel guarantees isolation of rule semantics from executable code:
- The application service — handles transport, data decoding, secrets and version checks;
- The embedded library — executes compiled rules;
- The knowledge graph — is refined through approved snapshots with discrete knowledge changes.
Standards
HL7 v2, IHE PCD, ISO/IEEE 11073 SDC, FHIR R4 instead of proprietary protocols
View →Conformance
Claims matrix: implemented, partial, planned — outside code
View →Safety Kernel
Command classes and seven checks before human confirmation
View →Key facts
| Fact | Value |
|---|---|
| Interoperability | HL7 v2/MLLP · IHE PCD · ISO/IEEE 11073 SDC · FHIR R4 · DICOMweb |
| Medical-equipment adapter levels | Level 1: HL7 v2/MLLP, read-only · 2: IHE PCD, structured data · 3: SDC, read and bidirectional observation · 4: SDC, governed parameter write |
| Command validation phases | Level 1: shadow only · 2: internal review · 3: recommendations only · 4: supervised write · 5: restricted write · 6: full control |
Technical composition — platforms, compilers, core languages — in the full documentation →
Discuss a phased rollout at your clinic or integration of your equipment.
Contact the teamFull concept →