System and method for remote control of life-critical medical devices

Abstract

Systems and methods for remotely controlling life-critical medical devices are provided herein. In one example, a system includes a life-critical medical device communicatively coupled to a remote device and configured to supply a medical therapy to a patient, the life-critical medical device including a display and a memory storing instructions executable to: output, to the display, a graphical user interface (GUI) displaying a plurality of real-time machine settings of the life-critical medical device; in response to a first user input, display, via the GUI, a remote control panel including a session code usable to authenticate the remote device; and in response to receiving an indication from an access server that the remote device has been authenticated, display, on the GUI, a notification indicating that the life-critical medical device is currently controlled by the remote device.

Description

Systems and methods for remote control of life-saving medical devices

[0001] Cross-references to related applications

[0002] This application claims priority to Indian Patent Application No. 202041016573, filed on April 17, 2020. The entire contents of the above application are hereby incorporated by reference for all purposes. Technical Field

[0003] The implementation schemes disclosed in this article involve patient monitoring during perioperative care, and more specifically, remote control of life-threatening medical devices. Background Technology

[0004] Certain medical procedures, such as surgery, may require various subroutines to prepare the patient for surgery, maintain the patient under certain conditions during surgery (e.g., anesthesia), and assist the patient's recovery after surgery. These subroutines performed to support the main procedure are known as perioperative care. Perioperative care for patients in hospitals or other healthcare facilities may involve multiple patient monitoring devices monitoring multiple patients. Therefore, near-continuous monitoring from the outputs of multiple monitoring devices may be necessary to ensure a rapid response in case of deterioration in a patient's condition. Furthermore, coordinating patient care among all care providers can be complex or time-consuming, further depleting care provider resources. Additionally, presenting patient medical information to care providers may require multiple time-consuming and cumbersome information requests or searches. Summary of the Invention

[0005] In one embodiment, a system includes: a life-saving medical device communicatively connected to a remote device and configured to deliver medical treatment to a patient, the life-saving medical device including a display and a memory storing instructions executable to: output a graphical user interface (GUI) to the display, the GUI displaying multiple real-time machine settings of the life-saving medical device; display a remote control panel via the GUI in response to a first user input, the remote control panel including a session code capable of authenticating the remote device; and display a notification on the GUI indicating that the life-saving medical device is currently controlled by the remote device in response to receiving an indication from an access server that the remote device has been authenticated.

[0006] It should be understood that the above brief description is provided to introduce selected 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 embodiments that address any shortcomings mentioned above or in any part of this disclosure. Attached Figure Description

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

[0008] Figures 1A and 1B schematically illustrate exemplary systems for perioperative care and monitoring, including a monitoring application.

[0009] Figures 2 through 4 illustrate exemplary display devices that display various views of a single patient graphical user interface generated via a monitoring application.

[0010] Figure 5 schematically illustrates an exemplary system for authenticating remote devices configured to remotely control life-threatening medical devices.

[0011] Figures 6 and 18 show exemplary views of a graphical user interface displayed on a life-threatening medical device (an anesthesia machine in this context).

[0012] Figures 7 to 9 are flowcharts illustrating exemplary methods for authenticating remote devices used to change settings on life-threatening medical devices, from the perspectives of a life-threatening medical device, a remote device, and a dedicated access server, respectively.

[0013] Figure 10 shows an exemplary view of a graphical user interface displayed by a life-saving medical device located at a point of care.

[0014] Figure 11 shows an exemplary view of a graphical user interface displayed within the GUI of a life-threatening medical device, which shows a notification indicating that a remote session has been activated.

[0015] Figure 12 shows an exemplary view of different modes for obtaining a session / access code in order to authenticate a remote session via a graphical user interface displayed on a remote device.

[0016] Figure 13 is an exemplary view of a graphical user interface displayed on a remote device, where parameter settings in an indoor life-saving medical device can be adjusted.

[0017] Figures 14 and 15 are flowcharts illustrating exemplary methods for requesting settings changes on a life-or-death medical device via a graphical user interface displayed on a remote device, respectively, from the perspectives of a remote device and a life-or-death medical device.

[0018] Figure 16 shows an exemplary view of a notification requesting settings changes on the graphical user interface displayed on a life-saving medical device.

[0019] Figure 17 shows an exemplary view of a settings change notification displayed in a graphical user interface on a remote device. Detailed Implementation

[0020] Implementations of the systems and methods disclosed herein facilitate remote control of one or more life-threatening medical devices (such as anesthesia machines) from a remote device. As used herein, a remote device may refer to a computing device that can be remotely operated from (e.g., operated in a different room) and communicatively connected to the life-threatening medical device. The remote device may be operated by a clinician (such as a supervising anesthesiologist). To enable a remote device to remotely control a life-threatening medical device, an authentication routine requiring the remote device to be near the life-threatening medical device can be used, such as by authenticating the remote device using a session code generated at the life-threatening medical device and displayed on the life-threatening medical device. Once control of the life-threatening medical device has been transferred to the remote device, the user of the remote device can directly change the desired settings of the life-threatening medical device from the remote device. By using an authentication routine requiring proximity to the life-threatening medical device, security issues associated with remote authentication can be avoided.

[0021] Remote control of life-critical medical devices can be facilitated by a monitoring application that can also be operated to facilitate perioperative care for multiple patients and monitoring of multiple care providers caring for multiple patients. To facilitate the perioperative care and monitoring described herein, systems and methods disclosed herein collect and process a wide variety of medical device data. Medical device data includes physiological data acquired by the medical device from the patient (also known as patient monitoring data) 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 also include settings and values ​​representing specific actions taken with the medical device, for example, in response to automated control 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 also 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 formats. 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 improved monitoring systems and methods as 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. While all medical device data can be stored for retrospective and automated machine learning and analysis, event detection and tagging can be used to create additional exemplary files of medical device data derived from specific events or conditions, which can be used as exemplary or case study data for further analysis.

[0023] Medical device data can be provided to one or more care providers, such as supervising anesthesiologists, nurse anesthesiologists, and other care providers. Specifically, medical device data can be provided to supervising anesthesiologists or other supervising care providers via a supervisory application that facilitates the presentation of medical device data in real-time or near real-time via one or more graphical user interfaces (GUIs) that can be displayed on the supervising care provider's device, such as a mobile device (e.g., a smartphone, tablet, wearable device). The supervisory application can facilitate the display to the supervising care provider 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 GUI, allowing the supervising care provider to easily monitor the patient status of each patient, even if the care provider is geographically distant from the patient. When additional information for a specific patient is required, the supervisory application can generate a single-patient GUI that provides more detailed medical device data for that patient.

[0024] The monitoring application can also monitor patient status via medical device data and output various notifications, such as alarms, when the patient's status changes or when specified patient monitoring parameters or combinations of parameters (such as blood oxygenation) reach or change over time, relative to predefined conditions (e.g., drop below a threshold). The monitoring application can also facilitate communication between the supervising care provider and one or more subordinate care providers, who may be in the same room as the patient, while the supervising care provider is located in a different room or area within the healthcare facility. For example, a subordinate care provider may send a request for a consultation by the supervising care provider via the in-room GUI of the monitoring application running on the subordinate care provider's device. The supervising care provider's device can receive the request and output it to the supervising care provider via the monitoring application's GUI. The in-room GUI can also facilitate text or voice messaging between the subordinate care provider and the supervising care provider.

[0025] The monitoring application can also generate a trend GUI that can be output on the monitoring care provider's device. Through the trend GUI, the monitoring care provider can assess changes in medical device data over time for multiple selected patient monitoring parameters. The trend of each selected patient monitoring parameter can be displayed simultaneously in a time-ordered manner. Furthermore, the relative change of each patient monitoring parameter over a specified duration can be determined and displayed in response to a single user input.

[0026] The various GUIs and functionalities of the aforementioned monitoring applications allow a single supervising care provider 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 a patient's anesthesia induction phase, which may require the supervising anesthesiologist to be present in the operating room with the patient during this time. However, the supervising anesthesiologist may also care for six other patients in the anesthesia maintenance phase, each of whom is monitored by a nurse anesthesiologist in the room. If one of these six other patients experiences an event requiring the supervising anesthesiologist's care, there may be a delay between when the supervising anesthesiologist receives notification of the event and when the supervising anesthesiologist can actually arrive to care for that patient. However, through the monitoring application described herein, supervising care providers may be able to monitor the patient status of all patients from any location and may be able to remotely adjust vital medical device settings and / or instruct subordinate care providers. This could improve patient care.

[0027] Supervisory applications facilitate the display of real-time medical device data acquired and / or determined by multiple medical devices monitoring multiple patients. This real-time medical device data can be displayed via various graphical user interfaces (GUIs). As an example, a single-patient GUI can be displayed on a care provider's device (e.g., a mobile phone, tablet, and / or wearable device). Through this single-patient GUI, the patient's real-time medical device data can be displayed via multiple patient monitoring parameter tiles. These multiple patient monitoring parameter tiles can be scalable, modular, and customizable by the user and / or the supervisory application to allow for convenient customizability and ease of adding new patient monitoring parameters / medical device data in the future. For example, a user of the supervisory application (e.g., a care provider such as an anesthesiologist) can create a set of rules or algorithms (wherein these rules or algorithms may be referred to as insights) that can be executed using real-time medical device data to determine outcomes (e.g., determination of procedural phases, prediction of patient status, recommended action procedures, etc.) or notification of patient status. When a user selects to apply the insight, the results are then displayed as tiles on a patient-specific GUI. Other patient monitoring parameter tiles on the patient-specific GUI can be adjusted (e.g., moved, resized, scaled, etc.) to fit the new insight result tiles. As another example, a user can choose to include live video feeds from the patient's room as tiles in a single patient GUI (more variety), which may require relatively large tiles. Remaining tiles can be rearranged (either automatically or in response to the user) to fit the larger tiles.

[0028] The monitoring application may also include a machine settings GUI, which may resemble or be considered part of a single-patient GUI. In the machine settings GUI, users of the monitoring application can view the current settings of the life-threatening medical device. In some examples, users of the monitoring application may be able to directly control a specific life-threatening medical device via the machine settings GUI (e.g., when a remote device is authenticated for direct control of the life-threatening medical device). For example, the machine settings GUI may include settings tiles, each indicating the current value of the corresponding machine setting. Selection of a settings tile may trigger the display of multiple associated value tiles, which may display other possible values ​​for the selected machine setting. Selection of a value tile (and confirmation of the selection) may result in a command to adjust the selected setting to the selected value for transmission to the life-threatening medical device, which may automatically adjust the selected setting in response to the command. In some examples, selection of a value tile may result in a request to adjust the selected setting to the selected value for transmission to the life-threatening medical device, and then display the request on the life-threatening medical device so that the attending clinician can accept or reject the request to modify the setting. In this way, life-saving medical devices can be controlled directly or indirectly from a remote location, depending on specific security needs, medical protocols, patient conditions / treatment status, etc.

