Systems and methods for real-time and retrospective anesthetic stage detection

Abstract

Systems for perioperative care are provided. In one example, a system for tracking a stage of anesthesia delivery in a case of a patient includes one or more processors and a memory storing instructions executable by the one or more processors to: output (802) a GUI including a first visual representation of a default or previously determined stage of anesthesia delivery for the patient; receive (602) a plurality of monitoring parameters for the patient within an observation window; identify (606) whether an event signaling a change to a new stage of anesthesia delivery for the patient is detected by applying a set of rules to the plurality of monitoring parameters; update (617) the GUI to display a second visual representation of the new stage based on the event being detected and determined to be a true event; and maintain (810) the first visual representation on the GUI based on the event not being detected.

Description

Technical Field

[0001] The implementation schemes of the subject matter disclosed herein relate to patient monitoring during perioperative care, and more specifically to automated detection of patients during anesthesia. Background Technology

[0002] Certain medical procedures, such as surgery, may require various subroutines to prepare the patient for surgery, keep the patient under certain conditions during surgery (e.g., under anesthesia), and assist the patient's recovery after surgery. These subroutines performed to support the main procedure are known as perioperative care. For example, in a medical facility with multiple operating rooms, monitoring perioperative care allows care providers and administrators to effectively manage the facility's resources, such as scheduling and preparing patients for surgery. Summary of the Invention

[0003] In one embodiment, a system for tracking anesthesia delivery stages in a patient's case includes one or more processors and a memory storing instructions executable by the one or more processors to: output a graphical user interface (GUI) for display on a display device, the GUI including a first visual representation of a default or previously determined stage of the patient's anesthesia delivery; receive multiple monitoring parameters of the patient within an observation window, at least a portion of which are obtained from an anesthesia delivery machine; identify whether an event signaling a change to a new stage of the patient's anesthesia delivery is detected by applying a set of rules to the multiple monitoring parameters, wherein the event is one of case start, maintenance start, awakening start, and case end; update the GUI to display a second visual representation of the new stage based on the detection and determination of the event as a real event; and maintain the first visual representation on the GUI based on the absence of the event detection.

[0004] It should be understood that the above brief description is provided to introduce some concepts further described in the detailed embodiments in a simplified form. This is not intended to identify key or essential features of the claimed subject matter, the scope of which is uniquely defined by the claims following the detailed embodiments. Furthermore, the claimed subject matter is not limited to specific implementations that address any shortcomings pointed out above or in any part of this disclosure. Attached Figure Description

[0005] This disclosure will be better understood by referring to the following description of non-limiting embodiments, in which:

[0006] Figure 1 and Figure 2An example system for perioperative care and supervision, configured to automatically detect the anesthesia phase, is illustrated schematically.

[0007] Figure 3 An example anesthesia delivery machine is shown.

[0008] Figure 4 An example patient monitoring parameter is illustrated schematically, which can be evaluated to detect events that signal changes in the anesthesia phase.

[0009] Figure 5 The process for allocating anesthesia stages based on detected events is illustrated schematically.

[0010] Figure 6 This is a flowchart illustrating an example method for automatically detecting events that signal changes in the anesthesia phase.

[0011] Figure 7 This is a flowchart illustrating an example method for applying a rule set to detect events that signal changes in the anesthesia phase.

[0012] Figures 8A to 8C It is shown that it is used based on Figure 7 The flowchart illustrates an example method for updating a graphical user interface in real time based on one or more events detected by the method.

[0013] Figure 9 It is shown that it is used based on Figure 7 The flowchart illustrates an example method for retrospectively updating the graphical user interface based on one or more events detected by the method.

[0014] Figures 10 to 13 An example graphical user interface depicting the anesthesia stages of multiple patients is shown.

[0015] Figure 14 It is shown that it is used based on Figures 8A to 8C The flowchart illustrates an example method for updating a second graphical user interface in real time based on the current anesthesia stage detected by the method. Detailed Implementation

[0016] The systems and methods disclosed herein are implemented to facilitate perioperative care for multiple patients. To facilitate the perioperative care and supervision described herein, the systems and methods disclosed herein collect and process medical device data. Specifically, medical device data can be processed to identify the current stage of anesthesia delivery for one or more monitored patients. The anesthesia delivery process can be categorized into multiple stages based on key events / time points. Specifically, the anesthesia delivery process can be categorized based on the start of the process (referred to as case start (CS)), the end of induction (end of induction (IE)) (which is also the same as the start of maintenance (end of maintenance (MS))), the start of awakening (end of awakening (SE)) (which is also the same as the end of maintenance (end of maintenance (ME))), and the end of the process (referred to as case end (CE)). Generally, induction refers to the transition from patient awakening to being under anesthesia, maintenance refers to keeping the patient under anesthesia, and awakening refers to the point where anesthesia is no longer needed and the medication administered during the maintenance phase can be turned off.

[0017] The current stage of anesthesia delivery can be displayed to one or more users outside the operating room (e.g., supervising anesthesiologist, administrator) via a visual dashboard (e.g., a graphical user interface). In some examples, the visual dashboard can be displayed via a supervisory application, which in some examples also facilitates the presentation of medical device data in real-time or near real-time via one or more graphical user interfaces that can be displayed on the user's device (e.g., a mobile device, tablet, wearable device). The supervisory application can facilitate the display to the user of medical device data (including physiological data and medical device settings / parameter data) for multiple patients and multiple different patient monitoring parameters. The displayed medical device data for multiple patients can be simultaneously displayed in a multi-patient graphical user interface (GUI), which allows the user to easily monitor the patient status of each patient, even if the user is located far from the patient.

[0018] The monitoring application can also monitor the patient's status via medical device data and output various notifications, such as alarms, when the patient's anesthesia stage changes or when the patient has been in a certain anesthesia stage for more than a threshold duration.

[0019] The visual dashboards and functionalities of the supervisory application described above allow a single supervising care provider and / or administrator to monitor multiple patients simultaneously during a given medical procedure, such as surgery. While each patient may be cared for by multiple care providers (such as one or more surgeons, nurses, medical technicians, etc.) during a medical procedure, some supervising care providers (such as anesthesiologists) may care for multiple patients simultaneously and supervise multiple subordinate care providers (such as nurse anesthesiologists). Due to the increasing number of subordinate care providers relative to the number of supervising care providers and the increasing complexity of medical procedures, the need for supervising care providers capable of remotely monitoring patients and supervising subordinate care providers has increased. For example, a supervising anesthesiologist may be scheduled to initiate and monitor the induction phase of anesthesia for the first patient. However, the supervising anesthesiologist may also be caring for six other patients in the maintenance and recovery phases of anesthesia. The visual dashboard can inform the supervising anesthesiologist of the relatively long recovery phase of a particular patient, indicating a delay in recovery due to anesthetic reasons (deep anesthesia), which allows for additional monitoring or action from the anesthesiologist. This improves patient care. In another example, a visual dashboard can indicate that the patient's depth of anesthesia is insufficient during the retention phase, which can signal to the anesthesiologist that the patient needs additional monitoring.

[0020] Furthermore, automated, real-time monitoring of the current anesthesia stage for each patient in a multi-patient pool can benefit hospital / medical facility resource utilization. For example, showing a summary of which operating rooms (ORs) have patients at which anesthesia stages at a given time point can help hospital administration make informed decisions, such as estimating wait times for each OR, determining staffing requirements, and preparing for the next surgical procedure. Similarly, a relatively long time lag between case initiation and induction initiation can indicate delays in case progression due to unavailability of equipment and nurses / anesthesiologists, which can be communicated to hospital administration. Additionally, a long lag between the end of awakening and case closure may indicate logistical problems (patients waiting in bed, staff shortages). In such cases, notifying patients of their readiness for transfer using anesthesia machine parameters or monitor parameters allows the next patient in the queue more preparation time to enter the OR.

[0021] As used herein, medical device data includes patient physiological data (also known as patient monitoring data) acquired from the medical device and machine data collected from within the medical device itself. Machine data may include alarms, device status, settings, messages, and measured operational data. Machine data may further include settings and values ​​representing specific actions taken with the medical device, such as in response to automated controls or due to clinician input. For example, in an anesthesia delivery machine, this may include changes in oxygen and / or anesthetic concentrations. Machine data may further include clinical and / or technical alarms initiated by the medical device or device diagnostic information. Other examples of machine data include proactive or predictive service alerts from the medical device, maintenance check information and / or processor clock cycle signals or power signals, or other operational signals from various components of the medical device indicating that the medical device is on, in use, in operation, in standby, or off.

[0022] Medical device data can be collected from time-series formats provided by the medical device itself. As used herein, the time-series format of medical device data can include waveforms, binary data, digital data, and / or text data in time-series format. Implementations of the systems and methods disclosed herein receive medical device data from the medical device at a frequency similar to the frequency at which the medical device generates data. In these implementations, this increasing rate of data reception, along with the monitoring and analysis of the medical device machine data, enables the improved monitoring systems and methods disclosed herein. As further described in detail herein, implementations of the systems and methods support high-speed data ingestion, enrichment, normalization, and data curation of medical device data. Medical device data can undergo real-time analysis and be further enriched with event detection and tagging.

[0023] Figure 1 and Figure 2 An exemplary implementation of a system 10 for perioperative care and monitoring is depicted, which can be configured to automatically detect and report the current anesthesia stage of multiple patients. See first. Figure 1 System 10 includes a Medical Device Data (MDD) processing system 12. The MDD processing system 12 may be implemented in various hardware and / or software embodiments, and it should be noted that such embodiments are not considered limiting. For example, it is conceivable that any or all of the MDD processing systems 12 may be implemented solely in hardware, solely in software, solely in firmware, or in any combination of hardware, software, and / or firmware. While exemplary methods and systems are described below, the examples provided herein are not the only ways to implement such methods and systems.

[0024] In embodiments covering the entire software and / or firmware implementation, in any embodiment, at least one element is thereby explicitly defined as including tangible and non-transitory computer-readable media. As used herein, the term tangible computer-readable media is explicitly defined as including any type of computer-readable storage device and excluding propagated signals. Additionally or alternatively, exemplary methods and systems may be implemented using coded instructions (e.g., computer-readable instructions) stored on a non-transitory computer-readable medium such as flash memory, read-only memory (ROM), random access memory (RAM), cache, or any other storage medium in which information is stored for any duration (e.g., a prolonged period of time, a permanent, brief instance, for temporary buffering, and / or for caching information). As used herein, the term non-transitory computer-readable media is explicitly defined as including any type of computer-readable medium and excluding propagated signals.

[0025] In an exemplary and non-limiting embodiment of the medical device data processing system 12, system 12 is implemented by one or more networked processors or computing devices. Processing system 12 may be implemented in a cloud computing platform and / or infrastructure. Memory and processors as referred to herein may be standalone or integrally constructed as part of various programmable devices, including, for example, computers or servers. Computer memory, as referred to herein, may include volatile and non-volatile or removable and non-removable media for storing information in electronic format (such as computer-readable program instructions or computer-readable program instructions, data, etc., which may be standalone or as part of a computing device). Examples of computer memory may include, but are not limited to, RAM, ROM, EEPROM, flash memory, CD-ROM, DVD-ROM or other optical memory, magnetic tape cassette, magnetic tape, disk or other magnetic storage devices, or any other medium that can be used to store information in a desired electronic format and is accessible by at least a portion of one or more processors or computing devices.

[0026] MDD processing system 12 is communicatively connected to at least one hospital network 14. Such communication connection and the hospital network itself may include, but are not limited to, wide area networks (WANs); local area networks (LANs); the Internet; wired or wireless (e.g., optical, Bluetooth, radio frequency (RF)) networks; cloud-based computing infrastructure such as computers, routers, servers, gateways, etc.; or any combination thereof that is associated with them and allows the system or parts thereof to communicate with one or more computing devices.

[0027] Hospital network 14 may be exemplarily a network associated with a part of a hospital (e.g., a surgical unit or department of the hospital), or more broadly, a network of medical devices located throughout the hospital. It will be further appreciated that while some embodiments and specific implementations of the systems and methods disclosed herein may attempt to operate at a single hospital or a single unit of a hospital, other embodiments may connect multiple hospital networks, including hospitals currently belonging to or operating with or otherwise affiliated with each other. In further embodiments, while individual hospitals or groups of hospitals may use MDD processing system 12, MDD processing system 12 may receive and process information from multiple hospital networks, including those unrelated to each other.

[0028] like Figure 1 As shown, hospital network 14 includes multiple medical devices 16. Medical devices 16 may include physiological monitoring devices 16a and patient treatment devices 16b. Physiological monitoring devices 16a may include, but are not limited to, patient monitors (e.g., heart rate monitors, blood pressure and / or oxygenation monitors, respiratory monitors), ECG monitors, EEG monitors, or EMG monitors. For the purposes of discussion, an anesthesia delivery machine will be used as an example of a medical device, and more specifically, as a patient treatment device 16b, although those skilled in the art will recognize that other devices, including but not limited to patient respiratory support devices or dialysis machines, may be other non-limiting examples of patient treatment devices. However, it will be appreciated that treatment devices may also include the ability to not only deliver treatment to patients but also measure patient physiological parameters. For example, embodiments of an anesthesia delivery machine may include a gas analysis module capable of operating to measure the concentration of gases exhaled by the patient. In some embodiments, imaging devices (including but not limited to X-ray devices, CT devices, MRI devices, and ultrasound devices) may be examples of the medical devices 16 contemplated within this disclosure. Other examples of medical devices may include video and / or audio recording devices.

[0029] In some examples, the limited-type MDD processing system 12 described herein can be implemented locally, for example, as an anesthesia delivery management system 18. In such an implementation, the anesthesia delivery management system 18 is operable to collect medical device data, in particular, from multiple anesthesia delivery machines 16b, in order to monitor anesthetic use between and across procedures performed by the anesthesia delivery machines, thereby attempting to visualize the consumption and use of anesthetics, and, in addition to the automated detection of anesthesia stages disclosed herein, to quantify, monitor, and evaluate trends of all anesthesia delivery machines in a hospital or surgical unit.

[0030] Medical device 16 may be communicatively connected to one or more edge devices, such as edge device 20. Edge device 20 may be, exemplarily, an edge processing device, a cloud processing device, or an Internet gateway. Edge device 20 may include an Internet of Things (IoT) gateway that facilitates a secure communication link between medical device 16 at hospital network 14 and servers, processors, and computer-readable media implementing MDD processing system 12. In some embodiments, edge device 20 may communicate directly with one or more medical devices in medical device 16, or may communicate with medical device 16 via an intermediate network (e.g., an anesthesia delivery management system 18 or another medical device data system or network).

[0031] Edge device 20 receives medical device data as time-series data of any of the medical device data available from the medical device. As described above, the data stream of medical device data (e.g., machine data, monitored patient physiological parameter data) can be obtained from the time-series format acquired by the medical device and may include, but is not limited to, time-series information of alarms, device status, device settings, messages, and measurement data. In embodiments, the medical device may be equipped with sensors that enhance the self-awareness of the medical device, such as sensors that monitor the function, inputs, and / or outputs of various components of the medical device itself. Many such sensors have been incorporated into medical devices, such as those for measuring compressor speed and / or cycle time, internal pressure, voltage, clock speed, or temperature, or other sensors as will be recognized by those skilled in the art or as disclosed in further detail herein.

[0032] Edge device 20 encrypts time-series data and transmits the encrypted data to the server, processor, and data storage of the MDD processing system 12 using wired and / or wireless communication technologies. Edge device 20 continuously transmits de-identified medical device data in time-series format to the high-speed data ingestion module 22 of the MDD processing system 12 via an encrypted communication channel. While the embodiments described herein refer to de-identified data, it should be recognized that other embodiments may use patient-identified data, and appropriate consideration should be given to processing patient data. The high-speed data ingestion module 22 acquires the medical device data stream in real time. Data ingestion can be performed automatically, and the received real-time data stream in the time series can be pre-processed for later processing by the MDD processing system 12. The high-speed data ingestion module 22 is capable of receiving concurrent data streams from multiple connected devices across multiple sites at a high ingestion rate (e.g., at or near the frequency at which the medical device can output data). In some embodiments, the high-speed data ingestion module 22 is capable of scaling up to continue ingesting increased bandwidth of medical device data without significantly reducing the ingestion rate.

