Implementing a stream analyzer for mixed named features and oscillograms

Authors

1. Prozorov A.A., Director of Technology, RTLAB; Architect, Sbertech; ap@rtlab.ru;

Abstract

Objective: Continuous bedside signals need a stream-oriented architecture that can accept protocol messages, maintain operational session/window state, align current named-feature or term-value context with bounded oscillogram windows, invoke executable knowledge, and publish reviewable evidence without becoming semantic authority. This paper defines a reference architecture for a stateful rule-based stream analyzer for mixed named features and oscillograms.

Method: The article is a methodological systems paper with bounded design evidence. It separates release-bound runtime basis, device protocol gateway, transport acknowledgement, stream session/window state, ordering and watermark policy, Compute core invocation, publication surfaces, and stream evidence projection. External sources ground software lifecycle discipline, risk-control framing, quality-system traceability, provenance, structured audit events, canonical digests, schema-constrained evidence, HL7 v2 messaging, service-oriented point-of-care device interoperability, wearable and internal-bus extensions, and selected gateway implementation options [1-22].

Results: The paper specifies a lifecycle from release evidence through startup verification, readiness, protocol intake, ACK/NACK, stream session/window management, window-local Compute core invocation, result/audit/debug/metric publication, and downstream stream evidence projection. It also distinguishes transport acknowledgement from terminal analyzer evidence, operational stream state from semantic authority, and reference architecture from deployed implementation evidence.

Conclusion: A stateful rule-based stream analyzer architecture can make continuous mixed named-feature and oscillogram processing reviewable while preserving separate semantic, release, gateway, service-host, runtime, and evidence responsibilities.

Keywords: stateful rule-based analyzer; mixed named features; oscillograms; stream session; windowed analysis; device protocol gateway; Rust native gateway; Compute core; stream evidence projection; auditability

Abbreviations And Terminology

Stream analyzer: A stateful rule-based analyzer service architecture for continuous intake, session/window management, window-local executable-knowledge invocation, and evidence publication over mixed named-feature and oscillogram streams. Where a domain paper supplies current named term values, the stream analyzer can carry them as window-local context that remains current until the next update; it does not define their clinical semantics. In this paper it is a reference architecture, not a deployed implementation claim.

Stateful rule-based analyzer: The keyword-level framing for the stream analyzer in this article. It preserves operational session/window state and evaluates release-bound executable rules over closed or admissible windows; it is not semantic authority and does not autonomously apply clinical commands.

Stream analyzer service architecture: The boundary that combines gateway intake, service-host readiness, session identity, ordering, watermarking, rolling windows, publication surfaces, and stream evidence projection around release-bound executable knowledge.

Stream session: The operational state associated with a continuous source over time. It may include source identity, connection state, ordering state, window membership, watermark state, duplicate handling, and reconnect history. It is not semantic authority.

Rolling window: A bounded segment of a stream assembled for analysis from ordered or policy-admitted late data. The window supplies the Compute core with a normalized execution request.

Windowed analysis: The evaluation of one stream window as a bounded runtime request. The analyzer may keep stream/session state around the window, while the Compute core receives only a normalized window-local invocation.

Event-time ordering: Ordering based on declared event timestamps or device-origin times rather than the wall-clock time at which the gateway observes a message.

Watermark: A stream-processing boundary that states which event-time horizon is considered complete enough for a window decision under the declared late-data policy.

Late data: Data that arrives after the analyzer has advanced the relevant ordering or watermark boundary. The architecture must either admit, quarantine, compensate, or reject late data under policy and evidence.

ACK/NACK: Transport acknowledgement and negative acknowledgement. In this paper, ACK/NACK marks protocol acceptance or rejection at the gateway boundary; it is not terminal analyzer evidence.

Deterministic ACK/NACK: A protocol acknowledgement decision based on a declared handoff guarantee, such as bounded memory admission, local durable append, or internal bus acknowledgement. It is deterministic with respect to the gateway contract; it is not analyzer completion.

Device protocol gateway: An interchangeable device-facing medical protocol boundary that owns protocol termination, framing, minimal validation, admission, acknowledgement, and handoff to downstream stream processing. It is not semantic authority.

Hard low-jitter gateway boundary: A device protocol gateway boundary designed to explicitly bound latency jitter for device-facing acknowledgement. It uses bounded buffers, explicit backpressure, deterministic ACK/NACK policy, and latency-jitter telemetry.

