Improved perioperative medicine involving semantic ai

Abstract

Improved perioperative medicine involving semantic AI The invention provides, amongst other aspects, a device comprising: an input interface; a control module connected to the input interface; an output interface connected to said control module; wherein the control module is configured, upon initiation of a respective next measurement cycle, 5 to: receive, via the input interface, respective next measurement data measured with respect to a patient; process the respective next measurement data, based at least on a respective previous graph associated with a respective previous measurement cycle, for obtaining a respective next graph associated with the respective next measurement cycle; output, via the output interface, the respective next graph; wherein the previous graph and the next graph each relate to knowledge 10 graphs and each comprise: a plurality of entities relevant to a clinical scenario to which the respective measurement cycles relate, and a plurality of relations between the entities; and wherein the previous and the next graph differ in at least one entity or relation.

Description

Improved perioperative medicine involving semantic AlField of the invention

[0001] The present invention relates to improved perioperative medicine through a comprehensive and computational semantic framework. Particularly, the invention relates to the application of knowledge graphs in a clinical context.Background art

[0002] The management of perioperative and critical care medicine increasingly relies on advanced technologies to optimize patient outcomes. The complexity of medical device integration, particularly in high-stakes environments like operating rooms and intensive care units, necessitates systems capable of interpreting vast amounts of heterogeneous data in real-time.

[0003] Current solutions often fall short in providing cohesive and adaptive decision support due to fragmented data streams and limited contextual integration. Advancements in artificial intelligence (Al) and semantic data processing have created opportunities to enhance device control and clinical decision-making.

[0004] A notable approach is the use of semantic knowledge graphs, which enable the synthesis of real-time data streams with contextual information derived from patient health records, procedural data, and physiological models. These graphs provide a structured, interpretable representation of clinical scenarios, facilitating automated reasoning and decision-making. Despite these advancements, integrating diverse data sources, ensuring real-time adaptability, and maintaining system explainability remain significant challenges.

[0005] Existing systems often lack the capacity to holistically consider the causative relationships between physiological changes and device settings, limiting their effectiveness in dynamic clinical environments.

[0006] US20230253117A1 discloses a method for determining an assessment of a patient for a medical condition. This involves a knowledge graph that is computed based on the input medical data. An issue with US20230253117A1 remains the lack of explainability. US20230253117A1 relies on a knowledge graph to generate a vector representing a state of the patient. This vector is then carried over to a next step, and an assessment of the patient for a medical condition is determined using a machine learning based network based on that vector. The approach of US20230253117A1 is thus directed to vector representation and not to a model that is explainable to an operator (medical staff).

[0007] CN117316465A discloses a method for constructing a multi-mode knowledge graph for nursing. However, CN117316465A is directed to providing feedback to the user on corresponding nursing knowledge based on a multimodal knowledge graph based on a nursing query instruction entered by the user, and not to real-time measurements. The approach of ON 117316465A therefor lacks effectiveness in dynamic clinical environments.

[0008] US2023253117A1, US20150294488A1, CN119026011A and JP2011170615A disclose related methods and systems. However, each of these disclosures either lacks explainability to an operator (medical staff) or lacks effectiveness in dynamic clinical environments.

[0009] The present invention aims at addressing issues, such as the issues mentioned above. Summary of the invention

[0010] According to a first aspect, the present invention provides a device comprising:an input interface;a control module connected to the input interface;an output interface connected to said control module;wherein the control module is configured, upon initiation of a respective next measurement cycle, to:receive, via the input interface, respective next measurement data measured with respect to a patient;process the respective next measurement data, based at least on a respective previous graph associated with a respective previous measurement cycle, for obtaining a respective next graph associated with the respective next measurement cycle;output, via the output interface, the respective next graph;wherein the previous graph and the next graph each relate to knowledge graphs and each comprise: a plurality of entities relevant to a clinical scenario to which the respective measurement cycles relate, and a plurality of relations between the entities; andwherein the previous and the next graph differ in at least one entity or relation.

[0011] Thereby, the measurement data may relate to one or more input streams (with, e.g., a waveform per input stream), and the processing may be referred to as semantic stream processing.

[0012] Through these features, the invention may advantageously combine semantic artificial intelligence techniques with graph-based data structures and real-time signal processing. The invention may thereby enable precise control of medical devices, such as mechanical ventilators, by dynamically adapting to patient-specific and clinical-scenario-aware contexts, thus addressing critical gaps in current technologies. Importantly, such advantages may be provided in a way that is explainable to the operator (medical staff), in view of the temporal sequence of graphs.

[0013] These advantages are not provided by US20230253117A1, relies on a knowledge graph to generate a vector representing a state of the patient. This vector is then carried over to a next step, and an assessment of the patient for a medical condition is determined using a machine learning based network based on that vector. The approach of US20230253117A1 is directed to a vector representation that is not "explainable", as the knowledge graph remains static. Any update of the knowledge graph does not relate to any "online" update but instead relates to an "offline" updating of the pre-determined graph. Hence, the knowledge graph of US20230253117A1 is to be construed as a static single graph that lacks any form of dynamic features. US20230253117A1 does describe some basic display of information according to "an assessment", e.g., "a risk or severity score representing the risk or severity of the medical condition for the patient", or a "likelihood of ventilator need", see par.

[0036] , but this merely relates to the assessment by itself, and does not allow for any explainability of how the assessment is arrived at.

[0014] Also, these advantages are not provided by CN117316465A. CN117316465A is directed to providing feedback based on queries entered by the user, which is not adapted to the needs of dynamic clinical environments.

[0015] In embodiments, the processing involves natural language processing (NPL).

[0016] In embodiments, the device comprises a postprocessing module relating to a large language model (LLM), with at least one graph, preferably the next graph, as input prompt; whereby the LLM output is displayed to the operator, either along with the at least one graph, or instead of the at least one graph. Such embodiments advantageously provide for enhanced explainability, through natural language output. This may allow the operator to respond faster or more adequately to unexpected changes in a patient's condition and may thus allow for better patient care.

[0017] According to a second aspect, the invention provides a system comprising:a device, the device comprisingan input interface;a control module connected to the input interface;an output interface connected to said control module;a data source module, preferably a sensor module, for connection to the input interface; a user module comprising at least a screen for display to an operator and for connection to the output interface;wherein the control module is configured to:receive, from the data source module, respective next measurement data; process the respective next measurement data, based at least on a respective previous graph associated with a respective previous measurement cycle, for obtaining a respective next graph associated with the respective next measurement cycle;send data of the respective next graph to the user module;wherein the data source module is configured to:measure next measurement data with respect to a patient, and send the next measurement data to the input interface of the device;wherein the user module is configured to:receive, from the output interface of the device, data of at least one graph; display, on said screen, said at least one graph;wherein the previous graph and the next graph each relate to knowledge graphs and each comprise:a plurality of entities relevant to a clinical scenario to which the respective measurement cycles relate, anda plurality of relations between the entities; andwherein the previous and the next graph differ in at least one entity or relation.

