Executable Knowledge as a Medical-Informatics Object in the OR/ICU Supervisory Ecosystem

Authors

1. Prozorov A.A., Director of Technology, RTLAB; Architect, Sbertech; ap@rtlab.ru;
2. Redkin I.V., Director of Science, RTLAB; MD, PhD; Leading Research Scientist, V.A. Negovsky Research Institute of General Reanimatology, FRCC RR; iredkin@rtlab.ru;
3. Bakhvalov I.M., General Director, RTLAB Oncology; ibakhvalov@rtlab.ru;

Abstract

Objective. To define executable knowledge as a medical-informatics object applicable to the supervisory ecosystem of the operating room and intensive care unit (OR/ICU), where low-latency physiological data processing, reproducible interpretation of physiological status, bounded device-facing control, and semantically governed authorization of change must coexist.

Methodological basis. This is a conceptual and architectural article. The analysis draws on work on computer-interpretable clinical guidelines and on standards and regulatory documents related to medical-device interoperability, medical software, provenance, audit, and software lifecycle governance. The authoring corpus is used as background synthesis rather than as an independent public citation layer.

Main provisions. In the OR/ICU setting, instant health assessment should be understood not only as an oscillogram-and-signal processing task but also as a governed transition from authorized semantics to a deterministic bedside execution contour. The central object of such a system is proposed to be executable knowledge: a governed source of authorized semantics that undergoes authorization, is compiled into bounded execution artifacts, is observed through structured runtime evidence, and is refined through a governed feedback loop. The model separates the integration contour from the execution contour, the compute core from the safety kernel, and clinical records, visualization, analytics, and governance from bedside execution logic.

Conclusion. Executable knowledge may be treated as a conceptual basis for an OR/ICU supervisory ecosystem oriented toward low-latency edge execution, reproducibility, auditability, and controlled evolution of clinical logic. This article does not claim clinical-efficacy improvement, registration-grade validation, full autonomy of a closed-loop therapy controller, or universal readiness of external write surfaces across all medical-device vendors.

Keywords: instant health assessment; executable knowledge; OR/ICU supervisory ecosystem; medical informatics; codified terms; operating room; intensive care unit; medical devices; clinical decision support; runtime evidence; auditability

Abbreviations and Terminological Conventions

ICU - intensive care unit; OR/ICU - operating room and intensive care unit; AI - artificial intelligence; FDA - U.S. Food and Drug Administration; IMDRF - International Medical Device Regulators Forum; SaMD - Software as a Medical Device; IHE PCD - Integrating the Healthcare Enterprise Patient Care Device; SDPi - Service-oriented Device Point-of-care Interoperability; ISO/IEEE 11073 SDC - service-oriented point-of-care medical-device communication model; FHIR - Fast Healthcare Interoperability Resources; DICOM - Digital Imaging and Communications in Medicine.

In this article, the term executable knowledge is used in the singular because the manuscript treats it as one central medical-informatics object rather than as a loose collection of rules. The term computable knowledge is retained for the broader tradition of rendering clinical knowledge machine-interpretable.

In this article, release denotes the governed publication point for compiled supervisor components. At release, compiled artifacts such as executables, the Authorized snapshot, the Lineage Receipt, and compilation and deployment evidence are accepted as the bounded execution set for deployment, replay, and review. Release is not deployment itself, does not create semantic authority, and does not constitute clinical validation.

1. Introduction

Operating rooms and intensive care units are clinical environments characterized by high data density, limited decision time, and elevated responsibility for patient safety. A single patient trajectory may include continuous physiological oscillograms, numeric trends, alarm streams, electronic-record context, information about device capabilities, local therapeutic protocols, and explicit human interventions. In such settings, instant health assessment cannot remain only an archival or retrospective exercise. It must support timely interpretation, clinical coordination, and, where appropriate authority exists, bounded interaction with bedside devices [1].

In this article, instant health assessment is defined as the logically rigorous derivation of a clinically meaningful and reproducible physiological status of the patient from continuous oscillograms and codified-term values in real time. In the OR/ICU environment, that derivation must support interpretation of the current physiological status, generation of recommendations, escalation of clinical attention, coordination of staff workflow, and bounded device-facing control under acute-care conditions. Clinical usefulness therefore depends not only on computational speed but also on preservation of semantic clarity, reproducibility, and post hoc reviewability.