[0029] In addition to ensuring that security is not compromised while allowing remote control of life-saving medical devices, the systems and methods described herein can reduce or avoid errors that could otherwise occur during handover between life-saving medical devices and remote devices, or when more than one clinician attempts to control a life-saving medical device. For example, real-time medical device data relevant to a patient connected to the life-saving medical device can be provided to the user of the remote device via the monitoring application described herein during authentication and handover. This real-time medical device data may include the current settings for the life-saving medical device, such that if any changes are made to the device settings before authentication and handover of the remote device are completed, these changes will be presented to the user of the remote device, ensuring that the remote device always displays the current medical device settings, thereby avoiding any potential problems associated with presenting inaccurate / outdated device settings to the user. This real-time medical device data may also include monitored patient parameters determined by other medical devices (e.g., those other than the life-saving medical device). In this way, the user of the remote device may be able to make decisions about patient care based on a complete picture of the patient's condition, including whether to adjust any settings on the life-saving medical device. As another example, control of a life-saving medical device can only be granted to a single device at a time. For example, control of a life-threatening medical device may be exercised only at the device itself until a remote device is authenticated and control is transferred to it. At this point, the life-threatening medical device may be controlled solely by the remote device. To return control to the life-threatening medical device, control of the remote device can be revoked via input to the device (and at least in some examples, not via input to the remote device). In some implementations, control of the remote device may also be revoked via the remote device itself (e.g., via user input to the remote device) and confirmed by the user (e.g., the attending clinician) on the treatment unit. By requiring the user to transfer and / or confirm remote control at the life-threatening medical device, unintended switching when the clinician is absent and unable to monitor / control the device can be avoided. Furthermore, the authentication process described herein allows only one user / remote device to remotely control the life-threatening medical device at a time, preventing conflicts of control over the device.

[0030] The systems and methods described below are presented specifically with respect to a monitoring application configured for a clinician, such as a supervising anesthesiologist, who monitors medical procedures such as anesthesia delivery during surgery. Therefore, the systems and methods are presented below with respect to an anesthesia delivery machine as an example of a life-threatening medical device. However, the systems and methods provided herein can be applied to other life-threatening medical devices without departing from the scope of this disclosure, such as dialysis machines, ventilators, drug delivery machines, infusion pumps, etc.

[0031] Figures 1A and 1B depict exemplary implementations of system 10 for perioperative care and supervision. Referring first to Figure 1A, 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 intended to be limiting. For example, it is conceivable that any or all of the MDD processing system 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.

[0032] In any embodiment of the software and / or firmware specific implementation as described in any of the claims, at least one of the elements is thereby explicitly defined as including a tangible and non-transitory computer-readable medium. As used herein, the term tangible computer-readable medium 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 medium is explicitly defined as including any type of computer-readable medium and excluding propagated signals.

[0033] 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.

[0034] 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, a wide area network (WAN); a local area network (LAN); 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 it and allows the system or parts thereof to communicate with one or more computing devices.

[0035] Hospital network 14 may be exemplarily a network associated with a part of a hospital (e.g., a surgical ward or department of the hospital), or it may be more broadly located across medical devices throughout the hospital. It will also be 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 ward within 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 that are unrelated to each other.

[0036] As depicted in Figure 1A, the 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, heart rate monitors, blood pressure and oxygenation monitors, respiratory monitors, ECG monitors, EEG monitors, or EMG monitors. For the purposes of discussion, exemplary embodiments of anesthesia delivery machines will be used as medical devices, and more specifically, as patient treatment devices 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 further, non-limiting examples of patient treatment devices (also referred to herein as life-saving medical 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 anesthesia delivery machines may include a gas analysis module capable of operating to measure the concentration of gases exhaled by a 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. Further examples of medical devices may include video and / or audio recording devices.

[0037] In an exemplary embodiment, the limited-type MDD processing system 12 described herein may be implemented, for example, locally as an anesthesia delivery management system 18. In such an embodiment, 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 to quantify, monitor, and evaluate trends across all anesthesia delivery machines in a hospital or surgical ward.

[0038] 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 an exemplary embodiment, 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).

[0039] 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.

[0040] Edge device 20 encrypts time-series formatted 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 exemplary 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 ingestion module 22 can receive concurrent data streams from multiple connected devices across multiple sites at a high inbound rate (e.g., at or near the frequency at which the medical device can output data). In an exemplary embodiment, the high-speed ingestion module 22 is able to extend the bandwidth to continue ingesting medical device data without significantly reducing the ingestion rate.

[0041] High-speed 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 ingestion module 22 supports open standards such as ASTM F2761 or Integrated Clinical Environment (ICE). Data quality management module 24 can normalize, enrich, and tag 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 File 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 an exemplary embodiment, medical device data may be normalized to ISO / IEEE 11073-10101 naming and its extensions. In yet another exemplary embodiment, the data quality management module 24 may normalize incoming time-series data streams by converting measurement wards. The data quality management module 24 can also be 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.

[0042] In an exemplary implementation, 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 the medical device, which may be waveform or binary format, audio data, image data, and / or video data. In this implementation, 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.

[0043] 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.

[0044] 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 include, for example, surgical and intensive care unit (ICU) cases. Clinical cases can be identified by the medical devices used and the temporal sequence of medical data in the time-series of 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 anesthetic.

[0045] 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.

[0046] 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 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 medical devices during the clinical case.

[0047] 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.

[0048] Medical device data associated with the actions of the anesthesia delivery device and / or other medical devices during the identified clinical case may be stored in the operation case database 30. In one example, the identification of the 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 operation case database 30.

[0049] In one implementation, before storing clinical cases in a clinical case database 30, the clinical cases may be classified or profiled using techniques for data curation. The profile analysis of clinical cases may be based in part on information in the clinical case summary and, as described further herein, may be used to group clinical cases into groups such as normal cases, marginal cases, and anomalous cases. These determinations may be made based on a comparison between the time-series data in the clinical cases and a normal distribution of the same type of time-series machine data in other similar clinical cases. Marginal cases may be identified as boundary-line or ambiguous cases, not explicitly defined as normal or anomalous values. In an implementation that is merely exemplary, the distribution of incidence rates may be used to establish normal, marginal, and anomalous cases for a specific measurement or incidence rate. In an implementation that is merely exemplary, normal cases may be within the standard deviation of the median in a normal distribution, while marginal cases may be between one and two standard deviations, and anomalous cases may deviate from the median by more than two standard deviations. Classified cases, as explained further herein, may be further studied, for example, to create or improve event detection algorithms, clinical decision support rules, alerting algorithms, and prediction algorithms.

[0050] The stream processing engine 28 also identifies events in the time-series stream of medical device data, for example in a manner described further in detail herein, and presents them as a business intelligence and visual analytics tool 32, which may, exemplarily, be presented on a graphical display communicatively connected to the medical device data processing system 12.

[0051] 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 also 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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 test events in the machine data stream and log these identified test events according to test schedules, requirements (e.g., daily), or other criteria.

[0056] The monitoring application 44 can be used by attending and / or supervising anesthesiologists to more effectively manage remote personnel, nurse anesthesiologists, and / or other care providers working simultaneously in multiple locations or operating rooms. The alarm management application 46 can report and present medical device data regarding alarm notifications and the silence of alarm notifications 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.

[0057] 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).

[0058] The monitoring application 44 allows users (e.g., clinicians such as anesthesiologists, nurses, and other care providers) to view ventilation, anesthesia, and vital signs of multiple patients in different locations (e.g., different operating rooms) on various 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 care provider device 134 shown in Figure 1B) using a suitable visualization platform.

[0059] Figure 1B schematically illustrates an exemplary device of system 10, through which a supervisory application can be executed, including an edge device 20 that communicates with multiple care provider devices 120 via hospital network 14 and also with MDD processing system 12.

[0060] As mentioned above, edge device 20 receives medical device data from medical device 16. The medical device data received by edge device 20 can be ingested by data ingestion module 102, which may be similar to ingestion module 22 in FIG. 1A, and stored in data storage 104. Data storage 104 may be a temporary data storage device, in which the received data is temporarily stored rather than permanently stored. (The received data (such as medical device data from medical device 16) can be sent to MDD processing system 12 for long-term storage). Furthermore, the received medical device data can be distributed to various microservices on edge device 20 to implement aspects of the supervisory application 44, including stream processing module 106, rule engine 108, inference engine 110, event notification service 112, streaming server 114, and cloud gateway 116.

[0061] 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 supervising 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 patient monitoring parameters (e.g., ECG, heart rate, blood oxygenation), procedure phases (e.g., induction, maintenance, and awakening), alarms, anesthesia machine settings, and other relevant or selected information, such as those determined by received medical device data, to the user (e.g., the supervising anesthesiologist) 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.

[0062] 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) and a GUI displaying more detailed information about a 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 and insights to apply, and other parameters of the GUI used to present the above information, such as the layout of each GUI. Additionally, via the monitoring application 44, users can request changes to the settings of medical devices (such as anesthesia machines) currently monitoring and / or delivering treatment to the patient.

[0063] The graphical user interface generated by the monitoring application 44 can be displayed on one or more suitable display devices associated with the respective care provider device and / or medical facility management device. As shown in Figure 1B, multiple care provider devices 120, from the first care provider device 134, the second care provider device 136, up to the nth care provider device 138, can be included as part of a hospital network 14 and can be communicatively connected to the edge device 20 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 the medical facility and substantially fixed in an appropriate location (such as in a nurses' station or a patient's room) and / or located locally or remotely within the medical facility and configured to move with the care provider (such as a care provider's mobile device).

[0064] When the care provider views the graphical user interface generated by the monitoring application 44 via the monitor of the care provider 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 device and sent to the edge device 20. In examples where the user input is the 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.

[0065] The devices disclosed herein (such as aspects of care provider devices and / or edge devices 20) may each include a communication module, a memory, and a 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.

[0066] 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., wired local area network (LAN), wireless LAN, wide area network (WAN), etc.) It communicates via USB 2.0, USB 3.0, etc.

[0067] 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 interconnected via an interconnect bus.