[0018] According to a further aspect, the invention provides a method for supporting a clinical event according to a clinical scenario, comprising the steps of:receiving, via an input interface comprised in a device, respective next measurement data measured with respect to a patient;processing, by a control module comprised in the device the respective next measurement data based at least on a respective previous graph associated with a respective previous measurement cycle, for obtaining a respective next graph associated with the respective next measurement cycle;outputting, via an output interface comprised in the device, the respective next graph; wherein the previous graph and the next graph each relate to knowledge graphs and each comprise:a plurality of entities relevant to a clinical scenario to which the respective measurement cycles relate, anda plurality of relations between the entities; andwherein the previous and the next graph differ in at least one entity or relation.

[0019] In embodiments, the method further comprises:sending, based on the difference between the graph associated with the previous measurement cycle and the graph associated with the new measurement cycle, an instruction to the patient-related device for altering an operational parameter of the patient-related device.

[0020] In embodiments, the method further comprises:displaying, via a screen comprised in a user module connected to the output interface of the device, at least one graph, said at least one graph relating to at least one of the previous graph and the next graph.

[0021] Preferred embodiments and their advantages are provided in the description and the dependent claims.Brief description of the drawings

[0022] The present invention will be discussed in more detail below, with reference to the attached drawings.

[0023] Fig. 1 illustrates an example system according to the invention.

[0024] Fig. 2 illustrates an example application of the system according to the invention.

[0025] Fig. 3 shows an example of a pre-determined patient-specific graph according to the invention.

[0026] Fig. 4 shows an example next graph according to the invention.Description of embodiments

[0027] The following descriptions depict only example embodiments and are not considered limiting in scope. Any reference herein to the disclosure is not intended to restrict or limit the disclosure to exact features of any one or more of the exemplary embodiments disclosed in the present specification.

[0028] Furthermore, the terms first, second, third and the like in the description and in the claims are used for distinguishing between similar elements and not necessarily for describing a sequential or chronological order. The terms are interchangeable under appropriate circumstances and the embodiments of the invention can operate in other sequences than described or illustrated herein.

[0029] Furthermore, the various embodiments, although referred to as “preferred” are to be construed as exemplary manners in which the invention may be implemented rather than as limiting the scope of the invention.

[0030] The term “comprising”, used in the claims, should not be interpreted as being restricted to the elements or steps listed thereafter; it does not exclude other elements or steps. It needs to be interpreted as specifying the presence of the stated features, integers, steps or components as referred to, but does not preclude the presence or addition of one or more other features, integers, steps or components, or groups thereof. Thus, the scope of the expression “a device comprising A and B” should not be limited to devices consisting only of components A and B, rather with respect to the present invention, the only enumerated components of the device are A and B, and further the claim should be interpreted as including equivalents of those components.

[0031] In this document, the term "knowledge graph" refers to a structured representation of knowledge that organizes information as a network of entities (nodes) and their relationships (edges). It is used to model real-world concepts and their interconnections in a way that is both human-readable and machine-interpretable. In embodiments, entities relate to any or any combination of objects, concepts, or instances, such as people, places, medical measurements, or devices. Relationships represent meaningful connections or associations between entities, such as "causes," "measured by," or "belongs to." Entities and relationships can have attributes that describe properties or values, such as "has a certain clinical condition," "time," or "status." In the context of the invention, the structure of the graph captures how entities relate to one another for a specific clinical scenario. In example embodiments, the next graph and / or the pre-determined graph include nodes for one or more of: arterial blood pressure, hypotension, ventilation flow, and mechanical ventilator, with edges describing relationships like "affects," "measured by," or "suspect cause." The temporal sequence of next graphs may thereby allow to identify changes in these nodes and their relationships, allowing to identify clinical trends, issue alerts, or adjust medical device settings dynamically, as described in this document.

[0032] In this document, the terms "measurement cycle" and "time step" are interchangeable unless where indicated differently.

[0033] Advantages of the invention are described in the summary section. Particularly advantageous may be the provision, through the generation of graphs, of a comprehensive, modular, multi-domain ontological framework. It may allow tailoring to the clinical reality of perioperative medicine and incorporation into an explainable and personalized recommendation engine. Related, it may allow its performance to be objectively evaluated and may serve as a decision engine for further integrations.

[0034] In embodiments, the input side of the device relates to two kinds of data: numeric (realtime) streaming data originating from any kind of medical device used in perioperative medicine. Numerical data can be delivered to the system in the form of waveforms (high sampling frequency), or as pre-processed inputs (e.g., averaged values, min / max etc). This distinction may be important given the fact that physiological signals are typically measured in a variety of ways, leading to different kinds of signals. The signal of an invasive blood pressure catheter (intra-arterial line) istypically a pseudo-continuous signal, whereas information regarding arterial blood pressure from oscillometric devices is typically presented as discrete measurement points with a lower sampling frequency (e.g., 1 / 60 Hz). In preferred embodiments, the device is capable of handling measurement data of both kinds. In principle, any kind of numerical monitoring data may thereby serve as an input to the device. The stream processing architecture may include ventilator settings. It may additionally, or alternatively, incorporate monitor waveforms, one or more, including but not limited to the measurement of arterial blood pressure, the measurement of central venous pressure, and the pressure aspects of the mechanical ventilation cycle. In embodiments, peritoneal insufflation settings are supported with monitor waveforms, including measurements of arterial blood pressure, central venous pressure, and mechanical ventilation pressure aspects. In embodiments, procedural information is another source, with monitor waveforms that include physical positioning of the patient, central venous pressure measurement, and mechanical ventilation cycle pressures. In embodiments, the measurement data and / or a pre-determined graph comprises contextual information regarding the patient and / or about the operative procedure (or, equivalently, clinical scenario), and / or a mechanistic schema that bridges the incorporation of numerical streaming data into a labelled-property graph model. This knowledge graph may be instantiated from a custom ontology, with the help of large language models and graph-native algorithms as well as machine learning procedures. In embodiments, based on measurement data and optionally also a pre-determined graph, the system can estimate a suitable input for clinical targets such as blood pressure, ventilation rate, and acid-base status. In preferred embodiments, the operator (health care physician) has the possibility to specify or overrule preset targets.

[0035] In embodiments, the user input means relates to an LLM (large language model). This may provide for user-friendly interfacing with the invention.

[0036] In embodiments, the invention is directed at control of a patient-related device without any display being available for an operator. Such embodiments may still enjoy the benefits known for the use of knowledge graphs, since the modus operandi of such may still be understood from the graph present in system logs. In embodiments, the invention is at the display of a graph being available for an operator, without any control of a patient-related device. Such embodiments may equally enjoy the benefits known for the use of knowledge graphs, effectively assisting an operator through automated interpretation of a temporal sequence of measurement data.

[0037] In embodiments, the processing of measurement data, or, equivalently, the semantic stream processing, relates to the following processing of input streams. First, each input stream (e.g., waveform) may be converted into a temporal sequence of knowledge graphs that is derived from a custom ontology. The graph nodes represent waveform features and clinical concepts (e.g., hypotension) in various window settings (short-term, medium-term, long-term). Translating the input waveforms into a sequence of labelled-property graphs corresponds to the way human healthcare operators process changes in the waveforms: over the long term, the patient has been hemodynamically stable, over the short term, there is a major drop in blood pressure, signifying an acute problem. Additional annotations to the input streams can be made for further processing by an inference engine (e.g., regarding data quality).