Medical-informatics literature has long addressed the translation of clinical knowledge from textual form into computable form. Computer-interpretable-guideline formalisms, including PROforma and GLIF3, demonstrated that clinical logic can be represented in a form suitable for software execution and exchange [2-4]. The OR/ICU supervisory ecosystem, however, imposes narrower and operationally stricter requirements. It is not enough to express a rule in an executable notation. The system must also support automated deployment, medical-device interoperability, explicit authority boundaries, release discipline, and a replayable chain of runtime evidence.

In practice, two broad classes of architectural limitation are common. In the first, knowledge remains explicit but persists mainly as a document, spreadsheet, or rule catalog that is later transcribed manually into software code, increasing the risk of divergence between authorized clinical logic and actual system behavior. In the second, the system executes quickly, but the deployed logic, gateway configuration, or local rule set becomes a de facto source of truth in its own right. In both cases it becomes difficult to determine whether a recommendation, alarm-suppression decision, or bounded command intent truly reflects the same knowledge that the organization authorized.

Regulatory and standards-oriented approaches to medical-device interoperability, clinical decision support, and software as a medical device all emphasize the need for explicit interfaces, intended use, software boundaries, and clearly delimited control contours [5-7]. For OR/ICU supervisory systems, this means that bedside behavior cannot be justified merely by invoking a trained model or local integration code. A reviewable chain is needed: what knowledge was authorized, how it was compiled, which bundle was released, what operational facts were recorded, and how those facts can be related back to the semantic basis from which the system was derived.

The aim of this article is therefore to define executable knowledge as a medical-informatics object for the OR/ICU supervisory ecosystem and to describe the architectural conditions under which governed clinical semantics can be translated into deterministic, auditable, low-latency bedside execution.

2. Executable Knowledge: Definition and Distinction from Weaker Forms

In broad usage, the expression “executable knowledge” is often reduced to a set of rules that can be run in software. That understanding is insufficient for the OR/ICU environment. Here, executable knowledge should be treated as a governed medical-informatics object whose semantic basis undergoes ontology authoring, authorization, compilation, release as bounded execution artifacts, and observation through structured runtime evidence. Under that model, operational facts remain traceable to a governed source of authorized semantics.

Executable knowledge differs from weaker forms of clinical-logic representation in three ways. First, its meaning is anchored in an explicit source of authorized semantics rather than only in the implementation of the execution contour. Second, it becomes operational through governed compilation rather than through manual re-expression by implementation engineers. Third, the runtime contour is required to emit structured evidence linked to the same authority source instead of leaving behind isolated technical logs. External provenance and audit standards already illustrate the value of stable evidence-bearing artifacts, even if the artifact names used in this paper are specific to the present program [12][13][16].

In the proposed model, the executable-knowledge chain includes several artifact types. An Authorized snapshot is the governed semantic basis selected for compilation. A Compiled IR Bundle is the deterministic operational projection consumed by the execution contour. A Lineage Receipt binds released artifacts to their semantic and release basis. A Runtime Evidence Report captures observed runtime behavior in normalized form. A Refinement Candidate is a structured proposal for change arising from review of runtime evidence. A Governed Graph Update Request formalizes the path by which such change returns into the space of authorized semantic modification.

The crucial point is that the execution contour does not become a parallel source of truth. It is a released, bounded, and replayable projection of authorized semantics. For that reason, executable knowledge is not equivalent to an opaque AI runtime. An AI model may be technically executable, but the mere executability of model weights does not establish governed authorized semantics, an inspectable semantic contract, or replayable linkage to a specific release. In OR/ICU, it must remain possible to determine what knowledge was active at the moment of assessment, why a recommendation or target command was formed, and how that behavior can be reviewed after the fact.

Table 1. Artifacts in the executable-knowledge chain

Artifact	Role in the chain	Why it matters for OR/ICU
Authorized snapshot	Governed semantic basis selected for compilation	Prevents bedside logic from drifting away from authorized semantics
Compiled IR Bundle	Deterministic operational projection consumed by runtime services	Supports low-latency execution without querying semantic authority at bedside
Lineage Receipt	Provenance and release binding across semantic and runtime artifacts	Makes every released bundle replayable and auditable
Runtime Evidence Report	Normalized runtime evidence emitted from operational behavior	Connects observed bedside behavior back to governed semantics
Refinement Candidate	Structured proposal triggered by review of runtime evidence	Keeps operational learning inside the governed loop
Governed Graph Update Request	Formal mutation path for semantic authority	Prevents ad hoc runtime patching from becoming hidden truth