Rust native gateway: A native gateway option for low-jitter protocol termination. It is the preferred design option when the device-facing boundary needs a strong balance of raw latency, jitter control, memory safety, explicit buffer ownership, reviewability, and deterministic handoff evidence.

HL7 v2/MLLP protocol path: The bounded device protocol path that owns Minimal Lower Layer Protocol framing, message intake, protocol acknowledgement, and gateway-level validation before downstream stream analysis.

Runtime library: The unified library linked into analyzer services for runtime execution. The stream analyzer invokes the Compute core path for window-local analysis. Safety-kernel command-application paths belong to downstream stateful human-in-the-loop contours, not to the normal stream feature path.

Compute core: The deterministic execution component that evaluates a normalized request against a validated in-memory runtime catalog and returns deterministic response/evidence.

Safety kernel: The runtime safety boundary that gates admissibility and evidence. In this paper it is not invoked by the normal stream feature path; it is reserved for downstream stateful human-in-the-loop command application.

Stateful analyzer: An analyzer path that preserves operational state and uses the Safety kernel for human-in-the-loop application of human-accepted commands.

Runtime term reference: A compiled term identity carried from the runtime catalog into a window-local request, deterministic response, audit/debug references, and stream evidence projection. Registry and trace joins remain the responsibility of the companion term-traceability article.

Non-repudiable audit record: A durable audit record whose provenance, digest or context binding, and append-only publication make it unsuitable for silent reconstruction from debug traces. This paper treats it as an evidence-bound auditability concept, not a legal non-repudiation claim.

HITL command application: A downstream stateful-analyzer path in which the Safety kernel gates application of human-accepted commands. It is not part of the normal stream feature path.

Stream evidence projection: The downstream normalization of stream-session, window, publication, audit, debug, metric, and runtime outputs into reviewable evidence for replay and diagnostic-contour handoff.

Global invariant: The stream analyzer, device protocol gateway, stream session state, window state, publication layer, debug evidence, and evidence projections are not semantic authority. They execute and report against release-bound artifacts; they do not authorize, repair, or reinterpret the knowledge graph.

Introduction

Request-local analyzers are not enough for continuous bedside signals. A monitor may hold a long-lived connection, send observations over time, retransmit or reconnect, produce out-of-order frames, drop channels, or expose partial evidence before a clinically meaningful window is ready for downstream interpretation. A stream analyzer therefore needs operational state: source identity, session history, ordering policy, watermark progress, window membership, backpressure, and publication state.

That operational state is useful only if its authority boundary is explicit. The analyzer may decide whether a window is complete enough to run, whether late data is admitted or rejected, and whether a terminal evidence gap exists. It must not decide semantic meaning. Semantic authority remains upstream in the governed knowledge graph and compiled artifacts; release and deployment evidence identify the bounded execution set; the service host and gateway manage transport and operations; the Compute core executes normalized window-local requests.

The contribution of this article is a reference architecture for implementing a stateful rule-based stream analyzer for mixed named features and oscillograms. The word “implementing” in the title names an implementation architecture pattern, not deployed implementation evidence. The article remains design/reference in the current program framing and keeps full deployment, clinical validation, release automation, and trust-chain claims out of scope.

Companion Articles

Implementing executable knowledge as compute core and safety kernel owns the Runtime library, Compute core, Safety kernel, stateless analysis, fail-closed execution, and runtime-library/service-host boundary. This paper consumes that boundary and focuses on continuous stream/session/window hosting around it.

Stateless rule-based analyzer for mixed named features and oscillograms owns the request-local analyzer service architecture for submitted analysis requests. The present paper owns continuous stream intake, session state, rolling windows, ordering, watermarking, late-data policy, and stream evidence projection.

Formal knowledge representation as the input and internal languages of the knowledge compiler owns compiler language layers and compiled representation concepts. End-to-end codified-term traceability for debugging and auditing the compiler and executable modules owns term registry/trace joins and Workbench-facing runtime evidence triage. Authorization and diagnostic contour as universal infrastructure for executable-knowledge development and governance owns diagnostic classification, remediation packets, governed graph-update requests, authority write evidence, rebuilt snapshots, closure evidence, and human closure decisions.

Instant health assessment through an ECG example: interpreting mixed named terms and ECG oscillograms owns ECG-domain interpretation over current named term values and a real-time 12-lead ECG stream as time-aligned, governed evidence. This stream-analyzer paper may use bedside signal flow and current term-value context as architectural scenarios, but it does not define ECG clinical interpretation. Automatic closed-loop release of trusted executable analyzer modules from a trusted knowledge snapshot and Continuous chain of trust in the automatic closed-loop release of executable analyzer modules own release automation and trust-chain continuity.