[0068] 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 illustrated in the figures can represent hardware that operates based on software or hardwired instructions, software that instructs the hardware to perform operations, or a combination thereof.

[0069] 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. Alternatively or additionally, one or more of these devices can be hardwired to logic circuitry to perform these operations.

[0070] One or more of the devices described herein may be implemented via the cloud or other computer networks. For example, edge device 20 is shown in Figure 1B as constituting a single entity, but it should be understood that edge device 20 may be distributed across multiple devices, such as across multiple servers.

[0071] The monitoring application 44 can provide various data, notifications, and messages to the multiple care provider devices 120. 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 to the multiple care provider devices 120 from event notification service 112 via MDD processing system 12 or another cloud-based service.

[0072] 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 recently determined values ​​or waveforms of real-time patient monitoring parameters, such as heart rate, oxygen saturation, respiratory rate, etc., obtained from medical devices. When the edge device 20 receives medical device data, some or all of the medical device data can be processed by the streaming 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 (e.g., as shown in Figures 2 and 4 and explained in more detail below) displaying 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 rule-based streaming analytics algorithms that apply windowing functions (slide, scroll, jump, etc.) for waveform analysis and event detection to trigger alerts, surgical phase detection, stream analysis, triage algorithms, etc. Furthermore, the stream processing module 106, connected to the inference engine 110, can perform predictions (such as continuous predictive scoring, patient deterioration scoring), calculate risk indices, identify early signs of disease, predict sepsis, respiratory distress attacks, case closure prediction, and provide general clinical decision support.

[0073] 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 edge device 20. Edge device 20 may include, for example, a Representational State Transfer (REST) ​​server that can receive data requests from care provider device 120 and respond to data requests by commanding streaming server 114 to stream selected medical device data to the requesting care provider device. Streaming server 114 may maintain a stateful session (e.g., WebSocket) with each client (e.g., care provider device). Medical device data may be adjusted (transformed and filtered) before being streamed to the client devices.

[0074] Data requests from care provider device 120 may also include requests for historical data (e.g., previous or non-real-time patient monitoring parameter values). Historical data may include trends in selected patient monitoring parameters over time. For example, a trend graphical user interface may be displayed on the care provider device as part of a monitoring application 44 that displays the values ​​of the selected patient monitoring parameters over time as trend lines. Trend lines may be collected from stored medical device data (e.g., stored in data storage 104). When a user requests to view the trend graphical user interface on the care provider device, the care provider device may send a request for a trend line to be displayed on the trend graphical user interface to edge device 20, and edge device 20 may obtain the trend line from data storage 104 or may obtain relevant stored medical device data and may collect the trend line at different locations (e.g., by the care provider device).

[0075] In some examples, users can communicate with each other via the monitoring application 44. For example, an in-room graphical user interface may be displayed as part of the monitoring application 44 on the care provider device. The in-room graphical user interface may include a message view, where a care provider (e.g., a nurse) in the room with the patient can communicate, for example, via text messages with another care provider (e.g., an anesthesiologist) located outside the room. Messages sent and received via the monitoring application can be routed via the edge device 20 and / or the MDD processing system 12. For example, a first care provider device (e.g., care provider device 134) may send a message intended for a second care provider device (e.g., care provider device 136). This message may be sent from the first care provider device to the edge device 20, and the messaging module of the edge device 20 may receive the message, determine the intended receiving care provider device, and send the message to the intended care provider device (e.g., the second care provider device).

[0076] 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 specific patient's oxygen saturation dropping below a threshold saturation). For example, an alarm tile may be displayed as part of a single-patient or multi-patient graphical user interface of the monitoring application 44, where the alarm tile includes an indication of how many alarms have been triggered for a specific patient, where a medical device generates an alarm in response to determining that a specific patient's patient monitoring parameter has reached a predefined condition relative to a threshold.

[0077] The aforementioned alarms can be triggered by medical devices monitoring the patient. For example, a pulse oximeter can monitor the patient and send SpO2 data directly or via an anesthesia delivery machine to edge device 20. If the patient's oxygen saturation drops below a threshold, the pulse oximeter and / or anesthesia delivery machine can send a notification to edge device 20 indicating that the patient's SpO2 value has fallen below the threshold. Edge device 20 can send alarm notifications to the care provider's device that is caring for the patient via event notification service 112 and / or cloud gateway 116. For example, generated alarms can be sent directly or via cloud gateway 116 to the appropriate care provider's device via event notification service 112, which can push the alarms (and other notifications generated by edge device 20, as explained in more detail below) to the appropriate care provider's device via MDD processing system 12, even when the monitoring application 44 is not running on the care provider's device.

[0078] As mentioned above, the supervisory application 44 is configured to apply insights to received medical device data to provide user-selected notifications, predictions, etc., regarding patient status. Insights may include rule-based streaming analytics algorithms (e.g., waveform analysis and event detection to trigger alerts, detection of surgical stages, streaming analytics, triage algorithms, continuous predictive scoring, patient deterioration scoring, calculation of risk indices, identification of early signs of disease, sepsis prediction, respiratory distress episodes, case closure prediction, and clinical decision support) executed by the aforementioned streaming processing module 106 and / or inference engine 110. Insights may include artificial intelligence-based models, such as machine learning or deep learning models. Generally, any algorithm, model, or set of rules that can be applied to medical device data to monitor patient status can be considered an insight. In some examples, particularly where insights require significant processing power, insights may be stored / executed on cloud-based devices such as the MDD processing system 12.

[0079] In some examples, insights can be defined and saved as a set of rules by the user based on predefined sets of parameters and predefined sets of operators. The predefined set of parameters may include all patient monitoring parameters (including physiological data and machine parameters / settings) available to the system (e.g., all patient monitoring parameters that can be measured, inferred, or otherwise determined from medical device data). When a parameter is selected (e.g., when a patient monitoring parameter is selected), a predefined range (e.g., time series) may be presented to the user to select whether to restrict the insight to a specific procedure, time series, etc. Furthermore, when a parameter is selected, a predefined or adjustable threshold may be presented to the user to be applied to that parameter. The predefined set of operators may include "and" operators, "or" operators, "while" or "during" operators, and / or any other suitable operators that allow the user to combine multiple parameters in an insight or allow the user to select only one parameter for that insight.

[0080] The rule engine 108 may include resources (e.g., memory and processors) allocated to the edge device 20 for storing and applying groups of insight rules, which may resemble alarms but may be multimodal and / or multiparameter-based. Insights may be user-customized / defined. Insight rules may define the conditions and scope of each insight. For example, an insight may include conditions defining patient monitoring parameters and corresponding thresholds that can trigger an insight notification, such as a patient heart rate above 150 heartbeats / minute. Insights may also include scopes, which may be time-based or procedural limitations regarding when the conditions of an insight will trigger a notification or outcome. For example, the scope may define parameters that will be applied during its process, such as how long the condition will last before triggering an insight notification (e.g., five minutes), at what stage of the procedure the condition will occur to trigger the insight notification (e.g., during the maintenance phase of anesthesia delivery), etc. As explained above, users can define conditions and scopes from a predefined set of parameters, and if more than one condition is required in an insight, users can select operators from a predefined set of operators. When an insight includes multiple conditions, after selecting an operator such as "and" or "or", the user can select another parameter from the parameter group.

[0081] Insight rules can be customized by users, thus defining which users (and therefore which care provider devices) will receive which insight notifications. Edge device 20 can distribute medical device data streams to rule engine 108, and rule engine 108 can apply stored insight rules to the incoming medical device data streams to determine whether any insight notifications or results should be generated. If an insight notification is to be generated, it can be generated and sent to the appropriate care provider device via event notification service 112 and / or cloud gateway 116.

[0082] In some examples, an insight may include the result of another insight as input. For instance, a first insight may include an algorithm that determines the current stage of anesthesia delivery for the anesthesia delivery machine. The output / result of the first insight may be displayed as tiles on the GUI of a monitoring application displayed on the care provider's device, as explained in more detail below. The result of the first insight may also be used as input for a second insight, along with medical device data. For example, the second insight may specify that a notification is output when a selected patient monitoring parameter value reaches a threshold (or when a change in a selected patient monitoring parameter over a specific time period reaches a threshold) if the result from the first insight indicates that the patient is in the maintenance phase of anesthesia delivery. Users may choose to include the result of an insight as input to another insight via the predefined parameter set described above. For example, when a user creates an insight or applies an insight created by another user, that insight may be included in the predefined parameter set.

[0083] Furthermore, insights can be shared with other users at other healthcare facilities and / or other users at other healthcare facilities. Therefore, insight rules can be stored at MDD processing system 12 upon request. The insight graphical user interface of the supervisory application 44 can be displayed on the care provider's device upon request. Through the insight graphical user interface, users can search for user-defined insights from other healthcare facilities and / or user-defined insights from the same healthcare facility where the user resides, as well as view user-defined insights. If a user selects to apply an insight, a notification that the insight has been selected can be sent to rule engine 108 and / or inference engine 110 and saved as an insight rule to be applied to that user.

[0084] The inference engine 110 can be used with artificial intelligence (AI)-based models (such as trained deep learning models) to process incoming data and draw conclusions (insights) from facts and rules contained in various machine learning models. The inference engine 110 can be a runtime engine for AI-based algorithms, such as the prediction of disease symptoms, and these will be part of the inference engine 110. Additionally, deep learning and / or learning networks can reside in the cloud (e.g., MDD processing system 12) to train the algorithms, requiring extremely high computational and resource requirements.

[0085] As explained above, through the insight engine features of the supervised application 44, users can create their own rules / algorithms to generate insights based on their pre-configured settings from the user interface and currently available data. The insight engine uses streaming and applies windowing functionality to generate insights. These insights can then be notified to the appropriate user using the event notification service 112 based on the user's configuration (e.g., insights subscribed to by the user). The available data for creating rules can include raw machine data or the results of AI algorithms driven by the inference engine 110 (e.g., another insight).

[0086] When users create their own insights (e.g., rules / algorithms) through the Insights Engine, they have the opportunity to share those insights with other users, allowing them to adopt and use the same insights. For example, a user can share insights within their institution, and other users can see how many people are using that insight and apply it to their own patients / rooms. Users can also see rules (or "insights") set by others globally on the platform outside their institution, see the popularity of each insight, and, if needed, select one or more of these insights to apply to their own patients / rooms.

