KIRETT: AI-Powered Wearable for Rescue Care

• KIRETT is a wearable decision support system for pre-hospital rescue operations that integrates patient vitals, situation detection, and medical protocols.
• The project combines FPGA-based edge processing with AI pre-recognition to deliver context-aware, step-by-step treatment recommendations under time-critical conditions.
• Evaluations reveal promising real-time performance while also highlighting challenges in ergonomics and the human–machine interface in dynamic rescue scenarios.

KIRETT, expanded in one paper as “Artificial intelligence in rescue operations,” is a research project on wearable decision support for pre-hospital emergency care. Across the 2025 publications, it is presented as a demonstrator family centered on a wrist-worn interface that acquires or receives patient vital signs, applies situation detection, queries a medical knowledge graph, and delivers step-by-step treatment recommendations under time-critical conditions (Nadeem et al., 29 Sep 2025). The project’s stated objectives include continuously aggregating and contextualizing patient vital signs, fusing real-time measurements with a knowledge-graph–driven treatment protocol, and supporting fast, accurate, patient-data-driven treatment in rescue scenarios such as cardiac arrest, severe trauma, seizure management, and acute respiratory compromise (Nadeem et al., 30 Sep 2025).

1. Project scope and clinical-operational setting

KIRETT is designed for pre-hospital, time-critical interventions in which family history, long-term medical data, and detailed consultation are often unavailable, yet treatment must remain fast, accurate, and patient-specific (Nadeem et al., 30 Sep 2025). The 2025 papers consistently frame the project as a support system for rescue personnel rather than as a replacement for clinical judgment. Its core functions are situation detection, treatment-path selection, and contextual presentation of recommended actions on a wearable device (Zenkert et al., 29 Sep 2025).

The targeted rescue scenarios are explicitly broad. They include “Cardiopulmonary resuscitation (CPR) and advanced life support in cardiac arrest,” “Severe trauma (e.g., major hemorrhage, shock states),” “Seizure management (with dose adjustments for age/weight),” and “Acute respiratory compromise (e.g., hypoxia, airway obstruction)” (Nadeem et al., 30 Sep 2025). Several publications emphasize that the patient’s condition may evolve rapidly, requiring immediate branching through different treatment paths based on changing vital signs rather than a single static protocol (Nadeem et al., 30 Sep 2025).

A recurrent misconception would be to read KIRETT as a fully autonomous diagnostic platform. The published material supports a narrower interpretation: KIRETT performs “computer-aided situation recognition,” presents “contextual recommendations,” and exposes explicit operator controls such as confirmation, override, “Accept,” and “Decline” rather than closed-loop autonomous actuation (Zenkert et al., 29 Sep 2025). This suggests that the project is positioned within explainable clinical decision support and workflow guidance, not autonomous diagnosis or treatment execution.

2. System architecture and hardware evolution

The architecture is described across the papers as a local IoT-based wearable platform that couples external medical devices, middleware, reasoning components, and a wrist-mounted display (Nadeem et al., 30 Sep 2025). One description presents “a wrist-worn prototype (touchscreen) plus a belt-worn power-pack and compute board in a 3D-printed enclosure,” while another quantitative description specifies “Two 3D-printed enclosures: a wrist-unit for the display and a harness-mounted box for the FPGA, battery pack, and comms modules” (Nadeem et al., 29 Sep 2025). The quantitative evaluation further reports a “Total demonstrator mass: ~550 g (390 g FPGA box + 160 g wrist display)” and notes that “Velcro and silicone straps ensure stable mounting even under vigorous movement” (Nadeem et al., 30 Sep 2025).

The sensing model is modular rather than sensor-integrated. Multiple papers state that the wearable does not embed its own medical sensors but connects to standard or medically certified devices through wireless links. Reported modalities include ECG, SpO₂, heart rate, systolic and diastolic blood pressure, respiratory rate, blood glucose, temperature, Glasgow Coma Score, ETCO₂, and skin temperature (Nadeem et al., 30 Sep 2025). The quantitative hardware description adds medical-grade sampling examples, “1 Hz for SpO₂, 0.2 Hz for blood pressure,” and incorporates “Accelerometer tri-axial data (50 Hz) for fall-detection” in the AI pipeline (Nadeem et al., 30 Sep 2025).

Communications are similarly heterogeneous. The project uses Bluetooth Low Energy for sensor uplink, Wi-Fi for higher-bandwidth or local-network connectivity, and optional mobile data or LTE-class fallback for hospital or control-center integration (Zenkert et al., 29 Sep 2025). One implementation reports “BLE 4.2 to monitors, 2.4 GHz Wi-Fi to local mesh network, future plan for encrypted LTE fallback,” while the quantitative evaluation describes “Wi-Fi (802.11n) or LTE-CatM fallback for hospital EHR integration” and an “Encrypted UART link (3 Mbps) between FPGA board and LCD controller” (Nadeem et al., 29 Sep 2025).