Materials And Methods

This is a methodological systems article with bounded design evidence. The internal authoring basis consists of ingest realization analysis, diagnostic-roadmap context, request-local analyzer contrast material, Runtime library and Compute core manuscripts, stream/batch publication and evidence surfaces, and the shared IHA terminology canon. Those internal artifacts shape the manuscript but are not public references.

The external reference set is deliberately compact. IEC 62304, ISO 14971, and ISO 13485 ground lifecycle, risk-control, and quality-system traceability framing [1-3]. PROV-O and FHIR AuditEvent ground provenance and structured audit-event analogies [4,5]. RFC 8785 and JSON Schema 2020-12 ground digest-bound and schema-constrained evidence [6,7]. HL7 v2, IHE Patient Care Device, IHE SDPi, and ISO/IEEE 11073 SDC materials ground patient-care-device messaging and service-oriented point-of-care device interoperability [8-11]. MQTT, Kafka, and gRPC ground optional wearable and internal integration-bus extensions [12-14]. Rust, Apache Camel, IPF, HAProxy, GoLevel7, and Google MLLP Adapter documentation ground gateway implementation options only where the article discusses those stacks [15-22].

Stream Analyzer Architecture Overview

The stream analyzer architecture begins with a release-bound runtime basis and ends with stream evidence projection. Release and deployment evidence identify the accepted bundle, release receipt, expected bundle digest, deployment context, and configuration fingerprint. Startup verification gates readiness. Only after readiness can the device protocol gateway accept messages, emit ACK/NACK, and forward admissible material to the service host. The service host maintains stream sessions, ordering state, watermarks, rolling windows, and worker execution. Closed windows become normalized window-local requests to the Compute core. Publication surfaces emit results, alerts, audit events, debug traces, metrics, failures, and cleanup evidence. Stream evidence projection then normalizes those outputs for replay and diagnostic-contour handoff.

Figure 1. Stream analyzer lifecycle contour. Release and deployment evidence flow into startup verification and readiness. The gateway owns protocol intake and ACK/NACK, while the service host owns session/window state, ordering, watermarking, window assembly, Compute core invocation, publication, and stream evidence projection.

Figure 1 separates transport acceptance from analysis evidence. A protocol ACK can say that a message was received or accepted at the gateway boundary; it cannot say that a stream window completed, that the Compute core ran, or that durable audit evidence exists. Those claims appear only after the analyzer publishes terminal stream evidence.

Table 1. Components, responsibilities, and authority boundaries.

Component	Responsibility	Authority boundary
Semantic authority and compiler	Produce authorized semantics, compiled runtime bundle, registry/trace material, and lineage evidence before release.	Do not own stream intake, session state, or publication.
Release/deployment evidence	Identify accepted bundle, release receipt, expected bundle digest, deployment context, and configuration fingerprint.	Does not execute windows or prove clinical validity.
Edge/device protocol gateway	Owns network edge, medical protocol framing, message intake, gateway validation, and ACK/NACK.	ACK/NACK is not terminal analyzer evidence.
Service host	Owns readiness, admission, session/window management, worker orchestration, publication, cleanup, and operational evidence.	Does not define semantic meaning or authorize graph changes.
Stream session manager	Maintains source identity, session state, reconnect history, duplicate handling, and window membership.	Operational state is not semantic authority.
Ordering and watermark policy	Orders events, advances completeness horizons, and classifies late data.	Does not change clinical thresholds or knowledge definitions.
Rolling window manager	Assembles bounded windows and carries runtime term refs into Compute core invocation.	Does not claim full stream completion beyond declared window policy.
Runtime library and Compute core	Executes normalized window-local requests against a validated in-memory catalog and returns deterministic response/evidence with runtime term refs.	Does not select, load, authorize, or authenticate semantic authority; registry/trace joins remain downstream diagnostic work.
Safety kernel	Reserved for downstream stateful HITL command application.	Is not a normal element of the stream feature path.
Publication surfaces	Publish result, alert, audit material, durable audit records, debug, metric, failure, and cleanup evidence.	Debug is not durable audit; publication is not semantic repair.
Observability	Exposes health, readiness, capacity, queue, session, and error metrics.	Does not expose raw waveform or PHI through diagnostic surfaces.
Stream evidence projection	Normalizes stream/session/window evidence for replay and diagnostic review.	Does not close remediation or approve semantic changes.

Release-bound Runtime Basis