[0033] High-speed data ingestion module 22 acquires time-series medical device data from medical devices in one or more hospital networks and formats it for further processing by data quality management module 24. In exemplary and non-limiting embodiments, high-speed data ingestion module 22 supports open standards such as ASTM F 2761 or Integrated Clinical Environment (ICE). Data quality management module 24 can normalize, enrich, and label data streams without negatively impacting data latency. In a healthcare environment, various healthcare information products and / or systems can be used to deliver healthcare services, collect medical data, conduct medical examinations, etc. However, many healthcare information systems use a variety of messaging standards (e.g., HL7 V2.x / v3, Clinical Document Architecture / Continuity of Care Documentation (CDA / CCD), American Society for Testing and Materials (ASTM), Digital Imaging and Communications in Medicine (DICOM), etc.) and various standards and / or protocols (e.g., Cross-Enterprise Document Sharing (XDS.A / B), Cross-Enterprise Document Media Exchange (XDM), Cross-Enterprise Reliable Document Exchange (XDR), Patient Identifier Cross-Reference / Patient Demographic Query (PIX / PDQ), Patient Administration (PAM), Query Existing Data (QED), National Prescription Drug Program Council (NCPDP), etc.), which makes system integration and / or communication more difficult. Therefore, normalization may include reformatting medical data into a consistent or compatible format for use within the MDD processing system 12. In one embodiment, medical device data may be normalized to ISO / IEEE 11073-10101 nomenclature and its extensions. In yet another embodiment, the data quality management module 24 may normalize incoming time-series data streams by converting measurement units. The data quality management module 24 can be further operated to identify and tag various types of medical device data, the location from which the medical device data is received, or time-series data streams originating from the same medical device. These tags can be used to identify and analyze groups of time-series data streams, as detailed herein.

[0034] In some implementations, the data quality management module 24 normalizes received incoming data by transforming and / or converting clinical data flowing from a source healthcare system or device into a canonical data model with relevant metadata. Processed medical device data is stored in a data lake 26, which is exemplarily implemented in a computer-readable storage device embodying the capacity to store bytes of data. The data lake 26 is a long-term computer repository that maintains a large amount of raw data in its native format until the data is needed. The native format may include time-series data from medical devices, which can be waveform or binary format, audio data, image data, and / or video data. In implementations, this can facilitate the ingestion of data that may not be processed in real time but can still be acquired in real time or near real time, rather than being stored in the data lake until further need. This can be facilitated by identifying specific data streams and restricting the processing of those streams (e.g., via the data quality management module 24) if it is known at this time that such data streams are not used for real-time analysis. In an exemplary implementation, the data quality management module 24 may not convert the data into a canonical data model, but may still attempt to tag, enrich, or index the data so that it can be retrieved from the data lake 26 in a standardized manner later.

[0035] In another embodiment, a portion of the data stored in data lake 26 may also be stored separately in a graph database, which may be a separate database residing on the same computer-readable storage device, or may be implemented on a computer-readable storage device separate from data lake 26. The graph database may receive data streams, wherein the system is known to analyze trends in the data streams. The graph database may store the data streams in a time-series format in a manner that facilitates the trend of data over time and appends the data to events identified in the data itself, events identified in one or more other data streams, or events received by the system from external sources. These events may include, but are not limited to, actions of medical devices or clinicians, clinical events, conditions, or complications occurring during medical procedures. Clinicians or technicians may later use the graph database to identify further relationships between trends and data streams with other analyses disclosed herein.

[0036] While the data is stored in data lake 26, enriched and normalized medical device data can be provided to stream processing engine 28. Stream processing engine 28 identifies cases and events in the time-series stream of medical device data. The identified clinical cases can be stored in operational case database 30. Clinical cases may exemplarily include surgical and intensive care unit (ICU) cases. Clinical cases can be identified by the medical devices used and the time series of medical data in the medical device data. For example, the time series of medical device data from an anesthesia delivery machine indicates that a clinical case has started or is in progress, showing the state changes when the machine is turned on, followed by changes in device settings and the delivery and / or consumption of anesthetics.

[0037] As described above, time-series medical device data streams originating from the same medical equipment or the same location within a hospital can be tagged or otherwise identified as related. These tags can be used to analyze related data streams simultaneously or in combination to identify clinical cases. For example, device status data stream analysis can be combined with user input data streams, device setting data streams, and operational data streams to identify when the device was used and how it was used in a clinical case. This information helps distinguish between technician maintenance or inspection of medical equipment and use of the device in relation to a clinical case.

[0038] Analysis of data streams from multiple medical devices, particularly those identified as related or co-located, can also be used to identify clinical cases. For example, coordination or similar actions in the data streams of anesthesia delivery devices and related patient monitoring and / or respiratory support and / or imaging devices can be further used to identify that these devices are being used together in a clinical case. In another embodiment, streaming time-series medical device data can be combined with information about a predetermined clinical case to help further identify the timing and manner of use of the medical devices during the clinical case.

[0039] In these implementations, knowledge of the intended use of a medical device (e.g., anesthesia delivery machine) can be used to further identify clinical cases within the medical device data stream. For example, inputting or receiving knowledge about the type and timing of a predetermined procedure can help identify the start and end of a clinical case (particularly the medical device machine data stream). In one implementation, a known usage schedule for the medical device can help identify clinical cases from maintenance or calibration actions that similarly require powering on and at least partially operating the medical device.

[0040] Medical device data associated with the actions of an anesthesia delivery machine and / or other medical devices during an identified clinical case may be stored in the operational case database 30. In one example, the identification of a clinical case is stored together with other time-series streams of medical device data from the anesthesia delivery machine and time-series streams of medical device data from any physiological monitors and / or other medical devices associated with the use of the anesthesia delivery machine. In another exemplary embodiment, as described in further detail, a summary of clinical cases with links or identifiers to associated time-series medical device data stored in data lake 26 may be created and stored in the operational case database 30.

[0041] In one implementation, clinical cases may be categorized or profiled before being stored in the operational case database 30. This categorization or profile analysis is a technique used for data curation. The profile analysis of clinical cases may be based in part on information from the clinical case summary. Profile analysis can be used to group clinical cases into multiple groups, such as normal cases, marginal cases, and abnormal cases. These determinations can be made based on a comparison between the time-series data in the clinical cases and the normal distribution of the same type of time-series machine data in other similar clinical cases. Marginal cases may be identified as boundary lines or ambiguous cases, not explicitly defined as normal or abnormal values. In one implementation, the distribution of an incidence rate for a specific measurement or incidence rate can be used to establish normal cases, marginal cases, and abnormal cases. In one implementation, normal cases are within the standard deviation of the median in the normal distribution, while marginal cases are between one and two standard deviations, and abnormal cases deviate from the median by more than two standard deviations. The categorized cases, as explained in further detail herein, may be further studied, for example, to create or improve event detection algorithms, clinical decision support rules, alerting algorithms, and prediction algorithms.

[0042] The stream processing engine 28 also identifies events in the time-series stream of medical device data, for example in a manner described in further detail herein, and presents them as reports and visual analysis tools 32, which are exemplary on a graphical display communicatively connected to the medical device data processing system 12.

[0043] Once clinical cases are stored in the operational case database 30, clinicians or technicians can manually review them using the curation and case review tool 34. The curation and case review tool 34 can be presented in a graphical user interface on a graphical display and further provides input via the graphical user interface for users or technicians to curate or otherwise evaluate clinical cases. This can be used for survey, educational, and data curation purposes.

[0044] Reporting and visual analytics tool 32 can present detected events across multiple communication channels. For example, detected events can be visually presented via a graphical user interface and a graphical display. Detected events or notifications of detected events can also be reported by transmitting event / event notifications to wearable or mobile devices and by visually presenting medical device data and identified events in reports and / or dashboards presented in a graphical user interface on a graphical display, as will be explained in more detail below.

[0045] The results of streaming analysis and event detection of time-series medical device data can be provided to an application programming interface (API) 38 for use by application developers to provide monitoring, reporting, and / or control applications based on the analytical stream of medical device data. Such applications can operate via a computer operating system, a web browser, or on a mobile or wearable computing device. Non-limiting examples of applications that can utilize the analysis of time-series medical device data include, but are not limited to, an anesthetic cost dashboard 40, an inspection dashboard 42, a monitoring application 44, an alarm management application 46, an asset management application 48, and a benchmarking application 50.

[0046] The Anesthetic Cost Dashboard 40 can present medical device data on anesthetic use across clinical cases and between anesthesia delivery machines within or relative to the hospital network. By presenting this information comparatively, it is possible to understand and take action on changes in anesthetic use and behavior to promote the effective use of anesthetics.

[0047] The inspection dashboard 42 helps monitor the inspection and maintenance of monitored medical devices. Medical device data, such as device status and settings, as well as messages and information in machine data, provide insights into the inspection process used to maintain medical devices within the hospital network. The inspection dashboard can identify maintenance and / or testing events in the machine data stream and log these identified testing events according to test schedules, requirements (e.g., daily), or other criteria.

[0048] The monitoring application 44 can be used by attending and / or supervising anesthesiologists to more effectively manage remote personnel, nurses, anesthesiologists, and / or other care providers working simultaneously in multiple locations or operating rooms. Additionally or alternatively, the monitoring application 44 can be used by ward or site administrators to more effectively manage personnel, dispatch, equipment, etc. The alarm management application 46 can report and present data on alarm notifications and silent medical devices to better understand and adjust alarms, improve the signal-to-noise ratio in alarm events, and reduce alarm fatigue in clinicians. Additional information about the monitoring application 44 is provided below.

[0049] Asset management application 48 may present information on the use, status, maintenance, and / or inspection of medical devices (e.g., anesthesia delivery machines) or consumer products used by medical devices, including components that may be frequently replaced, refilled, or refurbished during normal operation of the medical device (e.g., filters, absorbers). Benchmarking application 50 may provide further operational and quality performance across providers and / or organizations or in a comparative manner (e.g., between hospital networks and averages or between specific locations).

[0050] The monitoring application 44 allows users (e.g., clinicians such as anesthesiologists, nurses, and other care providers, as well as administrators) to view the anesthesia delivery stages, ventilators, anesthesia, and vital parameters of multiple patients in different locations (e.g., different operating rooms) on various workstations, smartphones, tablets, or other computing devices associated with the user. The monitoring application 44 may include a backend hosted as a Docker / microservice on edge device 20 and / or MDD processing system 12 and can be visualized on the user's device (such as...) using a suitable visualization platform. Figure 2 Presented on the care provider device 134 shown.

[0051] Figure 2 An example device of system 10, which can execute supervisory applications via it, is schematically shown, including a computing system 120 that communicates with multiple care provider devices 130 via a hospital network 14 and / or via a separate network 140. The computing system 120 may be... Figure 1 Edge device 20 and / or MDD processing system 12.

[0052] As mentioned above, the computing system 120 receives medical device data from the medical device 16. The medical device data received by the computing system 120 can be used by… Figure 1 The data is ingested by the ingestion module 22, similar to that of the data ingestion module 102, and stored in the data storage 104. The data storage 104 may be a temporary data storage device, where the received data is temporarily stored rather than permanently stored, or the data storage 104 may include long-term storage. Furthermore, the received medical device data can be distributed to various microservices on the computing system 120 to implement aspects of the monitoring application 44, including the stream processing module 106, the rules engine 108, the event notification service 112, the streaming server 114, and the cloud gateway 116.

[0053] As explained above, the supervisory application 44 can be used by the attending and / or supervising anesthesiologist to manage other care providers, such as nurse anesthesiologists and / or other subordinate care providers. Hospitals / medical facilities may rely on relatively high supervision rates (e.g., each supervising anesthesiologist supervises 4 to 10 subordinate care providers), which can increase the need for supervising anesthesiologists who are highly mobile across operating rooms while still supervising all subordinate care providers and monitoring patient status for all procedures that can be performed concurrently. The supervisory application 44 can facilitate this mobility and management by allowing the supervising anesthesiologist to monitor patient status from a remote location and communicate with subordinate care providers. As will be explained in more detail below, the supervisory application 44 can present the user (e.g., supervising anesthesiologist and / or administrator) with patient monitoring parameters (e.g., ECG, heart rate, blood oxygenation), procedure phases (e.g., case initiation, induction, maintenance, recovery, and case termination), alarms, anesthesia machine settings, anesthesia adequacy, and other relevant or selected information, such as those determined by received medical device data, via one or more graphical user interfaces displayed on the supervising anesthesiologist's mobile device or other device. The time-series stream of medical device data can be processed and analyzed as described above for detecting events related to the identified case (e.g., identifying the stage of anesthesia administration), and the output of such processing and analysis can be provided to the monitoring application 44. The monitoring application 44 can provide the user with determined values ​​of specified patient monitoring parameters, indications of detected events, and other notifications such as those determined by the time-series stream of medical device data via the graphical user interface described herein.

[0054] For example, via the monitoring application 44, users can switch between a graphical user interface (GUI) displaying limited information about multiple patients (multi-patient GUI), including the current procedural stage (anesthesia delivery stage), and a GUI displaying more detailed information about the selected patient (single-patient GUI). Users can also view patient monitoring data trends, detailed alarms / notifications, insights, and / or other information via the monitoring application 44. Furthermore, users can communicate with other care providers (such as subordinate care providers in the same room as the patient) via the monitoring application 44. Users can customize which patients / rooms to view, which patient monitoring parameters to view, which alarms to apply, and other parameters of the GUI used to present the above information, such as the layout of each GUI.