[0038] In embodiments, a means for causality assessment may be provided. This may relate, e.g., to combining computed results from graph-native reasoning and / or graph-based feature extraction of the mentioned input (e.g., waveforms and pre-determined (contextual) graph) and / or a fuzzy logic inference engine and / or a causal effect variational auto-encoder neural network. Such means may allow an assessment to be made regarding the strength of the causal relation between the physiological changes and current output device settings. Such strength may advantageously be displayed as annotation to a displayed graph, and / or be shown directly to the operator and / or form the basis for a modification of a control of a patient-related device.

[0039] In embodiments, a means for effect estimation may be provided. Through the causative model, the effects of individual and combined changes in actuator settings may be estimated, preferably not only on the target variables but also on underlying physiological variables. This may enable to reason within a broader context. For instance, increasing vasopressor dosage (actuator) in a patient with underlying vascular disease of the splanchnic vessels (context) may lead to increased risk of intestinal ischemia (physiological concept) despite increased blood pressure (output variable). By instantiating the knowledge graph further around the concept (’intestinal ischemia’), the invention may enable to discern that lactate tests are of value. If it is detected that this information is already presented, the accompanying semantic stream may be interpreted for this parameter; this allow to take this into account in the final inference of the course of action.

[0040] In embodiments, a means for enhanced language output is provided. This may enable the invention to converse clearly about its internal deductive and inductive reasoning processes with operators (health care staff), in any form possible (written, speech). Thereby, in preferred embodiments, the graphs (next graphs, pre-determined (contextual) graph (if any)) may serve as a basis for textual output generated by a large language model. Several approaches are possible: prompt engineering (including contextual information in the prompt input for a large language model), or incorporating this contextual information in the training data for the finetuning of a large language model. A suggested course of action may thereby be presented. Additionally, or alternatively, an altering of an operational parameter of a patient-related device may be provided.

[0041] In embodiments, means are provided for inferring (more) optimal output device settings. This may relate to the input graphs (measurement data) and final ("causally enriched") contextual graphs to serve as complementary inputs to a prediction head engine that outputs a suggested output state configuration for any output device present. Several graph algorithms can be employed to derive features, either local or topological, that serve as an input to the prediction head. In embodiments, the prediction head engine relates to any or any combination of: fuzzy logic regression inference, shallow or deep learning models.

[0042] In embodiments, the processing of measurement data, or, equivalently, the semantic stream processing, relates to a real-time data architecture wherein measurement data is fed to a streaming pipeline (block 1). Block 1 exchanges information regarding stream enrichment / transformation with a stream processor (block 2). Block 1 feeds its output to a real-time analytics agent (block 3). Block 3 feeds its output to a real-time analytics visualisation / decisioning agent (block 4). Optionally, block 4 is enhanced with monitoring / alert functionality, which receivesdirect input from block 2 to ensure swift handling of urgencies. In related embodiments, the control unit comprises a Streaming Pipeline which functions as a general information carrying layer. The streaming pipeline may allow the device to handle unbounded streams, given that adequate procedural usage of a generic stream processing component (e.g., Apache Flink) with a semantic engine (e.g., as provided by Neo4j Graph Database system with the Neo4j Semantics plugin) allows for the mentioned transformation into a sequence of semantic graph structures.

[0043] In preferred embodiments, the invention involves the use of a custom ontological organizing principle and stream processing subsystems. Preferably, the input data streams are then converted into a sequence of knowledge graphs that represent the clinically relevant information contained in their signal content. For example, the sequence of graphs may form a continuous situational assessment of the input waveforms.

[0044] In preferred embodiments, the device internally represents that which can be contextual input, in the form of a knowledge graph. This may allow for improved integration in a clinical context. Thereby, this graph may be instantiated guided by a variety of organizing principles, e.g., a (basic) taxonomy or a complicated ontology that represents causal or relational information on the entities relevant to the clinical scenario and physiological principles underpinning the reasoning principles that will be employed in the inference stage. In related embodiments, an ontology can be implemented using standard techniques, e.g.: Web Ontology Language (OWL).

[0045] For correct instantiation of the contextual knowledge graph, in preferred embodiments, the device makes use of one or more than one of a variety of input sources, comprising textual (reports) and numerical (e.g.: lab values or clinical scoring systems) information from the Electronic Health Records and external sources (e.g.: existing subontologies such as SNOMED-CT).

[0046] In embodiments, instantiation of the pre-determined knowledge graph relies on LLMs to match patient-related input to the structure of the graph.

[0047] In embodiments, obtaining the next graph relies on LLMs to incorporate input from the operator provided via the user input means, wherein the user input is used as input prompt and the LLM output is used for obtaining the next graph.

[0048] In preferred embodiments, the graphs of the invention relate to an overarching clinical context that is captured in a dedicated causal knowledge graph, which integrates information concerning the individual patient characteristics, underlying pathophysiological changes, specific aspects of a surgical procedure (if any) and mechanistic physiological models.

[0049] In embodiments, the patient-related device is at least partially controlled by the device of the invention. In related embodiments, the patient-related device partially controlled by the device generates measurement data which feeds, via the input interface, into the device. In yet other embodiments, at least part of the measurement data originates from a patient-related device which is not controlled in any way by the device of the invention.

[0050] In embodiments, the user input means relates to one or more than one of the following: touchscreen interfaces; mouse or trackpad devices; styluses or digital pens; voice input systems; joysticks or control knobs; graphical buttons and sliders on-screen; gesture recognition systems that track, e.g., hand or body movements; haptic feedback devices; biometric input systems.

[0051] In embodiments, the previous measurement cycle and the next measurement cycle belong to a temporal sequence of at least five respective cycles, preferably at least ten cycles, and wherein a maximum time between respective cycles is less than one minute, preferably less than 30 seconds, more preferably less than 10 seconds. This may advantageously provide real-time or near-real-time operation.

[0052] In embodiments, the output interface comprises electronic connection means for controlling a patient-related device, and wherein the control module is further configured to: send, based on the difference between the graph associated with the previous measurement cycle and the graph associated with the new measurement cycle, an instruction to the patient-related device for altering an operational parameter of the patient-related device. In embodiments, the instruction thereby triggers an altering-related action. The altering-related action may relate to altering said operational parameter. Additionally, or alternatively, the altering-related action may relate to generating a patient-related device alert via an alerting means comprised in the patient-related device. For instance, the instruction may trigger the patient-related device to emit an acoustic alert. This may have the advantage that an operator, intuitively and directly, receives the alert at a point where an issue may be detected.

[0053] In embodiments, the patient-related device relates to a mechanical ventilator, wherein the operational parameter relates at least to an intensity of ventilation flow, and wherein the respective next measurement data relate to at least one of, preferably at least two of: arterial blood pressure, central venous pressure, oxygen saturation in the blood, end-tidal carbon dioxide content, a pressure value characteristic of the ventilator, a volume value characteristic of the ventilator.

[0054] In embodiments, the patient-related device relates to a peritoneal insufflator, wherein the operational parameter relates at least to an intensity of insufflation, and wherein the respective next measurement data relate to at least one of, preferably at least two of: arterial blood pressure, central venous pressure, a pressure value characteristic of a mechanical ventilation cycle.