The stream analyzer starts from a release-bound runtime basis. The basis includes the selected runtime bundle, release receipt, deployment evidence, expected bundle digest, runtime configuration, and config fingerprint. Startup verification checks schema constraints, digest equality, release/deployment consistency, and host configuration before readiness. Schema-constrained evidence and canonical digests make the selected execution set reproducible for review [6,7].

Long-lived stream sessions create a specific stale-bundle risk. A service may start a session under one accepted bundle and later observe a release transition. The architecture therefore needs an explicit policy: continue existing sessions under their accepted bundle until window/session closure, drain and restart, or terminate with terminal evidence. Silent mid-session bundle replacement is not allowed because it would make replay and diagnosis ambiguous.

Streaming Ingest And Device Protocol Gateway

The device protocol gateway is protocol-pluggable. HL7 v2/MLLP is the bounded reference path because bedside monitor and enterprise-device integration commonly begin from long-lived clinical messaging interfaces rather than request/response file submission [8]. IHE Patient Care Device materials and IHE SDPi / IEEE 11073 SDC represent the broader OR/ICU device-interoperability family, including service-oriented point-of-care device integration [9-11]. The article treats SDPi/SDC as a parallel ingress family to be normalized at the same gateway boundary, not as a claim of autonomous device control.

MQTT is a possible extension for wearable or intermittent device streams, where lightweight publish/subscribe transport may be a better fit than bedside monitor messaging [12]. Kafka and gRPC are better framed as internal normalized integration transports after gateway admission: Kafka for durable event streaming and fan-out, gRPC for service-to-service APIs and streaming RPC [13,14]. They are not device-side semantic authority and should not own bedside ACK/NACK unless a specific deployment contract makes them part of the gateway handoff guarantee.

The gateway owns protocol framing, gateway-level message validation, connection/session behavior, and transport acknowledgement. For HL7 v2/MLLP, Apache Camel’s MLLP component remains a pragmatic integration candidate because its documentation supports MLLP consumer/producer behavior and HL7 acknowledgement handling [16]. That integration path should be paired with a service host that owns stream/session/window analysis rather than embedding semantic or runtime authority into the gateway.

Transport ACK/NACK must remain narrow. A positive acknowledgement may indicate that the gateway accepted a message for downstream handling. A negative acknowledgement may indicate framing, validation, routing, or gateway rejection. Neither one proves that a stream window has closed, that the Compute core executed, that durable audit was published, or that diagnostic review can close.

Hard Low-jitter Gateway Boundary

Some deployments need the device-facing protocol terminator to minimize latency jitter and make ACK/NACK behavior deterministic under load. That boundary should stay deliberately small: terminate the selected protocol, parse frames with bounded buffers, perform minimal syntactic and admission validation, attach source/session/epoch metadata, hand off to a bounded queue, local write-ahead log, or internal bus, and then emit ACK/NACK according to the declared handoff guarantee. It should not run clinical interpretation, mutate semantic authority, wait for diagnostic closure, or hide downstream analyzer failures.

The ACK mode is an explicit design choice. ACK after bounded memory admission has the lowest latency and jitter but weaker crash durability. ACK after local durable append adds storage jitter but gives stronger replay evidence. ACK after internal bus acknowledgement gives stronger shared-handoff evidence but inherits broker or RPC jitter. ACK after analyzer result is not recommended for the device-facing boundary because it collapses transport acknowledgement with terminal analyzer evidence.

For hard low-jitter gateway ownership, a Rust native gateway is the preferred design option. The choice is not made from one criterion alone. It reflects the combined weight of raw latency, low-jitter behavior, deterministic ACK/NACK implementation, memory safety, reviewability, maintenance cost, and development cost. This does not make Rust a clinical validator or semantic authority; it only makes it the strongest candidate for the device protocol terminator that produces deterministic handoff evidence.

Stream Session And Window Model

A stream session binds a continuous source to operational state. Its minimum identity surface includes a stable source identity, session id, connection epoch, accepted bundle digest, config fingerprint, gateway route, and admission policy. Reconnect behavior must decide whether a source resumes an existing session, starts a new session, or enters a collision/quarantine path. Identity collisions are evidence events, not hidden operational repairs.

Windowing turns continuous data into bounded Compute core invocations. A rolling window has a window id, event-time range, channel/feature membership, completeness state, ordering facts, watermark facts, late-data decisions, and closure status. When a stream combines oscillograms with named term values, the window also carries the current term-value context valid for that event-time range until a later term-value update supersedes it. The analyzer can close a window when policy says the window is complete enough, expired, aborted, superseded, or failed. Window closure is the boundary at which a normalized runtime request can be assembled.