[0087] Therefore, as explained above, the supervisory application 44 may include a backend hosted on edge device 20, which includes multiple microservices such as a rules engine 108, an inference engine 110, an event notification service 112, and a streaming server 114. The supervisory application 44, via the backend / edge device 20, may output real-time medical device data, trends in medical device data, messages, alerts, insight notifications / results, and / or other information requested by the frontend of the supervisory application 44 executing on the care provider devices. The frontend of the supervisory application 44 may include a supervisory application visualization platform that can be stored on each care provider device. The supervisory application visualization platform (such as supervisory application visualization platform 135 stored on care provider device 134) may render data received from edge device 20 into one or more graphical user interfaces. Additionally, aspects of the supervisory application 44 stored on each care provider device may include various containers, components, and presentation layers to receive data from edge device 20, populate the graphical user interface with the received data, send and receive messages, display notifications, collect GUI settings and other requested customizations (and send settings / configurations to edge device 20), etc. As an example, historical data (e.g., trends) received from edge device 20 can be sent to the first layer via a REST application programming interface (API), real-time medical device data can be streamed to the first layer via network sockets, and push notifications sent from MDD processing system 12 can be received, processed, and displayed via a visualization platform. Furthermore, when interacting with the graphical user interface of the monitoring application, users can adjust various settings (such as which patient monitoring parameters to display), activate or deactivate alarm notifications, create insights, etc. These user-specific preferences / configurations can be stored in a preference / configuration database on edge device 20.

[0088] In some implementations, medical device data and / or other information requested via the supervisory application 44 can be obtained from the electronic medical record (EMR) database 122. For example, historical data (e.g., trend lines) can be obtained from the EMR database 122 as a supplement to or alternative to the data storage 104. The EMR database 122 may be an external database via a secure hospital interface, or it may be a local database (e.g., housed on equipment within the hospital). The EMR database 122 may be a database stored in a mass storage device configured to communicate with secure channels (e.g., HTTPS and TLS) and to store data in encrypted form. Furthermore, the EMR database 122 is configured to control access to the patient's electronic medical records, enabling only authorized healthcare providers to edit and access the records. The patient's EMR may include patient demographics, family history, past medical history, lifestyle information, existing medical conditions, current medications, allergies, surgical history, previous medical screenings and procedures, previous hospitalizations and visits, etc.

[0089] Edge device 20 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 edge devices 20 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.

[0090] In exemplary and non-limiting embodiments of the edge device, edge device 20 is implemented by one or more processors or computing devices. 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.

[0091] Figure 2 illustrates an exemplary single-patient graphical user interface (GUI) 200 that may be displayed when a monitoring application 44 is launched on a monitoring care provider device. The single-patient GUI 200 may be displayed on a display device 202. The display device 202 may include a screen on which the single-patient GUI is displayed and may be coupled to and / or included as part of a computing device (such as care provider device 134). The single-patient GUI 200 may be displayed in response to a user's request to display the GUI. For example, a user may launch the monitoring application 44 by selecting a monitoring application icon displayed on the home screen of the display device. When the monitoring application 44 is launched (at least initially), the user may be authenticated via a suitable authentication method such as via password, facial recognition, fingerprint recognition, etc. Upon authentication, the user may select to view the single-patient GUI 200 from a suitable menu. For example, the user may access a multi-patient interface including a global view of all patients the user has selected to monitor (this may include all patients cared for by a care provider at a healthcare facility) and may select the desired patient to view. For example, the multi-patient GUI may include links to patient-specific interfaces. In the example shown in this article, patients are not identified by name or patient ID number, but rather by the room they are currently in. For example, links are displayed for interfaces specific to patients located in operating rooms 1 (OR 1), 2 (OR 2), 3 (OR 3), etc. Additional patient links can be viewed by scrolling through the interface. Selecting a patient link launches that patient's single-patient GUI.

[0092] Returning to Figure 2, the single-patient GUI 200 may include an identification header 204 that identifies the patient whose medical device data / status is being displayed, in the form of the room the patient is currently in. In the example shown, the single-patient GUI 200 is specific to a patient located in the second operating room (OR 2) of the medical facility. The identification header 204 may include a back button 206 that, when selected via user input (e.g., via touch input to the back button), triggers the display of a multi-patient GUI. The identification header 204 may also include one or more menu buttons, such as menu button 208. When menu button 208 is selected, a context menu may be displayed, which may include buttons that trigger the display of trends, insights, or other data visualizations or interactive controls.

[0093] The identification header also includes a settings view button 210, which, when selected, causes the display of a settings view showing the machine settings / parameters (such as machine settings for an anesthesia machine) of the one or more medical devices that monitor the patient and / or deliver treatment to the patient. Figure 3 illustrates an exemplary settings view 300 displayed on display device 202 in response to the selection of settings view button 210. Settings view 300 displays machine settings in a first layout including an array of tiles. Each selected machine setting may be displayed as a corresponding tile, such as first tile 210, second tile 212, and third tile 214. In the example shown in Figure 3, first tile 210 displays a first setting, namely the oxygen percentage, second tile 212 displays a second setting, namely the flow rate of oxygen or medical gas to the patient, and third tile 214 displays a third setting, namely the type and concentration of anesthetic. Each settings tile displayed via settings view 300 may present a recently determined value for the corresponding machine parameter. For example, the first plot 210 presents an oxygen concentration of 95%, the second plot 212 presents a gas flow rate of 6.50 L / min, and the third plot 214 presents a sevoflurane concentration of 2.5%. Each determined value presented via the machine setting plot can be determined by a time-series stream of medical device data described above with respect to Figures 1A and 1B, and can therefore be sent from the edge device 20 to the care provider device via the monitoring application 44. The determined values ​​displayed in the setting view 300, along with other determined values ​​(such as patient monitoring parameter values, which will be explained in more detail below), can be measured values, estimated values, and / or inferred values. For example, SpO2 can be measured directly from a pulse oximeter, while the respiratory rate can be inferred from the output of a carbon dioxide plot or from the output of a pulse oximeter.

[0094] The patient monitoring parameter tile included in the single-patient GUI 200 (described below) can display physiological data (e.g., SpO2, respiratory rate) of a patient obtained from one or more patient monitoring medical devices (e.g., pulse oximeter, carbon dioxide analyzer). The machine settings tile included in the single-patient GUI 200 and / or settings view 300 can display machine data from one or more life-saving medical devices (such as anesthesia delivery machines) used during medical procedures performed on the patient. Machine data may include machine settings or parameters (e.g., ventilation mode, type and concentration of anesthesia). As will be described in more detail below, the settings of the anesthesia machine can be changed or suggested via a monitoring application.

[0095] Returning to Figure 2, the single-patient GUI 200 also includes an insight tile 302, a message tile 304, an alarm tile 306, and a procedure timing tile 308. The insight tile 302 can notify the user if any preset and saved insights have been triggered. In short, insights can resemble threshold-based alarms, but can be multimodal and / or multiparametric, such that an insight is triggered only when more than one parameter meets a predetermined condition and / or when the selected parameter meets a predetermined condition during a specific phase of the medical procedure, meets a predetermined condition for a specified amount of time, changes at a certain rate, etc. The message tile 304 can notify the user if any message (such as a text message from another care provider) has been received. The alarm tile 306 can notify the user if any alarm has been triggered. An alarm can be triggered when a selected patient monitoring parameter (such as SpO2) reaches a predetermined condition relative to a threshold (such as SpO2 dropping below 90%). The procedure timing tile 308 can notify the user of the current progress of the medical procedure being performed on the patient. For example, as shown in Figure 2, the elapsed time since the start of anesthesia delivery (e.g., 02:12:15) and the current stage of anesthesia delivery (e.g., maintenance stage) are illustrated. The stage of anesthesia delivery can be determined by the stage determination insight that can be performed by the MDD processing system 12 and / or edge device 20 as explained above with respect to Figures 1A and 1B.

[0096] Additional patient monitoring parameters that can be displayed via the single-patient GUI 200 can be organized into categories, and each patient monitoring category can be collapsed or expanded. When collapsed, the patient monitoring parameters for that category are not displayed. When expanded, the patient monitoring parameters for that category are displayed. Figure 2 shows each category in a collapsed configuration. The patient monitoring categories shown in Figure 2 include circulatory category 310, oxygenation category 312, ventilation category 314, and neurological category 316, but other categories are also possible without departing from the scope of this disclosure. The displayed patient monitoring categories can be customized by the user, allowing the user to select which categories will be displayed on their device. Each patient monitoring category includes a forward arrow, such as forward arrow 318, which causes the category to expand when selected by the user, making the patient monitoring parameters within that category visible.

[0097] Figure 4 shows view 400 of the single-patient GUI 200. In view 400, the user has selected two categories to expand (circulatory category 310 and oxygenation category 312) and two categories remain collapsed (ventilation category 314 and neurological category 316). When a category is expanded, the associated forward arrow can switch to a down arrow (as shown by down arrow 402) to indicate that the category has been expanded. The user's selection of the down arrow causes the category to collapse.

[0098] As can be seen from Figure 4, multiple patient monitoring parameters can be displayed when a category is expanded. For example, circulatory category 310 includes eight patient monitoring parameters, all related to circulation (e.g., ECG waveform, recently determined heart rate, etc.). Oxygenation category 312 includes six patient monitoring parameters, all related to oxygenation (e.g., recently determined SpO2). Users can select the patient monitoring parameters included in each category via an editing function, which can be performed via a context menu or through user input on the category. For example, a swipe motion on the banner of circulatory category 310 can trigger the display of an edit button. Selecting the edit button triggers the display of control buttons, via which patient monitoring parameters in that category can be deleted and / or additional patient monitoring parameters can be added. In this way, the editing / customization function allows users to view any parameter within a tile in the system using a single-patient GUI, including the trend of that parameter. For example, via the editing function, users can choose to view patient monitoring parameters as a single value (e.g., a recently determined value), as a trend showing the change of patient monitoring parameters over time, or both. Users are able to create their own views, their own insights, etc.

[0099] As explained above, one or more patient monitoring parameters displayed in the expanded view of a category may include the most recently determined value of that parameter. For example, in oxygenation category 312, SpO2 tile 404 may be displayed, showing the most recently obtained SpO2 value. However, it may be advantageous for the user to view the changes in the value of a patient monitoring parameter over time. To access a view displaying the trends of one or more patient monitoring parameters, the user can enter input into the selected patient monitoring parameter tile, such as a single touch input to SpO2 tile 404 (illustratively shown by hand 406). The selection of a patient monitoring parameter tile triggers a trend view of the selected patient monitoring parameter, where the trend data of the additional parameter can be displayed with an optional movable timeline to show parameter values ​​at any given time point, across different ranges, and at different trends, with different orientation and layout options that can be customized as described below.