[0055] The graphical user interface generated by the monitoring application 44 can be displayed on one or more suitable display devices associated with the corresponding care provider equipment and / or healthcare facility management equipment. For example... Figure 2As shown, multiple care provider devices 130, from a first care provider device 134, a second care provider device 136, up to an nth care provider device 138, may be included as part of a hospital network 14 and may be communicatively coupled to a computing system 120 via the hospital network 14. Each care provider device may include a processor, memory, a communication module, a user input device, a display (e.g., a screen or monitor), and / or other subsystems, and may take the form of a desktop computing device, a laptop computing device, a tablet computer, a smartphone, or other device. Each care provider device may be adapted to send and receive encrypted data and display medical information (including medical images in suitable formats such as Digital Imaging and Communications in Medicine (DICOM) or other standards). Care provider devices may be located locally within a healthcare facility and substantially fixed in an appropriate location (such as at a nurses' station or in a patient's room) and / or located locally or remotely within a healthcare facility and configured to move with the care provider (such as a care provider's mobile device).

[0056] When the care provider views the graphical user interface generated by the monitoring application 44 via the display of the care provider's device, the care provider may enter input (e.g., via a user input device, which may include a keyboard, mouse, microphone, touchscreen, stylus, or other device), which may be processed by the care provider's device and sent to the computing system 120. In an example where the user input is a selection of a link in the graphical user interface or a user interface control button, the user input may trigger advancement to a desired view or state in the graphical user interface (e.g., triggering the display of desired patient medical information), triggering an update to the configuration of the graphical user interface, triggering alarms, insights, and / or other notification settings to be saved, triggering changes to a machine (such as an anesthesia delivery machine), or other actions.

[0057] The devices disclosed herein (such as aspects of care provider devices and / or computing system 120) may each include a communication module, memory, and processor to store and execute aspects of the supervisory application 44 and to send and receive communications, graphical user interfaces, medical data, and other information.

[0058] Each communication module facilitates the transmission of electronic data within and / or between one or more systems. Communication via the communication module can be implemented using one or more protocols. In some examples, communication via the communication module occurs according to one or more standards (e.g., Digital Imaging and Communication in Medicine (DICOM), Health Class 7 (HL7), ANSI X12N, etc.). The communication module can be a wired interface (e.g., data bus, Universal Serial Bus (USB) connection, etc.) and / or a wireless interface (e.g., radio frequency, infrared, near field communication (NFC), etc.). For example, the communication module can use any past, present, or future communication protocol (e.g., BLUETOOTH) via a wired local area network (LAN), wireless LAN, wide area network (WAN), etc. ® It communicates via USB 2.0, USB 3.0, etc.

[0059] Each memory includes one or more data storage structures, such as optical memory devices, magnetic memory devices, or solid-state memory devices, for storing programs and routines executed by a processor to perform the various functions disclosed herein. The memory can include any desired type of volatile and / or non-volatile memory, such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc. The processor can be, for example, any suitable processor, processing unit, or microprocessor. The processor can be a multiprocessor system and therefore can include one or more additional processors that are identical or similar to each other and communicatively coupled via an interconnect bus.

[0060] As used herein, the terms “sensor,” “system,” “unit,” or “module” can include hardware and / or software systems that operate to perform one or more functions. For example, a sensor, module, unit, or system can include a computer processor, controller, or other logic-based device that performs operations based on instructions stored on a tangible, non-transitory computer-readable storage medium, such as computer memory. Alternatively, a sensor, module, unit, or system can include a hardwired device that performs operations based on the device’s hardwired logic. The various modules or units shown in the accompanying drawings can represent hardware that operates based on software or hardwired instructions, software that instructs the hardware to perform operations, or a combination thereof.

[0061] The terms "system," "unit," "sensor," or "module" can include or represent hardware and associated instructions (e.g., software stored on a tangible, non-transitory computer-readable storage medium, such as a computer hard disk drive, ROM, RAM, etc.) that perform one or more of the operations described herein. Hardware can include electronic circuitry that includes and / or is connected to one or more logic-based devices, such as microprocessors, processors, controllers, etc. These devices can be readily available devices that are appropriately programmed or instructed to perform the operations described herein according to the instructions described above. Additionally or alternatively, one or more of these devices may be hardwired to logic circuitry to perform these operations.

[0062] One or more of the devices described herein can be implemented via the cloud or other computer networks. For example, computing device 120 in Figure 2 While shown as constituting a single entity, it should be understood that computing device 120 may be distributed across multiple devices, such as across multiple servers.

[0063] The monitoring application 44 can provide various data, notifications, and messages to multiple care provider devices 130. The data, notifications, and / or messages may include historical data, real-time medical device data (e.g., provided by streaming server 114), and notifications that can be pushed from event notification service 112 to multiple care provider devices 130.

[0064] As will be explained in more detail below, the monitoring application 44 can be visualized on a care provider device in the form of one or more graphical user interfaces (GUIs). These GUIs can be populated with real-time patient monitoring parameters, including the current stage of anesthesia delivery. In some examples, the GUIs can be further populated with other real-time patient monitoring parameters, such as recently determined values ​​or waveforms of heart rate, oxygen saturation, respiratory rate, etc., obtained from the medical device. When the computing system 120 receives medical device data, some or all of the medical device data can be processed by the stream processing module 106 and provided to the streaming server 114, which can then provide the real-time patient monitoring parameter values ​​and / or waveforms to the requesting care provider device. For example, when a user is viewing a patient-specific GUI of the monitoring application 44 on the care provider device 134, the GUI may include tiles or other display areas showing the recently determined values ​​of the selected patient monitoring parameters. The streaming server 114 can stream the recently determined values ​​of the selected patient monitoring parameters to the care provider device 134, which can then populate the received values ​​into the GUI. The stream processing module 106 may include a rule-based streaming analysis algorithm that applies window functions (slide, roll, jump, etc.) for waveform analysis and event detection to trigger alerts, surgical phase detection, stream analysis, classification algorithms, etc.

[0065] The determination of which patient monitoring parameter values ​​to send to which care provider device may be based at least in part on data requests sent by the care provider device to the computing system 120. The computing system 120 may include, for example, a Representational State Transfer (REST) ​​server that can receive data requests from care provider device 130 and respond to data requests by commanding a streaming server 114 to stream selected medical device data to the requesting care provider device. The streaming server 114 may maintain a stateful session (e.g., WebSocket) with each client (e.g., care provider device). The medical device data may be adjusted (transformed and filtered) before being streamed to the client devices.

[0066] The monitoring application 44 can generate and / or send various alarms and notifications based on medical device data received from various medical devices. Alarms may include threshold-based alarms, where a notification / alarm is generated and output to one or more care provider devices in response to a patient monitoring parameter value meeting a predetermined condition relative to a threshold (e.g., an alarm may be generated and sent to a care provider device in response to a particular patient's awakening phase lasting longer than a threshold duration). The computing system 120 can send notifications of alarms to the care provider devices of care providers caring for patients and / or to care provider devices of administrators via event notification service 112 and / or cloud gateway 116. For example, generated alarms may be sent directly to the appropriate care provider device via event notification service 112 or via cloud gateway 116, which can push alarms (and other notifications generated by the computing system 120, as explained in more detail below) to the appropriate care provider device, even when the monitoring application 44 is not running on the care provider device.

[0067] Rule engine 108 may include resources (e.g., memory and processor) of computing system 120 allocated for storing and applying a set of anesthesia event detection rules to medical device data to automatically determine, in real-time or near real-time, whether an event signaling a change in anesthesia stage has occurred for each of multiple patients. As mentioned above, the current stage of anesthesia delivery can be identified based on a set of events (CS, MS, ES, and CE). To correctly detect these events, a sliding window of time-series medical device data (e.g., anesthesia delivery machine data) is collected as input, and rule-based logic is deployed to detect each event in real-time. Maintaining previous states / events is not required to support a stateless architecture (with low input / output costs). Each input parameter can occur at a variable frequency, which can be further interpolated within modules. Patient cases can be parsed using a given window size (preferably small, e.g., 1 minute) with a sliding step size (e.g., 1 second). In other words, for each machine and / or monitoring parameter, a time-aligned data window (e.g., one minute of data) can be collected, and an event detection rule set can be applied to each data window to identify whether an event has been detected. This can be repeated with a new data window at a given frequency (e.g., per second). Additional details about the event detection rules and the machine and monitor parameters that can be evaluated to determine the current phase are provided below.

[0068] The computing system 120 can distribute medical device data streams to a rules engine 108, and the rules engine 108 can apply stored event detection rules to the incoming stream of medical device data to determine whether any stage notifications or outcomes (e.g., indicating a change to a new stage of anesthesia delivery) should be generated. If a stage notification is to be generated, it can be generated and used to update the GUI to indicate the new stage of anesthesia delivery, where the GUI can be viewed via the appropriate care provider's device. The following section discusses... Figures 5 to 9 This presents example methods for applying event detection rules to detect events and update the GUI, and... Figures 10 to 13 The example GUI shown can be displayed to illustrate the anesthesia stages of multiple patients.

[0069] The computing system 120 may be implemented in various hardware and / or software embodiments, and it should be noted that such embodiments are not considered limiting. For example, it is conceivable that any or all of the computing system 120 may be embodied solely in hardware, solely in software, solely in firmware, or in any combination of hardware, software, and / or firmware. The examples provided herein are not the only ways to implement such methods and systems.

[0070] In exemplary and non-limiting embodiments of computing system 120, computing system 120 is implemented by one or more processors or computing devices. Memory and processors as referred to herein may be separate or integrally constructed as part of various programmable devices, including, for example, computers or servers. Computer memory, as referred to herein, may include volatile and non-volatile or removable and non-removable media for storing information in electronic format (such as computer-readable program instructions or computer-readable program instructions, data, etc., which may be separate or as part of a computing device). Examples of computer memory may include, but are not limited to, RAM, ROM, EEPROM, flash memory, CD-ROM, DVD-ROM or other optical memory, magnetic tape cassette, magnetic tape, disk or other magnetic storage devices, or any other medium that can be used to store information in a desired electronic format and is accessible by at least a portion of one or more processors or computing devices.

[0071] Figure 3 An example of an anesthesia machine 399 is shown, which is Figure 1 Non-limiting examples of patient treatment device 16b. Anesthesia machine 399 includes a frame 364 supported by casters 360, wherein the movement of the casters can be controlled (e.g., stopped) by one or more locks 307. In some examples, the frame 364 may be formed of a plastic material (e.g., polypropylene). In other examples, the frame 364 may be formed of a different type of material (e.g., metal, such as steel).

[0072] The anesthesia machine 399 also includes a breathing gas module 301, a ventilator 312 (explained in more detail below), a vaporizer 314 (explained in more detail below), an anesthesia display device 315, and a patient monitoring display device 316.

[0073] The vaporizer 314 may be in the form of one or more removable cartridges, allowing the supply of anesthetic to be removed from the cartridges and enabling the supply of different types of anesthetic to the anesthesia machine by simply removing the cartridges and replacing them with different cartridges for different anesthetics. When more than one anesthetic is to be delivered, more than one cartridge may be included, each containing a different anesthetic. The vaporizer 314 includes a housing with a drug reservoir that holds the supply of anesthetic to be delivered to the patient. The drug reservoir may have an outlet formed in the rear wall of the housing, configured to receive an exhaust tube (not shown) that is part of the anesthesia machine, thereby forming an airtight seal for delivering anesthetic vapor to the patient.

[0074] Vaporizer 314 may include at least one absorbent core within the reservoir. A passage allows fresh gas from a gas source to be delivered to the absorbent core. Vaporized liquid and accompanying fresh gas from the absorbent core flow to the rear of the drug reservoir and out through an outlet in the housing. The lower part of the drug reservoir may contain liquid anesthetic, and the upper part of the reservoir may contain vaporized anesthetic and respiratory gas. During operation, a combination of temperature and pressure affects the liquid anesthetic and causes it to vaporize into the respiratory gas. The gas carrying the vaporized reagent is then discharged through the outlet.

[0075] The rear portion of the anesthesia machine 399 may include one or more tubing connections for coupling the anesthesia machine to a tubular gas source. Additionally, the rear portion of the anesthesia machine may include a cylindrical support via which one or more gas holding cylinders may be coupled to the anesthesia machine. Thus, gas can be supplied to the anesthesia machine via tubing and / or cylindrical connections, wherein the gas may include, but is not limited to, fresh gas, oxygen, and nitrous oxide. As described above, the gas entering the anesthesia machine may be mixed with vaporized anesthetic at the vaporizer and supplied to the patient via a ventilator. In some embodiments, the rear portion of the anesthesia machine may also include a serial port, a collection bottle connection, a cylindrical wrench storage, an anesthetic gas purging system, a main power inlet, a system circuit breaker, an equipotential stud, an outlet circuit breaker, and an isolated power socket.

[0076] The ventilator 312 may include an expiratory check valve 322, an inspiratory check valve 323, an absorbent canister 326, and a bellows assembly 333. When the patient's breathing circuit is coupled to the ventilator, respiratory gases (e.g., fresh gas mixed with vaporized anesthetic, oxygen, and / or nitrous oxide) exit the machine from the inspiratory port (which may be located in the same position as the inspiratory check valve 323) and proceed to the patient. Exhaled gases from the patient may re-enter the anesthesia machine via the expiratory port (which may be located in the same position as the expiratory check valve 322), wherein carbon dioxide may be removed from the exhaled gases via the absorbent canister 326.

[0077] During operation of the vaporizer 314, an operator (e.g., an anesthesiologist) can regulate the amount of vaporized anesthetic supplied to the patient by adjusting the gas flow rate from a gas source (e.g., a gas line) to the vaporizer. The operator can regulate the gas flow rate from the gas source to the vaporizer by adjusting one or more flow control devices. For example, the flow control device may include an analog and / or digital control dial and / or other user input devices configured to actuate one or more flow control valves of the anesthesia machine 399. In one example, a first flow control valve may be positioned between the gas source and the vaporizer 314 and may be actuated via the flow control device to a fully open position, a fully closed position, and multiple positions between the fully open and fully closed positions.

[0078] The anesthesia machine may additionally include one or more bypass valves configured to allow gas from a gas source to bypass vaporizer 314. The bypass valves allow a first portion of gas flowing from the gas source to flow directly from the gas source to the inhalation port, and a second portion of gas flowing from the gas source to flow through vaporizer 314 to mix with vaporized anesthetic before reaching the inhalation port. By adjusting the ratio of the amount of gas flowing to the port via the bypass valve to the amount of gas flowing to the port via vaporizer 314, the operator can control the concentration of vaporized anesthetic in the gas at the port.

[0079] Furthermore, the aforementioned regulation can be facilitated at least in part based on the output from the respiratory gas module 301. The respiratory gas module 301 can be configured to measure various parameters of the gas leaving the vaporizer and / or supplied to the patient. For example, the respiratory gas module 301 can measure the concentrations of carbon dioxide, nitrous oxide, and anesthetic supplied to the patient. Additionally, the respiratory gas module 301 can measure respiratory rate, minimum alveolar concentration, patient oxygen, and / or other parameters. The output from the respiratory gas module 301 can be displayed via a graphical user interface on a display device (e.g., devices 315 and / or 316) and / or used by the controller to provide closed-loop feedback control of the amount of anesthetic supplied to the patient.

[0080] The ventilator 312 may optionally be coupled to a breathing circuit (not shown) comprising multiple tubes (e.g., gas channels). The breathing circuit may be coupled between the patient's airway (e.g., via a breathing mask positioned to enclose the patient's mouth and / or nose) and an inspiratory port. A gas (e.g., oxygen, or a mixture of oxygen and a vaporized anesthetic from vaporizer 314) may flow from the port through the breathing circuit and into the patient's airway, where the gas is absorbed by the patient's lungs. By adjusting the concentration of the vaporized anesthetic in the gas as described above, the operator can adjust the amount of anesthesia administered to the patient.

[0081] With the breathing circuit coupled to the airway, anesthetic and / or fresh gas can flow into the airway via the inspiratory check valve 323 (e.g., be inhaled by the patient). For example, the inspiratory check valve 323 can automatically open in response to the patient's inhalation (e.g., without operator input or adjustment) and automatically close in response to the patient's exhalation. Similarly, the expiratory check valve 322 can automatically open in response to the patient's exhalation and automatically close in response to the patient's inhalation.

[0082] In some examples, the operator may optionally and / or additionally control one or more operating parameters of the anesthesia machine 399 via the electronic controller 362 of the anesthesia machine 399 (by...). Figure 3 (Shown schematically). Controller 362 includes a processor operatively connected to a memory. The memory may be a non-transitory computer-readable medium and may be configured to store computer-executable code (e.g., instructions) to be processed by the processor to execute one or more routines. The memory may also be configured to store data received by the processor. Controller 362 may be communicatively (e.g., wired or wirelessly) coupled to one or more external or remote computing devices, such as computing system 120, and may be configured to send and receive various information, such as measured patient monitoring parameters (e.g., output from respiratory gas module 301), electronic medical record information, program information, etc.

[0083] The controller receives signals from various sensors of the anesthesia machine 399 and uses various actuators of the anesthesia machine 399 to adjust the operation of the anesthesia machine 399 based on the received signals and instructions stored in the controller's memory. For example, gas flow to the inhalation port can be controlled via an input device (e.g., keyboard, touchscreen, etc.) coupled to the electronic controller of the anesthesia machine 399. The controller can be electrically coupled to display devices 315 and / or 316 to display the operating parameters of the anesthesia machine 399. The controller can receive signals (e.g., electrical signals) via the input device and can adjust the operating parameters of the anesthesia machine 399 in response to (e.g., acknowledgment) the received signals. For example, the operator can input the desired flow rate of gas (e.g., oxygen) from the gas source to the patient and / or vaporizer 314.

[0084] The corresponding valve positions of one or more valves in the anesthesia machine (e.g., the positions of one or more bypass valves, as described above) can be determined empirically and stored in a predetermined lookup table or function in the controller. For example, the controller may receive a desired gas flow rate via an input device and determine the opening amount of one or more bypass valves corresponding to the desired flow rate based on a lookup table, where the input is the desired flow rate and the output is the valve position. The controller may transmit an electrical signal to the valve actuator to adjust the valve position. In some examples, the controller may compare the desired gas flow rate with a gas flow rate measured by a flow sensor (e.g., an inspiratory flow sensor).

[0085] For illustrative purposes, Figure 3 The controller 362 is shown, and it should be understood that the controller 362 may be located inside the anesthesia machine 399 and therefore may not be visible from the outside of the anesthesia machine. The controller 362 may include multiple devices / modules that can be distributed within the anesthesia machine 399.

[0086] Figure 4 An example monitoring parameter 400 (e.g., medical device data) is schematically illustrated, which can be processed by the computing system 120 using the stage detection rules of the rule engine 108 to determine whether an event signaling a change to a new stage of anesthesia delivery has occurred. Parameter 400 may be as described above regarding... Figures 1 to 3Non-limiting examples of medical device data discussed. Parameter 400 may include a first set of parameters 402 obtained from an anesthesia delivery machine (e.g., anesthesia machine 399), which may include one or more of the following: measured fraction of inhaled oxygen (FiO2); measured end-expiratory oxygen (EtO2); measured end-expiratory CO2 (EtCO2); set FiO2 (Set_FiO2); set EtO2 (Set_EtO2); spontaneous respiratory rate (RR_spont); total respiratory rate (RR_total); set mechanical ventilation (Set_mech_vent); set inhaled anesthetic (Set_insp_agent); set exhaled anesthetic (Set_exp_agent); measured inhaled anesthetic (Insp_agent); measured exhaled anesthetic (Exp_agent); fresh gas flow (Fresh_gas_flow); O2 flow (Flow_O2); air flow (Flow_air); cardiac bypass mode (CBP); and anesthesia machine standby status. It should be understood that different anesthesia delivery machines may output different monitoring parameters. For example, some anesthesia delivery machines may not output settings for FiO2 (Set_FiO2), EtO2 (Set_EtO2), and / or setting of inhaled anesthetic (Set_insp_agent) or setting of exhaled anesthetic (Set_exp_agent). As a specific example, a high-quality or next-generation anesthesia delivery machine with a first configuration can output all the parameters listed above, while a first previous-generation anesthesia delivery machine with a second configuration can output all the parameters listed above except for setting of inhaled anesthetic (Set_insp_agent) and setting of exhaled anesthetic (Set_exp_agent). A second previous-generation anesthesia delivery machine with a third configuration can output all the parameters listed above except for setting of FiO2 (Set_FiO2), setting of EtO2 (Set_EtO2), setting of inhaled anesthetic (Set_insp_agent), and setting of exhaled anesthetic (Set_exp_agent).

[0087] Parameter 400 may optionally include a second set of parameters 404 obtained from one or more patient monitoring devices not included as part of the anesthesia machine, including one or more of oxygen saturation measurements (SpO2), heart rate (HR), and pulse rate (PR).

[0088] Rule engine 108 can apply a set of rules to determine whether an event among multiple events 410, which signals a change to a new stage of anesthesia delivery, is detected. Multiple events 410 may include case start (CS) signaling the initiation of induction, start of maintenance (MS), start of awakening (ES), and case end (CE). Specifically, each event may have one or more subsets of rules that can be applied to detect that event.

[0089] As shown in the figure, the rule engine 108 includes seven rule subsets. The first rule subset 412 can be applied to detect case initiation and manage updates to one or more GUIs in real time based on the detection of case initiation. When applied to monitoring parameters 400 within the observation window, the first rule subset 412 can indicate a CS in response to the end of the anesthesia machine standby state (e.g., the anesthesia machine standby switching from being in standby to standby being turned off / ended). The first rule subset 412 can further manage updates to one or more GUIs such that when a patient's CS event is detected, the patient can be indicated to be in induction, and induction can be plotted on the patient's timeline, along with other changes to the GUI to reflect the patient being in induction. The following section discusses... Figures 8A to 8C and Figures 10 to 13 Additional details are provided regarding updating one or more GUIs based on the detection that a patient is in induction. Additionally, the first subset of rules 412 may specify that any CS event detected between the initial CS and CE events causes the previous CS event to be discarded and a new case to be started.

[0090] The second rule subset 414 and the third rule subset 416 can be applied to detect hold-on starts and to manage updates of one or more GUIs in real time based on the detection of hold-on starts. The second rule subset 414, when applied to monitoring parameters 400 within the observation window, can indicate MS in response to the presence of a mechanical ventilation start event (e.g., setting mechanical ventilation from off / zero to an effective value) within the observation window and the existence of at least one effective value of EtCO2 (e.g., EtCO2 greater than 0.2) during the observation window. The third rule subset 416, when applied to monitoring parameters 400 within the observation window, can indicate MS in response to the detection of a specific total flow pattern within the observation window. A total flow pattern may include two consecutive total flow values ​​in the observation window equal to or greater than a total flow threshold (e.g., 5 L / min), at least three of the next five total flow values ​​less than the total flow threshold, and a third total flow value (e.g., a value immediately following the first two total flow values) less than the total flow threshold. Therefore, the total flow pattern may include seven total flow values ​​received during the observation window, wherein the first two values ​​are equal to or greater than a total flow threshold, the third value is less than the total flow threshold, and at least two of the fourth through seventh values ​​are less than the total flow threshold. In some examples, the total flow value may be a fresh gas flow rate value.

[0091] The second subset 414 can be applied in parallel with the third subset 416 to ensure robust detection at the start of maintenance. Once MS is detected via the second subset 414 or the third subset 416, the patient can be indicated to be in maintenance, and maintenance can be plotted on the patient's timeline, along with other changes to the GUI to reflect this maintenance status. The following section discusses... Figures 8A to 8C and Figures 10 to 13 Additional details are provided regarding updating one or more GUIs based on the detection that a patient is in hold.

[0092] The fourth rule subset 418 and the fifth rule subset 420 can each be applied to detect the onset of awakening and to manage updates of one or more GUIs in real time based on the detection of the onset of awakening. When applied to monitoring parameters 400 within the observation window, the fourth rule subset 418 can indicate an ES in response to the presence of a mechanical ventilation termination event (e.g., setting mechanical ventilation from on to off) within the observation window (and lasting for at least a specified duration, such as 55 seconds) and the anesthesia machine not operating in cardiac bypass mode. When applied to monitoring parameters 400 within the observation window, the fifth rule subset 420 can indicate an ES in response to two of the following three conditions being true / met within the observation window: an increase in the percentage of O2 (e.g., an increase in FiO2 or set_FiO2), an increase in total flow rate (e.g., fresh gas flow rate) exceeding a threshold (e.g., 4 L / min), and the termination of anesthetic delivery (e.g., which can be detected based on a set or measured inhaled anesthetic).

[0093] Subset 418 can be applied in parallel with subset 420 to ensure robust detection of awakening. Once an ES is detected via subset 418 or subset 420, the patient can be indicated to be awake, and awakening can be plotted on the patient's timeline, along with other changes to the GUI to reflect the patient's awakening status. The following section discusses... Figures 8A to 8C and Figures 10 to 13 Additional details are provided regarding updating one or more GUIs based on the detection that the patient is in a holding state. Furthermore, the fourth subset of rules 418 and the fifth subset 420 may specify that awakening is indicated only if the current stage is holding and any MS event detected during awakening (including any mechanical ventilation initiation event) results in a return to the previous stage (e.g., holding).

[0094] Each of the sixth rule subset 422 can be applied to detect case completion and manage updates to one or more GUIs in real time based on the detection of case completion. When applied to monitoring parameters 400 within the observation window, the sixth rule subset 422 can indicate CE in response to the start of an anesthesia machine standby state (e.g., the anesthesia machine switching from active mode to standby mode). The sixth rule subset 422 can further manage updates to one or more GUIs such that when a patient's CE event is detected, the patient's case can be indicated as complete, and the patient's timeline and other changes to the GUI can be made to reflect the case completion. The following section discusses... Figures 8A to 8C and Figures 10 to 13 Additional details are provided regarding updating one or more GUIs based on the detected CE of a patient.

[0095] Therefore, subsets 1 through 6 of the rules can be applied to each observation window for each patient / OR / anesthesia machine to track the current anesthesia stage for each patient in real time. One or more GUIs can be updated in real time based on event detection (e.g., while each case is in progress and in response to each event detection without intentional delay).

[0096] Retrospectively (e.g., after an active case is completed), a subset of rule 424 is applied to manage updates to the summary view of cases on one or more GUIs based on the detection of each event and the timing of each detection. Subset of rule 424 (also referred to as the summary rule) specifies which CS, MS, ES, and / or CE events (in cases where multiple CS, MS, ES, and / or CE events are detected for a given case / patient) should be used to mark the start, end, and transitions between phases for each completed case. Furthermore, subset of rule 424 specifies when MS and / or ES should be added to the summary in cases where no MS and / or ES were detected at all, and in other marginal / edge scenarios. The following section discusses… Figure 9Additional details are provided regarding updating one or more summary views in the GUI based on patient-based summary rules.

[0097] Rules stored within rule engine 108 that are applicable to detecting the events described herein may also consider certain use cases that would otherwise trigger false event detection or miss event detection. For example, some clinicians may turn a mechanical ventilator on and off at the very beginning of a case to confirm that the ventilator is functioning correctly. Rules applied to detect sustaining may include the mechanical ventilator being activated, while rules applied to detect awakening may include the mechanical ventilator being deactivated. Thus, a mechanical ventilator that is turned on and then off at the beginning of a case may send a mixed signal that could cause induction and sustaining to be truncated and jump to awakening almost immediately. Rules stored within rule engine 108 can address this by restarting a sustaining case when a second mechanical ventilation is detected and / or by not allowing the case to transition to awakening due to the short sustaining phase, thus avoiding false event detection.

[0098] Therefore, the method for stage detection disclosed herein uses anesthesia machine parameters to detect events that signal changes in anesthesia stage, as well as CS and CE events. In contrast, existing solutions only assess brain activity-related states or depend on explicit clinician input. Thus, the method disclosed herein does not require additional patient equipment (e.g., EEG equipment), and is therefore potentially cheaper, more patient-comfortable, and / or more accurate and faster than existing solutions, allowing detection of all events, including case start and case end. Furthermore, the method for stage detection disclosed herein relies on a relatively small number of anesthesia machine parameters that can be used in any anesthesia machine configuration and do not require parameters from a separate patient monitor. For example, detection of each stage can be achieved based on only seven parameters (e.g., FiO2, EtCO2, fresh gas flow rate, measured inhaled anesthetic, CBP mode, set mechanical ventilation, and standby settings), which simplifies processing and reduces the amount of data that needs to be passed to the rule engine 108 compared to other methods for detecting anesthesia stages. Furthermore, the proposed method is a real-time and stateless multi-parameter approach applicable to all types of anesthesia machines, special cases such as cardiac bypass, total intravenous aspiration (TIVA) cases, and with or without monitor data availability. By being stateless, the proposed method does not rely on previously determined anesthesia stages, but rather identifies whether an event is detected at each observation window (e.g., a sliding window of received parameters), without knowing the current or previous anesthesia stage or previously identified events. In doing so, the proposed method requires less memory and is less susceptible to excessive impact from previous erroneous event detections, thus improving processing efficiency and system performance. It should be understood that event determination based on the current observation window can be stateless, but processing of event determination for the purpose of updating one or more GUIs may depend on knowing the current and / or previous anesthesia stages (e.g., in cases where awakening is plotted on the timeline only if the current stage is maintained and ES has been detected).

[0099] Figure 5 The schematic depiction illustrates a processing flow 500 for transitioning between anesthetic phases in a case / patient based on events detected by applying a set of rules to anesthesia machine parameters, as described above. Figure 4 As explained above, a CS event is detected by applying the first subset of rules 412, indicating that the case is currently in induction. During induction (e.g., before an MS event is detected), there may be situations where a CS event or an ES event is detected, such as when a clinician operating the anesthesia machine turns on mechanical ventilation, then off, and then on again. In such cases, induction can be restarted or maintained, as indicated by the arrow pointing back to induction in response to the detection of a CS or ES event.

[0100] When a case is in induction and an MS event is detected by applying the second subset of rules 414 and the third subset of rules 416, the case may be indicated as currently in hold. During hold, there may be a situation where an MS event is detected again or a CS event is detected. If an MS event is detected while in hold, the hold is maintained (as indicated by the arrow pointing to hold in response to the detection of an MS event). If a CS event is detected while in hold, the current case is considered complete, and a new case is started (e.g., induction), as indicated by the arrow pointing to induction in response to the detection of a CS event during hold.

[0101] When a patient is in a hold state and an ES event is detected by applying rule subset 418 and rule subset 420, the patient may be indicated as currently in a state of awakening. During awakening, there may be a re-detection of an ES event, or a CS event, MS event, or ventilation start (VS) event. If an ES event is detected while the patient is in a state of awakening, the patient remains in a state of awakening (as indicated by the arrow pointing to awakening in response to the detection of an ES event). If an MS or VS event is detected while the patient is in a state of awakening, the patient returns to hold state (as indicated by the arrow pointing to hold state in response to the detection of an MS or VS event). If a CS event is detected while the patient is in a state of awakening, the current patient is considered complete, and a new patient is initiated (e.g., induction), as indicated by the arrow pointing to induction in response to the detection of a CS event during awakening.

[0102] Once a CE event is detected by applying rule subset 422 of the sixth rule, the case is considered complete at any point where the CE event is detected (e.g., regardless of the current stage). Figure 5 The process flow 500 described in the document can specify how one or more GUIs can be updated based on detected events, as explained in more detail below.

[0103] Figure 6 A high-level method 600 for detecting anesthesia delivery events in a patient is shown. Method 600 can utilize... Figure 1 and Figure 2 System 10 is used to implement this. Method 600 can be based on data stored in non-transitory memory and processed by one or more processors (such as...). Figure 2 The instructions are executed by the memory and processor of the computing system 120.

[0104] At point 602, method 600 receives monitoring parameters of the patient within the observation window. These parameters can be obtained from an anesthesia delivery machine (such as...). Figure 3 The anesthesia machine (399) receives monitoring parameters. These monitoring parameters may include those mentioned above. Figure 4 Some or only a subset of the 400 monitoring parameters described. Additionally, as mentioned above... Figure 1 and Figure 2 As explained, monitoring parameters may be ingested and stored (at least temporarily) by the computing system. The observation window may include a set time period during which monitoring parameters are received and stored for further processing to detect events, as explained below. Therefore, the observation window may include an appropriate duration, such as one minute. The observation window may be selected to allow sufficient time to detect changes in the selected monitoring parameters that indicate events signaling a new phase of anesthesia delivery, but short enough to minimize the total amount of data stored and allow for rapid event detection (e.g., avoiding excessive delays in detecting transitions to new phases).

[0105] At 604, method 600 may include: processing any monitoring parameters received in a non-normalized format to convert them into a normalized format. The processing to normalization is performable to prepare the received monitoring parameter data for evaluation via a rule set of a rule engine to detect events, as explained in more detail below, and therefore the normalized format may include a format usable by the rule engine. This processing may include: interpolating one or more monitoring parameters to include a normalized number of data points. For example, some monitoring parameters may be recorded and / or transmitted at a relatively low frequency (e.g., once every 10 seconds) compared to other monitoring parameters that may be recorded and / or transmitted at a relatively high frequency (e.g., once per second). Therefore, the monitoring parameters recorded and / or transmitted at the lower frequency may be interpolated to increase the number of data points for those monitoring parameters within the observation window. In this way, any missing values ​​in the raw data from the anesthesia machine and optionally the patient monitor can be replaced by positively filling the raw data in the observation window with previous data segments (e.g., data from the previous 30 seconds) to maintain data validity and aid parameter comparison. Other examples of processing may include averaging, filtering, trend determination (e.g., changes in monitoring parameters within the observation window), etc. Other processing may also be applied, such as conversion to a standardized communication protocol. For example, some anesthesia machines may communicate according to a first protocol, while others may communicate according to a second protocol, and the processing may include converting monitoring parameters received according to the second protocol to the first protocol.

[0106] At 606, method 600 includes applying a set of rules based on received monitoring parameters to detect whether an event has occurred. As indicated at 608, the set of rules may include a first subset of rules for detecting the onset of a case (e.g., first subset 412). As indicated at 610, the set of rules may include a second and a third subset of rules for detecting the onset of maintenance (e.g., second subset 414 and third subset 416). The selected set of rules may include a fourth and a fifth subset of rules for detecting the onset of awakening (e.g., fourth subset 418 and fifth subset 420), as indicated at 612. As indicated at 614, the set of rules may include a sixth subset of rules for detecting the end of a case (e.g., sixth subset 422). The following section discusses... Figure 7 Additional details are provided regarding the application of rule sets to monitoring parameters to identify whether an event has been detected. As previously explained, detectable events include those that signal a change to a new phase of anesthesia delivery, and are therefore likely to be slightly transient events. Therefore, for each observation window, an output indicating whether an event was detected (and, if so, which event), or not, can be generated, as indicated at 616, depending on the result of the rule set applied to the monitoring parameters. When no event is detected, the new phase of anesthesia delivery has not yet occurred, and the current phase of anesthesia delivery may be in progress. However, as this paper discusses… Figure 6 The described method for identifying whether an event has occurred can be stateless because the previous or current anesthesia stage is unknown. Therefore, when no event is detected, the output indication may not include the current anesthesia stage.

[0107] At 617, method 600 includes: updating one or more graphical user interfaces (GUIs) based on an output indication when indicated. The following section discusses... Figures 8A to 8C Additional details are provided regarding updating one or more GUI elements. In short, the GUI (such as...) can be updated each time an event is detected. Figure 10 The GUI shown reflects the transition to a new stage of anesthesia delivery. The GUI can be updated in real time, for example, while anesthesia delivery / case is in progress.

[0108] At 618, method 600 includes: sliding an observation window and repeating the method (e.g., receiving patient monitoring parameters within a new observation window, processing the monitoring parameters, applying a rule set, outputting an indication, and updating one or more GUIs), which can be repeated until the end of the case is detected. The observation window can slide by an appropriate amount, such as one second. In this way, the indication of whether an event was detected can be repeated during the patient's anesthesia delivery using the past minute (or other suitable duration) of the received monitoring parameters at a desired frequency (e.g., per second) using newly acquired monitoring parameters. At 620, method 600 includes: applying summary rules (e.g., seventh subset 424) to retrospectively define the anesthesia stage. The following section discusses... Figure 9 Additional details regarding the application of the summary rules are provided. It should be understood that Method 600 can be performed for each patient / operating room in which anesthesia delivery is in progress, about to be performed, or has ended at a given medical facility, unit, or ward.

[0109] Turn now Figure 7 A method 700 is shown for applying a set of rules to monitoring parameters of a received patient in order to detect events that signal changes in anesthesia delivery to the patient. Method 700 can utilize... Figure 1 and Figure 2 System 10 is used to implement this. Method 700 can be based on data stored in non-transitory memory and processed by one or more processors (such as...). Figure 2 The method is implemented by instructions executed by the computing system 120 (memory and processor). In some examples, method 700 may be executed as part of method 600, for example, at 606 of method 600.

[0110] At 702, method 700 includes: applying a first subset of rules to indicate CS in response to the end of the standby setting of the anesthesia machine. The first subset of rules may be applied within an observation window such that CS is detected if the standby setting is turned off at any point during the observation window (e.g., thus indicating that the anesthesia machine is active).

[0111] At 704, method 700 includes: applying a second subset of rules to indicate MS in response to ventilation initiation and a valid EtCO2 measurement. The second subset of rules may be applied within an observation window such that MS is detected if mechanical ventilation is initiated at any point during the observation window, followed by a valid EtCO2 measurement (e.g., where EtCO2 is above a threshold, such as 0.2 mmHg).

[0112] At 706, method 700 includes: applying a third subset of rules to indicate an MS in response to a total flow pattern showing a decrease in total flow within an observation window. The total flow pattern may include observing seven consecutive fresh gas flow values, wherein the first two of the seven consecutive fresh gas flow values ​​are equal to or higher than a flow threshold (5 L / min), followed by a third fresh gas flow value lower than the flow threshold, and at least two of the next three fresh gas flow values ​​are lower than the flow threshold. The third subset of rules may be applied within the observation window such that if the total flow pattern is detected at any point during the observation window, an MS is detected. Furthermore, the second and third subsets may be applied in parallel, and an MS may be indicated in response to any subset that first indicates an MS.

[0113] At 708, method 700 includes: applying a fourth rule subset to indicate an ES in response to ventilation termination lasting for a period of time and the absence of a CBP mode. The fourth rule subset may be applied within an observation window such that an ES is detected if mechanical ventilation terminates at any point during the observation window and remains closed for the duration of the observation window (e.g., 55 seconds) while the anesthesia machine is not operating in cardiac bypass mode.

[0114] At 710, method 700 includes: applying a fifth subset of rules to indicate an ES in response to two of the following parameters being true: an increase in FiO2 (e.g., oxygen percentage), an increase in total flow rate (e.g., an increase in fresh gas flow rate), and the end of anesthetic delivery. The fifth subset of rules can be applied within an observation window such that if two of the three parameters are observed at any point during the observation window, an ES is detected. Furthermore, the fourth and fifth subsets can be applied in parallel, and an ES can be indicated in response to whichever subset first indicates an ES.

[0115] At 712, method 700 includes: applying a sixth subset of rules to indicate a CE in response to the start of a standby setting of the anesthesia machine. The sixth subset of rules may be applied within an observation window such that a CE is detected if the standby setting is turned on at any point during the observation window (e.g., thereby indicating that the anesthesia machine is in standby mode).

[0116] At 714, method 700 determines whether an event is detected by applying a set of rules to the received monitoring parameters as explained above, wherein the event is one of case start, sustaining, awakening start, and case end. If an event is detected (e.g., case start as explained above, sustaining start as explained above, awakening start as explained above, or case end as explained above), method 700 proceeds to 716 to output an indication of the detected event. This indication may include identification of the detected event and a timestamp indicating the time the event was detected. This indication may be stored in memory (e.g., of computing system 120) and / or sent to one or more computing devices (e.g., first care provider device 134). This indication may be used to update one or more GUIs, as will be discussed below. Figures 8A to 8C The explanation given.

[0117] If no event is detected (e.g., no case start, hold start, awakening start, or case end is detected), method 700 proceeds to 718 to output an indication of the undetected event. This indication may be stored in memory (e.g., of computing system 120) and / or sent to one or more computing devices (e.g., first care provider device 134). When no event is detected, this indication may be used to maintain the current state of one or more GUIs relative to the patient, as will be explained below.

[0118] In some examples, two or more subsets of rules in the rule set can be applied simultaneously to the received monitoring parameters, which can speed up event detection. In such examples, method 700 can be executed entirely for each observation window of each patient, regardless of whether an event is detected. For example, method 700 can be executed to apply the rule set to the monitoring parameters received within the patient's observation window, and case start can be detected. Even though case start is detected, the rest of method 700 can still be executed to determine whether any other events are detected. In other examples, subsets of rules in the rule set can be applied serially (e.g., one after another). In such examples, the next subset of rules can only be applied if no event is detected in the current subset of rules. For example, once an event is detected, the method can be terminated (e.g., once case start is detected, any remaining subsets of rules that have not yet been applied can not be applied), which can also speed up event detection by eliminating unnecessary continuation of event detection.

[0119] Figures 8A to 8C A method 800 for displaying the current stage of anesthesia for each of multiple patients is shown. Method 800 can utilize... Figure 1 and Figure 2System 10 is used to implement this. Method 800 can be based on data stored in non-transitory memory and processed by one or more processors (such as...). Figure 2 The method 800 is implemented according to instructions executed by the memory and processor of the computing system 120. In some examples, the method 800 may alternatively be based on instructions stored in non-transitory memory and executed by... Figure 2 The computing system 120 communicates with one or more processors of a computing system (such as a care provider device (e.g., first care provider device 134)) to execute instructions. In some examples, method 800 may be executed as part of method 600, for example, at 617 of method 600.

[0120] At 802, a graphical user interface (GUI) is displayed (e.g., on a display device included as part of a communicatively coupled computing system), which includes an operating room (OR) status panel and an anesthesia stage timeline for each of multiple patients. Multiple patients may be undergoing or about to undergo anesthesia delivery as part of a surgical or other medical procedure at a specific medical facility tracked by the computing system. For example, each of the multiple patients may be located in a corresponding operating room at the medical facility. The OR status panel may include a summary of the current anesthesia delivery stage for the multiple patients, such as the number of patients in induction, the number of patients in hold, and the number of patients in recovery. The OR status panel may further include multiple operating rooms that are open (e.g., currently without any patients). Each anesthesia stage timeline depicts a color-coded anesthesia stage as a function of time, as indicated at 804. For example, the first anesthesia stage timeline for the first patient may begin at the start of the case, signaling the start of induction and indicated in a first color on the timeline, and transition to hold 10 minutes after the start of the case, where hold may be indicated in a second color on the timeline. Figures 10 to 12 The example GUI shown includes an OR status panel and timeline for multiple patients.

[0121] At 808, method 800 includes receiving an event detection indication for each patient at each observation window. For example, the indication may be generated according to methods 600 and 700. As explained above, an event may include one of case start, maintenance start, awakening start, and case end. Methods for identifying whether an event has occurred (e.g., methods 600 and 700) may be performed for each patient about to begin anesthesia or currently receiving anesthesia. In some examples, instead of identifying the patient themselves, the method may be performed for each operating room or each anesthesia delivery machine that operates as an agent for patient identification. As explained above regarding... Figure 6As explained, during each observation window, for each patient (or operating room or anesthesia delivery machine), an indication can be generated as to whether an event has been detected for that patient or not. The computational system performing method 800 can receive each indication for each observation window for each patient, and each indication can be timestamped. In some examples, each indication can be stored in a table or other data structure. Alternatively, once an indication indicating the start of a case has been detected for a given patient is received, the table can be updated to indicate the current stage of anesthesia delivery (e.g., hold) and the time the current stage began. The current stage can be held until an indication that a new stage has been detected for a given patient is received, at which point the table can be updated to indicate the current stage of anesthesia delivery (e.g., awakening) and the time the new stage begins for the given patient. In either example, the table can store the current stage of anesthesia delivery for each patient, as well as each known previous stage and the timing / duration of each stage.

[0122] At 808, method 800 includes: determining whether an indication has been received that a first CS has been detected for the selected patient. If not, method 800 proceeds to 810 to maintain or adjust the OR status panel and timeline of the GUI for other patients based on the detected event. For example, the method may include: determining whether any indication (e.g., received at 806) indicates that an event has been detected (or other than the first CS for the selected patient), or determining whether all indications indicate that no event has been detected. If no indication has been received for an event that has been detected for a patient (e.g., the most recently received indications all indicate that no event has been detected), the OR status panel and each timeline may remain in their current state, rather than an earlier timeline. For example, referring back to the first timeline of the first patient discussed above, this first timeline may continue to indicate that the first patient is undergoing induction because no event indicating other conditions has been detected. If an event is detected for a patient, the OR status panel may be updated, and the patient's timeline may be adjusted to reflect the new phase. This process may continue until each case is determined to be complete. Method 800 then ends. It should be understood that the process described below is performed for each patient (e.g., updating the GUI of the selected patient based on the first CS event detected for that patient, and then subsequently updating the GUI when another event is detected for the selected patient).

[0123] If an indication is received that a first CS has been detected for the selected patient, method 800 proceeds to 812 to begin plotting the induction of the selected patient on the timeline and adjusting the OR status panel of the GUI (e.g., to increase the number of patients currently in induction). At 814, method 800 includes determining whether an indication is received that an MS has been detected for the selected patient. Indications may be received for each patient (including the selected patient) throughout the execution of method 800. When one of the indications includes that an MS has been detected for the selected patient, method 800 proceeds to 816 to begin plotting the hold and adjusting the OR status panel of the GUI on the timeline of the selected patient (e.g., to increase the number of patients currently in hold and decrease the number of patients currently in induction). If no indication is received that an MS has been detected for the selected patient, method 800 proceeds to 818.

[0124] At 818, method 800 includes: determining whether an indication has been received that ES has been detected for the selected patient. If no indication has been received that ES has been detected for the selected patient, method 800 proceeds to... Figure 8C Method 836, which will be explained in more detail below, proceeds to step 800 if an indication is received that ES has been detected for the selected patient. Figure 8B At 820, method 800 includes determining whether the selected patient is currently in a holding state. As explained above, some actions can trigger the detection of an ES (Emergency Event) even if the patient has not actually transitioned from holding to awakening. Therefore, determining whether the patient is currently in a holding state when an ES is detected can help mitigate false ES event detections.

[0125] If the selected patient is not currently in a hold state, the ES event detection may not be a true detection, and therefore method 800 may proceed to 828 to maintain the timeline of the selected patient in the current phase and maintain the OR status panel. If the selected patient is currently in a hold state, the ES event detection may be a true detection, and therefore method 800 may proceed to 822 to begin plotting the awakening of the selected patient on the timeline and update the OR status panel of the GUI (e.g., to increase the number of patients currently awake and decrease the number of patients currently in a hold state).

[0126] At 824, method 800 determines whether a CS trigger has been detected. As explained above, a CS trigger may include the anesthesia machine standby mode being turned off and may be determined based on a received indication that a CS event has been detected for the selected patient. If a CS trigger is detected, method 800 proceeds to 826 to begin plotting the induction of a new patient / case on the timeline and adjusting the OR status panel. At any point while tracking the anesthesia phase of the selected patient, if a CS event is detected, the current case for the selected patient can be considered complete, and a new case can be started (e.g., for a new patient). If no CS trigger is detected, method 800 proceeds to 830 to determine whether a hold-start trigger has been detected (e.g., if an indication has been received that an MS event has been detected for the selected patient). As explained above, MS may be detected based on the start of ventilation and / or based on a specific flow pattern observed. It is possible that a hold-start trigger can be detected when it is determined that the selected patient is in a state of awakening. Therefore, if no hold-start trigger is detected, method 800 proceeds to Figure 8C Method 840, which will be explained in more detail below, proceeds to 832 if a hold start trigger is detected, to determine if the selected patient is currently awake. If the selected patient is not currently awake, method 800 proceeds to 816 to begin plotting the patient's hold on the timeline and adjusting the OR status panel, as explained above. When a hold start event is detected and the selected patient is not awake, it is determined that the selected patient is on hold and the GUI is updated accordingly.

[0127] If it is determined at 832 that the patient is currently awake, method 800 proceeds to 834 to restore the selected patient's timeline to a previous stage (e.g., hold) and adjust the OR status panel accordingly (e.g., reduce the number of patients currently awake). Therefore, when an MS event is detected while the selected patient is currently awake, the awakening event that triggered the transition to awakening can be considered an error event, and the selected patient can be restored to hold on the GUI.

[0128] Return to Figure 8A If, after receiving an indication that CS has been detected for the selected patient and optionally also receiving an indication that MS has been detected for the selected patient, it is determined that no indication has been received for ES has been detected for the selected patient, then method 800 proceeds to 836. Figure 8CAs shown in the diagram, method 800 includes: determining whether a CS trigger has been detected, which is similar to the determination in 824 explained above. When the selected patient is currently in induction or maintenance and a CS trigger is detected (e.g., the anesthesia machine is removed from standby mode), method 800 proceeds to 838 to begin plotting the induction of a new patient / case on the timeline and adjusting the OR status panel. At any point while tracking the anesthesia phase of the selected patient, if a CS event is detected, the current case of the selected patient can be considered complete, and a new case can begin (e.g., for a new patient). If no CS trigger is detected, method 800 proceeds to 840 to determine whether an indication has been received that a CE event has been detected. If no CE event is detected for the selected patient, method 800 proceeds to 814 to continue monitoring MS events. Essentially, once the initial CS event for the selected patient is detected and the induction of the selected patient begins to be plotted on the GUI, method 800 iterates to determine whether any events for the selected patient are detected. In standard cases without erroneous event detection or atypical events (e.g., sudden removal of the patient from the anesthesia machine), method 800 proceeds after the initial CS event is detected to eventually detect the MS event (and begins plotting hold on the timeline of the selected patient's GUI). During the interval between the detection of the initial CS event and the detection of the MS event, the selected patient is assumed to be in induction, and the hold timeline is maintained to reflect this. Once the selected patient is in hold, method 800 proceeds to eventually detect the ES event (and begins plotting awakening on the timeline of the selected patient's GUI). During the interval between the detection of the MS event and the detection of the ES event, the selected patient is assumed to be in hold, and the timeline is maintained to reflect this. However, method 800 includes checks and actions for when events deviating from the above sequence are detected.

[0129] Returning to 840, if a CE event is detected for the selected patient, method 800 proceeds to 842 to mark the case as complete. When the case is marked as complete, the timeline for the selected patient is complete, and the OR status panel is adjusted to reflect that the selected patient is no longer in the current stage (e.g., awake). In the standard case period as explained herein, the CE event is detected after the selected patient has been awake for a period of time. However, it is possible that the CE event may be detected when the selected patient is in a different stage (e.g., in a non-standard case), and therefore 842 may be performed at any point during the case period in which the CE event is detected. Method 800 then ends.

[0130] Figure 9A method 900 is shown for retrospectively updating one or more anesthesia stages of a patient by applying summary rules (e.g., subset 424 of rule 7). Method 900 can utilize... Figure 1 and Figure 2 System 10 is used to implement this. Method 900 can be based on data stored in non-transitory memory and processed by one or more processors (such as...). Figure 2 The method 900 is implemented according to instructions executed by the memory and processor of the computing system 120. In some examples, the method 900 may alternatively be based on instructions stored in non-transitory memory and executed by... Figure 2 The computing system 120 communicates with one or more processors of a computing system (such as a care provider device (e.g., first care provider device 134)) to execute instructions. In some examples, method 900 may be executed as part of method 600, for example, at 620 of method 600. Method 900 is described below with respect to patients whose cases have been marked as completed based on the execution of the above-described method 800. In some examples, method 900 may be executed in response to an instruction that a case has been marked as completed for a patient. Once all patients / cases have been marked as completed, method 900 may be executed for all patients / cases to update the timeline on that patient's GUI. It should be understood that, in addition to updating the timeline displayed on the GUI, the timeline may also be stored in long-term memory for later viewing and insight collection. Furthermore, the events and their relative timing can be used for various downstream processing tasks, such as anesthesia adequacy or other algorithms.

[0131] At 902, method 900 includes: if instructed, adjusting the initiation of patient induction based on a first CS event that occurred / was detected prior to the detection of a CE event for that patient. (See above regarding...) Figures 8A to 8C As explained, when a patient's case is actively progressing, induction for that patient can be plotted on the timeline when the first CS event is detected. However, some cases may involve more than one CS event. If more than one CS event is detected for a patient, the timeline for that patient can be adjusted (as will be explained below, it will still be displayed on the GUI for at least a period of time after the case ends) so that induction begins when the first CS event is detected before the CE event for that patient. Figures 8A to 8C The real-time updates mean that whenever a CS event is detected for a case, previous events are discarded and the plotting restarts, and therefore multiple CS events are not shown on the real-time timeline. However, for Figure 9 The retrospective analysis records all CS events, and when more than one CS event is detected, the last CS event that occurred before CE is selected, thus synchronizing live / real-time and retrospective data.

[0132] At 904, method 900 includes: adjusting the duration of the hold if indicated. The duration of the hold phase can be adjusted when multiple MS events are detected or when no MS event is detected for the case. Adjusting the duration of the hold may include: if the case duration is greater than 30 minutes, setting the start of the hold to the last MS detected within the first 8 minutes of the case, as indicated at 906. In this way, if multiple MS events are detected and the case duration is greater than 30 minutes, the final MS event detected within the first 8 minutes of the case can be selected as the actual MS event, and the hold can be plotted to begin at that MS event. However, if no MS event is detected within the first 8 minutes of the case (and the case duration is greater than 30 minutes), the first MS event occurring between the start and end of the case is used as the start of the hold, as indicated at 908.

[0133] Furthermore, as indicated at 910, adjusting the duration of the hold phase may include: if no MS event is detected and the case duration is in the range of 6 to 10 minutes, then the hold phase is indicated to begin 3 minutes after the CS. If no MS event is detected, it is likely that hold will occur but will be undetectable / not meet the detection criteria. Therefore, only the first 3 minutes are considered induction, and hold is added starting 3 minutes after the case begins. Further, as indicated at 912, adjusting the duration of the hold phase may include: if no MS event is detected and the case duration is greater than 10 minutes, then the hold phase is indicated to begin 5 minutes after the CS.

[0134] At 914, method 900 includes: adjusting the duration of awakening if instructed. The duration of awakening can be adjusted due to the detection of more than one ES event, due to an awakening lasting longer than a threshold duration, or due to the absence of a detected ES event. Adjusting the duration of awakening may include: as indicated at 916, if the case duration is greater than 30 minutes, using the first ES detected within the last 15 minutes of the case. In this way, if more than one ES event is detected, when the case duration is greater than 30 minutes, the first ES event occurring within the last 15 minutes of the case can be set as the actual ES event, and awakening can be plotted starting from that ES event. As indicated at 918, if no ES event is detected within the last 15 minutes of the case (and the case duration is greater than 30 minutes), the last ES event occurring between the beginning and end of the case can be set as the actual ES event, and awakening can be plotted starting from that ES event. Additionally, as indicated at 920, if it is determined that the set ES event occurred before a specified MS event, the set ES event is removed as invalid. Furthermore, as indicated at 922, adjusting the duration of awakening may include shortening the duration of awakening if the awakening time is greater than 30 minutes. For example, the duration of awakening may be reduced to the last 10 minutes of the case. Thus, the ES event may be moved from the detected / set ES event to 10 minutes before the CE. Awakening typically does not last longer than 30 minutes. In some cases, awakening may be prolonged because the anesthesia machine remains on while the patient is removed. Additionally, false awakening detection may occur at the start of the case, and in such cases, actual awakening may be missed, resulting in an awakening that is longer than actually occurred. By shortening the duration of awakening when it is longer than 30 minutes, awakening can be accurately reflected based on the most probable scenario. Further, as indicated at 924, if no ES event is detected, the end time of anesthetic administration (the time when the last dose ends, which may be determined based on the set or measured inhaled anesthetic reaching zero) may be set as the ES event. As explained above, if the set ES event precedes the set MS event, the ES event may be removed.

[0135] At 926, method 900 includes: setting the CE as the first detected CE. In this way, if multiple CE events are detected, the first CE can be set as a valid CE event, and the case is marked as complete at the set / valid CE event. Method 900 then ends.

[0136] Therefore, the systems and methods disclosed herein provide for the detection of anesthetic events and notification of the patient's anesthesia phase based on the detection of anesthetic events. (As mentioned above regarding...) Figures 8A to 8C The description and in Figures 10 to 13As illustrated in the examples and described below, a GUI can be displayed that includes a first visual representation of the default or previously determined stage of the patient's anesthesia delivery, such as in the form of a timeline. For example, the default stage could be "anesthesia delivery not started," which could be depicted via blank / blank spaces on the timeline, or the previously determined stage could be induction, which could be depicted via a first color or pattern on the timeline. Multiple monitoring parameters of the patient can be received within the observation window, with at least a portion of these parameters obtained from the anesthesia delivery machine. A set of rules can be applied to the multiple monitoring parameters to identify whether an event signaling a change to a new stage of the patient's anesthesia delivery has been detected, where the event is one of case start, hold start, awakening start, and case end. If an event is detected, the GUI can be updated to display a second visual representation of the new stage, such as changing the color or pattern on the timeline. Conversely, if no event is detected, the first visual representation can be maintained on the GUI; for example, the timeline can continue to depict the color or pattern indicating the default or previously determined stage.

[0137] In addition, as mentioned above... Figure 6 As explained, some of the received monitoring parameters can be received in a normalized format (e.g., at a first higher frequency), while others can be received in a non-normalized format (e.g., at a second lower frequency). Before analyzing the monitoring parameters to detect events, monitoring parameters received in a non-normalized format can be converted to a normalized format (e.g., by interpolation using the previous 30-second value of the monitoring parameter to the first frequency), as described above. In doing so, various different monitoring parameters indicating anesthesia delivery steps / actions can be analyzed in the same normalized format, regardless of the format in which the monitoring parameters are received.

[0138] For example, the systems and methods disclosed herein can be configured to output a GUI for display on a display device, the GUI including a first visual representation of a patient's default or previously determined anesthesia delivery stage; receive multiple monitoring parameters of the patient within an observation window, at least a portion of which are obtained from an anesthesia delivery machine; identify whether an event signaling a change to a new stage of anesthesia delivery for the patient is detected by applying a set of rules to the multiple monitoring parameters, wherein the event is one of case start, maintenance start, awakening start, and case end; update the GUI to display a second visual representation of the new stage based on the detection and determination of the event as a real event; and maintain the first visual representation on the GUI based on the absence of the event detection.

[0139] In some examples, applying a rule set to identify whether an event was detected may include: applying a first subset of rules to determine whether a case start was detected; applying a second and third subset of rules to determine whether a sustaining start was detected; applying a fourth and fifth subset of rules to determine whether an awakening start was detected; and applying a sixth subset of rules to determine whether a case end was detected. In some examples, applying the first subset of rules to determine whether a case start was detected includes: determining that a case start was detected in response to the end of a first standby event of the anesthesia delivery machine; applying the second and third subset of rules to determine whether a sustaining start was detected includes: determining that a sustaining start was detected in response to the first of the following: (a) and (b) are true or (c) is true, wherein (a) includes the occurrence of a mechanical ventilation start event, (b) includes at least one valid value of end-tidal carbon dioxide (EtCO2), and (c) includes the following fresh gas flow pattern: two initial fresh gas flow values ​​are above a threshold, and at least three of the next five fresh gas flow values ​​are fresh gases. The flow rate value is below the threshold, and the third fresh gas flow rate value is below the threshold; applying the fourth and fifth rule subsets to determine whether the start of awakening is detected includes: determining that the start of awakening is detected in response to the first of the following: (d) and (e) are true or (f) is true, wherein (d) includes a mechanical ventilation termination event that occurs and is observed at the threshold time amount, (e) does not include cardiac bypass mode, and (f) includes both of the following being true: an increase in O2 percentage, an increase in fresh gas flow rate, and the termination of anesthetic delivery; and applying the sixth rule subset to determine whether the end of case is detected includes: determining that the end of case is detected in response to the start of a second standby event of the anesthesia delivery machine. In some examples, the second and third rule subsets are applied in parallel, and the fourth and fifth rule subsets are applied in parallel.

[0140] In some examples, the systems and methods disclosed herein further include: if a case initiation is detected, determining that the case initiation is a real event and updating the GUI to display the second visual representation indicating that the patient is currently in induction, regardless of the previously determined stage of anesthesia delivery; if a hold initiation is detected, determining that the hold initiation is a real event and updating the GUI to display the second visual representation indicating that the patient is currently in hold, regardless of the previously determined stage of anesthesia delivery; if an awakening initiation is detected during hold, determining that the awakening initiation is a real event and updating the GUI. The GUI displays the second visual representation indicating that the patient is currently awake; if awakening is detected during induction, it is determined that the awakening start is not a real event, and the first visual representation is maintained on the GUI; if case end is detected, it is determined that case end is a real event, and the GUI is updated to display the second visual representation indicating that the patient is currently in case end, regardless of the previously determined stage of anesthesia delivery; and if no case start, maintenance start, awakening start, or case end is detected, the first visual representation is maintained on the GUI. It should be understood that the GUI can be... Figures 10 to 12 The GUI and / or shown Figure 13 The second GUI.

[0141] In some examples, when the event is the end of a case, and in response to detecting the end of a case, the case is marked as complete, and a subset of the seventh rule is applied to retrospectively update the timing and / or occurrence of one or more stages of anesthesia delivery for the case, as described above regarding Figure 9As explained. For example, applying this subset of rules to retrospectively update the timing and / or occurrence of one or more phases of anesthesia delivery for a case may include: if more than one instance of a given type of event is detected during the case, selecting one instance of the given type of event as the valid event, and updating the timing of the phase corresponding to the given type of event; and if no instance of the given type of event is detected during the case, adding the given type of event and updating the occurrence of the phase corresponding to the given type of event. In some examples, the given type of event is a hold start, such that if more than one instance of a hold start is detected during the case, selecting one instance of a hold start as the valid event, wherein selecting the one instance of a hold start includes: if the duration of the case is greater than a threshold duration, selecting the last instance of a hold start that occurred during a first time period of the case. In some examples, if no instance of a hold start is detected during the case, adding a hold start to the case includes: if the duration of the case is within a threshold range, specifying a first predefined time amount since the case start as a hold; and if the duration of the case is greater than the threshold range, specifying a second predefined time amount since the case start as a hold, the second predefined time amount being greater than the first predefined time amount.

[0142] In some examples, the event of a given type is awakening start, such that if more than one instance of awakening start is detected during the case, one instance of awakening start is selected as the valid event. Selecting this one instance of awakening start includes: if the duration of the case is greater than a threshold duration, selecting the first instance of awakening start that occurred during the last time period of the case; and if the duration of the case is greater than the threshold duration and no instance of awakening start was detected during the last time period of the case, selecting the last instance of awakening start detected during the case. In some examples, adding an awakening start to the case if no instance of awakening start is detected during the case includes: determining the end time of anesthetic delivery to the patient, and adding the awakening start at the determined time.

[0143] The systems and methods disclosed herein can detect multiple events (e.g., a first event and a second event) for a given patient and determine whether the first event or the second event is a false positive event based on the first event and the second event. If the first event or the second event is a false positive, the GUI can be updated to reflect the false positive (e.g., the timeline can be adjusted to remove the false positive). For example, the first event could be the start of awakening and the second event could be the start of sustaining, wherein determining that the first event or the second event is a false positive based on the first event and the second event includes determining that the start of awakening is a false positive based on detecting the start of sustaining after the start of awakening was detected. In such an example, the GUI can be updated by removing awakening from the patient's timeline and extending the duration of sustaining on the timeline. As another example, the first event could be the start of sustaining and the second event could be the start of a case, wherein determining that the first event or the second event is a false positive based on the first event and the second event includes determining that the start of sustaining is a false positive based on detecting the start of a case after the start of sustaining was detected. In such an example, the GUI can be updated by removing sustaining from the patient's timeline and plotting induction on the timeline.

[0144] Figure 10 An example GUI 1000 in a first state 1001 is shown. The GUI 1000 can be displayed on a display device (e.g., the first care provider device 134) and can be based on... Figure 6 and Figure 7 Anesthesia delivery event detection according to Methods 600 and 700 Figures 8A to 8C Method 800 and Figure 9 Method 900 is used to generate and update the GUI 1000. The GUI 1000 may include an OR status panel 1002, which includes multiple display elements providing a summary of the current stage of all patients among multiple patients undergoing anesthesia delivery at a particular facility, ward, or unit (e.g., an operating room in a hospital). These multiple display elements may include a first display element 1004 indicating the number of patients undergoing induction, a second display element 1006 indicating the number of patients undergoing maintenance, and a third display element 1008 indicating the number of patients undergoing awakening. The OR status panel may include additional display elements, such as a fourth display panel indicating the total number of patients in monitoring mode (e.g., where the anesthesia delivery machine has been switched to "monitoring only mode") and / or the number of operating rooms open.

[0145] The GUI 1000 further includes multiple anesthesia delivery timelines 1010. Each of the multiple timelines 1010 depicts the anesthesia delivery stages as a function of time for a corresponding patient among multiple patients. In some examples, the user can adjust the amount of time displayed on the GUI 1000 by selecting time elements. Figure 10 As shown, the user has selected to view the past three hours, and the timeline is adjusted to display those three hours. Alternatively, the user can choose to view the past hour, the past six hours, the past day (e.g., 12 or 24 hours), or another suitable amount, and the timeline can be expanded or contracted accordingly.

[0146] The timelines can be arranged by the operating room or the anesthesia machine. For example, a first row 1011 is depicted, showing the anesthesia delivery phases as a function of time for a patient in a selected operating room (OR4 in this example). The first row 1011 includes timelines for three different patients (e.g., three different cases), where two timelines have been completed (e.g., completion timeline 1013), and one timeline is active, shown as the active timeline 1012. The active timeline 1012 can be visually depicted as a color-coded bar representing the current anesthesia phase. For example, induction is shown as a first color at region 1014, and retention is shown as a second color at region 1016. Induction (e.g., region 1014) can begin at a time specified in a first indication that the patient's case has started. Retention can begin at a time specified in a second indication that the patient's retention has started. This can be as described above regarding... Figures 6 to 8C The first and second indicators are generated as described. Therefore, when the second indicator is received (indicating that an event signaling a change to a new stage has been detected), the activity timeline 1012 can be adjusted to add a new stage (e.g., a change from a first color to a second color). After the second indicator is received, any subsequent received indicators may not recognize the event, and thus the activity timeline 1012 can be maintained (e.g., region 1016 may extend in time but retain the second color).

[0147] In some examples, GUI 1000 may further include a pop-up panel 1018 that is displayed in response to receiving hover input (e.g., input to region 1014 of timeline 1012) on a selected stage of a selected timeline. Pop-up panel 1018 may include additional information about the selected stage, such as the stage name (e.g., induction), the stage duration, the stage start time, and the stage end time. In the example shown, pop-up panel 1018 indicates that the induction begins at 9:25, ends at 9:35, and lasts for 10 minutes.

[0148] GUI 1000 in Figure 11 The second state 1101 is shown in the middle. In the second state, a different hover input has been received (e.g., above area 1016 of the activity timeline 1012), resulting in the display of another pop-up panel 1102, which identifies that the hold phase that started at 9:35 has not yet ended (e.g., is in progress) and has a current duration of 41 minutes.

[0149] GUI 1000 in Figure 12 The third state 1201 is shown in the diagram. In this third state, a different hover input has been received (e.g., on the completion timeline 1013), resulting in the display of another pop-up panel 1202. This pop-up panel identifies a previous case (e.g., a previous patient) that occurred in OR4 and has been completed, lasting 1 hour and 7 minutes, starting at 8:08 and ending at 9:15. Completed cases can be identified using a specific color (such as gray). Although in Figure 12 Not shown, but it should be understood that in some examples, the completion timeline 1013 may visually depict the various stages identified for the case (e.g., by color, using text or another suitable visual representation).

[0150] As mentioned above Figures 8A to 9 As explained, if it is determined that the initially detected event is not an actual / valid event, the activity timeline and / or completion timeline can be updated. For example, a detected first CS event (e.g., at 9:24) can trigger the plotting of induction on activity timeline 1012. If a second CS event is detected after the first CS event, the first CS event can be discarded, and activity timeline 1012 can be adjusted to show the induction that began at the time of the second CS event (e.g., at 9:25). A detected first MS event can trigger a switch to plotting hold on activity timeline 1012, and any additional MS events may not affect activity timeline 1012. As the case progresses, an ES event can be detected, which will trigger a switch to plotting awakening on activity timeline 1012 (not shown, but it should be understood that awakening can be shown in a third color). However, if an MS event is detected when awakening is plotted, the case can be reverted to hold. In such an example, the portion of activity timeline 1012 initially plotted in a third color to show awakening can be switched to a second color to show hold. Similarly, once a case is marked as completed and the activity timeline 1012 switches to the completion timeline, if multiple CS events, MS events, ES events, and / or CE events are detected, and if no MS or ES events are detected, then it can proceed as described above. Figure 9 Adjust all aspects of the timeline as explained.

[0151] In this way, when instructed to consider both false-positive event detection (e.g., when a specific event is detected more than once during the case) and false-negative event detection (e.g., when an event of a specific phase is not detected during the case), both the real-time / active visual representation of the patient's anesthesia phase and the complete visual representation of the patient's anesthesia phase can be adjusted. For example, in some use cases, clinicians may turn the mechanical ventilator on and off at the very beginning of the case to test and confirm that the ventilator is functioning correctly. Activation of the ventilator indicates that the current phase is hold, while subsequent deactivation of the ventilator indicates that the current phase is awake. To reduce false-positive awakening detections, a case can only be determined to be awake if the ventilator has been held off for at least a threshold amount of time (e.g., 55 seconds). If the ventilator has indeed been held off for the threshold amount of time, and then a second activation of the ventilator is detected, the system can assume that the second activation is actual entry into hold and update the GUI accordingly. Furthermore, there may be cases where awakening is detected but the case is still in hold, which could lead to false detections. Therefore, after detecting an ES event and then an MS event, the system can assume that the ES event was a false positive event and revert the case to hold. The presence of multiple ventilation switches also provides a signal for the detection of nondeterministic events, and thus, as explained above, if the anesthesia delivery machine remains active (e.g., does not enter standby mode, which would signal the patient to complete), the system can assume that the patient is in hold each time the ventilator is turned on.

[0152] Although Figures 10 to 12While not shown in the GUI, various notifications can be provided via the GUI in some examples, such as notifications indicating that a specific stage of anesthesia delivery for a patient has been prolonged beyond a threshold duration. For example, if a patient's induction lasts longer than a first threshold duration (e.g., ten minutes), a first notification can be displayed to alert the user to the prolonged induction stage, as a prolonged case-onset stage can indicate a delay in the patient's progress to anesthesia due to equipment and / or personnel unavailability. Similarly, if a patient's awakening lasts longer than a second threshold duration (e.g., 20 minutes), a second notification can be displayed to alert the user to prolonged awakening, which can indicate that the patient is exhibiting deep anesthesia and / or logistical problems (e.g., lack of bed or personnel) are preventing the patient from being moved out of the operating room. By automatically determining the anesthesia stage for each of multiple patients, visually indicating the current stage for each patient via the GUI, and notifying the user when the current stage has been prolonged beyond a threshold duration, the current status of anesthesia delivery for each patient and / or any problems can be communicated to the user without being in the room with the patient, without direct communication with any clinician caring for the patient, and without access to the patient's electronic medical records or other data sources. In doing so, the efficiency of the entire system can be improved by reducing excessive delays between patients in the operating room, reducing user interaction with patient data / monitoring parameters in an attempt to determine the current stage of anesthesia delivery for one or more patients or each patient in the medical facility, and so on.

[0153] In another example, one or more notifications may be displayed when there is a pause or interruption in the reception of one or more monitoring parameters for the patient. As explained above, the event signaling a change to a new stage of anesthesia delivery may occur only during one observation window or within several observation windows. Therefore, most of the generated indications may indicate that no event was detected, and the GUI may continue to maintain the previously determined anesthesia stage. However, if one or more monitoring parameters for the patient are not received for a period of time (e.g., the patient's anesthesia delivery machine loses connection to the network), the GUI may continue to indicate that the patient is in the previous anesthesia stage even if the patient has been switched to a new stage, because the event signaling a change to a new stage may have been missed due to the lack of monitoring parameters received during the event. Therefore, if one or more monitoring parameters are not received within an observation window or within two or more consecutive observation windows, an indication of unreliable event detection (or its lack thereof) may be generated, and / or an indication indicating that insufficient monitoring parameter data was received to determine whether an event was detected may be sent, rather than an indication of a detected event or an indication of no detected event. In such examples, the GUI may be updated to reflect unreliable or indeterminate event / no event detection.

[0154] As previously explained, the detected stages of anesthesia can be used in various algorithms, such as anesthetic adequacy. Figure 13 An example second GUI 1300 is shown, indicating the output of an anesthesia adequacy (AoA) algorithm utilizing the detected anesthesia stage. The second GUI includes a status panel 1302 similar to the OR status panel 1002 of GUI 1000, and therefore includes a first display element 1304 indicating the number of patients who underwent induction, a second display element 1306 indicating the number of patients who underwent maintenance, and a third display element 1308 indicating the number of patients who underwent awakening. Additional display elements may be included in the status panel 1302, such as a fourth display element 1310 indicating the total number of active cases and a fifth display element 1312 indicating the number of cases for which the AoA algorithm has triggered an alert / flag to check the anesthesia delivery protocol. Among other parameters, the anesthesia delivery protocol may specify the type of anesthesia to be delivered and the optimal range of various anesthesia parameters (referred to as AoA parameters), which may be based on the current stage of anesthesia. The anesthesia delivery protocol may be set / selected by a user (e.g., an anesthesiologist) and may be patient-specific, general for all patients, or combined (e.g., a first protocol may be applied to adult patients while a second protocol may be applied to pediatric patients).

[0155] The second GUI further includes multiple AoA display panels 1314, each AoA display panel including AoA parameters for each active patient / case, such as neuromuscular transmission monitoring parameters (e.g., TOF%), bispectral index (BIS), and / or entropy monitoring parameters (e.g., state entropy (SE) / response entropy (RE)), as well as the current anesthesia phase (e.g., induction, maintenance, or awakening) and the duration of the current phase for each case. Figure 13 This includes a magnified view 1316 of the AoA display panel 1318. As shown in magnified view 1316, the case / patient (e.g., in OR4) is currently in hold and has been in hold for 49 minutes and 20 seconds. The current phase and the duration of being in the current phase can be described above regarding... Figure 6 and Figure 7 As described above, it is determined and used to update the second GUI 1300, as mentioned above. Figures 8A to 8C This is explained. Furthermore, magnified view 1316 shows the patient's SE / RE ratio with triggered warnings / signs. In some examples, warnings / signs may be based on the current stage of anesthesia. For example, during induction, SE may drop to the optimal range (e.g., 40-60) and may be less than RE, which indicates sufficient depth of anesthesia but not (to be avoided) deep anesthesia. During maintenance, SE and RE should be equal or within a narrow range of each other. During emergence, an SE above 65 may be optimal. If the values ​​of SE and / or RE deviate from these rules, warnings / signs may be triggered. Figure 13In the example shown, in magnified view 1316, SE is higher than RE during the hold period, and therefore an alert / flag has been triggered. Therefore, to know whether the SE / RE value is optimal / meets the rules of the AoA protocol, the current stage of anesthesia is required. The method described herein can be used to ensure accurate, real-time detection of the current stage of anesthesia for each case / patient in a medical facility, which can be displayed to one or more clinicians via the GUI disclosed herein, and used to accurately determine whether the delivery of anesthesia at each stage is adequate (and not too high).

[0156] Figure 14 This is a flowchart illustrating a method 1400 for updating a second GUI (such as second GUI 1300). Method 1400 can utilize... Figure 1 and Figure 2 System 10 is used to implement this. Method 1400 can be based on data stored in non-transitory memory and processed by one or more processors (such as...). Figure 2 The method 1400 is implemented according to instructions executed by the memory and processor of the computing system 120. In some examples, method 1400 may alternatively be based on instructions stored in non-transitory memory and executed by... Figure 2 The computing system 120 communicates with one or more processors of a computing system (such as a care provider device (e.g., first care provider device 134)) to execute instructions. In some examples, method 1400 may be executed as part of method 600, for example, at 617 of method 600, and in conjunction with method 800.

[0157] At 1402, method 1400 includes: displaying a second GUI comprising a status panel and an AoA display panel for each patient currently undergoing anesthesia delivery. In some examples, instead of identifying the patient themselves, each AoA display panel may be specific to the corresponding operating room or operate as an agent for patient identification for each anesthesia delivery machine. The second GUI may be a second GUI 1300, and thus the status panel may include a first display element indicating the number of patients undergoing induction, a second display element indicating the number of patients undergoing maintenance, a third display element indicating the number of patients undergoing awakening, a fourth display element indicating the total number of active cases, and a fifth display element indicating the number of cases for which the AoA algorithm has triggered alerts / flags to check the anesthesia delivery protocol, which will be explained in more detail below. Each AoA display panel depicts the AoA parameters for the corresponding patient, as shown at 1404. For each patient, the AoA parameters may include the most recently determined TOF%, SE / RE value and / or BIS value, as well as the current stage of anesthesia delivery and the duration of being in the current stage. As described above, the current stage of anesthesia delivery may be determined according to method 800.

[0158] At 1406, method 1400 includes receiving an event detection indication for each patient at each observation window. For example, the indication may be generated according to methods 600 and 700. As explained above, an event may include one of case start, maintenance start, awakening start, and case end. Methods for identifying whether an event has occurred (e.g., methods 600 and 700) may be performed for each patient about to begin anesthesia or currently receiving anesthesia. As described above regarding... Figure 6 As explained, during each observation window, for each patient (or operating room or anesthesia delivery machine), an indication can be generated as to whether an event has been detected for that patient or not. This indication can be stored and / or used to determine the current anesthesia stage for each, as indicated at 1408, and as stated above regarding... Figures 8A to 8C The explanation.

[0159] At point 1410, AoA parameters are determined for each patient, and when instructed, the AoA display panel is updated to reflect any changes in the AoA parameters. As an example, when a patient's case initiation event is detected, a new AoA display panel can be added to that patient's second GUI, indicating whether the current stage is induced and displaying the patient's TOF% and SE / RE values ​​or BIS value. Similarly, if the calculated SE / RE value changes for the patient, the patient's AoA panel can be updated to display the new SE / RE value.

[0160] At point 1412, one or more parameters in the AoA parameters can be compared to a corresponding range. In some examples, the corresponding range can be a stage-based range. For example, a patient's BIS value can be compared to a first BIS range, where the first BIS range is selected based on the patient's current stage of anesthesia. Similarly, a patient's SE / RE value (or ratio) can be compared to a first SE / RE range (or a first SE / RE ratio range), where the first SE / RE range or ratio range is selected based on the patient's current stage of anesthesia.

[0161] At 1414, method 1400 includes: determining whether any AoA parameter satisfies a condition relative to a corresponding range. For example, method 1400 may include: determining whether any BIS value is greater than or less than a corresponding BIS range. As a non-limiting example, the BIS range for the first patient may be 40-60, and if the BIS value of the first patient is greater than 60 or less than 40, it can be determined that the BIS value satisfies a condition relative to the BIS range.

[0162] If the AoA parameter does indeed meet the condition relative to the corresponding range, method 1400 proceeds to 1416 to trigger an alert / sign and update the appropriate AoA display panel and the status panel of the second GUI. For example, using the scenario described above where the first patient's BIS value is higher or lower than the first patient's BIS range, the first patient's AoA display panel can be updated to visually indicate the alert / sign. Furthermore, the fifth display element of the status panel can be updated to reflect the first patient's alert / sign (e.g., the fifth display element can display the total count of patients whose alerts / signs have been triggered). Method 1400 then returns, allowing it to be repeated at a given frequency (e.g., once per second) to provide real-time / live updates to the AoA parameter for each patient. It should be understood that once an alert / sign has been triggered for a patient, the patient's AoA display panel can continue to display the visual indication of the alert / sign until it is determined that the patient's AoA parameter no longer meets the condition relative to the corresponding range. For example, a clinician may adjust the amount of anesthesia delivered to a patient, and therefore, the patient's BIS value may fall into the corresponding range, at which point the alert / sign can be removed.

[0163] Returning to 1414, if no AoA parameter satisfies the condition relative to the corresponding range, method 1400 proceeds to 1418 to maintain the AoA display panel and status panel, and then method 1400 returns, allowing method 1400 to be repeated at a given frequency (e.g., once per second) to provide real-time / live updates of the AoA parameters for each patient.

[0164] The systems and methods described herein offer specific technological improvements to computer technology and medical monitoring systems in several ways. First, the systems disclosed herein improve the field of anesthesia monitoring by providing automated solutions to complex technical challenges that are practically impossible to perform mentally. Specifically, the systems disclosed herein simultaneously analyze multiple real-time physiological parameters and apply in parallel rule-based algorithms to detect key transition events with high temporal accuracy. This parallel processing approach enables the systems disclosed herein to identify phase transitions that would be impractical to calculate manually given the amount and frequency of monitoring data.

[0165] Second, the system disclosed in this paper provides technical improvements through a dedicated processing architecture, which includes: a stateless design that independently processes each observation window, thereby reducing memory overhead and improving system reliability by preventing error propagation; parallel application of multiple rule subsets to enable simultaneous evaluation of different phase transition criteria; real-time analysis of time-series medical device data using sliding windows with configurable duration and frequency; dynamic interpolation capabilities for handling variable input frequencies from different monitoring parameters; and automated retrospective analysis to detect and correct false positive and false negative events.

[0166] Third, the system implementations disclosed in this paper provide specific technical solutions to form a system with a specific configuration, including: a rule-based logic engine that processes multiple physiological parameters simultaneously to detect phase transitions; a dedicated algorithm for handling marginal cases such as cardiac bypass and total intravenous anesthesia; automated phase detection that operates in different anesthesia machine configurations without requiring explicit clinician input; and real-time processing of streaming medical device data to enable instant phase detection and GUI updates.

[0167] The technical advantage of identifying whether an event signaling a change to a new stage of anesthesia delivery is detected by applying a selected set of rules to multiple patient monitoring parameters, and updating the GUI to display a visual representation of the new stage if such an event is detected, is that anesthesia stages can be automatically detected using parameters from the anesthesia delivery machine without the need for separate / dedicated monitoring equipment such as EEG. This improves processing efficiency by utilizing parameters that are already available / being analyzed, and eliminates the need to process and analyze data from separate / dedicated monitoring equipment. Anesthesia stages can be displayed or otherwise indicated to one or more users, such as administrators or clinicians, which facilitates enhanced patient care and operational efficiency. By utilizing the event detection described herein, events signaling a change to a new stage of anesthesia delivery can be detected as quickly as possible, where available monitoring parameters allow, without needing to know the specific configuration of the specific anesthesia delivery machine being used. Furthermore, slow / delayed parameters can still be detected by using sliding observation windows of monitoring parameters of appropriate duration (e.g., one minute) (i.e., the same duration for each parameter and each observation window), while allowing for rapid event detection.

[0168] This disclosure also provides support for a system for tracking various stages of anesthesia delivery in a patient's case, the system comprising: one or more processors, and a memory storing instructions executable by the one or more processors to: output a graphical user interface (GUI) for displaying on a display device a first visual representation including a default or previously determined stage of the patient's anesthesia delivery; receive, within an observation window, a plurality of monitoring parameters of the patient, at least a portion of which are obtained from an anesthesia delivery machine; identify, by applying a set of rules to the plurality of monitoring parameters, whether an event signaling a change to a new stage of the patient's anesthesia delivery is detected, wherein the event is one of case start, hold start, awakening start, and case end; update the GUI to display a second visual representation of the new stage based on the event being detected and determined to be a real event; and maintain the first visual representation on the GUI based on the absence of the event. In a first example of the system, executing the instruction to apply the rule set to identify whether the event was detected includes: applying a first subset of rules to determine whether a case start was detected; applying a second and third subset of rules to determine whether a hold start was detected; applying a fourth and fifth subset of rules to determine whether an awakening start was detected; and applying a sixth subset of rules to determine whether a case end was detected. In a second example of the system, optionally including the first example, applying the first subset of rules to determine whether a case start was detected includes: determining that a case start was detected in response to the end of a first standby event of the anesthesia delivery machine; applying the second and third subset of rules to determine whether a hold start was detected includes: determining that a hold start was detected in response to the first of the following: (a) and (b) are true or (c) is true, wherein (a) includes the occurrence of a mechanical ventilation start event, (b) includes at least one valid value of end-tidal carbon dioxide (EtCO2), and (c) includes the following fresh gas flow pattern: two initial fresh gas flow values ​​are above a threshold, and the next five fresh gas flow values... At least three fresh gas flow rates are below the threshold, and a third fresh gas flow rate is below the threshold; applying the fourth and fifth rule subsets to determine whether awakening has been detected includes: determining that awakening has been detected in response to the first of the following: (d) and (e) are true or (f) is true, wherein (d) includes a mechanical ventilation termination event that occurs and is observed for the threshold time amount, (e) excludes cardiac bypass mode, and (f) includes both of the following being true: an increase in O2 percentage, an increase in fresh gas flow rate, and the termination of anesthetic delivery; and applying the sixth rule subset to determine whether case termination has been detected includes: determining that case termination has been detected in response to the start of a second standby event of the anesthesia delivery machine.In a third example of the system, one or both of the first and second examples are optionally included, the second and third rule subsets are applied in parallel, and the fourth and fifth rule subsets are applied in parallel. In a fourth example of the system, one or more or each of the first to third examples are optionally included. Updating the GUI to display the second visual representation of the new phase based on the detection and determination of the event as a real event includes: if a case start is detected, determining that the case start is a real event, and updating the GUI to display the second visual representation indicating that the patient is currently in induction, regardless of the previously determined phase of anesthesia delivery; if a hold start is detected, determining that the hold start is a real event, and updating the GUI to display the second visual representation indicating that the patient is currently in hold ... If the start of awakening is detected during the holding period, it is determined that the start of awakening is a real event, and the GUI is updated to display the second visual representation indicating that the patient is currently awake; if the start of awakening is detected during induction, it is determined that the start of awakening is not a real event, and the first visual representation is maintained on the GUI; if the end of case is detected, it is determined that the end of case is a real event, and the GUI is updated to display the second visual representation indicating that the patient is currently at the end of case, regardless of the previously determined stage of anesthesia delivery; and if no case start, holding start, awakening start, or case end is detected, the first visual representation is maintained on the GUI. In a fifth example of the system, optionally one or more or each of the first to fourth examples is included, the event being case end, and in response to the detection of case end, the case is marked as completed and a subset of the seventh rules is applied to retrospectively update the timing and / or occurrence of one or more stages of anesthesia delivery for the case. In a sixth example of the system, optionally including one or more of the first to fifth examples, applying the seventh subset of rules to retrospectively update the timing and / or occurrence of one or more stages of anesthesia delivery for the case includes: if more than one instance of a given type of event is detected during the case, selecting one instance of the given type of event as a valid event, and updating the timing of the stage corresponding to the given type of event; and if no instance of a given type of event is detected during the case, adding the given type of event and updating the occurrence of the stage corresponding to the given type of event.In a seventh example of the system, one or more or each of the first to sixth examples may be included, wherein the event of the given type is a hold start, such that if more than one instance of a hold start is detected during the case, one instance of a hold start is selected as the valid event, wherein selecting the one instance of a hold start includes: if the duration of the case is greater than a threshold duration, then selecting the last instance of a hold start that occurred during a first time period of the case. In an eighth example of the system, one or more or each of the first to seventh examples may be included, wherein adding a hold start to the case if no instance of a hold start is detected during the case includes: if the duration of the case is within a threshold range, then designating a first predefined time amount since the case start as a hold; and if the duration of the case is greater than the threshold range, then designating a second predefined time amount since the case start as a hold, the second predefined time amount being greater than the first predefined time amount. In a ninth example of the system, one or more or each of the first to eighth examples may be included, wherein the event of the given type is awakening start, such that if more than one instance of awakening start is detected during the case, one instance of awakening start is selected as the valid event, wherein selecting the one instance of awakening start includes: if the duration of the case is greater than a threshold duration, selecting the first instance of awakening start that occurred during the last time period of the case; and if the duration of the case is greater than the threshold duration and no instance of awakening start is detected during the last time period of the case, selecting the last instance of awakening start detected during the case. In a tenth example of the system, one or more or each of the first to ninth examples may be included, wherein adding an awakening start to the case if no instance of awakening start is detected during the case includes: determining the time to end the delivery of anesthetic to the patient, and adding an awakening start at the determined time.

[0169] This disclosure also provides support for a system comprising: one or more processors, and a memory storing instructions executable by the one or more processors to: output a graphical user interface (GUI) for displaying on a display device a plurality of timelines including anesthesia delivery stages, each timeline depicting an anesthesia delivery stage as a function of time for a corresponding patient among a plurality of patients; receiving, within a first observation window, a plurality of monitoring parameters for a first patient among the plurality of patients, at least a portion of the plurality of monitoring parameters being obtained from an anesthesia delivery machine; and, based on the plurality of monitoring parameters within the first observation window, in real time and without knowing the current or previous stage of anesthesia delivery for the first patient, identifying and signaling a change to a new stage of anesthesia delivery for the first patient. The system defines a first event, which is one of case start, maintenance start, awakening start, and case end. Based on the detection of the first event, the GUI is updated to add the new phase to a first timeline of multiple timelines, which represents the anesthesia delivery phase of the first patient. A second event is identified based on multiple monitoring parameters of the first patient within a second observation window. Based on the first and second events, it is determined whether the first or second event is a false positive event. If the first or second event is a false positive event, the GUI is updated to adjust the first timeline to reflect the false positive event. If the first or second event is not a false positive event, the GUI is updated to add another new phase to the first timeline. In a first example of the system, executing the instructions to identify the detection of the first and / or second event includes: applying a first subset of rules to determine whether case start was detected; applying a second and a third subset of rules to determine whether maintenance start was detected; applying a fourth and a fifth subset of rules to determine whether awakening start was detected; and applying a sixth subset of rules to determine whether case end was detected.In a second example of the system, optionally including the first example, applying the first subset of rules to determine whether a case start is detected includes: determining that a case start is detected in response to the end of a first standby event of the anesthesia delivery machine; applying the second subset of rules and the third subset of rules to determine whether a hold start is detected includes: determining that a hold start is detected in response to the first of the following: (a) and (b) are true or (c) is true, wherein (a) includes the occurrence of a mechanical ventilation start event, (b) includes at least one valid value of end-tidal carbon dioxide (EtCO2), and (c) includes the following fresh gas flow pattern: two initial fresh gas flow values ​​are above a threshold, and the next five fresh gas flow values ​​are above a threshold. At least three fresh gas flow rates are below the threshold, and a third fresh gas flow rate is below the threshold; applying the fourth and fifth rule subsets to determine whether awakening has been detected includes: determining that awakening has been detected in response to the first of the following: (d) and (e) are true or (f) is true, wherein (d) includes a mechanical ventilation termination event that occurs and is observed for the threshold time amount, (e) excludes cardiac bypass mode, and (f) includes both of the following being true: an increase in O2 percentage, an increase in fresh gas flow rate, and the termination of anesthetic delivery; and applying the sixth rule subset to determine whether case termination has been detected includes: determining that case termination has been detected in response to the start of a second standby event of the anesthesia delivery machine.

[0170] This disclosure also provides support for a method comprising: outputting a graphical user interface (GUI) for displaying on a display device a plurality of timelines including anesthesia delivery stages, each timeline depicting an anesthesia delivery stage as a function of time for a corresponding patient among a plurality of patients; receiving, within a first observation window, a plurality of monitoring parameters for a first patient among the plurality of patients, at least a portion of the plurality of monitoring parameters being obtained from an anesthesia delivery machine; based on the plurality of monitoring parameters within the first observation window, identifying, in real time and without knowing the current or previous stage of anesthesia delivery for the first patient, a first event signaling a change to a new stage of anesthesia delivery for the first patient, wherein the first event is one of case start, maintenance start, awakening start, and case end; updating the GUI based on the detection of the first event to add the new stage to a first timeline among the plurality of timelines, the first timeline representing an anesthesia delivery stage for the first patient; identifying a second event for the first patient based on the plurality of monitoring parameters within a second observation window; determining, based on the first event and the second event, that the first event or the second event is a false positive event; and, in response, updating the GUI to adjust the first timeline to reflect the false positive event. In a first example of the method, the first event is the start of awakening, the new phase is awakening, and the second event is the start of maintenance. Determining whether the first event or the second event is a false positive event based on the first event and the second event includes: determining that the start of awakening is the false positive event based on detecting the start of maintenance after the start of awakening is detected, and updating the GUI to adjust the first timeline to reflect the false positive event includes: removing awakening from the first timeline and extending the duration of maintenance on the first timeline. In a second example of the method, optionally including the first example, the first event is the start of maintenance, the new phase is maintenance, and the second event is the start of a case. Determining whether the first event or the second event is a false positive event based on the first event and the second event includes: determining that the start of maintenance is the false positive event based on detecting the start of a case after the start of maintenance is detected, and updating the GUI to adjust the first timeline to reflect the false positive event includes: removing maintenance from the first timeline and plotting induction on the first timeline. In a third example of the method, optionally including one or both of the first and second examples, identifying the detection of the first event includes: applying a first subset of rules to determine whether a case start is detected in response to the end of a first standby event of the anesthesia delivery machine; applying a second and a third subset of rules in parallel to determine whether a hold start is detected; applying a fourth and a fifth subset of rules in parallel to determine whether an awakening start is detected; and applying a sixth subset of rules to determine whether a case end is detected in response to the start of a second standby event of the anesthesia delivery machine.In a fourth example of the method, one or more or each of the first to third examples may be optionally included, wherein the plurality of monitored parameters include one or more of the following: measured fractional oxygen inhalation (FiO2), measured end-expiratory CO2 (EtCO2), mechanical ventilation setup, measured inhaled anesthetic, measured exhaled anesthetic, fresh gas flow rate, cardiac bypass mode, and anesthesia machine standby status. In a fifth example of the method, one or more or each of the first to fourth examples may be optionally included, wherein the GUI includes: an operating room status panel indicating the total number of patients at each stage of anesthesia delivery, and wherein each of the plurality of timelines is color-coded to indicate a different stage of anesthesia delivery, including induction, maintenance, and awakening.

[0171] As used herein, elements or steps listed in the singular and beginning with the word "a" or "an" should be understood to not exclude multiple said elements or steps unless such exclusion is explicitly stated. Furthermore, references to "an embodiment" of the invention are not intended to be construed as excluding the existence of additional embodiments that also include the referenced features. Moreover, unless explicitly stated to the contrary, embodiments that "comprise," "include," or "have" elements or multiple elements having a particular characteristic may include additional such elements that do not have that characteristic. The terms "comprise" and "in" are used as concise linguistic equivalents to the corresponding terms "comprising" and "wherein." Furthermore, the terms "first," "second," and "third," etc., are used merely as notations and are not intended to impose numerical requirements or a particular order of position on their objects.

[0172] This written description uses examples to disclose the invention, including the best mode, and also enables those skilled in the art to practice the invention, including making and using any device or system and performing any included methods. The scope of patentability of the invention is defined by the claims, but may include other examples that would occur to those skilled in the art. Such other examples are intended to fall within the scope of the claims if they have structural elements that are not indistinguishable from the literal language of the claims, or if they include equivalent structural elements that have minor differences from the literal language of the claims.

Claims

1. A system for tracking the various stages of anesthesia delivery in a patient's medical record, the system comprising: One or more processors; and The memory stores instructions that can be executed by the one or more processors to: Output (802) for displaying a graphical user interface (GUI) on a display device, the graphical user interface (GUI) including a first visual representation of the default or previously determined stage of anesthesia delivery to the patient; (602) Receive multiple monitoring parameters of the patient within the observation window, at least a portion of which are obtained from the anesthesia delivery machine; By applying a set of rules to the plurality of monitoring parameters, it is identified (606) whether an event signaling a change to a new phase of anesthesia delivery to the patient is detected, wherein the event is one of case start, maintenance start, awakening start, and case end; The GUI is updated (617) to display a second visual representation of the new phase based on the fact that the event is detected and identified as a real event; as well as The first visual representation is maintained (810) on the GUI based on the fact that the event was not detected.

2. The system of claim 1, wherein executing the instructions to apply the rule set to identify whether the event has been detected comprises: Apply the first rule subset (702) to determine whether a case start has been detected; Apply the second and third rule subsets (704, 706) to determine whether a hold start is detected; Apply the fourth and fifth rule subsets (708, 710) to determine whether a wake-up start has been detected; as well as Apply the sixth rule subset of (712) to determine whether the case has ended.

3. The system according to claim 2, wherein: Applying (702) the first subset of rules to determine whether a case start has been detected includes: determining that a case start has been detected in response to the end of a first standby event of the anesthesia delivery machine; Applying (704, 706) the second subset of rules and the third subset of rules to determine whether a hold start is detected includes: determining that a hold start is detected in response to a first of the following: (a) and (b) are true or (c) is true, wherein (a) includes the occurrence of a mechanical ventilation start event, (b) includes at least one valid value of end-tidal carbon dioxide (EtCO2), and (c) includes the following fresh gas flow pattern: two initial fresh gas flow values ​​are above a threshold, at least three of the next five fresh gas flow values ​​are below the threshold, and a third fresh gas flow value is below the threshold; Applying the fourth and fifth rule subsets of (708, 710) to determine whether the start of awakening is detected includes: determining that the start of awakening is detected in response to the first of the following: (d) and (e) are true or (f) is true, wherein (d) includes the occurrence and observation of a mechanical ventilation termination event of a threshold time amount, (e) excludes cardiac bypass patterns, and (f) includes both of the following being true: an increase in O2 percentage, an increase in fresh gas flow rate, and the termination of anesthetic delivery; and Applying the sixth rule subset of (712) to determine whether case termination is detected includes: determining that case termination is detected in response to the start of a second standby event of the anesthesia delivery machine.

4. The system of claim 3, wherein the second rule subset and the third rule subset are applied in parallel, and wherein the fourth rule subset and the fifth rule subset are applied in parallel.

5. The system of claim 3, wherein updating the GUI to display the second visual representation of the new phase based on the event being detected and determined to be a real event comprises: If a case start is detected (808), the case start is determined to be a real event, and the GUI is updated (812) to display the second visual representation, which indicates that the patient is currently in induction, regardless of the previously determined stage of anesthesia delivery; If a hold start is detected (814), the hold start is determined to be a real event, and the GUI is updated (816) to display the second visual representation indicating that the patient is currently in a hold, regardless of the previously determined stage of anesthesia delivery; If the start of awakening is detected during the hold period (818, 820), it is determined that the start of awakening is a real event, and the GUI is updated (822) to display the second visual representation, which indicates that the patient is currently awake; If a wake-up start is detected during induction (818, 820), it is determined that the wake-up start is not a real event, and the first visual representation is maintained on the GUI (828). If case termination is detected (840), it is determined that the case termination is a real event, and (842) the GUI is updated to display the second visual representation indicating that the patient is currently in case termination, regardless of the previously determined stage of anesthesia delivery; and If none of the case start, hold start, awakening start and case end are detected, the first visual representation is maintained on the GUI (810).

6. The system of claim 3, wherein the event is case completion, and in response to detecting case completion, the case is marked as completed and a subset of the seventh rules (620) is applied to retrospectively update the timing and / or occurrence of one or more stages of anesthesia delivery for the case, wherein applying the subset of the seventh rules to retrospectively update the timing and / or occurrence of one or more stages of anesthesia delivery for the case comprises: If more than one instance of a given type of event is detected during the case, one instance of the given type of event is selected as the valid event, and the timing of the phase corresponding to the given type of event is updated. as well as If no instance of a given type of event is detected during the case, the given type of event is added, and the occurrence of the phase corresponding to the given type of event is updated.

7. The system of claim 6, wherein the event of the given type is a hold-on start, such that if more than one instance of hold-on start is detected during the case, one instance of hold-on start is selected as the valid event, wherein selecting the one instance of hold-on start comprises: If the duration of the case is greater than the threshold duration, then (906) the last instance that was kept starting during the first time period of the case is selected.

8. The system of claim 7, wherein adding a hold-on start to the case if no instance of a hold-on start is detected during the case comprises: If the duration of the case is within the threshold range, then the first predefined amount of time since the start of the case is designated (910) as the hold; as well as If the duration of the case is greater than the threshold range, then a second predefined time amount since the start of the case is designated (912) as a hold, the second predefined time amount being greater than the first predefined time amount.

9. The system of claim 8, wherein the event of the given type is the start of awakening, such that if more than one instance of the start of awakening is detected during the case, one instance of the start of awakening is selected as the valid event, wherein selecting the one instance of the start of awakening comprises: If the duration of the case is greater than the threshold duration, then select (916) the first instance of awakening that occurred during the last time period of the case; as well as If the duration of the case is greater than the threshold duration and no instance of awakening initiation is detected in the last time period of the case, then (918) the last instance of awakening initiation detected during the case period is selected.

10. The system of claim 9, wherein adding a wake-up start to the case if no instance of wake-up start is detected during the case comprises: Determine the time to end the delivery of anesthetic to the patient, and add (924) the start of awakening at the determined time.

11. A method, the method comprising: The output (802) is used to display a graphical user interface (GUI) (1000) on a display device, the graphical user interface (GUI) including multiple timelines (1010) of anesthesia delivery phases, each timeline depicting anesthesia delivery phases as a function of time for a corresponding patient among multiple patients; For the first patient among the plurality of patients, multiple monitoring parameters of the first patient are received (602) within a first observation window, at least a portion of the multiple monitoring parameters being obtained from the anesthesia delivery machine; Based on the multiple monitoring parameters within the first observation window, in real time and without knowing the current or previous stage of anesthesia delivery to the first patient, identify (606) a first event that signals a change to a new stage of anesthesia delivery to the first patient, wherein the first event is one of case start, maintenance start, awakening start and case end; The GUI is updated (617) based on the detection of the first event to add the new stage to a first timeline in the plurality of timelines, the first timeline representing the anesthesia delivery stage of the first patient; Based on the multiple monitoring parameters of the first patient within the second observation window, a second event of the first patient is identified and detected. Based on the first event and the second event, it is determined whether the first event or the second event is a false positive event, and in response, the GUI is updated to adjust the first timeline to reflect the false positive event.

12. The method of claim 11, wherein the first event is the start of awakening, the new phase is awakening, and the second event is the start of sustaining, wherein determining whether the first event or the second event is a false positive event based on the first event and the second event comprises: Determining that the start of awakening is a false positive event based on detecting the start of sustaining after the start of awakening is detected (830), and wherein updating the GUI to adjust the first timeline to reflect the false positive event includes: removing (834) awakening from the first timeline, and extending the duration of sustaining on the first timeline.

13. The method of claim 11, wherein the first event is a maintenance start, the new phase is maintenance, and the second event is a case start, wherein determining whether the first event or the second event is a false positive event based on the first event and the second event comprises: Determining that the start of the maintenance is a false positive event based on detecting the start of the case after the start of the maintenance (836) is detected, and wherein updating the GUI to adjust the first timeline to reflect the false positive event includes: removing (838) the maintenance from the first timeline, and plotting the induction on the first timeline.

14. The method of claim 11, wherein identifying the detection of the first event comprises: Apply (702) a first subset of rules to determine whether a case start is detected in response to the end of a first standby event of the anesthesia delivery machine; The second and third rule subsets (704, 706) are applied in parallel to determine whether a hold start is detected; The fourth and fifth rule subsets (708, 710) are applied in parallel to determine whether a wake-up start is detected; as well as The sixth rule subset of (712) is applied to determine whether the case end is detected in response to the start of the second standby event of the anesthesia delivery machine.

15. The method of claim 11, wherein the GUI comprises: Operating room status panel (1002), which indicates the total number of patients at each stage of anesthesia delivery; and Each of the plurality of timelines (1010) is color-coded to indicate different stages of anesthesia delivery, including induction, maintenance, and awakening.

Images