Late and out-of-order data need explicit policy. Some late data may be admitted before the watermark, some may cause a correction window, some may be quarantined, and some may be rejected. The important property is not that every stream becomes perfect; it is that the analyzer emits evidence explaining which policy handled the data and whether prior results are unchanged, superseded, or incomplete.

Partial channel or named-feature loss is also a first-class state. The analyzer can emit a missing-channel failure, run a degraded path only if declared policy allows it, or defer window closure until the watermark or timeout. Undeclared degradation is not an alternative to fail-closed execution.

This session/window state is the architectural hinge of the paper. The gateway determines whether material is admitted, but the session/window layer determines how admitted material becomes reviewable analysis: it binds messages to source/session identity, tracks completeness, records ordering and late-data facts, and decides when enough evidence exists to assemble a bounded window-local request.

Gateway And Integration Stack Option Analysis

The stack analysis is a bounded design input, not the central claim of the paper. It records which component owns device-facing acknowledgement, which component owns integration, and which component must not be treated as terminal analyzer evidence.

Table 2. Gateway and integration-stack option analysis and residual gaps.

Option	Design role	Reviewer meaning	Residual gap
Rust native gateway	Preferred hard low-jitter device-facing ACK owner.	Small protocol terminator with downstream handoff [15].	Custom protocol evidence required.
Camel/MLLP or adapter-style MLLP path	Pragmatic MLLP ingress when hard jitter is not required [16,22].	Mature HL7 v2/MLLP path; analyzer still owns sessions.	Weaker for hard low-jitter boundaries.
Kafka/gRPC internal bus	Internal transport after gateway admission [13,14,17].	Fan-out and service APIs after ACK decision.	Not device ACK owner or terminal analyzer evidence.
IPF over Camel	Conditional healthcare integration option [18].	Useful for heavier IHE-aware perimeters.	Not the low-jitter edge default.
HAProxy edge, SPOE/SPOA, or HAProxy fork	TCP/TLS routing and policy offload only [19,20].	Avoids making an edge proxy fork the medical transport product.	Still needs a real device protocol gateway.

The table intentionally stops at stack selection. It does not claim that any option delivers clinical validation, exactly-once analyzer semantics, release-chain proof, or diagnostic closure.

Table 3. Go, Rust, and C++ comparison for the device protocol gateway.

Implementation option	Raw latency	Low-jitter behavior	Deterministic ACK/NACK	Memory safety	Reviewability	Maintenance cost	Development cost	Architecture decision
Go / GoLevel7-style gateway	Good.	Good for soft low-jitter; runtime pauses must be measured.	Strong with explicit tested ACK policy.	Good compared with manual memory.	High; approachable code.	Low to moderate.	Low to moderate with GoLevel7-style libraries [21].	Pragmatic soft low-jitter option.
Rust native gateway	Very good.	Very good with explicit ownership and bounded buffers.	Strong through typed admission and handoff states.	Very high; ownership reduces common defects [15].	High; low-level code can be isolated.	Moderate.	Moderate.	Winner: default hard low-jitter device protocol gateway.
C++ gateway	Excellent.	Very good if allocation, threading, and system calls are controlled.	Strong with disciplined state machines.	Lower; depends on discipline and tooling.	Moderate; more ownership/lifetime evidence needed.	High.	High.	Specialized maximum-control option.

The selected default for the hard low-jitter device protocol gateway is Rust. Go remains the best lower-cost pragmatic option when soft low-jitter behavior is enough. C++ remains viable for specialized maximum-control gateways, but its memory-safety, reviewability, maintenance, and development-cost burden makes it the less balanced default for this architecture.

The gateway decision changes admission latency, jitter control, and handoff durability; it does not change the stream-analyzer model. After the gateway admits a frame, the central responsibilities return to session identity, ordering, watermarking, window closure, Compute core invocation, publication, and evidence projection.

Named-feature Preparation In Streams

Named-feature preparation in streams is more complex than request-local preparation because feature material may arrive over multiple messages and windows. The analyzer must preserve the source identity, session id, event-time range, channel membership, declared feature name, feature version or release-bound selector where applicable, window id, ordering facts, and evidence references. It then produces a window-local request whose inputs are stable enough for deterministic Compute core execution.