Executable knowledge in OR/ICU is therefore not a static rule catalog but a connected chain of semantics, compilation, execution, evidence, and refinement. It is this connectedness that justifies treating it as a distinct medical-informatics object.

3. OR/ICU Supervisory Ecosystem

In this article, the OR/ICU supervisory ecosystem is understood not as a single model, dashboard, or bedside device, but as a set of contours operating together under bounded authority. Continuous oscillograms and signals originate at bedside devices, are normalized in the integration contour, interpreted inside the deterministic compute core of the execution contour, linked to enterprise clinical context, and, where needed, constrained by the safety kernel. In a correctly designed ecosystem, no layer should silently become the owner of clinical meaning.

The first element is the integration contour. Its task is to collect and route data from monitors, anesthesia workstations, ventilators, infusion devices, and associated gateways. For a high-acuity supervisory stack, the most relevant families are IHE Patient Care Device profiles, the SDPi family, and the ISO/IEEE 11073 service-oriented communication model, while HL7-based messaging remains important in surrounding integration practice [8-10]. If ingress semantics are arbitrary or undocumented, the downstream execution contour cannot remain reliably governed.

The second element is the execution contour, built around a compiled deterministic core. This is where executable knowledge becomes operational at low latency. The execution contour should not query a live source of authorized semantics on the bedside hot path. Instead, it consumes released artifacts and produces deterministic state assessments, findings, and recommendations.

The third element is the safety kernel, separated from the compute core. This separation is necessary because an OR/ICU supervisory system does more than classify state. It may also mediate device-facing action. The execution contour may produce a recommendation or target command, but the safety kernel is responsible for checking compatibility with device capability, temporal freshness, validity of clinical context, local policy, and, where necessary, human acknowledgement [5][17][18].

The fourth element is a structured event log. Assessment results, alerts, audit records, and diagnostic traces should form an operational memory suitable for replay and analysis. The event layer must be structured enough to support generation of a Runtime Evidence Report and subsequent governed review. This requirement is consistent with FHIR Provenance, FHIR AuditEvent, and PROV-O, even though the runtime-evidence artifact used in the present architecture remains domain-specific [12][13][16].

The fifth element is downstream projections: FHIR-facing clinical surfaces, analytic and graph projections, and operational stores used for reporting or review. Their function is to support visibility, interoperability, and continuity of enterprise workflow. They must not be treated as a new source of semantic authority or as a bedside execution surface.

The sixth element is the visualization and ontology-debug contour. This is where waveform review, episode export, replay, and ontology-linked investigation may occur. DICOM and DICOMweb are well suited to this contour, but not to the primary bedside control role in the architecture described here [14][15]. This placement allows each standards family to be used where it best matches latency, auditability, and clinical meaning.

The ecosystem should also support staged operational modes. The same executable knowledge may initially be used for interpretation only, then for interpretation plus recommendation, and only later for selected target commands in those device families and local contexts where such authority is explicitly permitted. What changes across these modes is the width of the permitted execution boundary, not the identity of the knowledge object itself.

Figure 1. Layered OR/ICU supervisory ecosystem

Table 2. Contours, responsibilities, and authority boundaries