The compute substrate differs by publication, which indicates prototype iteration rather than a single frozen hardware design. The qualitative study describes a wrist unit with a “single-board ARM device (e.g. Raspberry Pi Zero) hosting Python/Tkinter stack” and a “2″ capacitive touchscreen (240×320 px)” (Nadeem et al., 29 Sep 2025). The quantitative evaluation instead foregrounds “Edge processing via FPGA,” specifically a “mid-range FPGA board (Xilinx Artix-7 or similar)” supporting FIR filtering, hardware-accelerated feature extraction, and “sub-100 ms inference cycles,” together with a “wrist-worn 2.4″ capacitive LCD, glove-compatible touch surface” and “Haptic feedback motor for unmissable alarms” (Nadeem et al., 30 Sep 2025). A plausible implication is that KIRETT has moved through multiple demonstrator configurations while retaining the same high-level sense–reason–display pipeline.

3. Knowledge graph and protocol representation

The knowledge graph is the central representation used to encode rescue procedures and generate treatment guidance. One paper describes a “Neo4j-backed, directed, cyclic, weakly connected graph” derived from the regional “Manual for Rescue Operations” (“Behandlungspfade und Standardarbeitsanweisungen, 2020”) (Nadeem et al., 11 Aug 2025). Another states that the source was a text-mined “Treatment Paths and Standard Operating Procedures” manual (Nadeem et al., 29 Sep 2025). Together these descriptions identify the KG as an explicit operationalization of formal rescue protocols rather than a latent embedding-only representation.

The graph formalism is partially specified. The 2025 knowledge-graph paper defines

$$KG = (V,E), \qquad E \subseteq V \times P \times V,$$

with node types including “StartNode, StopNode,” “BPRNode,” “SAANode,” “JumpNode,” “DecisionNodeYN,” “DecisionNodeOR,” “ProcedureNode,” “InvasiveProcedureNode,” “ActionNode,” “DisplayNode,” and “WarningNode” (Nadeem et al., 11 Aug 2025). Relationship types include priority edges “R1…Rn,” binary “yes/no” exits, “BPR,” “SAA,” “association,” and “additionalInformation” (Nadeem et al., 11 Aug 2025). Node properties include “id,” “name,” “BPR,” “SAA,” “d_type,” “value,” “min,” and “max” (Nadeem et al., 11 Aug 2025).

A parallel, more application-oriented schema appears in the qualitative study. Its conceptual classes are “Patient,” “Symptom,” “Sign,” “VitalSign,” “Condition,” “TreatmentStep,” “Medication,” “Dosage,” and “Equipment,” with key relations such as hasSymptom(Patient, Symptom), indicatesCondition(Symptom, Condition), recommendedStep(Condition, TreatmentStep), nextStep(TreatmentStep, TreatmentStep), and requiresEquipment(TreatmentStep, Equipment) (Nadeem et al., 29 Sep 2025). The quantitative evaluation describes the rule layer in RDF/OWL terms: “A domain ontology encodes emergency protocols (e.g. ABCDE, CPR guidelines) in RDF/OWL,” and a “forward-chaining rule engine (based on Apache Jena + Pellet) fires production rules” (Nadeem et al., 30 Sep 2025).

The operational logic is threshold-aware and graph-traversal-based. In the vital-sign integration paper, each treatment node encodes a set of required vitals and permissible ranges, and measured values are displayed in green if they lie within range and in red with a warning pop-up if they do not (Nadeem et al., 30 Sep 2025). The same paper presents automated step-skipping logic: if all queried vitals remain within the node’s admissible ranges, the system can auto-advance; otherwise it warns and re-renders the current node (Nadeem et al., 30 Sep 2025). The knowledge-graph paper adds that priority labels order successors at branching points, and the reasoning engine traverses alternatives in descending priority (Nadeem et al., 11 Aug 2025).

The scale of the encoded protocol graph is substantial. Expert walkthroughs covered “37 distinct BPR paths and 39 SAA paths,” with “3 046 nodes and 4 467 edges implemented and validated” (Nadeem et al., 11 Aug 2025). That publication also reports “sub-100 ms per node-expansion” on Neo4j queries and states that by activating context-triggered subgraphs, the “working set at any time remains ≲ 200 nodes” (Nadeem et al., 11 Aug 2025).

4. Situation detection, vital-sign processing, and knowledge fusion

KIRETT combines symbolic protocol execution with AI-based pre-recognition. The project paper describes the AI task as multi-class classification of “complication groups” under real-time constraints, trained on “>300 000 historical rescue records (last five years)” that include vitals, first impressions, administered treatments, and free-text impressions (Zenkert et al., 29 Sep 2025). The output space is explicitly given as 10 groups: pulmonary, central nervous system, cardiovascular, respiratory, abdominal, psychiatric, metabolic, gynecologic-obstetrical, infections, and special/other diseases (Zenkert et al., 29 Sep 2025).