Mixed named features, named term values, and oscillograms can enter the same window through different paths. A named feature may arrive as a codified value, may be derived from a signal chunk, or may be assembled from multiple prior observations. A named term value may arrive as current context, such as a laboratory-test item and value, whose validity lasts until the next update. The architecture must make that provenance explicit so reviewers can distinguish a source-data problem, decoder problem, feature-preparation problem, runtime-execution problem, and semantic-authority question.

The preparation step therefore records the input form and transformation path for each named feature. Direct feature input, derived feature input, and oscillogram-backed feature input should remain distinguishable in evidence even when they are evaluated together in one window. This keeps named-feature extraction operationally reviewable without claiming that the stream analyzer defines the clinical meaning of the feature name.

Compute Core Invocation From Stream Windows

The stream analyzer invokes the Compute core only after a window is closed or otherwise admissible under declared policy. The service host prepares the normalized request and release-bound configuration, including runtime term references carried from the accepted bundle and runtime catalog. The Compute core evaluates the window-local request through the Runtime library and returns deterministic response/evidence with those runtime term references intact. This paper does not repeat the Compute core’s internal scheduler, staged-write, barrier-commit, or response-hash design because that belongs to Implementing executable knowledge as compute core and safety kernel.

The Safety kernel is not a normal part of the stream feature path. In this article, windows produce evidence-bearing analysis outputs, not automatically applied commands. HITL command application belongs to downstream stateful analyzer contours where a human-in-the-loop workflow must ensure that accepted human commands are applied according to accepted command state.

Evidence Publication Surfaces

The stream analyzer publishes multiple surfaces because stream review needs more than a result. Results carry window-local outputs, runtime term references, and deterministic response hashes. Alerts carry operational or declared analyzer events. The Compute core and runtime path may emit audit material, but the service host or audit surface must publish it through the durable audit path before it can be treated as a non-repudiable audit record. Debug evidence explains request/session/window decisions and runtime path selection. Metrics expose aggregate operational state. Failure evidence records rejection, late-data handling, stale-bundle handling, publication errors, and cleanup outcomes. Stream evidence projection normalizes these surfaces for downstream replay and diagnostic-contour handoff.

Audit evidence must not be reconstructed from debug traces. Debug is diagnostic and may link to audit refs. Audit is durable and must have its own publication contract. PROV-O and FHIR AuditEvent ground provenance-bearing and structured audit-event analogies for this separation [4,5]. Runtime term references can appear in result, audit, debug, and stream evidence projection, but the term registry/trace join that classifies those references remains outside the stream analyzer.

Backpressure, Degradation, And Failure Semantics

Backpressure is part of the evidence model. Queue saturation, slow consumers, broker unavailability, gateway overload, worker exhaustion, or publication stalls must become observable failure or degradation facts, not silent latency. A bounded queue prevents unreviewable accumulation of stream material and helps operators separate capacity failure from decoder, runtime, release, or semantic issues.

Controlled degradation is narrower than failure handling. A missing optional channel, delayed feature, or partial source may yield a degraded window only when a declared policy allows it and the degraded state appears in result metadata, control facts, audit links when applicable, debug evidence, and stream evidence projection. Undeclared degradation remains a fail-closed condition.

Publication failure must be terminally visible. If Compute core execution succeeds but result or audit publication fails, the evidence chain must show a publication-error state rather than pretending that the window completed normally. If audit publication is mandatory and cannot be confirmed, debug evidence cannot fill the gap.

Security, PHI, And Operational Controls

Security controls sit at the gateway and service-host boundaries. The architecture includes transport-security posture, secret loading, payload admission, request size limits, message quarantine, cleanup, zeroization of request-local memory where applicable, health/readiness endpoints, and operational metrics. These controls support risk management and quality-system traceability, but they do not constitute clinical validation [2,3].

PHI and raw waveform material must remain bounded. The stream analyzer can publish references, hashes, metadata, failure classes, lead/channel summaries, ordering facts, and safe diagnostics. Debug evidence should not expose raw waveform, patient-identifying fields, secrets, private keys, credentials, or unbounded payload dumps.

Table 4. Key risks and mitigations.