[0055] In embodiments, the output interface comprises electronic connection means for connecting to a user module comprising a screen for display to an operator, and wherein the control module is further configured to: display, via said screen, at least one graph, said at least one graph relating to at least one of the previous graph and the next graph.

[0056] In embodiments, the user module further comprises user input means for receiving input from the operator, and wherein the at least one graph being displayed comprises at least one entity and / or at least one relation that is editable by the operator via said user input means.

[0057] In embodiments, the user input means relates to the screen being a touchscreen.

[0058] In embodiments, the control module is further configured to: determine, based at least on the next graph, whether an alert for the operator should be generated; if yes, generate said alert and display the alert via said screen.

[0059] In embodiments, the alert relates to procedural information and comprises instructions to be carried out by the operator.

[0060] In embodiments, the user module further comprises user input means for receiving input from the operator, wherein the alert relates to a prompt for receiving a response from the operatorvia said user input means, and wherein the control module is further configured to: display, on said screen and along with the prompt and the at least one displayed graph, an annotation of said displayed graph for indicating a predicted impact of the response.

[0061] In embodiments, the processing of the next measurement data for obtaining a respective next graph is further based on a pre-determined patient-related graph instantiated based on predetermined patient data specific to the patient.

[0062] In embodiments, the system further comprises: a patient-related device connected to the output interface; wherein the control module is further configured to: send, based on the difference between the graph associated with the previous measurement cycle and the graph associated with the new measurement cycle, an instruction to the patient-related device for altering an operational parameter of the patient-related device; wherein the patient-related device is configured to: receive, from the output interface of the device, the instruction for altering the operational parameter; executing, based on said instruction, an altering-related action; wherein the altering-related action relates to altering said operational parameter and / or generating a patient-related device alert via an alerting means comprised in the patient-related device, e.g., an acoustic alert.

[0063] In embodiments, the next graph generated by the device is fed to a postprocessing module.

[0064] In embodiments, the postprocessing module relates to an LLM, with the graph as input prompt, whereby the LLM output may be displayed to the operator, either along with one of the graphs, or instead of the graph. In embodiments, the postprocessing relates to a decision support tool. This may advantageously allow enhancing decision-making through the connection of disparate data sources and identification of patterns. In embodiments, the postprocessing relates to Al reasoning. In embodiments, the postprocessing relates to data integration, e.g., involving combining heterogeneous data into a unified, structured format for analysis and / or visualization. In embodiments, the postprocessing relates to search and querying capabilities that are improved through contextual and relational queries enabled by the graph structure.

[0065] In embodiments, the respective next graph is obtained for each next measurement cycle as an intermediate, machine-readable graph state Gk that is recomputed by applying graph-update operations to the prior graph G*-i based on one of, or both of: (i) features and detected events derived from the next measurement data, (ii) a pre-determined patient-related graph Gpatient instantiated from patient-specific data. In related embodiments, it is further based on (iii) operator input via user input means.