The feature pipeline is multimodal. Reported preprocessing stages include raw CSV ingestion into PostgreSQL, filtering and outlier removal, extrapolation of missing values where domain knowledge permits, one-hot encoding for non-hierarchical categorical attributes, binary event flags, TF-IDF vectorization of free text, and standard scaling of continuous vitals such as SpO₂, blood pressure, blood sugar, and heart rate (Zenkert et al., 29 Sep 2025). Other publications focus on streaming windows of physiological data and questionnaire responses (Nadeem et al., 11 Aug 2025). The quantitative evaluation further specifies FPGA-side preprocessing: low-pass FIR filtering to remove motion artifacts, a “5 s Hamming window for HRV spectrum,” and a feature vector $f \in \mathbb{R}^M$ with “$M \approx 32$” containing “mean, variance, spectral bands, step count” (Nadeem et al., 30 Sep 2025).

Model descriptions vary with publication and level of maturity. The qualitative study summarizes “Three scenario-detection pipelines (cardiac, respiratory, neurological)” using input features such as heart rate, SpO₂, blood pressure trends, and symptom flags from an initial questionnaire, and characterizes the model family as “lightweight probabilistic classifiers or small feed-forward neural nets” (Nadeem et al., 29 Sep 2025). The knowledge-graph paper describes a small feed-forward MLP on FPGA with softmax output over situation classes (Nadeem et al., 11 Aug 2025). The quantitative evaluation gives a concrete pseudoarchitecture:

$$H = \mathrm{ReLU}(W_1 f + b_1), \qquad \hat{y} = \mathrm{softmax}(W_2 H + b_2),$$

with input dimension 32 and hidden dimension 16, implemented as a hardware-accelerated CNN/MLP pipeline whose outputs are refined in production by a “knowledge-graph-driven rule engine (OWL-RL)” (Nadeem et al., 30 Sep 2025).

The role of fusion is explicitly transitional. The vital-sign integration paper states that “in the current implementation, KIRETT does not yet apply multi-sensor fusion algorithms (e.g. Kalman filters) on the wearable itself, but relies on the Medical Devices’ internal filtering” (Nadeem et al., 30 Sep 2025). By contrast, the qualitative study reports ongoing integration of “n external KGs (medical guidelines, SNOMED CT snippets),” “Bayesian networks learned from historical rescue-station logs,” and “live vital signs streams,” conceptually fused by mapping nodes to graph entities, reconciling conflicting values by source-confidence weighting, and integrating new facts as graph edges (Nadeem et al., 29 Sep 2025). This suggests an architecture in which symbolic treatment graphs, learned probabilistic components, and live telemetry are being consolidated incrementally rather than having already reached a single finalized formalism.

5. Recommendation workflow and human–machine interaction

The recommendation loop is procedural and interactive. In one high-level algorithm, the system first identifies patient condition candidates from the detected scenario, then queries the KG for recommendedStep(Condition, s₀), presents the result, waits for operator confirmation, follows nextStep, and continues until a terminal node is reached (Nadeem et al., 29 Sep 2025). If multiple successor branches exist, selection can be ranked by a Bayesian-network posterior $P(\mathrm{Condition}\mid \mathrm{vitals})$ (Nadeem et al., 29 Sep 2025). A related workflow begins with ANN inference, locates the corresponding start node in the treatment graph, traverses a bounded subgraph, and displays multiple candidate paths when confidence warrants top-$K$ alternatives (Zenkert et al., 29 Sep 2025).

The GUI is designed to expose protocol state and threshold context directly at the point of care. The vital-sign integration paper describes a central display of the current treatment step, a vital-sign panel showing value, min/max, timestamp, and color coding, and “Accept” and “Decline” buttons that allow the rescuer either to confirm the graph’s suggested branch or override it (Nadeem et al., 30 Sep 2025). The qualitative study notes that the GUI layer was first prototyped in Tkinter on a tablet and then ported to a wrist display (Nadeem et al., 29 Sep 2025). The quantitative evaluation adds glove compatibility, adjustable backlight, and haptic feedback for alarming (Nadeem et al., 30 Sep 2025).

The interaction paradigm is deliberately conservative. The graph may auto-advance when rules are unambiguous and all required vitals are within admissible ranges, but it can also fall back to prompts, warnings, and manual confirmation when ambiguity, missing data, or threshold violations arise (Nadeem et al., 30 Sep 2025). In the knowledge-graph architecture, if no fresh value is available, the middleware returns the last-known reading or the interface presents a manual prompt; if the vital is unavailable in the vital-sign integration workflow, the GUI displays “unknown” (Nadeem et al., 11 Aug 2025). This design is consistent with the project’s emphasis on explainability, step decomposition, and operator control.