Risk	Failure mode	Mitigation in the architecture
Clinical overclaim	Stream architecture is mistaken for clinical ECG or patient-state validation.	Abstract, companion boundaries, worked scenario, and limitations state that this is not clinical validation.
Hidden semantic authority	Gateway, session state, or window policy is treated as semantic authorization.	Global invariant and component boundaries keep semantic meaning upstream.
ACK without terminal evidence	Gateway accepts a message but no analyzer outcome becomes reviewable.	ACK/NACK is separated from terminal result, failure, cancellation, publication-error, and evidence-projection states.
Low-jitter overclaim	A JVM or broker-backed path is described as hard deterministic ACK/NACK.	The article reserves hard low-jitter wording for a native boundary with explicit latency telemetry, bounded handoff, and protocol-specific evidence; Camel/Kafka/gRPC remain integration paths unless the handoff guarantee says otherwise.
Stale bundle across long session	A session spans a release transition and evidence no longer identifies what ran.	Bundle digest, release receipt, config fingerprint, and session/window policy remain attached to each window.
Late or out-of-order frames	Windows close on incomplete or misordered data without evidence.	Event-time ordering, watermark, late-data classification, and correction/quarantine policy are recorded.
Reconnect identity collision	Two sources or epochs are merged incorrectly.	Stable source identity, session id, connection epoch, and collision/quarantine evidence separate sessions.
PHI leakage	Debug, metrics, or failure records expose raw waveform or identifiers.	Publication surfaces prefer references, hashes, metadata, failure classes, and safe summaries.
Stream state mistaken for semantic authority	Operational state is interpreted as domain meaning.	Stream state is defined as session/window state only and cannot authorize terminology or graph changes.
Publication failure	Runtime work completes but durable evidence is missing.	Publication-error evidence and retry/terminal status separate execution from publication success.
Exactly-once overclaim	In-process idempotency is mistaken for multi-pod exactly-once delivery.	The article limits idempotency and ordering claims to declared architecture boundaries.

Worked Stream Scenario

Consider a bedside monitor session that emits oscillogram chunks while adjacent clinical systems update named term values used as current window context. Before any message is accepted, the analyzer service has passed startup verification: the accepted bundle digest matches the expected digest, the release receipt and deployment evidence are present, the config fingerprint is fixed, and readiness is exposed.

The gateway receives an HL7 v2/MLLP-framed message or an equivalent normalized event from another protocol family such as SDPi/SDC. It validates framing and gateway-level message structure, then returns ACK or NACK according to protocol and handoff policy. If the message is accepted, the service host admits it to the stream session manager. That ACK does not mean analysis is complete; it only means the gateway boundary accepted the message for downstream handling under the declared guarantee.

The session manager binds the message to source identity, session id, connection epoch, accepted bundle digest, and config fingerprint. Ordering policy places the event into event-time order. Watermark policy determines whether the corresponding rolling window is still open, ready to close, or already closed. If a late frame arrives, the analyzer follows declared late-data policy and emits evidence explaining whether it was admitted, quarantined, rejected, or used to supersede a prior window.

When a window closes, named-feature preparation assembles a normalized window-local request from the named features, oscillogram references, channel membership, ordering facts, watermark facts, runtime term references, and release-bound runtime basis. The service host invokes the Compute core through the Runtime library. The Compute core returns deterministic response/evidence for that window while preserving runtime term references for downstream evidence joins.

The analyzer publishes result, alert when declared, audit material through the durable audit path, debug trace, metrics, cleanup evidence, and stream evidence projection. The projection links request/session/window identity, bundle digest, config fingerprint, ordering facts, watermark facts, runtime term references, response hash, audit refs, debug refs, and publication state. Downstream diagnostic review can then classify a problem as a gateway issue, stream-state issue, stale-bundle issue, feature-preparation issue, runtime issue, publication gap, term-trace join issue, or semantic-authority question.

This scenario demonstrates reviewable stream architecture. It does not validate ECG interpretation, prove full patient-state assessment, or authorize semantic changes.

Stream Session, Windowing, And Evidence Publication

Figure 2. Stream session, windowing, and evidence publication. The gateway emits transport ACK/NACK, while the analyzer service maintains session identity, ordering, watermarking, and rolling-window state. Only closed or policy-admissible windows become Compute core invocations. Terminal result, failure, and publication states feed stream evidence projection.

Figure 2 shows why ACK/NACK and terminal analyzer evidence must not be collapsed. A gateway ACK occurs near the start of the path. Terminal evidence appears only after the analyzer decides what happened to the relevant session/window state.

Evidence Chain For Replay And Review

Figure 3. Evidence chain for replay and review. Replay begins from source/session identity and joins to connection epoch, release-bound bundle digest, config fingerprint, window identity, ordering/watermark facts, named-feature evidence references, oscillogram evidence references, runtime term references, Compute core response hash, publication references, and stream evidence projection.