Figure 1 element	Level	Primary responsibility	Authority boundary
Bedside environment	Environment group	Provide the physical OR/ICU setting in which devices, patients, staff, and gateways produce time-sensitive observations and possible action surfaces	Does not authorize semantics, replace clinical accountability, or decide governance changes
Monitors, ventilators, anesthesia devices, pumps, gateways	Device and gateway group	Expose measurements, settings, device state, alarms, and bounded device-facing capabilities to the integration contour	Source of observations and capabilities, not a source of executable knowledge or cross-device supervisory decisions
Integration contour	Contour	Move device and gateway data into the supervisory ecosystem as structured facts suitable for deterministic execution	Must not become a hidden source of authorized semantics or bedside assessment logic
IHE PCD, SDPi, ISO/IEEE 11073 SDC, HL7-linked gateways	Adapter group	Provide protocol and gateway adapters that carry telemetry, device state, and clinical-context links into the integration contour	Transport and normalization authority only; no authority to approve terms, compile logic, or issue device-facing actions
Execution contour	Runtime contour	Host the released compute core and safety kernel under low-latency bedside constraints	May execute the released bounded set; must not mutate source semantics or replace governance
compute core	Runtime component	Execute authorized logic and produce deterministic state assessments, findings, recommendations, and target-command candidates	Assessment authority inside the released bundle only; not the device-facing actuation boundary and not a semantic-authority surface
safety kernel	Runtime component	Bound device-facing action through device capability, freshness, contextual validity, local policy, and human-acknowledgement rules where required	Action-constraint authority only; not a direct synonym for assessment logic and not a clinical-autonomy claim
Event log	Evidence contour	Preserve results, alerts, audit events, and diagnostic traces as structured operational memory for replay and audit	Evidence preservation authority only; not an unstructured debug dump or a new source of semantic truth
Results, alerts, audit, diagnostic traces	Evidence artifact group	Record behavior emitted by the compute core, safety kernel, and surrounding runtime surfaces	Observed-behavior evidence, not by itself clinical validation, semantic repair, or governed closure
Downstream projections	Projection group	Serve clinical-record, analytical, graph, reporting, visualization, and ontology-debug consumers from structured event evidence	Consumer-facing projection authority only; no authority to change the released bundle or source semantics
Clinical record plane	Projection component	Carry record-relevant summaries and events into clinical-record workflows	Documentation-facing surface, not the bedside hot path or the semantic authority
Analytics, graph, and reporting views	Projection component	Support aggregate analysis, graph review, quality review, and operational reporting	Analytical view only; not executable bedside decision logic
Visualization and ontology-debug contour	Projection component	Make structured evidence and semantic relationships inspectable for reviewers and ontology-debug workflows	Review surface only; not direct graph mutation, UI trace repair, or device-facing control
Governance contour	Governance group	Authorize semantic content, compile release artifacts, observe runtime evidence, and route refinement back toward controlled semantic change	Governs executable knowledge; does not execute the bedside hot path or issue device-facing actions
Source of authorized semantics	Governance component	Maintain the single governed source of authorized semantic content used as release input	Semantic authority only; not a runtime observation store or deployment evidence record
Authorization and compilation	Governance component	Validate, authorize, and lower governed semantics into released execution artifacts with accountable lineage	Compilation and acceptance authority only; does not prove clinical efficacy or activate a deployment by itself
Runtime Evidence Report	Governance evidence artifact	Normalize event-log observations into reviewable evidence that can be joined back to released semantics	Evidence-join artifact only; not a replacement for the event log, source graph, or closure decision
Refinement Candidate / Governed Graph Update Request	Governance workflow artifact	Carry reviewable proposed changes from observed behavior toward governed graph-update and closure workflows	Proposal authority only; not an approved semantic change until governed closure is completed

The OR/ICU supervisory ecosystem is thus a composition of existing and compiled components intended for deployment in a fault-tolerant configuration. The bedside environment and integration contour supply structured facts, the compute core executes compiled semantics inside the execution contour, the safety kernel constrains device-facing action, the event log preserves behavior, downstream projections expose that behavior to consumers, and the governance contour returns observed behavior into controlled semantic refinement. This complete path is what allows the ecosystem to be treated as an exemplar of executable knowledge rather than merely as an integration stack.

4. Semantic-to-Execution Lifecycle

The OR/ICU supervisory ecosystem can be treated as an executable-knowledge system only if a closed path exists between the source of authorized semantics and the behavior of the bedside execution contour. In this article, that path is described in applied terms because the full generic method of governing formalizable knowledge belongs to the companion methodological paper.

The first step is ontology authoring. At this level, clinically meaningful concepts, device capabilities, context variables, permitted effects, and policy boundaries are expressed as governed semantic content. Ontology authoring does not mean bedside execution. It creates the knowledge that may later be authorized, compiled, and released.

The second step is authorization. Not every working graph state should become executable. A governed boundary is required within which a particular semantic basis is recognized as acceptable release input. In OR/ICU, this is especially important because device integration, state-assessment logic, and safety policy interact under high operational pressure.

