HealthOS ICU: Full Concept

1. The clinical information problem

Operating rooms and intensive care units generate the densest clinical data environments in medicine. A single patient in an ICU may have 15–20 active monitoring parameters, 3–5 infusion pumps, and a ventilator. The combined stream exceeds what a clinician without technological support can integrate within their attention.

The existing solutions — vendor-specific alarm systems, generic EHR-integrated alerts, human observation — share a structural weakness: they treat each parameter in isolation. Real clinical deterioration manifests as a pattern across parameters and over time. No single alarm captures it. The cognitive load of correlating multiple alarms is precisely what can overwhelm the clinical team’s attention at the highest-acuity moments.

2. The architecture

2.1 Edge-first design

All real-time analysis runs locally at the bedside. The Compute core (the module that executes at the patient’s bedside) is an energy-efficient binary library that receives data streams from medical devices through the device protocol gateway, applies the compiled bundle of rules to analyse the data, and produces recommendations — without any cloud calls.

This architectural choice reflects three clinical requirements. Command latency must be within the clinical response window (~20–30 seconds for yellow-class commands, and no more than ~30 seconds for red-class commands). System availability must be maintained through network or other failures. Data confidentiality must be preserved within the institution.

2.2 Vendor-neutral interoperability

Interoperability is organised across three planes — as on the «Standards and interoperability» page: the control-and-telemetry plane (HL7 v2/MLLP, IHE DEV/PCD, ISO/IEEE 11073 SDC) on the input side, the record plane (FHIR R4, PROV-O, SHACL) on the output side, and an auxiliary plane (DICOMweb) used only for retrospective review. HealthOS ICU’s point of entry is the bedside device protocol, not an institutional data hub.

The platform integrates with existing bedside devices without modifying them. The four-level adapter architecture is the same one described in the «Vendor interoperability» section of the standards page:

Four-level adapter architecture Four levels on the left — HL7 v2/MLLP, IHE PCD, SDC read, SDC write — converge on a single node on the right: HealthOS ICU, the edge layer. ADAPTER ARCHITECTURE Level 1 · HL7 v2/MLLP Level 2 · IHE PCD Level 3 · SDC read Level 4 · SDC write HealthOS ICUEdge Layer
Four adapter levels converge on the platform's shared edge layer.

Level 1 is available for any device with HL7 v2 output — covering the majority of existing installations. Levels 2–4 are roadmap items for specific vendor partnerships; the status of each standard is listed on the «Conformance statements» page.

2.3 Knowledge and compilation

Medical knowledge is maintained as a formal graph in the medical knowledge graph store, subject to SHACL constraint validation. Changes to the graph go through a three-role governance process:

  1. Knowledge author proposes a rule
  2. Knowledge approver validates and approves it
  3. Knowledge compiler compiles the approved snapshot into a compiled bundle
  4. Release operator deploys the bundle to the edge

Each step is logged. The evidence-of-fact receipt (proof of provenance) chains all four digests cryptographically, giving a verifiable trail from rule authorship to bedside execution.

2.4 Signal pipeline

The monitoring signal analysis pipeline deterministically processes every data channel for every patient:

  1. Signal quality
  2. Waveform
  3. Morphology
  4. Rhythm
  5. Clinical findings
  6. Patterns
  7. Synopsis

Each stage is audited. The entire pipeline is reproducible: given the same input segment and the same bundle version, the output is always identical.

3. Safety and governance

3.1 Command classes

Three command classes — safe (green), supervised (yellow), high-risk (red) — determine the confirmation requirements for each recommended action. No red-class command is issued without explicit clinical acknowledgement.

3.2 Seven checks before command execution

After clinician authorisation, the safety kernel evaluates seven conditions before writing a command to the equipment: rule provenance, device identity, parameter envelope, state coherence, conflict check, audit slot availability, and clinician authorisation. Any failed check cancels the command.

3.3 Phased rollout

Six deployment stages — capture only → internal review → recommendation only → supervised write → restricted write → full governance — ensure that no capability is exposed to patients before it has been validated in the specific clinical environment. Stage transitions require formal clinical leadership sign-off.

Six deployment stages Capture only, internal review, recommendation only, supervised write, restricted write, full governance — each transition requires formal clinical leadership sign-off. Captureonly Internalreview Recommendationonly Supervisedwrite Restrictedwrite Fullgovernance every arrow — formal sign-off from the deploying institution's clinical leadership
Capture only → internal review → recommendation only → supervised write → restricted write → full governance.

4. Records and provenance

4.1 Clinical-data facade

The clinical-data facade exposes FHIR R4 resources to clinical information systems: Observation, Device, DeviceMetric, GuidanceResponse, Provenance, AuditEvent. This is a downstream projection of the canonical audit event log — not the primary store.

4.2 Evidence-of-fact receipt

Every recommendation is backed by an evidence-of-fact receipt: a cryptographic chain of digests from the approved knowledge graph snapshot through SHACL validation, compilation, and runtime execution to the specific output. The receipt is human-readable, machine-verifiable, and publishable in a peer-reviewed methods section.

4.3 Audit event log

Every event — analysis output, command proposed, accepted, rejected, timed out — is recorded in the audit event log with full provenance. The log is immutable and available for governance review, incident investigation, and research.

5. The refinement cycle

The platform is designed as a closed learning system — not through AI retraining, but through a formal governance loop:

The refinement cycle Seven 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 REFINEMENT CYCLE KnowledgeAuthor Knowledge GraphStorevalidate SHACL KnowledgeApprover KnowledgeCompiler CompiledBundle ComputeCore RefinementCandidate propose 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, reviewed by a knowledge approver, compiled by the knowledge compiler into a compiled bundle, deployed to the Compute core, and monitored for evidence that feeds the next iteration.

Evidence from the audit event log informs refinement candidates, which feed knowledge authors, who update the graph — closing the cycle. Each iteration produces a new, cryptographically distinct bundle version.

6. Conformance and standards

See the conformance matrix for precise statements on what is implemented, what is partial, and what is explicitly out of scope. All conformance claims are traceable to the evidence referenced there.

See standards for a summary of the interoperability planes and their current conformance status.

Documents

Whitepapers → · Glossary → · Conformance →

Request the full technical dossier and discuss a pilot deployment. Contact us →