If a reviewer finds a stale bundle digest, missing config fingerprint, absent watermark fact, unmatched runtime term reference, debug-only claim, missing audit reference, or publication-error state, the chain helps classify the problem without treating stream behavior as clinical meaning. The result is not automatic remediation; it is a reviewable handoff to the diagnostic contour.

Limitations And Non-claims

This paper does not claim a deployed stream analyzer implementation, clinical ECG validation, full patient-state assessment coverage, autonomous diagnosis, release automation, trust-chain continuity, exactly-once multi-replica delivery, or stateful HITL command application. It does not claim that a JVM gateway, broker-backed handoff, or integration framework satisfies hard real-time or hard latency-jitter requirements. It does not make the gateway, service host, stream session state, window state, runtime term reference, debug trace, publication surface, or stream evidence projection a semantic authority. It does not use debug traces as a substitute for durable audit evidence or non-repudiable audit records. It does not perform term registry/trace joins inside the stream analyzer. It does not expose raw waveform or PHI through debug-oriented evidence. It does not claim that any OSS stack option alone provides healthcare governance, clinical validation, or diagnostic closure.

Conclusion

The stream analyzer architecture closes the operational gap between release-bound executable knowledge and reviewable continuous-stream evidence. Its central move is to keep responsibilities separate: device protocol gateways own transport acknowledgement, service hosts own stream/session/window state, the Compute core owns deterministic window-local execution, publication surfaces own evidence visibility, and semantic authority remains upstream. When a hard low-jitter device-facing boundary is required, Rust is the preferred bounded device protocol gateway decision, but the main claim remains the same: continuous mixed named-feature and oscillogram processing becomes reviewable without turning operational stream state into a second source of truth.

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: stateful stream/session/window analyzer architecture.

Funding

The work was funded by RTLAB.

References

1. IEC. IEC 62304:2006/AMD 1:2015 Medical device software - Software life cycle processes. International Electrotechnical Commission / International Organization for Standardization. https://www.iso.org/standard/64686.html
2. ISO. ISO 14971:2019 Medical devices - Application of risk management to medical devices. International Organization for Standardization. https://www.iso.org/standard/72704.html
3. ISO. ISO 13485:2016 Medical devices - Quality management systems - Requirements for regulatory purposes. International Organization for Standardization. https://www.iso.org/standard/59752.html
4. W3C. PROV-O: The PROV Ontology. https://www.w3.org/TR/prov-o/
5. HL7. FHIR R4 AuditEvent. https://hl7.org/fhir/R4/auditevent.html
6. RFC Editor. RFC 8785: JSON Canonicalization Scheme (JCS). https://www.rfc-editor.org/rfc/rfc8785
7. JSON Schema. JSON Schema Draft 2020-12. https://json-schema.org/draft/2020-12
8. HL7 International. HL7 Version 2 Product Suite. https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185
9. Integrating the Healthcare Enterprise. Patient Care Device Technical Frameworks. https://www.ihe.net/resources/technical_frameworks/#PCD
10. Integrating the Healthcare Enterprise. Service-oriented Device Point-of-care Interoperability (SDPi). https://profiles.ihe.net/DEV/SDPi/index.html
11. ISO. ISO/IEEE 11073-20701:2020 Health informatics - Device interoperability - Point-of-care medical device communication - Service oriented medical device exchange architecture and protocol binding. https://www.iso.org/standard/78227.html
12. OASIS. MQTT Version 5.0. https://www.oasis-open.org/standard/mqtt-v5-0-os/
13. Apache Kafka. Introduction. https://kafka.apache.org/intro
14. gRPC Authors. Introduction to gRPC. https://grpc.io/docs/what-is-grpc/introduction/
15. The Rust Project. The Rust Programming Language: What Is Ownership? https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html
16. Apache Camel. MLLP Component. https://camel.apache.org/components/4.18.x/mllp-component.html
17. Apache Camel. Kafka Component. https://camel.apache.org/components/4.18.x/kafka-component.html
18. Open eHealth Integration Platform. mllp component. https://oehf.github.io/ipf-docs/docs/ihe/mllpcustom/
19. HAProxy Technologies. HAProxy Configuration Manual. https://docs.haproxy.org/3.0/configuration.html
20. HAProxy Technologies. Extending HAProxy with the Stream Processing Offload Engine. https://www.haproxy.com/blog/extending-haproxy-with-the-stream-processing-offload-engine
21. GoLevel7 v2 project. GoLevel7 v2 repository. https://github.com/dshills/golevel7v2
22. GoogleCloudPlatform. MLLP Adapter. https://github.com/GoogleCloudPlatform/mllp