The third step is compilation. The governed source of authorized semantics is transformed into a Compiled IR Bundle and related release artifacts, including a Lineage Receipt. At this stage, meaning becomes suitable for machine-fast execution while preserving accountable lineage. The supervisory ecosystem must not query a graph store on the bedside hot path. Governance is preserved because only a released and bounded projection of authorized semantics is executed.

The fourth step is release. Release is the governed publication and acceptance point for compiled supervisor components. It fixes which compiled artifacts, executables, authorized snapshot, lineage receipt, and compilation and deployment evidence form the bounded execution set that may later be deployed, replayed, and reviewed. Release therefore creates a reviewable package boundary, but it does not itself activate the package in a bedside environment.

The fifth step is deployment. In OR/ICU, deployment means more than copying files. It activates a released bounded execution set in a specific semantic-to-execution state: which bundle is active, which capabilities are enabled, which safety contour is in force, and which event stream will be emitted as evidence. If deployment is not linked to the same lineage chain, executable knowledge loses its verifiable connection to operational reality.

The sixth step is runtime evidence. The execution contour must produce a Runtime Evidence Report compatible with the same semantic chain that authorized, compiled, released, and deployed the bundle. PROV-O, FHIR Provenance, and FHIR AuditEvent demonstrate that provenance, action context, and audit events can be modeled as structured objects suitable for later review [12][13][16]. In the present architecture, runtime evidence must be designed as a first-class object rather than as a side-effect technical log.

The seventh step is governed refinement. A Refinement Candidate is not an operational patch to the execution contour. It is a structured finding that, if accepted, may lead to a Governed Graph Update Request. This distinction preserves the asymmetry between the execution contour and the authority source: operational experience may trigger reassessment of the semantic basis, but it must not silently modify that basis during runtime.

Figure 2. Closed semantic-to-execution lifecycle in the OR/ICU supervisory ecosystem

This lifecycle helps avoid two common architectural failures. The first is the document-oriented pattern, in which semantics are governed but never become full operational logic. The second is the execution-only pattern, in which behavior is operational but no longer remains semantically governed. The OR/ICU supervisory ecosystem should avoid both by ensuring that execution artifacts arise from authorized semantics and that operational learning returns only through a governed refinement path.

5. Rationale for a Deterministic Bedside Execution Architecture

The OR/ICU architecture considered in this paper should be deterministic, edge-oriented, rule-based, and formally auditable. This position is not a rejection of a possible role for artificial intelligence in medical informatics. It reflects the requirements of the specific environment: inspectability, reproducibility, strictly bounded device-facing authority, and high-confidence governance of semantic change in a regulatory and safety-critical clinical setting [5-7][17][18].

Inspectability is necessary because outputs of the supervisory system may influence clinical attention and workflow even before any device-facing action is taken. A risk indicator, recommendation, alarm-suppression decision, or handoff-completeness flag can all alter how clinicians distribute their attention. The more critical and time-constrained the environment, the stronger the requirement to review the basis of the system’s output in meaningful terms.

Reproducibility is necessary because the supervisory system must support retrospective analysis of how a state assessment or target command was produced under a specific bundle, clinical context, and device state. Reproducibility is stronger when the execution path is deterministic, the active knowledge artifact is a Compiled IR Bundle, and operational behavior is captured in a Runtime Evidence Report.

Bounded authority for command issuance is the third reason. The system described here is a deterministic supervisory system rather than a fully autonomous therapeutic controller. The execution contour may produce a recommendation or target command, but the final device-facing act must pass through a separate safety kernel that checks device capability, freshness, contextual validity, local policy, and, where appropriate, human acknowledgement. In that sense, the deterministic stance is not only about model transparency; it is about preserving the difference between the assessment layer and the actuation boundary.

There is also a deployment reason. The OR/ICU ecosystem described here is vendor-neutral and edge-first, which means it must operate across heterogeneous device families, gateway styles, and local operational policies. Deterministic released bundles make it easier to reason about what is portable, what remains device-specific, and what must remain under explicit local approval. A bedside AI runtime would tend to blur those boundaries by pushing more hidden logic into the execution layer itself.

At the same time, AI may still play a meaningful role upstream of the bedside execution contour. Trusted agentic systems may be used to collect and organize knowledge sources, prepare material for review, design a draft knowledge graph, and analyze use materials in support of later refinement. In the present architecture, however, such systems do not authorize the stable snapshot, compile the released module, or issue bedside recommendations or device-facing actions on their own. Their role belongs to knowledge preparation and maintenance rather than to the bedside execution boundary.