[0100] The supervisory application 44 supports further customization options via a menu triggered by menu button 208, including single-patient or multi-patient views, custom insight views, default and custom layouts, and editable room views where customizable tile layouts can be created to visualize patient data for multiple patients. In addition to visualizing patient data, the supervisory application also supports customizable alarms, alerts, or notifications; messaging between two or more users of the supervisory application (e.g., supervisor and attending clinician) via text, voice, or audio recordings, including the ability to send screenshots or other images; the ability to attach annotations to patient displays or records; display status indicators about which stage a patient is currently in a given procedure; and the ability to remotely and directly change settings on various machines or devices, or request / suggest setting changes to the attending physician. As an example, an anesthesia representative administering anesthesia to a patient could use the aforementioned supervisory application to improve patient care in a specific area. Communication between the attending clinician and the supervising clinician can be complex if the supervising clinician lacks firsthand information, if there are technical and / or distance limitations, and if the supervisor may be overseeing multiple rooms / clinicians simultaneously. As non-operating room anesthesia (NORA) continues to outpace traditional operating room anesthesia, and nursing work moves further away from the traditional operating room environment, especially with the increasing use of supervised models, the need to support remote anesthesia care is growing.

[0101] The aforementioned monitoring application allows clinicians (e.g., supervising anesthesiologists) to remotely monitor one or more patients at any given time by providing real-time medical device data on demand in various user-defined formats. Real-time medical device data may include settings for the current treatment machine (e.g., anesthesia machine), such as oxygen flow rate and anesthetic concentration. In some cases, it may be helpful for clinicians to request changes to anesthesia machine settings when they are outside the room where the anesthesia machine is located.

[0102] There may also be situations where the attending clinician at the point of care needs to monitor or control anesthesia administration from outside. For example, in a NORA situation, the anesthesia machine may be located in the same place as an X-ray machine, requiring the attending physician to temporarily leave the room to avoid radiation exposure. In such cases, monitoring of the anesthesia setup and patient response must typically be suspended, and the patient faces a higher risk if an unexpected reaction, machine malfunction, or other unforeseen event occurs while the clinician is away from the anesthesia machine. Other situations may include unforeseen clinician shortages, accidents or absences, highly infectious or abusive patients, hazards in the temporary workplace, or any other situation where the attending clinician cannot, cannot, is impractical, or does not wish to be physically present with the patient.

[0103] The following embodiments of a system for temporarily transferring control of an anesthesia machine to a remote device are illustrated in Figures 5 through 18. The system may include an anesthesia machine, a remote device (such as care provider device 134), and a dedicated anesthesia access server for managing authentication for traditional hospital accreditation services, as described below and shown in Figures 5 through 12. If the attending physician cannot directly operate the anesthesia machine, remote access may require directly changing settings on the anesthesia machine via controls provided in a GUI displayed on the remote device, as described below and shown in Figure 13. In cases where a supervising anesthesiologist monitors one or more attending physicians, remote access may include sending a notification to the attending physician requesting a setting change, which may be displayed on the anesthesia machine, as described below and shown in Figures 14 through 17.

[0104] Because security vulnerabilities can cause patient care problems, such as disruption of ordered / command treatment, remote access can be managed via authentication procedures. Currently, most security measures involve network-layer and organization-level authentication (e.g., LDAP). Since network-layer security and organization-level authentication mechanisms may not provide the necessary level of security, additional mechanisms may be needed to ensure that remote operators of anesthesia machines are properly authorized, identified, and tracked according to hospital policies and best practices. Furthermore, for security purposes and to ensure that attending clinicians can change anesthesia machine settings at the point of care, authentication for remote access should only be initiated through direct interaction with the anesthesia machine, not through the remote device.

[0105] Figure 5 schematically illustrates an exemplary system 500 for managing authentication via a dedicated anesthesia access server 504, which verifies users against a hospital authentication service 506. The access server 504 manages switching between the anesthesia machine 502 and remote devices 508 (e.g., smartphones, such as care provider devices 134). It should be understood that the anesthesia machine 502 is a non-limiting example of a patient treatment device in the patient treatment device 16b of Figure 1A. The authentication process according to the exemplary system 500 is initiated via user interaction with the graphical user interface of the anesthesia machine, as described below and illustrated in Figure 6.

[0106] The anesthesia access server 504 and the hospital authentication service 506 can be implemented in a variety of hardware and / or software embodiments, and it should be noted that such embodiments are not considered limiting. For example, it is conceivable that either or both of the anesthesia access server 504 and the hospital authentication service 506 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.

[0107] In the implementation, the anesthesia access server 504 and the hospital authentication service 506 may be hosted on hospital computing infrastructure (such as physical servers), which includes communication modules, memory, and processors to store and execute aspects of the anesthesia access server 504 and the hospital authentication service 506, similar to the server explained above with respect to Figure 1A. For example, the server or system may include a computer processor, controller, or other logic-based device that performs operations based on instructions stored on a tangible and non-transitory computer-readable storage medium (such as computer memory).

[0108] In exemplary and non-limiting embodiments, the anesthesia access server 504 and the hospital authentication service 506 may be implemented by one or more networked processors or computing devices, including cloud computing platforms and / or infrastructure.

[0109] The anesthesia access server 504 and hospital authentication service 506 can be accessed on at least one hospital network (e.g., hospital network 14). The hospital network may include, but is not limited to: a wide area network (WAN); a local area network (LAN); the Internet; wired or wireless (e.g., optical, Bluetooth, radio frequency (RF) networks); cloud-based computing infrastructure such as computers, routers, servers, and gateways; or any combination thereof that allows the system or parts thereof to communicate with one or more computing devices. Hospital authentication service 506 may use Lightweight Directory Access Protocol (LDAP) to provide access to user credentials over the hospital network.

[0110] It should be understood that while some implementations and specific implementations of Hospital Authentication Service 506 and Anesthesia Access Service 504 may seek to operate within a single hospital or hospital unit, Hospital Authentication Service 506 and Anesthesia Access Service 504 may be hosted outside the hospital, and / or their scope may include multiple hospitals or patient care centers, including hospitals currently owned or operated or otherwise associated with each other. In yet another implementation, while individual hospitals or groups of hospitals may use Hospital Authentication Service 506 and Anesthesia Access Service 504, the use of Hospital Authentication Server 506 and Anesthesia Access Service 504 can simultaneously receive and process information from multiple hospital networks (including networks unrelated to each other).

[0111] Figure 6 illustrates two exemplary views of a graphical user interface displayed on an anesthesia machine. GUI 602 shows the graphical user interface seen by an operator (e.g., an attending clinician) monitoring a patient at the point of care. Various machine settings are displayed via a series of display elements, including, but not limited to, dials (airway pressure) and gauges (total air and O2 flow) on the left; trend lines and parameters for airway pressure, flow, and CO2 in the center of the GUI; additional parameters displayed in tiles in the bottom third of the GUI; and function menu buttons (tiles) on the right. In some embodiments, the display elements may include interactive control elements that allow the operator to change parameter settings by directly selecting (e.g., clicking or touching) on ​​the display elements in GUI 602.

[0112] GUIs 602 and 606 include a display element 604, which is a control element (e.g., a button) that, when selected, opens a remote control panel 608 displayed on the left side of GUI 606. This remote control panel partially obscures GUI 602, within which display or control elements related to enabling remote control may be presented. The remote control panel 608 may include a control element 610 (e.g., a slider) that allows a user to send a request to initiate a procedure to transfer control of the anesthesia machine to a remote device. Display elements 604 and 610 are shown as a button and a slider, respectively, for illustrative purposes, but may include any interactive element (button, slider, radio button, checkbox, etc.).

[0113] The remote control panel may include other display elements, such as access code information displayed during the authentication process (as shown in Figure 10), or notification that control of the anesthesia machine has been transferred to a remote device (as shown in Figure 11) and / or other information, such as the object to which control is transferred, the amount of time elapsed since the transfer of control, contact information, etc.

[0114] In addition to the display elements, control elements such as buttons can be provided to revoke a remote session and return control to the anesthesia machine, as shown in Figure 11. Since the attending clinician is ultimately responsible for patient care, they can personally initiate and revoke remote sessions on the machine, ensuring their presence when control is transferred and returned to the anesthesia machine. When a remote session is revoked, the remote control panel disappears from the anesthesia machine GUI, leaving the GUI as shown in 602. A cancel button can also be displayed, which closes the remote control panel and removes the remote panel from view, allowing the operator to view the full GUI displayed in 602. The same functionality can be provided via window closing elements (such as the X in the upper right corner of the panel), as shown in 612. It should be understood that, at least in some examples, remote control of the anesthesia machine may not be revoked when the remote control panel on the anesthesia machine is closed.

[0115] Figure 6 illustrates a first embodiment of a GUI that can be configured to invoke remote control of an anesthesia delivery machine. Figure 18 illustrates a second embodiment of a GUI configured to invoke remote control of an anesthesia delivery machine. The GUI 1800 of Figure 18 can be displayed on the display device / screen of the anesthesia machine, as explained above with respect to Figure 6, and may include similar control elements, displayed machine settings, etc., as described above. The GUI 1800 may lack display element 604 and may alternatively include a remote control button 1802 positioned along the bottom of the GUI 1800. The remote control button 1802 may include an icon indicating remote control (e.g., indicating wireless connection) or have another suitable visual appearance.

[0116] Next, Figures 7, 8, and 9 illustrate exemplary method flowcharts for requesting and establishing remote control of an anesthesia machine from the perspectives of the anesthesia machine, a remote device, and an anesthesia access server, respectively. Figures 7 through 9 are described with reference to the systems and components in Figures 1A, 1B, and 6, but it should be understood that this method can be implemented using other systems and components without departing from the scope of this disclosure.

[0117] Figure 7 illustrates a method 700 for establishing remote control of an anesthesia machine from the perspective of the anesthesia machine itself. Method 700 can be executed according to instructions stored in the non-transitory memory of the anesthesia machine (such as anesthesia machine 502 in Figure 5). At 702, a request is received from a user (e.g., the attending clinician) to enable remote control of the anesthesia machine via a remote device. For example, the user can select a remote button on a graphical user interface displayed on the anesthesia machine's display device (e.g., button 604 in Figure 6 or button 1802 in Figure 18), or enter another suitable user input. At 704, a session code is generated by the anesthesia machine. The session code can be a unique code (e.g., a number) used to uniquely identify interactive temporary information exchanges between two or more communication devices on a network. For example, the anesthesia machine can generate the session code via a random number generator. The session code may not be usable on a hospital computer network (such as hospital network 14) to prevent unauthorized individuals or elements outside the system from improperly accessing the session code, which could constitute a security vulnerability and allow unauthorized users to control the anesthesia machine.