[0066] In embodiments, the LLM is used to output a schema-constrained “graph patch” from a prompt comprising at least one of, preferably at least two of: a machine-generated summary of the extracted measurement features and detected events (including timestamps), the relevant neighborhood of G*-i to preserve continuity, the relevant subgraph of Gpatient providing patientspecific context (e.g., targets, diagnoses, device configuration), operator input events and / or notes, wherein preferably the patch is then validated against a predetermined ontology (with fixed allowed node / edge types and fixed relation labels, e.g., “precedes", “onset”, and "short / medium / long term", and optionally “predates” and "SUSPECT") and applied deterministically to obtain Gk. An advantage thereof may lie in that LLMs are used in a specific guided way, leading to very relevant and directlyapplicable results. This contrast with the case of having an LLM generating an unconstrained freeform graph, which would not lead to the advantages provided by the invention. In preferred embodiments, the "graph patch" relates at least partly to JSON operations such as create-node / create-edge / update-property.

[0067] In embodiments, obtaining the respective next graph relates to repeating the same sequence of steps at least ten measurement cycles, preferably at least 100 measurement cycles or more preferably during an entire procedure, the being repeatable relating to: the input concerning the same kinds of objects (e.g. , cycle summary + previous graph excerpt + patient context excerpt), and / or the output concerning the same kind of object (e.g., graph patch). In related embodiments, particularly embodiments with the steps being repeatable, re-running at least some, preferably all of the measurement cycles, (e.g., for debugging or audit purposes) is enabled by storing at least one of, preferably each of: (i) a cycle summary Ck, (ii) a graph excerpt used, (iii) an LLM prompt, and (iv) a resulting patch AR. As illustrated in Example 2, this may, e.g., relate to applying a patch to a graph being deterministic, as this may enable re-applying the same patch and obtaining the same Gk. Also as illustrated in Example 2, this may, e.g., relate to an LLM call being made stable by keeping the model / version fixed and using fixed decoding settings (e.g., temperature = 0), preferably combined with validation rules such as the rules illustrated in Example 2.

[0068] Example embodiments of the invention will be described with reference to Figs. 1-4.

[0069] Example 1: example system, application and graphs according to the invention

[0070] Fig. 1 illustrates an example system 100 according to the invention. It relates to example embodiments where the device 1 belongs to a system 100 that comprises a user module being a screen 8 and a patient-related device being a mechanical ventilator 7. Fig. 2 thereby illustrates an according example application of this example system, with the presence of a patient receiving treatment involving mechanical ventilation, through the mechanical ventilator 7 (shown as integrated with further devices on Fig. 2) and an operator 17 being a medical doctor.

[0071] The behaviour of the system 100 is governed by graphs, and updating of graphs (determining of the next graph) based on real-time measurements. Fig. 3 thereby shows an example of a pre-determined patient-specific graph 300 according to the invention. As shown in Fig. 3, the graph is a scenario-specific graph 9 relating to a first example clinical scenario that may involve both a respirator and an insufflator. On the other hand, Fig. 4 shows an example next graph 400 according to the invention, i.e., an intermediate graph that is recomputed for each next measurement cycle.

[0072] For illustration purposes, the intermediate graph relates to a scenario-specific next graph 6 relating to a second example clinical scenario, which may be different from the first example clinical scenario. It may be clear that, based on the scenario-specific graph 9 relating to the first example clinical scenario, scenario-specific next graphs (not shown) relating to the first example clinical scenario may be determined. Likewise, correspondence may be established between a scenariospecific graph (not shown) relating to the second example clinical scenario, and the scenariospecific next graphs 6 relating to the second example clinical scenario. Such correspondence is assumed for the system 100 illustrated in Fig. 1 and the system illustrated in Fig. 2, with the nextgraphs 6', 6" and 6"' depicted on Fig. 1 and the corresponding pre-determined graph (not shown used for instantiation of the first of these graphs.

[0073] Focusing on Fig. 1 , the system 100 comprises a device 1. The device 1 comprises an input interface 2, a control module 3 connected to the input interface, and an output interface 4 connected to said control module.

[0074] Fig. 1 illustrates a stream of measurement data 5 that is sent by a data source module 10 and transmitted 13 to the input interface 2 of the device 1.

[0075] The control module is configured, upon initiation of a respective next measurement cycle, to carry out a sequence of steps. The first step is to receive 13, via the input interface 2, respective next measurement data 5", 5"' measured with respect to a patient 16. The second step is to process the respective next measurement data 5", 5"', based at least on a respective previous graph 6', 6" associated with a respective previous measurement cycle, for obtaining a respective next graph 6", 6"' associated with the respective next measurement cycle. The third step is to output 15, via the output interface, the respective next graph 6", 6"'.

[0076] The previous graph 6', 6" and the next graph 6", 6"' each relate to knowledge graphs 6, 9. These are illustrated by Fig. 3 and 4. As may be seen on these figures, they each comprise a plurality of entities relevant to a clinical scenario to which the respective measurement cycles relate, and a plurality of relations between the entities.

[0077] Fig. 1 thereby shows several instances ofthe next graphs that are updated. While not visible on the figure, the previous 6', 6" and the next graph 6", 6"' are different; they differ in at least one entity or relation. This may be further understood from Fig. 4 (see below).

[0078] The previous measurement cycle and the next measurement cycle belong to a temporal sequence. The real-time measurements come in at a high refresh rate and hence do not constitute a bottleneck. The maximum time between respective cycles is kept below 10 seconds by fast computation of the next graph.

[0079] The device has an output interface 4 comprising electronic connection means for controlling a patient-related device 7, here a mechanical ventilator. The control module 3 is further configured to send 14, based on the difference between the graph associated with the previous measurement cycle and the graph associated with the new measurement cycle, an instruction to the mechanical ventilator 7 for altering the intensity of the flow of the ventilator.

[0080] The alteration of the ventilation flow is based on following measured data 5", 5"': arterial blood pressure, central venous pressure, a maximum pressure value of the mechanical ventilation cycle.

[0081] In variants of this example, the system as shown in Fig. 1 further includes (not shown) a peritoneal insufflator. The control module 3 is further configured to send, based on the difference between the graph associated with the previous measurement cycle and the graph associated with the new measurement cycle, an instruction to the peritoneal insufflator for altering the intensity of insufflation.

[0082] The alteration of the intensity of insufflation is based on following measurement data 5", 5"': arterial blood pressure, central venous pressure, a pressure value characteristic of a mechanical ventilation cycle.

[0083] The device has an output interface 4 comprising electronic connection means for connecting to a user module comprising a screen 8 for display to an operator 17, and the control module 3 is further configured to display 15, via said screen 8, the next graph 6", 6"'.

[0084] The user module further comprises user input means for receiving input from the operator 17. Particularly, the screen 8 is a touchscreen, and thus acts both for display and for user input. The next graph 6', 6", 6"' is displayed with a relation being editable by the doctor 17 via the touchscreen.

[0085] The control module 3 is further configured to determine, based at least on the next graph 6", 6"', whether an alert for the doctor 17 should be generated. If yes, the control module generates said alert and displays the alert via the touchscreen 8. In some cases, the alert is an instruction that may be carried out by the doctor 17 as part of the clinical procedure. In other cases, the alert is a prompt for the doctor 17. The doctor 17 thereby is informed of the predicted impact of their response, via an annotation of the displayed graph.

[0086] Fig. 1 further illustrates pre-determined patient data 19 specific to the patient 16, together with the real-time measurements constituting all patient data 18 that is available. This is the medical record that is available as offline resource (and thus, "received" 11 from the patient 16) and contains patient-specific information that is relevant to the clinical scenario. For instance, the pre-determined patient data 19 may indicate that insufflation should only be applied to a limited extent in view of the patient's medical history. Accordingly, a pre-determined patient-related graph may be instantiated based on pre-determined patient data 19 specific to the patient 16. This may relate to the graph illustrated by Fig. 3.

[0087] The data source module 10 is configured to measure next measurement data 5", 5"' with respect to a patient 16, and send the next measurement data to the input interface 2 of the device.

[0088] Both the ventilator 7 (shown in Fig. 1) and the insufflator (not shown) may receive instructions from the device to alter an operational parameter. This may trigger the execution of an altering-related action. In this example, the altering-related action is (indeed) the altering of the operational parameter. In variants of this example (not further discussed), the action relates to generating a patient-related device alert, particularly an alarm sound, via an alerting means comprised in the patient-related device.

[0089] Fig. 2 illustrates the application of this system 100 to an environment with a patient 16 and a doctor 17. While the ventilator and insufflator are not shown separately in Fig. 2, they are both assumed to be present.

[0090] Turning to Fig. 3, the scenario-specific graph 9 relating to a first example clinical scenario that may involve both a respirator and an insufflator. It represents entities and their relations within this first example clinical scenario. Entities include, e.g., "Patient" (John Doe), "Procedure" (RALP), "Pathology" (COPD, Flow Limitation, Hypercarbia, Hypotension, RV Failure, Atelectasis), "Medical Device" (Mechanical Ventilator, Insufflator), and "Physiological Derangement." Relations(underlined) describe interactions between these entities. For example, John Doe suffers from COPD, which leads to Flow Limitation and, if synergistic with "MinVol" (minimal volume), increases IntraTx Pressure. Flow Limitation thereby synergistically acts along with MinVol to increase IntraTx pressure. On the other hand, MinVol reduces Hypercarbia. The RespFreq increases MinVol. The Insufflator provides Pneumoperitoneum, which increases Atelectasis, which in its turn increases Hypercarbia. RALP employs both the Mechanical Ventilator and the Insufflator. IntraTx pressure leads to RVFailure which leads to Hypotension The graph thus captures cause-and-effect pathways, device interactions, and physiological impacts through directional relationships connecting the entities. The Physiological Derangement may thereby relate to an instantiation for a specific patient with, e.g., a flow limitation.

[0091] Regarding Fig. 3, for simplicity, not all instantiation relationships have been drawn, and the Pharmacology module is, while present, not shown.

[0092] On the other hand, Fig. 4 shows an example next graph 400 according to the invention, i.e., an intermediate graph that is recomputed for each next measurement cycle.

[0093] The graph is an example intermediate graph produced from semantic stream processing of the input data according to the invention. It is tailored to the context of a periodic acute hypotensive episode in a mechanically ventilated patient. For simplicity and illustrative purposes, the amount of graph nodes, node properties and inter-node relationships has been reduced significantly. The nodes "AIRWAY PRESSURE" and "ARTERIAL BP" (arterial blood pressure) represent a physiological concept for which an input stream serves as a direct or indirect (proxy) measure. In this example, Arterial BP could for example be obtained from the use of an intra-arterial catheter connected to a transducer. The airway pressure can be obtained from a sensor device that is part of a mechanical ventilator, or from any other commonly available measurement technique suitable to this purpose. The node "HYPOTENSION" is a detected feature that has been recognized as a clinical problem. The nodes "PEEP" and "A PRESSURE" represent concepts that have been designated as potential causes or contributing factors to the clinical problem. Other entities include "NORMOTENSION," "SIMV MODE" and "UNDERDAMPING," as well as timestamps ("16:03:50 UCT" and "08:01 :14 UCT"). Relations (underlined) connect these entities to indicate their temporal, causal, or observational relationships. For instance, "16:03:50 UCT" precedes "16:02:54 UCT" and onsets "A PRESSURE." "HYPOTENSION" is suspected to relate to "PEEP" and relates to "ARTERIAL BP" through a short term connection. "ARTERIAL BP" is further connected to "NORMOTENSION" over a medium term relation. Other key relationships include "AIRWAY PRESSURE," which has a short term relation to "A PRESSURE" and a long term relation to "SIMV MODE."

[0094] The graph of Fig. 4 thus visually represents causal and temporal interactions among various clinical measurements, conditions, and (time-stamped) events. As may be clear, each new event causes a new (time-stamped) entity to be created, and thus leads to the generation of a new graph. The next graph and the previous graph thereby differ with respect to this new event (new entity) and the associated relation(s) (new relation(s)). In variants of this example, the introduction of thenew entity and new relation may thereby cause an entity and associated relations of the previous graph to be omitted.

[0095] Example 2: detailed example according to the invention

[0096] This example is essentially the same as Example 1, except that it contains further detail regarding the role of the graphs illustrated in Fig. 3 and 4, where this is kept general in Example 1. Also, the example details how the next graph, in accordance with Example 2, is obtained from the previous graph, thereby further illustrating detailed aspects of the invention.

[0097] In this example, interaction with the user, i.e., the operator, is enabled with an LLM as user input means.

[0098] In this example, instantiation of the pre-determined knowledge graph relies on LLMs to match patient-related input to the structure of the graph. Furthermore, also the obtaining of the next graph relies on LLMs to incorporate input from the operator provided via the user input means, wherein the user input is used as input prompt and the LLM output is used for obtaining the next graph. Thereby, the processing of the next measurement data for obtaining a respective next graph is further based on a pre-determined patient-related graph instantiated based on pre-determined patient data specific to the patient.

[0099] Additionally, in this example, a postprocessing module is provided whereby the LLM receives the generated next graph as input prompt. The LLM output is displayed to the operator, along with the generated next graph. This may help the operator to respond faster or more adequately to unexpected changes in a patient's condition and may thus allow for better patient care.

[0100] In this example, the respective next graph is obtained for each next measurement cycle as an intermediate, machine-readable graph state G / dhat is recomputed by applying graph-update operations to the prior graph Gk-i based on (i) features and detected events derived from the next measurement data, (ii) a pre-determined patient-related graph Gpatient instantiated from patientspecific data, and optionally (Hi) operator input via user input means.

[0101] In this example, an LLM is used to output a schema-constrained “graph patch” (e.g., JSON operations such as create-node / create-edge / update-property) from a prompt comprising: a machine-generated summary of the extracted measurement features and detected events (including timestamps), the relevant neighborhood of G*-i to preserve continuity, and the relevant subgraph of Gpatient providing patient-specific context (e.g., targets, diagnoses, device configuration), together with any operator input events and / or notes. The patch is then validated against a predetermined ontology (with fixed allowed node / edge types and fixed relation labels, e.g., “precedes", “onset”, and "short / medium / long term", and optionally “predates” and "SUSPECT") and applied deterministically to obtain Gk. An advantage thereof may lie in that LLMs are used in a specific guided way, leading to very relevant and directly applicable results. This contrast with the case of having an LLM generating an unconstrained free-form graph, which would not lead to the advantages provided by the invention. As is elucidated by the below Code Example, the implementation of such an approach in code relates to following steps: feature extraction andretrieval, LLM-based generation of structured graph edits under a fixed schema, and deterministic validation and application.

[0102] 0.2 Code Example

[0103] This example shows one concrete, repeatable way to build the intermediate “next graph at a new measurement cycle k. The key idea is:1. turn new measurements + operator actions into a small machine-readable summary, 2. ask an LLM to propose a graph patch (a list of nodes / edges to add or update) using a fixed set of relation labels,3. validate the patch, then apply it to the previous graph Gk-i to obtain the next graph Gk.

[0104] 0.2.1 Graph patch format and relation labels

[0105] A graph patch Ak is JSON with three lists:create nodes: nodes to create,create_e ges : edges to create,up ate_properties : node property updates.With reference to Fig. 3-4 and their terminology, the relation labels are fixed to:["long term" , "short term" , "medium term" , "onset" ,"precedes" , "predates" , "SUSPECT" ] .

[0106] 0.2.2 Step 1 : build a cycle summary Ck (measurements + operator actions + LLM-enriched features)

[0107] At measurement cycle k, the system creates a small JSON summary Ck. In this example:• HYPOTENSION and A PRESSURE onsets come from numeric stream processing,• UNDERDAMPING is produced by an LLM-based enrichment step [signal-quality classification),• PEEP increased comes from an operator setpoint change (the operator set PEEP higher).{"cycle id" : "k" ,"window utc" : { "start" : "16 : 02 : 54 UCT" , "end" : "16 : 03 : 54 UCT" } , "streams " : {"ARTERIAL BP" : {"map mean" : 54 ,"target map from patient graph" : 65 , "units" : "mmHg"} ,"AIRWAY PRESSURE" : {"peep value" : 12 ,"delta pres sure value" : 18 ,"mode" : " SIMV MODE" ,"units" : " cmH2O"}} ,"detected events from numeric proces sing" : [ {"type" : "onset" ,"entity" : "HYPOTENSION" ,"time utc" : " 16 : 03 : 54 UCT" ," rule" : "MAP < target for >= 60s"} ,{"type" : "onset" ,"entity" : " $ \Delta$ PRESSURE" ,"time utc" : " 16 : 03 : 50 UCT" ," rule" : " step increase in $ \Delta$ P"}] ,"operator input events" : [{"type" : " setpoint change" ,"entity" : " PEEP" ,"direction" : "increased" ,"time utc" : " 16 : 03 : 49 UCT" ,"new value" : 12 ,"units" : " cmH20"}] ,"11m enriched stream features" : [{"entity" : "UNDERDAMPING" ,"applies to" : "ARTERIAL BP" , " confidence" : 0 . 78 ,"time utc" : " 16 : 03 : 40 UCT"}] ,"history reference times" : [{"label" : " 08 : 01 : 14 UCT" ,"meaning" : "earlier reference time in episode history"}]1

[0108] 0.2.3 Step 2: derive UNDERDAMPING via an LLM (prompt + JSON output)

[0109] This example prompt classifies arterial-line waveform quality into a small fixed vocabulary. The LLM is required to output only JSON.UNDERDAMPING classifier prompt (system message)You are a clinical signal-quality clas si fier .Return ONLY valid JSON . No extra text .Choose arti fact labels ONLY from:[ "UNDERDAMPING" , "OVERDAMPING" , "DI SCONNECTION" , "TRANSDUCER_LEVEL_ERROR" , " NONE" ] .Output fields : arti fact label , confidence , rationale short .UNDERDAMPING classifier prompt (user message)Clas si fy the arterial line waveform quality ( 16 : 03 : 30—16 : 03 : 40 UCT ) from these features :- overshoot ratio : 1 . 35- ringing cycles after upstroke : 3- rise time ms : 45- damping index : 0 . 22- note : multiple os cillations after systolic peakUNDERDAMPING classifier output (LLM JSON){"arti fact_label" : "UNDERDAMPING" ," confidence" : 0 . 78 ," rationale short" : "Overshoot with postpeak os cillations consistent with underdamping . "The system stores this result back into llm_enriched_stream_f eatures in Ck (plus timestamp and provenance).

[0110] 0.2.4 Step 3: ask an LLM to propose a graph patch R (prompt + JSON patch)To update the intermediate graph, the system gives the LLM:• a small excerpt of the previous graph Gk-i [so the LLM reuses existing nodes),• a small excerpt of patient context (e.g., target MAP),• the current cycle summary Ck,• a strict instruction to output only a JSON graph patch using the exact relation labels.Example previous graph excerpt{"nodes " : ["ARTERIAL BP" ,"AIRWAY PRESSURE" ," PEEP" ," $ \Delta$ PRESSURE" ," SIMV MODE" ,"NORMOTENSION" ,"HYPOTENSION" ,"UNDERDAMPING"] ,"edges " : [{"label" : "long term" ," s rc" : "AIRWAY PRESSURE" ,"dst" : " SIMV MODE" ,"properties" : { " confidence" : 0 . 90 , "provenance" : "device context" }}Example patient context excerpt{"patient id" : " P16" ,"targets" : { "MAP target" : 65 , "units" : "mmHg" } ," context" : { "mechanically ventilated" : true }Graph patch prompt (system message)You generate graph update patches for the intermediate graph .Return ONLY valid JSON conforming to :{" create nodes" : [ { "id" : string, "label" : string, "properties" : obj ect } ] , " create edges" : [ { "label" : string, " s rc" : string, "dst" : string, "properties" : ob j ect } ] ,"update properties " : [ { "target" : string, " key" : string, "value" : any } ] }Allowed edge labels (MUST match exactly) :[ "long term" , " short term" , "medium term" , "onset" , "precedes " , "predates " , " S USPECT" ]Rules :- Reuse existing concept nodes ( do not create new concept nodes unles s n eces sary) .- Create timestamp nodes for any timestamp used by an edge .- Use " SUSPECT" only i f supported by an operator input event ( e . g . , setp oint change )or explicit operator text .- For every edge include properties : confidence ( 0 . . 1 ) and provenance . - No prose outside JSON .Graph patch prompt (user message)previous graph excerpt :<insert the previous graph excerpt JSON>patient graph excerpt :<insert the patient context excerpt JSON>cycle summary Ck :<insert the C k JSON>Example graph patch output At (LLM JSON){" create nodes" : [{ "id" : "t_16_03_49" , "label" : " 16 : 03 : 49 UCT" ,"properties " : { "type" : "time st amp" , " source" : "operator input event : set point change" } } ,{ "id" : "t_16_03_50" , "label" : " 16 : 03 : 50 UCT" ,"properties " : { "type" : "time st amp" , " source" : "numeric event detection" } } ,{ "id" : "t_16_03_54" , "label" : " 16 : 03 : 54 UCT" ,"properties " : { "type" : "time st amp" , " source" : "numeric event detection" } } ,{ "id" : "t_16_03_40" , "label" : " 16 : 03 : 40 UCT" ,"properties " : { "type" : "time st amp" , " source" : "11m enrichment : signal qu ality" } } ,{ "id" : "t_08_01_14" , "label" : " 08 : 01 : 14 UCT" ,"properties " : { "type" : "time st amp" , " source" : "history reference" } } ] ," create edges" : [{ "label" : "precedes" , " s rc" : "t 16 03 50" , "dst" : "t 16 03 54" , "properties" : { " confidence" : 0 . 99 , "provenance" : "timestamp order" } } ,{ "label" : "onset" , " s rc" : "t 16 03 50" , "dst" : " $ \Delta$ PRESSURE" , "properties " : { " confidence" : 0 . 88 , "provenance" : "numeric rule : step inc rease in $ \Delta$ P" } } ,{ "label" : "onset" , " s rc" : "t 16 03 54 " , "dst" : "HYPOTENSION" , "properties " : { " confidence" : 0 . 92 , "provenance" : "numeric rule : MAP belo w patient target" } } ,{ "label" : " short term" , " s rc" : "HYPOTENSION" , "dst" : "ARTERIAL BP" , "properties" : { " confidence" : 0 . 95 , "provenance" : " clinical definition" } } ,{ "label" : "medium term" , " s rc" : "ARTERIAL BP" , "dst" : "NORMOTENSION" , "properties " : { " confidence" : 0 . 62 , "provenance" : "trend window" } } ,{ "label" : " short term" , " s rc" : "AIRWAY PRESSURE" , "dst" : " $ \Delta$ PRESSU RE" ,"properties" : { " confidence" : 0 . 81 , "provenance" : " stream coupling" } } ,{ "label" : "long term" , " s rc" : "AIRWAY PRESSURE" , "dst" : " SIMV MODE" , "properties" : { " confidence" : 0 . 90 , "provenance" : "device context" } } ,{ "label" : "SUSPECT" , "src" : "HYPOTENSION" , "dst" : "PEEP" , "properties " : {"confidence" : 0 . 55,"provenance" : "operator setpoint change+temporal concurrence" , "operator action time" : "16 : 03 : 49 UCT" ,"operator new value" : 12 ,"operator units "cmH20"} } ,{ "label" : "predates" , "src" : "t 08 01 14 " , "dst" : "NORMOTENSION" , "properties" : { "confidence" : 0 . 70, "provenance" : "episode history refer ence" } } ,{ "label" : "short term" , "src" : "UNDERDAMPING" , "dst" : "ARTERIAL BP" , "properties " : { "confidence" : 0 . 78 , "provenance" : "11m enrichment : signal quality" , "time" : " 16 : 03 : 40 UCT" } }] ,"update properties" : [{ "target" : "HYPOTENSION" , "key" : "active" , "value" : true } ,{ "target" : "HYPOTENSION" , "key" : "last seen utc" , "value" : " 16 : 03 : 54 UCT" }]}roomio.2.5 Step 4: validate and apply the patch, then repeat at the next cycle

[0112] After receiving A*, the system of this example runs a few simple checks before applying it:• the patch is valid JSON and uses only the allowed relation labels,• every edge references nodes that already exist or are created by create_nodes,• timestamp ordering makes sense for precedes,• SUSPECT edges are grounded in an operator input event (here, the recorded PEEP setpoint increase).Then the system applies Ak to Gk- .1. create the timestamp nodes,2. create the edges,3. update node properties,to obtain the next graph Gk.

[0113] It is important to emphasize that, as illustrated by this example, the invention allow the same procedure to be repeated at any time step. The same workflow may run at every cycle because the inputs may repeatedly (or like in this example, for the whole procedure) concern the same kinds of objects (cycle summary + previous graph excerpt + patient context excerpt), and the output may repeatedly (or like in this example, for the whole procedure) concern the same kind of object (graph patch). Also, the system of this example can re-run any cycle later (e.g., for debugging or audit purposes) by storing: (i) the cycle summary Ck, (ii) the graph excerpts used, (iii) the exact prompts, and (iv) the resulting patch AR. In this example, applying a patch to a graph is deterministic, so re-applying the same patch yields the same Gk. In addition, the LLM call can be made stable by keeping the model / version fixed and using fixed decoding settings (e.g., temperature = 0) plus the validation rules above.

[0114] (End of Example 2)

Claims

24Claims1. A device (1 ) comprising:an input interface (2);a control module (3) connected to the input interface;an output interface (4) connected to said control module;wherein the control module is configured, upon initiation of a respective next measurement cycle, to:receive (13), via the input interface (2), respective next measurement data (5", 5"') measured with respect to a patient (16);process the respective next measurement data (5", 5"'), based at least on a respective previous graph (6', 6") associated with a respective previous measurement cycle, for obtaining a respective next graph (6", 6"') associated with the respective next measurement cycle;output (15), via the output interface, the respective next graph (6", 6"');wherein the previous graph (6', 6") and the next graph (6", 6"') each relate to knowledge graphs (6, 9) and each comprise:a plurality of entities relevant to a clinical scenario to which the respective measurement cycles relate, anda plurality of relations between the entities; andwherein the previous (6', 6") and the next graph (6", 6"') differ in at least one entity or relation,wherein preferably the previous measurement cycle and the next measurement cycle belong to a temporal sequence of at least five respective cycles, more preferably at least ten cycles, and wherein preferably a maximum time between respective cycles is less than one minute, more preferably less than 30 seconds, even more preferably less than 10 seconds.

2. The device (1) of claim 1, wherein the output interface (4) comprises electronic connection means for controlling a patient-related device (7), and wherein the control module (3) is further configured to:send (14), based on the difference between the graph associated with the previous measurement cycle and the graph associated with the new measurement cycle, an instruction to the patient-related device (7) for altering an operational parameter of the patient-related device (7).

3. The device (1) of claim 2, wherein the patient-related device relates to a mechanical ventilator (7), wherein the operational parameter relates at least to an intensity of ventilation flow, and wherein the respective next measurement data (5", 5"') relate to at least one of, preferably at least two of: arterial blood pressure, central venous pressure, a pressure value characteristic of a mechanical ventilation cycle.

4. The device (1) of claim 2 or 3, wherein the patient-related device (7) relates to a peritoneal insufflator, wherein the operational parameter relates at least to an intensity of insufflation, and wherein the respective next measurement data (5", 5"') relate to at least one of, preferably at least two of: arterial blood pressure, central venous pressure, a pressure value characteristic of a mechanical ventilation cycle.

5. The device (1) of claims 1-4, wherein the output interface (4) comprises electronic connection means for connecting to a user module comprising a screen (8) for display to an operator (17), and wherein the control module (3) is further configured to:display (15), via said screen (8), at least one graph (6', 6", 6"'), said at least one graph relating to at least one of the previous graph (6', 6") and the next graph (6", 6"').

6. The device of claim 5, wherein the device comprises a postprocessing module relating to an LLM, with the at least one graph (6', 6", 6"') as input prompt, whereby the LLM output is displayed to the operator (17), either along with the at least one graph (6', 6", 6"'), or instead of the at least one graph.

7. The device (1) of claim 6, wherein the user module further comprises user input means for receiving input from the operator (17), and wherein the at least one graph (6', 6", 6"') being displayed comprises at least one entity and / or at least one relation that is editable by the operator (17) via said user input means.

8. The device (1) of claim 7, wherein the user input means relates to the screen being a touchscreen.

9. The device (1) of claims 6-8, wherein the control module (3) is further configured to: determine, based at least on the next graph (6", 6"'), whether an alert for the operator (17) should be generated;if yes, generate said alert and display the alert via said screen (8).

10. The device (1) of claim 9, wherein the alert relates to procedural information and comprises instructions to be carried out by the operator (17).

11. The device (1) of claims 9-10, wherein the user module further comprises user input means for receiving input from the operator (17), wherein the alert relates to a prompt for receiving a response from the operator (17) via said user input means, and wherein the control module (3) is further configured to:display, on said screen and along with the prompt and the at least one displayed graph (6', 6", 6"'), an annotation of said displayed graph for indicating a predicted impact of the response.

12. The device (1) of claims 1-11, wherein the processing of the next measurement data (5", 5"') for obtaining a respective next graph (6", 6"') is further based on a pre-determined patient-related graph instantiated based on pre-determined patient data (19) specific to the patient (16).

13. A system (100) comprising:a device (1), preferably the device (1) of any of claims 1-12, the device comprising an input interface (2);a control module (3) connected to the input interface;an output interface (4) connected to said control module;a data source module (10), preferably a sensor module, for connection to the input interface (2);a user module comprising at least a screen (8) for display to an operator (17) and for connection to the output interface (4);wherein the control module (3) is configured to:receive (13), from the data source module (10), respective next measurement data (5", 5"'); process the respective next measurement data (5", 5"'), based at least on a respective previous graph (6', 6") associated with a respective previous measurement cycle, for obtaining a respective next graph (6", 6"') associated with the respective next measurement cycle;send (15) data of the respective next graph (6", 6"') to the user module;wherein the data source module (10) is configured to:measure next measurement data (5", 5"') with respect to a patient (16), and send the next measurement data to the input interface (2) of the device (1 ); wherein the user module is configured to:receive (15), from the output interface (4) of the device (1), data of at least one graph (6', 6", 6"');display, on said screen (8), said at least one graph (6', 6", 6"');wherein the previous graph (6', 6") and the next graph (6", 6"') each relate to knowledge graphs (6, 9) and each comprise:a plurality of entities relevant to a clinical scenario to which the respective measurement cycles relate, anda plurality of relations between the entities; andwherein the previous (6', 6") and the next graph (6", 6"') differ in at least one entity or relation.

14. The system (100) of claim 13, further comprising:a patient-related device (7) connected to the output interface (4);wherein the control module (3) is further configured to:send (14), based on the difference between the graph associated with the previous measurement cycle and the graph associated with the new measurement cycle, an instruction to the patient-related device (7) for altering an operational parameter of the patient-related device (7);27wherein the patient-related device (7) is configured to:receive, from the output interface (4) of the device, the instruction for altering the operational parameter;executing, based on said instruction, an altering-related action;wherein the altering-related action relates to altering said operational parameter and / or generating a patient-related device alert via an alerting means comprised in the patient-related device, e.g., an acoustic alert.

15. Method for supporting a clinical event according to a clinical scenario, comprising the steps of:receiving (13), via an input interface (2) comprised in a device (1), respective next measurement data (5", 5"') measured with respect to a patient (16);processing, by a control module (3) comprised in the device (1) the respective next measurement data (5", 5"') based at least on a respective previous graph (6', 6") associated with a respective previous measurement cycle, for obtaining a respective next graph (6", 6"') associated with the respective next measurement cycle;outputting (15), via an output interface (4) comprised in the device, the respective next graph (6", 6"');wherein the previous graph (6', 6") and the next graph (6", 6"') each relate to knowledge graphs (6, 9) and each comprise:a plurality of entities relevant to the clinical scenario to which the respective measurement cycles relate, anda plurality of relations between the entities; andwherein the previous (6', 6") and the next graph (6", 6"') differ in at least one entity or relation; wherein the method further comprises:sending (14), based on the difference between the graph associated with the previous measurement cycle and the graph associated with the new measurement cycle, an instruction to the patient-related device (7) for altering an operational parameter of the patient-related device (7)and / ordisplaying (15), via a screen (8) comprised in a user module connected to the output interface (4) of the device (1), at least one graph (6', 6", 6"'), said at least one graph relating to at least one of the previous graph (6', 6") and the next graph (6", 6"').

Images