The claim of this section should therefore be read narrowly. Within the OR/ICU supervisory ecosystem defined here, AI does not belong inside the bedside execution boundary. A useful role above that boundary is not excluded, but it does not replace deterministic, auditable, and governed bedside logic.

6. Interoperability and Deployment Contours

Executable knowledge in OR/ICU exists inside an environment of medical-device and health-information interoperability. The architecture should therefore explicitly distinguish the integration contour, the clinical-record plane, auxiliary visualization and debug surfaces, and strictly bounded device-facing pathways. This separation reduces the risk that one integration family is forced to perform tasks for which it was never designed.

For the integration contour, the most relevant families are IHE Patient Care Device profiles, the SDPi family, and the ISO/IEEE 11073 service-oriented communication model [8-10]. These approaches are better suited to low-latency telemetry, alarm and event flow, and bounded external device interaction in acute-care settings than document-centric or archive-centric protocols are.

The clinical-record contour serves a different function. FHIR and related enterprise representations are appropriate for preservation of structured patient context, results, provenance, audit events, continuity of handoff, and clinical documentation [11-13]. This contour is indispensable to the supervisory ecosystem, but it is not identical to the bedside control plane. Any architecture that assumes the enterprise record pathway is automatically suitable for low-latency bedside execution should be regarded as methodologically vulnerable.

The visualization and debug contour has a separate role as well. DICOM and DICOMweb may be used for visualization, episode export, waveform review, and investigation of ontology-linked traces [14][15]. This placement does not diminish DICOM; it assigns it to the part of the ecosystem where visual representation and review should live, apart from latency-sensitive execution and apart from the clinical-record contour.

Vendor neutrality is supported precisely by this explicit separation of contours. Device ecosystems differ in how much public integration surface they expose and in how much external control they allow. An executable-knowledge architecture should not require every vendor to support an identical mode of external interaction. Instead, it should preserve one source of authorized semantics and one deterministic execution model while allowing device-facing adapters to vary within an authorized boundary.

Portability of executable knowledge is therefore achieved not by flattening all local boundaries but by governed projection of authorized semantics into heterogeneous deployment conditions. Telemetry standards, enterprise record surfaces, visualization pathways, and bounded device adapters may differ while still participating in the same semantic-to-execution chain.

In this article, the regulatory context is treated as a factor reinforcing the need for a deterministic, inspectable, and bounded architecture, but not as an independent object of analysis. The paper is not a product-market strategy and does not provide regulatory classification of a specific software component.

7. Discussion and Scope Limitations

The proposed executable-knowledge framework keeps authorized semantics, the execution contour, and runtime evidence inside one connected medical-informatics object. Its main risk is overextension beyond the task addressed here. The boundaries of this article must therefore remain explicit.

First, the article does not demonstrate improvement in clinical outcomes. It argues for executable knowledge as an architectural and governance framework for the OR/ICU supervisory ecosystem. Clinical effectiveness, registration-grade validation, and comparative outcome evaluation belong to later translational and domain-specific studies.

Second, the article does not claim full autonomy. The ecosystem described here supports deterministic state assessment, recommendation, and bounded target commands within a safety kernel envelope. That is different from claiming a fully autonomous closed-loop therapeutic controller.

Third, the article does not claim that every medical-device vendor exposes open write interfaces or that the deployment problem has already been solved uniformly. The proposed framework is compatible with uneven capability exposure precisely because device-facing command authority is separated from the source of authorized semantics and from the state-assessment core.

Fourth, the article does not claim engineering completeness for downstream analyzer services or release contours. Stream-oriented and request-local analyzer services are discussed in later systems papers at their own evidentiary level. The present article remains conceptual and architectural.

Fifth, the article is not a generic compiler paper. Compile-time projection, provenance, and runtime evidence appear here only because they are required to define executable knowledge. Formal language design, compiler internals, and traceability machinery should be treated separately.

Finally, the article is not the generic methodological paper on governance of formalizable knowledge. It uses the closed semantic-to-execution loop to describe the OR/ICU domain, but it does not exhaust the general governance method itself.

8. Conclusion