[0118] It should be noted that when discussing remote devices and remote device GUIs, the term "access code" can be replaced with "session code" for common usage and communication purposes, as shown in GUI1204 in Figure 12. The terms "access code" and "session code" are used as synonyms in this document.

[0119] The session code can be transmitted to a remote device, such as care provider device 134, in one or more ways. For example, the session code can be displayed in text form on the GUI of the anesthesia machine, such as in the remote control panel 608 of the anesthesia machine GUI 606, for manual entry into the remote device, or displayed via a QR code to be scanned by the remote device, or via another form. The remote control panel 608 can also display an indication that the session has been provided to the remote device by near field communication (NFC). An example of an alternative session / access code display scheme is shown in Figure 10.

[0120] Returning to Figure 7, once the session code has been successfully transferred to the remote device as described above, at 712, the mobile application on the remote device can send the session code to an anesthesia access server, such as anesthesia access server 504, for authentication. Once the authentication process has successfully terminated, as described in more detail in method 900, the anesthesia access server can send a session token to the anesthesia machine at 714, indicating that the session has been authorized. In this case, the anesthesia machine continues to transfer control to the remote device at 716, and at 718, a notification that control has been transferred to the remote device can be displayed on the anesthesia machine GUI, as shown in Figure 11. Once control has been successfully transferred to the remote device, at 720, the anesthesia machine determines whether it has received a setting change request from the remote device that has been authorized to remotely control the anesthesia machine. If a request is received, method 700 proceeds to 722, where the anesthesia machine changes the requested settings. For example, a clinician operating the remote device might receive (e.g., via a monitoring application running on the remote device) a warning that monitoring parameters of a patient connected to the anesthesia machine have changed (e.g., SpO2 has decreased by 5%). In response, the clinician can enter a request via a remote device to increase the O2 flow of the anesthesia machine (explained in more detail below). The anesthesia machine can receive the request and can automatically (e.g., without additional explicit human-machine interaction) increase the O2 flow. If no request is received (or once a setting change has been made), method 700 proceeds to 724 to determine whether control of the anesthesia machine has been returned to the anesthesia machine. Control can be returned to the anesthesia machine via user input / commands at the anesthesia machine, such as user selection of control elements in the anesthesia machine GUI, such as the undo button 1108 in Figure 11. If control has not yet been returned to the anesthesia machine, method 700 returns to 718 and / or 720 to continue processing the setting change request as described above. If control is returned to the anesthesia machine at 724, the method returns. In some examples, once control of the anesthesia machine has been returned to the remote device, the anesthesia machine settings cannot be adjusted via the anesthesia machine itself (e.g., via GUI 602) unless remote control is revoked at the anesthesia machine.

[0121] Furthermore, in some examples, when control has been transferred to a remote device, the anesthesia machine can monitor the connection between the anesthesia machine and the remote device. If the connection is lost (e.g., the remote device moves to a location with weak / absent WiFi and / or cellular network coverage), the anesthesia machine may detect that the connection has been lost or is too weak to maintain the remote device's control over the anesthesia machine. The anesthesia machine can then notify any local users via visual and / or auditory notification outputs on the anesthesia machine and / or may attempt to notify the operator of the remote device via a notification system that can be configured to send notifications to the remote device via multiple connections (e.g., the connection between the remote device and the anesthesia machine may be via a wireless hospital network, but the notification system may be configured to communicate with the remote device via a cellular network). In some examples, if the lost connection is temporary (e.g., the connection is re-established within a threshold time, such as 5-30 seconds after the connection is lost), the remote device's previous remote control over the anesthesia machine can be maintained once the connection is re-established.

[0122] Therefore, method 700 of Figure 7 provides an authentication process managed by an anesthesia access server to transfer control of the anesthesia machine to a remote device to ensure security. As mentioned above, remote control of the anesthesia machine is required when the attending clinician must temporarily leave the machine while monitoring the patient. Method 700 securely transfers control to the remote device by requiring the remote device / user of the remote device to be located at the anesthesia machine to authenticate the user / remote device, for example, via a session code displayed on the anesthesia machine. This session code can be manually entered by the user on the remote device, scanned via a QR code, or received from the anesthesia machine at the remote device via NFC. Turning now to Figures 8 and 9, methods 800 and 900 reflect different views of the same procedure from the perspectives of the remote device and the anesthesia access server, respectively.

[0123] In Figure 8, method 800 illustrates the same process from the perspective of a remote device. Method 800 can be executed according to instructions stored in the non-transitory memory of a remote device (such as remote device 508 in Figure 5 and / or care provider device 134 in Figure 1B) configured to communicate with an anesthesia machine. At 802, the remote device receives a session code from the anesthesia machine. As described above, the remote device can receive the code by scanning a QR code (as indicated at 804), by manually entering the code into a device (as indicated at 806), or via NFC (as indicated at 808). At 810, the remote device sends the session code to an anesthesia access server (AAS), such as AAS 504 in Figure 5, for authentication.

[0124] Once the anesthesia access server successfully authenticates the session code (as shown in Figure 9), the anesthesia machine relinquishes remote control to the remote device at point 812. The remote device continues to display a notification at point 814 (e.g., on a display device associated with the remote device), informing the user of the remote device that remote control has been transferred. At point 816, the remote device displays a GUI with the anesthesia machine settings upon request, allowing the user to select settings to change. For example, an interactive tiled layout can be used, where one or more setting tiles indicate specific anesthesia machine settings. For example, as described above, Figure 3 shows an example of a GUI that can be displayed on the remote device when control of the anesthesia machine has been transferred, including multiple setting tiles (e.g., a tile displaying the O2 concentration setting). When the user selects a tile, each setting tile triggers the display of multiple interactive setting value tiles, each indicating a different setting / value option, such as the multiple different O2 concentration tiles shown in the exemplary GUI of Figure 13, and explained in more detail below. The setting of any selected parameter can be changed by selecting the relevant setting tile and performing a confirmation action (e.g., pressing a button). An example of this tiling layout is shown in Figure 13 and discussed below.

[0125] At 818, method 800 determines whether a request to change the anesthesia machine settings has been received from the user. In the example above, a request can be triggered on a remote device when the user selects a setting value block indicating the desired value of a given setting and presses a button to confirm the setting change. If such a request is received, method 800 proceeds to 820 to send a command to the anesthesia machine to change the settings. If no request to change the anesthesia machine settings is received, method 800 proceeds to 822 to determine whether control of the anesthesia machine has been returned to the anesthesia machine. If control has not been returned to the anesthesia machine, method 800 returns to 816 to continue waiting for any further setting change requests. Alternatively, if control has been returned to the anesthesia machine, method 800 returns.

[0126] Similar to methods 700 and 800, method 900 of Figure 9 similarly provides the transfer of control of the anesthesia machine to a remote device via an authentication process managed by an anesthesia access server. Method 900 illustrates the authentication process from the perspective of the anesthesia access server. Method 900 can be executed according to instructions stored in the non-transitory memory of the anesthesia access server (such as anesthesia access server 504 in Figure 5).

[0127] At 902, the anesthesia access server (such as anesthesia access server 504) receives the session code generated by the anesthesia machine via the remote device. At 904, the anesthesia access server continues to send the session code to a hospital authentication service (such as hospital authentication service 506) for authentication. At 906, the anesthesia access server receives a session token from the hospital authentication service, indicating that the remote session has been successfully authenticated. Then, at 908, the anesthesia access server continues to send the session token to the anesthesia machine, enabling the anesthesia machine to relinquish remote control to the remote device, and then the method returns.

[0128] Therefore, methods 700, 800, and 900 provide different perspectives of the procedure, thereby allowing control of the anesthesia machine (such as the anesthesia machine 502 in Figure 5) to be transferred to a remote device (such as the remote device 508 in Figure 5) via an anesthesia access server (such as the anesthesia access server 504 in Figure 5). The procedure described above in methods 700-900 is performed by a user (e.g., the attending clinician) through a series of steps performed by interacting with GUIs provided on the anesthesia machine and the remote device. Figures 10-13 illustrate exemplary GUIs that may be displayed on the anesthesia machine and the remote device during this procedure. Figures 10 and 11 illustrate an exemplary anesthesia machine GUI, while Figures 12 and 13 illustrate a remote device GUI.

[0129] Figure 10 illustrates an exemplary view 1000 of GUI 502, with a remote control panel 1004 displayed on the left side of the GUI, partially obscuring GUI 502. As described above, a QR code 1006 can be displayed to transmit a session code to a remote device (such as care provider device 134). Alternatively, the session code can be manually entered into the remote device, for example, the access code 1008 shown in Figure 10 can be manually entered into the remote device. Figure 10 also illustrates a visual indication 1010 that the session code can be used to transmit to a remote device via NFC.

[0130] Figure 11 illustrates an exemplary view 1100 of the remote access menu 1102, which can be displayed in the remote control panel of GUI 502 once remote control has been transferred from the anesthesia machine to the remote device. Display area 1104 may include notification 1106 that the remote session is active, as well as information about the clinician who has been granted remote control, or any other relevant information such as the current duration of the session, contact information, etc. An "Undo" button 1108 is displayed; when selected, this button cancels the remote session and returns control to the anesthesia machine. A "Cancel" button 1110 is also displayed; when selected, this button closes the remote access menu, allowing the underlying elements of GUI 502 to be seen.