A second misconception would be to equate KIRETT with a purely data-driven black box. The papers instead describe a hybrid stack in which graph-encoded procedures, threshold rules, and explicit node types remain first-class objects, while neural models contribute pre-recognition or prioritization rather than replacing the protocol representation (Nadeem et al., 11 Aug 2025).

6. Evaluation, operator perspectives, and unresolved issues

The 2025 evaluation corpus is centered on a two-day on-site study. The quantitative evaluation reports a user study at “Siegen Fire Station (Feb 29–Mar 1, 2024)” with “Participants: $N = 14$ (10 fire-station paramedics, 4 German Red Cross), aged 18–55+, mixed experience (0–>11 yrs)” (Nadeem et al., 30 Sep 2025). Six scripted rescue missions were used, including “hypoxia, arrhythmia, minor trauma,” and participants completed tasks that included donning the wearable, acquiring vitals via BLE sensors, observing alerts, following treatment prompts, and logging actions for debriefing (Nadeem et al., 30 Sep 2025). Data collection combined a 23-question LimeSurvey instrument, neutral observer notes on reaction times and misreads, and follow-up expert interviews (Nadeem et al., 30 Sep 2025).

The quantitative ratings indicate strong perceived relevance but also significant ergonomic shortcomings. Reported results include: “Need for digitalization: Relevant: 7% (1/14); Very relevant: 86% (12/14),” “AI integration importance: Important: 57% (8/14); Very important: 43% (6/14),” “Hygiene/disinfection rated ‘very important’: 100% (14/14),” “Glove-compatible UI: 79% (11/14) ‘important’ or ‘very important’,” “Real-time vitals monitoring ‘very important’: 64% (9/14),” and “Structured reporting to hospital: 79% (11/14)” (Nadeem et al., 30 Sep 2025). At the same time, “FPGA harness ‘very uncomfortable’: 50% (7/14),” “Harness weight ‘heavy/very heavy’: 86% (12/14),” and the wrist display was only “comfortable/very comfortable” for 50% (7/14) (Nadeem et al., 30 Sep 2025).

The qualitative study sharpens these findings into operator themes. It reports “High medical fidelity of treatment paths vs. need for broader contextual overview,” “Desire for alternative view modes (expanded tree, timeline),” “Trust concerns over external data feeds (control–station vital signs),” “Mixed appetite for voice control (background noise, patient comfort),” and “Strong appreciation for UI simplicity, but requests for color-blind accessibility and haptic/tactile confirmation” (Nadeem et al., 29 Sep 2025). Ancillary questionnaire results in that study include “100 % of testers rated AI introduction as ‘important’ or ‘very important’,” “Mean age = 32,” and a UX learning curve rated “good” by approximately 50% (Nadeem et al., 29 Sep 2025).

The evidence base remains exploratory rather than clinically definitive. The papers explicitly state that “classic performance metrics were not directly reported,” that no inferential tests such as t-tests or chi-square were reported, and that there is a “Lack of ground-truth benchmarking for the FPGA-accelerated AI kernels (no published TP/FP rates)” (Nadeem et al., 30 Sep 2025). Another KIRETT paper states that no formal clinical trial data are yet available and presents lab responsiveness figures instead: “Average end-to-end update time: 250 ms (± 50 ms)” and “System ‘availability’ (no lost packets): 99.5 % in static tests,” against a latency budget in which “Each step change and vital-sign display must occur within 500 ms” (Nadeem et al., 30 Sep 2025). The knowledge-graph paper reports expert validation and embedded real-time measurements, but also marks several evaluation targets as “upcoming,” including “Precision/Recall of SD classification in simulated vital streams (> 90 % target)” (Nadeem et al., 11 Aug 2025). These statements collectively indicate that KIRETT, as currently documented, is a demonstrator and research program with partial field evaluation, not a fully benchmarked clinical product.

The project’s future directions are correspondingly concrete. Reported next steps include miniaturizing hardware “to sub-300 g total mass,” integrating custom PCBs, publishing “full AI model training, validation curves, and on-site inference accuracy (A, F1),” extending the user study to “multiple national and international rescue services (N>100),” implementing live EHR integration, pursuing “FHIR/EHR–KG linking,” standardizing vital-sign ontologies, adding advanced alarm-notification and explainable historical data views, and exploring alternatives to Bluetooth in difficult environments such as mesh networking or Ultra-Wideband (Nadeem et al., 30 Sep 2025). This suggests that KIRETT’s principal research challenge is no longer simply whether protocol graphs and wearable AI can be combined, but how to reconcile symbolic rigor, edge inference, communication robustness, ergonomics, and evidentiary validation within the operational constraints of rescue medicine.