Concept

Deterministic Supervisory Control for Critical Care

HealthOS ICU provides a deterministic supervisory control system for operating rooms and intensive care units. Unlike AI-based clinical decision support, every recommendation traces to a rule — formally compiled and approved by a clinician — and can be audited, replayed, and explained in a court or regulatory review.

The Problem

The core problem

Bedside devices in ORs and ICUs generate continuous high-frequency streams — ECG, SpO₂, invasive arterial pressure, ventilator parameters, drug infusion rates. Integrating and acting on these streams requires human attention that is often already saturated. Existing systems either operate as opaque AI models or require manual integration that scales poorly.

What breaks when knowledge is dissolved into implementations

This problem predates AI. When an interpretation rule lives at once in the analyzer’s code, in gateway settings, in a configuration table, in documentation, and in developers’ memory, four reproducible gaps appear:

Provenance

The rule began as a line of code, and a line of code has no clinical lineage.

Traceability

The component's version is known, the knowledge version is not tied to it, and "which rule was executing at the moment of the incident" stays unanswered.

Closure

Clinicians' observations return as retellings and amend the implementation rather than the knowledge; the divergence between them grows with every amendment.

Extensibility

A new clinical domain brings its own local solutions, and knowledge is rewritten instead of carried over.

The upshot of these four gaps fits in one sentence: every enhancement of such a system increases its uncertainty — the system gets worse from its own development. A model added to such a system inherits all four gaps and brings its own.

The platform’s answer is built to close each of them: provenance and traceability through a single source of meaning and the binding of everything executable to a knowledge version, closure through governed refinement, extensibility by making a new domain an extension of the same source rather than a system beside it.

The Answer

The platform’s answer

Data and command flowBedside devices send data over HL7 v2, IHE PCD and ISO/IEEE 11073 to the device protocol gateway, the stream then flows to the compute core, rules to the compiled bundle, from it runtime evidence with an audit reference goes to the clinical team; a governed write returns from the team to the devices, passing through the safety kernel with clinician acknowledgement.DATA AND COMMAND FLOWBedsideDevicesHL7 v2 · IHE PCDISO/IEEE 11073ProtocolGatewayComputeCoreCompiledBundleRuntimeEvidence+ audit refClinicalTeamSafety KernelCliniciangoverned write
Data and command flow: from bedside devices to a governed write.

Four principles

1. Rule-based, not AI.

The [compiled bundle](/en/terms/#compiled-bundle) (the rules version that runs at the bedside) is a compiled, deterministic artifact — identical inputs always produce identical outputs. No training-data exposure, no gradient drift.

2. Vendor-neutral.

A four-level adapter architecture (HL7 v2/MLLP → IHE PCD → ISO/IEEE 11073 SDC → proprietary) lets the platform integrate with Philips, Dräger, GE, and any HL7-capable device without vendor lock-in.

3. Edge-first.

Signal analysis runs locally at the bedside. Cloud connectivity is for analytics and governance, not for real-time decisions. Latency budget stays within clinical tolerance.

4. Formally auditable.

Every recommendation is backed by an [evidence-of-fact receipt](/en/terms/#release-receipt) (proof of provenance) and runtime evidence: a chain from the approved knowledge graph through validation, compilation, and execution to the specific output.

Knowledge

The knowledge cycle

The knowledge cycleSeven nodes in a loop: knowledge author, medical knowledge graph store, knowledge approver, knowledge compiler, compiled bundle, compute core, refinement candidate; an arrow returns from the candidate to the author.THE KNOWLEDGE CYCLEKnowledgeAuthorKnowledge GraphStorevalidate SHACLKnowledgeApproverKnowledgeCompilerCompiledBundleComputeCoreRefinementCandidatepropose change — from runtime evidence
A closed cycle: from a draft rule to a refinement candidate and back.

Medical knowledge flows through a closed cycle: drafted by a knowledge author (the clinician-expert formulating the rule), reviewed by a knowledge approver (who signs off on it), compiled by the knowledge compiler (the tool assembling rules into a module) into a compiled bundle, deployed to the compute core, and monitored for evidence feeding the next iteration.

Signal

Seven-stage signal pipeline

Signal pipelineSeven stages left to right: signal quality, waveform, morphology, rhythm, clinical findings, patterns, synopsis; each stage's output feeds the next and is logged.Signal QualityWaveformMorphologyRhythmClinical FindingsPatternsSynopsiseach stage is deterministic · output is logged to runtime evidence

The deterministic signal-evidence pipeline processes each monitor channel: signal quality → waveform → morphology → rhythm → clinical findings → patterns → synopsis. Each stage is deterministic; outputs feed the next stage and are logged to runtime evidence.

Safety

Governance and safety

The safety kernel splits commands into three classes — from a recommendation to an action requiring explicit clinician confirmation; no high-risk command is issued without it. Command classes and seven checks →

All write-path actions go through the governed write surface (the single path by which a command reaches equipment): logged, version-controlled, and traceable to the approving clinical authority.

Next

Documents

Full Technical Document

The concept in full, with technical detail

View →

Standards

HL7 v2, IHE PCD, ISO/IEEE 11073 SDC, FHIR R4

View →

Conformance Matrix

Implemented, partial, planned

View →

Discuss a phased rollout at your clinic or an integration with your equipment.

Contact the team