[0131] Figures 12 and 13 illustrate exemplary GUIs that can be displayed on a remote device, such as care provider device 134, in conjunction with methods 700, 800, and 900. Figure 12 illustrates a set of alternative remote control panel GUIs 1200 for receiving access codes from an anesthesia machine. The remote control panel GUI can be displayed (e.g., in a context menu displayed in response to a user input requesting pairing of the remote device with the anesthesia machine, such as a user selection of a remote control option in a monitoring application's menu) in response to user selection of menu button 208 of Figure 2. If the user selects to receive the access code by scanning a QR code, the remote device can display a scan box for positioning the remote device at the appropriate distance and orientation relative to the anesthesia machine so that the QR code 1006 can be correctly scanned, as shown in remote control panel 1202. If the user selects to manually enter the access code, the remote device can display a data input field with a text prompt for the access code, as shown in remote control panel 1204. If the user chooses to receive the access code via Near Field Communication (NFC), the remote device can display an indication that the access code can be obtained via NFC through any relevant scanning command, as shown in the remote control panel 1206.

[0132] To allow remote device users to choose their preferred method for receiving access codes and displaying the corresponding GUI, remote control panels may include control elements such as buttons, clickable text, or other navigation options that allow users to navigate between remote control panels 1202, 1204, and 1206, as shown by the QR code scanning button 1208, the access code button 1210, and the NFC button 1212. Buttons 1208, 1210, and 1212 may use visual cues (such as highlighting, color changes, or similar visual indicators) to indicate which control panel option is currently active on the screen. For example, in remote control panel 1202, the QR code scanning button 1208 displays text in a different color (e.g., blue) than other buttons, indicating that the GUI for scanning QR codes is displayed on the screen. Similarly, in remote control panel 1204, the access code button 1210 displays text in a color indicating that the GUI for manually entering access codes is displayed on the screen, and in remote control panel 1206, the NFC button 1212 displays text in a color indicating that the GUI for transmitting access codes via NFC is displayed on the screen.

[0133] Remote control panels 1202, 1204, and 1206 are shown for illustrative purposes and may optionally include other or additional display and / or control elements, such as identification information for the anesthesia machine authorized for remote access, information about the patient receiving anesthesia, timestamps, or other similar information. In Figure 13, GUI 1300 shows an example of a settings view of GUI 204 displayed on a remote device (such as care provider device 134) that includes control elements allowing the user to remotely change the anesthesia machine. GUI 1300 includes an identification header 204 that identifies the patient whose medical device data / status is being displayed, as explained above with reference to Figure 2. Since the remote device is authenticated for remote control of the anesthesia machine currently connected to the patient in OR2, a remote connection icon 1301 is displayed next to the patient / room identifier. The upper half of GUI 1300 includes an exemplary view of the tiled layout of the anesthesia machine settings. For example, a monitoring application may display an interactive tile of O2, as shown in 210, indicating 80% of the settings on the anesthesia machine. Depending on the user-defined or default layout selection, additional tiles for different settings (e.g., total flow, SEV, mode, TV, RR, Psupport, etc.) can also be displayed. As mentioned above, the GUI 1300 can also display control features such as the back arrow 206, settings view buttons 210, or context menus 208.

[0134] In GUI 1300, a user can select a tile to request changes to settings on the anesthesia machine, as shown in tile 210 (O2). A visual indication that a tile has been selected can be provided to the remote device user via changes to a highlighted border, color, brightness, or any other visual characteristic of the tile. When a tile is selected, a settings control panel 1302 can be displayed, showing one or more display elements or interactive control elements related to the selected setting. The settings control panel 1302 includes the current value of the selected setting (e.g., 95% O2).

[0135] As an example, in Figure 13, a tiled layout including various value tiles can be displayed in the lower half of the GUI 1300, where each value tile is an interactive control element that allows the user to reset the selected setting based on the value indicated on the corresponding tile. As mentioned above, a visual indication that a tile has been selected can be provided, for example, through a color change as shown in value tile 1304, where the selected tile indicates 80% of the desired setting for oxygen setting tile 210. Once a new setting has been selected, the user can submit a request to change the settings on the anesthesia machine via control elements such as confirmation tile 1306, indicated by a checkmark. Confirmation that the setting has been successfully changed can be indicated by updating setting tile 210 to the new setting. By displaying a set of possible value tiles instead of control boxes where the user can enter text / numbers to specify the desired value, changes to the selected setting can be entered more quickly, which improves patient care. Furthermore, where the setting only allows a limited set of possible values, the values ​​displayed via value tiles can represent all possible values ​​for the setting.

[0136] Regarding the switching mechanism, while Figures 5 through 13 illustrate one method where remote control of the anesthesia machine can be delegated from the attending clinician to a remote device, Figures 14 through 17 illustrate a method where a remote user (e.g., a supervising anesthesiologist) can propose changes to the settings on the anesthesia machine, but only with the approval of a local user (e.g., the attending clinician). In other words, some control is delegated to the remote user, such as the ability to view parameter settings and display notifications on the GUI displayed on the anesthesia machine, without relinquishing the full control (the ability to directly change settings) described in methods 700-900. As mentioned above, in cases where the supervising anesthesiologist wishes to monitor anesthesia administered by one or more attending clinicians at the point of care, it may be preferable to retain control of the anesthesia machine in the hands of the attending clinician.

[0137] Figure 14 illustrates a method 1400 for requesting and establishing remote access to an anesthesia machine via a remote device (e.g., a smartphone, such as care provider device 134). Method 1400 can be executed according to instructions stored in a non-transitory memory of a remote device configured to communicate with the anesthesia machine (such as remote device 508 of Figure 5 and / or care provider device 134 of Figure 1B).

[0138] At 1402, method 1400 may optionally include initiating a supervisory application, such as supervisory application 44 discussed above. As previously described, the supervisory application may be initiated in response to a user request. In some examples, the supervisory application may have already been initiated, thus eliminating the need for separate initiation. At 1404 of method 1400, when the remote device requests a setting change (e.g., a request to change the settings of an anesthesia machine), the supervisory application sends a setting change request to the anesthesia machine. At 1406, method 1400 determines whether a response has been received from the anesthesia machine. If no response is received within a pre-established time limit (e.g., 30 seconds, one minute), the anesthesia machine performs a default action at 1408, and at 1410, the supervisory application displays a notification on the remote device, and then the method returns. The notification of no proposed setting change may indicate that the attending clinician did not see the proposed change or may have ignored it; this may be displayed on the remote device in text form or via identifiable display elements such as icons, images, or similar visual features. If a response is received again from the anesthesia machine at 1406, method 1400 determines at 1412 whether the request has been approved or rejected by the attending clinician. As an example, in Figure 16, the attending clinician can approve or reject the setting via a notification displayed on the anesthesia machine GUI at 1602, by selecting a checkmark at 1604 to indicate approval, or by selecting an X at 1606 to indicate rejection. At 1412, if the request has been approved by the attending clinician on the anesthesia machine, the monitoring application continues to display an acceptance notification on the remote device at 1416, and the method returns. An example of an acceptance notification displayed on the remote device is shown in Figure 17. Alternatively, if the request is rejected, the monitoring application displays a rejection notification on the remote device at 1414, and the method returns.

[0139] Figure 15 illustrates a method 1500 for receiving a notification of a proposed setting change on an anesthesia machine (e.g., anesthesia machine 502), the notification being sent by a user (e.g., a supervising anesthesiologist) via a remote device (e.g., a smartphone, such as care provider device 134). Method 1500 illustrates the same procedure described in method 1400 from the perspective of the anesthesia machine and can be executed according to instructions stored in the non-transitory memory of the anesthesia machine (such as anesthesia machine 502 in Figure 5).

[0140] Similar to method 1400, method 1500 is initiated at 1504, where a setting change request is received from a remote device via a supervisory application. Upon receiving the request, the anesthesia machine displays the request as a notification on its GUI, as illustrated at 1602 in Figure 16, and waits for the user (e.g., the attending clinician) to record a response in the form of acceptance or rejection. If the anesthesia machine does not receive user input (acceptance or rejection of the request as described above in method 1400) at 1506, a default action is taken at 1508 when a timer expires. For example, a default action may be performed when a timer expires (e.g., the timer may expire after 30 seconds, after one minute, or after another suitable amount of time). The default action may include sending a timeout notification to the remote device (e.g., informing the user that no action has been taken at the anesthesia machine) and / or stopping the display of the setting change request. The method returns. If user input is received from the anesthesia machine at 1506, method 1500 continues to determine at 1510 whether the request has been approved by the user. If approval is recorded at 1510, the method proceeds to 1514 to change the requested settings on the anesthesia machine. For example, if the requested settings change includes requesting a change in the oxygen concentration in the airflow supplied to the patient currently connected to the anesthesia machine (e.g., from 85% to 80%), the oxygen concentration delivered by the anesthesia machine may change (e.g., to 80%). At 1516, the anesthesia machine continues to send a notification of acceptance of the requested settings change to a remote device (e.g., via a monitoring application), and the method returns. Alternatively, if a rejection of the request is recorded at 1510, the anesthesia machine sends a notification of rejection of the requested settings change to a remote device (e.g., via a monitoring application) at 1512, and method 1500 returns. Examples of acceptance and rejection notifications are shown in Figure 17.

[0141] Figure 16 illustrates an exemplary view 1600 of an anesthesia machine GUI 502, where a notification of a setting change request sent from a monitoring application (such as monitoring application 44) is shown at 1602 in the lower left corner of the GUI. The notification panel 1602 may include one or more display elements that identify a remote user (e.g., a supervisor) on the anesthesia machine requesting the attending clinician to change the settings of the anesthesia machine, and the new settings requested by the remote user. For example, in the notification panel 1602, a setting change request for setting O2 is displayed by the monitoring application, where the remote user requests to change the setting to 2.2%. The notification panel 1602 may also include control elements that allow the attending clinician to accept or reject change requests on the anesthesia machine, as shown by checkmarks at 1604 and X at 1606.

[0142] The elements included in the notification panel 1602 are for illustrative purposes and may also include additional or other display or control elements, such as the name of the remote supervisor, the time the notification is displayed, the time remaining before the default action is taken, or one or more control elements that trigger additional functions, such as messaging, screenshots, etc.

[0143] Figure 17 illustrates a set of two exemplary remote device GUIs 1700, each showing an exemplary notification in response to a setting change request made by a remote supervisor. Once a setting change request is made via the supervisory application and notified on the anesthesia machine as shown in Figure 16, any acceptance or rejection made by the remote device user (e.g., the supervisor) via control element 1604 or 1606 of Figure 16 can be notified. An acceptance notification may be displayed, indicating that the attending clinician has accepted the setting change, as shown at 1706 in the header of GUI 1702. Alternatively, a rejection notification may be displayed, indicating that the attending clinician has rejected the setting change, as shown at 1708 in the header of GUI 1704.

[0144] Therefore, the systems and methods described herein provide remote control over life-threatening medical devices, such as anesthesia delivery machines. Due to the consequences of incorrect control of life-threatening medical devices (which can negatively impact patient outcomes), authentication of the remote device is only performed when the remote device is near it, enhancing the security of the device. Furthermore, remote control of the life-threatening medical device can be performed via a monitoring application that provides the remote device with real-time information regarding the device's settings and patient monitoring data of the patient being treated / monitored by the device. Patient monitoring data can be obtained from one or more patient monitoring / medical devices (such as SpO2 monitors, heart rate monitors, etc.). The ability of the remote device user to remotely and comprehensively monitor the patient makes remote control of the life-threatening medical device possible, which might otherwise be impossible because the remote device user does not fully understand the patient's condition and therefore cannot make adequate informed decisions about when and how to adjust the settings of the life-threatening medical device. For example, if a remote device cannot inform its user of all relevant patient monitoring data (such as data from patient monitoring devices outside of life-threatening medical devices), the remote device may malfunction when the user attempts to enter settings changes for the life-threatening medical device. Because the user is unaware of all aspects of the patient's condition before entering and implementing the settings changes, an uninformed (potentially life-threatening) decision is made. The life-threatening medical device monitoring application and remote control described herein address this issue by providing a specific, dynamically updated list of patient monitoring data. By presenting remote control of the life-threatening medical device within the context of the monitoring application, the room environment can be mimicked / presented to the user of the remote device, improving patient care while also maintaining the safety of the care provider (e.g., allowing the care provider to leave the room during X-ray imaging).

[0145] One embodiment relates to a system comprising: a life-saving medical device communicatively connected to a remote device and configured to deliver medical treatment to a patient; the life-saving medical device including a display and a memory storing instructions executable to: output a graphical user interface (GUI) to the display showing multiple real-time machine settings of the life-saving medical device; display a remote control panel via the GUI in response to a first user input, the remote control panel including a session code capable of authenticating the remote device; and display a notification on the GUI indicating that the life-saving medical device is currently controlled by the remote device in response to receiving an indication from an access server that the remote device has been authenticated. In a first embodiment of the system, the instructions are executable to change settings in multiple real-time settings in response to receiving a request to change settings from the remote device upon receiving an indication that the remote device has been authenticated. In a second embodiment of the system (which optionally includes the first embodiment), the notification includes an undo button, and wherein the instructions are executable to terminate the remote device's control over the life-saving medical device in response to a user selection of the undo button. In a third embodiment of the system (which optionally includes one or both of the first and second embodiments), instructions are executable to change settings of multiple real-time settings only in response to receiving a request from the remote device and not in response to receiving user input at the life-saving medical device, until the undo button is selected, upon receiving an indication that the remote device has been authenticated. In a fourth embodiment of the system (which optionally includes one or more of the first to third embodiments), the GUI includes remote control buttons, and the first user input includes a user selection of the remote control buttons. In a fifth embodiment of the system (which optionally includes one or more of the first to fourth embodiments), the life-saving medical device is an anesthesia machine configured to supply anesthetics to a patient. In a sixth embodiment of the system (which optionally includes one or more of the first to fifth embodiments), the display is a first display, the remote device includes a second display, and the remote device is configured to: output a remote control panel to the second display; and, in response to receiving a session code at the remote control panel, send the session code to an access server, which can use the session code to authenticate the remote device. In a seventh embodiment of the system (which optionally includes one or more or each of the first to sixth embodiments), the remote device is configured to receive multiple real-time machine settings and real-time patient monitoring data from a life-critical medical device, and, upon request, display one or more of the multiple real-time machine settings and / or real-time patient monitoring data on a second display.

[0146] An implementation of the system includes: a display; and a computing device operatively connected to the display and storing instructions executable to: output a first graphical user interface (GUI) to the display, the GUI including a remote control panel for receiving a session code, the session code being usable for authenticating the computing device to remotely control an anesthesia machine; output a second GUI to the display, the second GUI including a plurality of anesthesia machine setting blocks, each anesthesia machine setting block indicating a corresponding anesthesia machine setting; in response to a user selection of an anesthesia machine setting block among the plurality of anesthesia machine setting blocks, displaying via the second GUI a plurality of value blocks of the selected anesthesia machine setting block, each value block indicating a possible value for the selected anesthesia machine setting; and in response to receiving an indication from an access server that the computing device has been authenticated and further in response to a user selection of a value block among the plurality of value blocks, sending a command to the anesthesia machine to adjust the selected anesthesia machine setting to the selected value. In a first embodiment of the system, the anesthesia machine is configured to receive the command and, in response to receiving the command, automatically adjust the selected anesthesia machine setting to the selected value. In a second embodiment of the system (which optionally includes the first embodiment), the anesthesia machine is configured to adjust the selected anesthesia machine settings to the selected values ​​only in response to receiving a command and not in response to direct user input at the anesthesia machine, until the computing device relinquishes control of the anesthesia machine. In a third embodiment of the system (which optionally includes one or both of the first and second embodiments), instructions are executable to send a session code to an access server upon receipt of a session code. In a fourth embodiment of the system (which optionally includes one or more, or each of, the first to third embodiments), instructions are executable to receive real-time values ​​of multiple anesthesia machine settings before, during, and / or after authentication by the computing device.

[0147] The system implementation includes: a display; and a computing device operatively connected to the display and storing instructions capable of executing to: upon receiving an instruction that the computing device has been certified for remote control of an anesthesia machine, outputting a first graphical user interface (GUI) to the display, the first GUI including a plurality of anesthesia machine setting tiles, each indicating a corresponding anesthesia machine setting; in response to a user selection of an anesthesia machine setting tile among the plurality of anesthesia machine setting tiles, displaying via the first GUI a plurality of value tiles for the selected anesthesia machine setting tile, each value tile indicating a possible value for the selected anesthesia machine setting; in response to a user selection of a value tile among the plurality of value tiles, sending a request to the anesthesia machine to adjust the selected anesthesia machine setting to the selected value; and in response to receiving a response to the request from the anesthesia machine, displaying via the first GUI a notification indicating whether the request to adjust the selected anesthesia machine setting has been approved by the user at the anesthesia machine. In a first embodiment of the system, displaying a notification via a first GUI indicating whether a request to adjust the selected anesthesia machine setting has been approved includes receiving a response indicating that the request has been approved by the user at the anesthesia machine, and in response, displaying a notification indicating that the selected anesthesia machine setting has been approved. In a second embodiment of the system (which optionally includes the first embodiment), the display is a first display, and the anesthesia machine is configured to output a second GUI to be displayed on a second display associated with the anesthesia machine, the second GUI including real-time values ​​for each corresponding anesthesia machine setting. In a third embodiment of the system (which optionally includes the first embodiment), the anesthesia machine is further configured to, in response to receiving a request to adjust the selected anesthesia machine setting to the selected value, display via a second GUI a notification panel indicating that the user of the computing device has requested to adjust the selected anesthesia machine setting to the selected value, the notification panel including an accept button and a reject button. In a third embodiment of the system (which optionally includes one or both of the first and second embodiments), the anesthesia machine is configured to adjust the selected anesthesia machine setting to the selected value in response to the selection of the accept button, and send a response indicating that the request has been approved to the computing device. In a fourth embodiment of the system (which optionally includes one or more or each of the first to third embodiments), instructions are executable to output a remote control panel to a display for receiving a session code before outputting a first GUI. The session code can be used to authenticate the computing device, and the instruction indicates that it is received from an access server upon receiving the session code. In a fifth embodiment of the system (which optionally includes one or more or each of the first to fourth embodiments), instructions are executable to receive real-time patient monitoring data from one or more monitoring devices monitoring a patient connected to an anesthesia machine, and output the real-time patient monitoring data for display on a display upon request.

[0148] The advantage of remotely controlling life-saving medical devices is that it allows clinicians to respond to changes in patient condition without physically being at the point of care, thereby improving patient care by enabling faster responses to changes in patient condition.

[0149] As used herein, elements or steps listed in the singular and beginning with the word "a" or "an" should be understood to not exclude a plurality of such 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.

[0150] 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 and 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 life-saving medical device communicatively connected to a remote device and configured to deliver medical treatment to a patient, the life-saving medical device including a display and a memory storing instructions executable to: output a graphical user interface to the display showing multiple real-time machine settings of the life-saving medical device; and, in response to a first user input, display a remote control panel via the graphical user interface, the remote control panel including a session code authenticating the remote device; And in response to receiving an indication from the access server that the remote device has been authenticated, a notification indicating that the life-saving medical device is currently controlled by the remote device is displayed on the graphical user interface; wherein the instruction is executable to change the settings among the plurality of real-time settings in response to receiving a request to change settings from the remote device upon receiving the indication that the remote device has been authenticated; wherein the notification includes an undo button, and wherein the instruction is executable to terminate the remote device's control over the life-saving medical device in response to a user selection of the undo button; The instructions described therein are executable to respond only to receiving the request from the remote device and not to receiving user input at the life-saving medical device to change the settings of the plurality of real-time settings, until the undo button is selected, upon receiving the indication that the remote device has been authenticated.

2. The life-threatening medical device of claim 1, wherein the display is a first display, wherein the remote device includes a second display, and wherein the remote device is configured to: output a remote control panel to the second display; and in response to receiving the session code at the remote control panel, send the session code to the access server, the access server being able to use the session code to authenticate the remote device.

3. A remote control system, the system comprising: monitor; The device includes a computing device operatively connected to the display and storing instructions executable to: output a first graphical user interface (GUI) to the display, the GUI including a remote control panel for receiving a session code, the session code being usable for authenticating the computing device for remote control of an anesthesia machine; output a second GUI to the display, the second GUI including a plurality of anesthesia machine setting tiles, each indicating a corresponding anesthesia machine setting; in response to a user selection of an anesthesia machine setting tile from the plurality of anesthesia machine setting tiles, displaying a plurality of value tiles of the selected anesthesia machine setting tile via the second GUI, each value tile indicating a possible value for the selected anesthesia machine setting; and in response to receiving an indication from an access server that the computing device has been authenticated and further in response to a user selection of a value tile from the plurality of value tiles, sending a command to the anesthesia machine to adjust the selected anesthesia machine setting to the selected value. The anesthesia machine is configured to receive the command and, in response to receiving the command, automatically adjust the selected anesthesia machine settings to the selected value, and is configured to adjust the selected anesthesia machine settings to the selected value only in response to receiving the command and not in response to direct user input at the anesthesia machine, until the computing device’s control over the anesthesia machine is revoked.

4. The system of claim 3, wherein the instructions are executable to send the session code to the access server upon receipt of the session code.

5. The system of claim 3, wherein the instructions are executable to receive real-time values ​​of the plurality of anesthesia machine settings before, during, and / or after authentication of the computing device.

Images