The OR/ICU supervisory ecosystem requires more than interoperable data flows and more than fast bedside computation. It requires a medical-informatics object capable of holding the source of authorized semantics, deterministic execution, provenance, runtime evidence, and governed refinement within one inspectable chain. In this article, that object is defined as executable knowledge.

The proposed model clarifies why semantic governance must survive compilation, why the bedside execution contour must remain deterministic and bounded, why the integration contour, clinical-record contour, visualization contour, and governance contour must remain distinct, and why the path from Authorized snapshot to Runtime Evidence Report is constitutive rather than optional. These propositions can serve as a conceptual basis for further treatment of closed-loop governance of formalizable knowledge and for future domain instantiations in anesthesiology, critical care, and cardiology.

9. Authoring Basis

The article draws on the internal documentation of the HealthOS project: the specifications, schemas, and registries that define authorized semantics and its compiled form, the runtime and tooling that produce execution evidence, and the companion manuscripts of the series, bound together by a shared terminology canon. These are working sources that ground the engineering decisions and keep terminology consistent across the series. They remain internal authoring basis rather than public references and are not cited as repository links in the text.

Conflict of Interest

The manuscript describes the implementation of a specific aspect of the HealthOS platform, namely: the executable-knowledge model in the OR/ICU supervisory ecosystem.

Funding

The work was funded by RTLAB.

10. References

1. World Health Organization. “Integrated emergency, critical and operative care (ECO).” https://www.who.int/teams/integrated-health-services/clinical-services-and-systems/emergency–critical-and-operative-care
2. M. Peleg. “Computer-interpretable clinical guidelines: a methodological review.” Journal of Biomedical Informatics, 46(4), 744-763, 2013. https://doi.org/10.1016/j.jbi.2013.06.009
3. J. Fox, N. Johns, and A. Rahmanzadeh. “Disseminating medical knowledge: the PROforma approach.” Artificial Intelligence in Medicine, 14(1-2), 157-181, 1998. https://doi.org/10.1016/S0933-3657(98)00021-9
4. M. Peleg, A. A. Boxwala, O. Ogunyemi, et al. “GLIF3: a representation format for sharable computer-interpretable clinical practice guidelines.” Journal of Biomedical Informatics, 37(3), 147-161, 2004. https://doi.org/10.1016/j.jbi.2004.04.002
5. U.S. Food and Drug Administration. “Design Considerations and Pre-Market Submission Recommendations for Interoperable Medical Devices.” Guidance for Industry and Food and Drug Administration Staff, September 2017. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/design-considerations-and-pre-market-submission-recommendations-interoperable-medical-devices
6. U.S. Food and Drug Administration. “Clinical Decision Support Software.” Guidance for Industry and Food and Drug Administration Staff, January 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
7. International Medical Device Regulators Forum. “Software as a Medical Device (SaMD): Key Definitions.” IMDRF/SaMD WG/N10FINAL:2013. https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
8. Integrating the Healthcare Enterprise. “Patient Care Device (PCD) Technical Frameworks.” https://www.ihe.net/resources/technical_frameworks/#PCD
9. Integrating the Healthcare Enterprise. “Service-oriented Device Point-of-care Interoperability (SDPi).” https://profiles.ihe.net/DEV/SDPi/index.html
10. ISO. “ISO/IEEE 11073-10207:2017 Health informatics - Point-of-care medical device communication - Domain information and service model for service-oriented point-of-care medical device communication.” https://www.iso.org/standard/76538.html
11. HL7 International. “FHIR Release 4 (v4.0.1).” https://hl7.org/fhir/R4/index.html
12. HL7 International. “FHIR Resource Provenance (R4).” https://hl7.org/fhir/R4/provenance.html
13. HL7 International. “FHIR Resource AuditEvent (R4).” https://hl7.org/fhir/R4/auditevent.html
14. National Electrical Manufacturers Association. “DICOM Standard.” https://www.dicomstandard.org/
15. National Electrical Manufacturers Association. “DICOMweb: DICOM Over the Web.” https://www.dicomstandard.org/using/dicomweb
16. W3C. “PROV-O: The PROV Ontology.” https://www.w3.org/TR/prov-o/
17. ISO. “ISO 14971:2019 Medical devices - Application of risk management to medical devices.” https://www.iso.org/standard/72704.html
18. ISO. “IEC 62304:2006/AMD 1:2015 Medical device software - Software life cycle processes.” https://www.iso.org/standard/64686.html