Unit resource management for clinical guidance

Abstract

A method for medical device resource management, the method comprising: monitoring a plurality of medical devices for adjustments to the medical devices during a time period; based on the monitoring, identifying a plurality of adjustments to a plurality of medical devices during the time period; constructing a treatment profile associated with the patient and the medical device based on the identified adjustments; identifying an adverse event related to the patient or a respective one of the plurality of medical devices; and after identifying the adverse event: generating a plurality of consecutive control signals based on the treatment profile to correct the adverse event, each control signal associated with a different one of the medical devices or a different user.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 395,294, filed on August 4, 2022, the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to a control device configured to facilitate crew resource management. Background Art

[0004] Crew Resource Management (CRM) is a set of procedures used in environments where human error could have catastrophic effects. CRM is primarily used to improve aviation safety and focuses on interpersonal communication, leadership, and decision-making within the cockpit of an aircraft. CRM has proven to be highly effective in managing flight emergencies and preventing disasters and loss of life. Summary of the invention

[0005] CRM can be applied in the healthcare industry to solve urgent problems. Using checklists can provide error-proofing during medical emergencies or other high-stakes situations where knowing which steps to perform during a time-critical situation may be critical and relying on the clinician's memory may not be the best option.

[0006] The subject technology described herein provides a crew resource management unit integrated with an intelligent control module (ICM) to replace the use of physical lists (e.g., flip charts) that may be lost or not easily accessible when needed. Unlike lists that cannot be updated at any time when changes or new procedures are to be added, the CRM unit can receive updated program / protocol information in a timely and efficient manner via software updates performed on the institutional network (e.g., without active user input), and actively make real-time treatment decisions and / or adjustments based on this information. Traveling clinicians may be unfamiliar with the emergency practices of a particular hospital and are therefore prone to errors and / or unnecessary delays in the clinical environment. Therefore, the disclosed centrally managed CRM unit can synchronize the actions taken by different clinicians in emergency situations by explicitly providing protocol information to the corresponding clinicians, causing treatment changes, and reducing uncertainty and improving coordination.

[0007] By dynamically presenting relevant protocol information on the display of the ICM or on the display of the user device of the corresponding clinician, a user interface can be presented to the clinician or a group of clinicians in which important information is emphasized or highlighted. The interface and / or the algorithm behind the interface can include and / or integrate a calculator for determining the patient's weight-based drug dosage. In addition, information about the drug (e.g., mixing ratios of different drugs, compatibility of drugs) and adverse reactions can also be presented to the clinician without the clinician having to find and read the instructions on the drug packaging. In addition, the subject technology enables clinicians to navigate to relevant information more quickly by guiding one or more clinicians to the required steps and order of information at the appropriate time. Additional resources can be accessed using the CRM program through the communication function of the ICM (e.g., submitting pharmacy requests, convening expert consultations, requesting code alerts, requesting equipment, accessing the patient's electronic health record to obtain key health and allergy information). The CRM can retain a record of the steps performed by different clinicians for later analysis.

[0008] According to various aspects, the subject technology provides a system and method for intelligent medical device resource management. In this regard, a medical device resource management system for infusion pumps and related equipment is disclosed.

[0009] According to various aspects, a disclosed medical device resource management system includes: a communication interface, which is configured to exchange information with multiple medical devices and exchange information with at least one of multiple user devices; a processor; and a non-transitory computer-readable medium, which includes instructions, which, when executed by the processor, cause the medical device resource management system to: monitor multiple medical devices for adjustments to the multiple medical devices during a time period; based on the monitoring, identify adjustments to the multiple medical devices during the time period; build a treatment profile associated with a patient and multiple medical devices based on the identified multiple adjustments; identify adverse events related to the patient or a corresponding medical device among the multiple medical devices; in response to identifying the adverse event: generate multiple continuous control signals based on the treatment profile to correct the adverse event, each control signal being associated with a different medical device among the medical devices or a different user.

[0010] According to various aspects, a disclosed method includes: monitoring a plurality of medical devices for adjustments to the medical devices during a time period; based on the monitoring, identifying a plurality of adjustments to the medical devices during the time period; constructing a treatment profile associated with a patient and the medical devices based on the identified plurality of adjustments; identifying an adverse event associated with the patient or a corresponding medical device in a plurality of medical devices; in response to identifying an adverse event: generating a plurality of continuous control signals based on the treatment profile to correct the adverse event, each control signal being associated with a different medical device in the medical devices or a different user. Other aspects include corresponding systems, apparatus (e.g., infusion devices), and computer program products for implementing corresponding methods and features thereof.

[0011] It will be appreciated that other configurations of the subject technology will become apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are illustrated and described by way of illustration. As will be appreciated, the subject technology is capable of other and different configurations, and several of its details can be modified in various other aspects, all without departing from the scope of the subject technology. Therefore, the accompanying drawings and detailed description should be considered illustrative in nature rather than as limiting. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] For a better understanding of the various described embodiments, reference should be made to the following description of the embodiments in conjunction with the following drawings. Throughout the drawings and description, like reference numerals refer to corresponding parts.

[0013] Figure 1 An example of an institutional patient care system for a healthcare organization in accordance with aspects of the subject technology is depicted.

[0014] Figure 2 is a conceptual diagram illustrating an example system architecture including an example fleet resource management unit in accordance with aspects of the subject technology.

[0015] Figure 3 is a conceptual diagram illustrating an example user interface for placing a code call in accordance with aspects of the subject technology.

[0016] Figure 4 Depicted is an example process performed prior to initiating closed-loop control in accordance with aspects of the subject technology.

[0017] Figure 5 Depicted are example selection panels in accordance with aspects of the subject technology.

[0018] Figure 6 A selection catalog for other emergency situations in accordance with aspects of the subject technology is shown.

[0019] Fig. 7ADepicted are example processes for intelligently responding to urgent clinical situations in accordance with aspects of the subject technology.

[0020] Figure 7B Describes various aspects of the subject technology Fig. 7A The following sections describe the example procedures shown in .

[0021] Fig. 8A Depicted are example processes for intelligently responding to urgent clinical situations in accordance with aspects of the subject technology.

[0022] Figure 8B Describes various aspects of the subject technology Fig. 8A The following sections describe the example procedures shown in .

[0023] Fig. 9 An example process for medical device resource management in accordance with aspects of the subject technology is depicted.

[0024] Fig.10 is a conceptual diagram illustrating an example electronic system 1000 for crew resource management in accordance with aspects of the subject technology. DETAILED DESCRIPTION

[0025] Reference will now be made to embodiments, examples of which are shown in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide an understanding of the various described embodiments. However, it will be apparent to one of ordinary skill in the art that the various described embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks are not described in detail in order to avoid unnecessarily obscuring aspects of the embodiments.

[0026] Figure 1 An example of an institutional patient care system 100 for a healthcare organization in accordance with aspects of the subject technology is depicted. Figure 1 In the present invention, patient care devices (or generally "medical devices") 12 are connected to the hospital network 10. The term patient care device (or "PCD") can be used interchangeably with the term patient care unit (or "PCU"), either of which can include various auxiliary medical devices, such as infusion pumps, vital signs monitors, medication dispensing equipment (e.g., cabinets, suitcases), medication preparation equipment, automatic dispensing equipment, modules coupled to one of the foregoing (e.g., a syringe pump module configured to be attached to an infusion pump), or other similar equipment. Each element 12 is connected to the internal medical and health network 10 via a transmission channel 31. The transmission channel 31 can be a wired or wireless transmission channel, for example, an 802.11 wireless local area network (LAN). In some embodiments, the network 10 also includes computer systems located in various departments throughout the hospital. For example, Figure 1 The network 10 optionally includes computer systems associated with an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers, and / or a medical decision support system. As further described below, the network 10 may include separate sub-networks. In the depicted example, the healthcare network 10 includes a device network 40 through which the patient care devices 12 (and other devices) communicate in accordance with normal operation.

[0027] In addition, the institutional patient care system 100 may include a separate information system server 30, the functionality of which will be described in more detail below. Furthermore, although the information system server 30 is shown as a separate server, the functionality and programming of the information system server 30 may be incorporated into another computer if this is desired by the engineers designing the institutional information system. The institutional patient care system 100 may also include one or more device terminals 32 for connecting and communicating with the information system server 30. The device terminal 32 may include a personal computer, a personal data assistant, a mobile device (such as a laptop, tablet computer, augmented reality device, or smart phone) configured with software for communicating with the information system server 30 via the network 10.

[0028] The patient care device 12 includes a system for providing patient care, such as U.S. Patent Application No. 5,713,856 described in Eggers et al., which is incorporated herein by reference for this purpose. The patient care device 12 may include or contain a pump, a physiological monitor (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter and other patient monitors), a therapeutic device, and other drug delivery devices that can be used according to the teachings set forth herein. In the depicted example, the patient care device 12 includes an interface device 14 connected to one or more functional modules 16, 18, 20, 22, also referred to as an interface unit 14. The interface unit 14 includes a central processing unit (CPU) 50 connected to a memory (e.g., a random access memory (RAM) 58), and one or more interface devices, such as a user interface device 54, an encoded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. The interface unit 14 also (although not necessarily) includes a main non-volatile storage unit 56 (such as a hard drive or non-volatile flash memory) for storing software and data, and one or more internal buses 64 for interconnecting the aforementioned elements.

[0029] In various embodiments, the user interface device 54 is a touch screen for displaying information to the user and allowing the user to input information by touching a defined area of ​​the screen. Additionally or in the alternative, the user interface device 54 may include any device for displaying and inputting information (specially configured with one or more of the features described), such as a monitor, printer, keyboard, soft keys, mouse, trackball and / or light pen. The data input device 60 may be a bar code reader capable of scanning and interpreting data printed in a bar code format. Additionally or in the alternative, the data input device 60 may be a specially configured device for inputting encoded data into a computer, such as one or more devices for reading a magnetic strip, a radio frequency identification (RFID) device, whereby digital data encoded in an RFID tag or smart tag (defined below) is captured by the reader 60 via radio waves, a PCMCIA smart card, a radio frequency card, a memory stick, a CD, a DVD or other analog or digital storage medium. Other examples of the data input device 60 include a voice activated or identification device or a portable personal data assistant (PDA). Depending on the type of interface device used, the user interface device 54 and the data input device 60 may be the same device. Although the data input device 60 is Figure 1 14, but it is recognized that the data input device 60 can be integrated into the pharmacy system 34, or located externally and communicate with the pharmacy system 34 via an RS-232 serial interface or other suitable communication means. The auxiliary interface 62 can be an RS-232 communication interface, but other means for communicating with peripheral devices in the environment (such as printers, patient monitors, infusion pumps or other medical devices) can be used without departing from the subject technology. Additionally, the data input device 60 can be a separate functional module, such as modules 16, 18, 20 and 22, and is configured to communicate with the controller 14, or other systems on the network using suitable programming and communication protocols.

[0030] The network connection 52 may be a wired or wireless connection, such as via Ethernet, WiFi, BLUETOOTH, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem, or a cable modem. A direct or indirect network connection may be used, including but not limited to a telephone modem, a MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link, a personal area network connection, a local area network connection, a cellular link, or a WLANS connection or other wireless connection.

[0031] Functional modules 16, 18, 20, 22 are specially configured devices for providing care to a patient or for monitoring the patient's condition. Figure 1As shown, at least one of the functional modules 16, 18, 20, 22 can be an infusion pump module, such as an intravenous infusion pump for delivering drugs or other fluids to a patient. For the purpose of this discussion, the functional module 16 is an infusion pump module. Each of the functional modules 18, 20, 22 can be a patient treatment or monitoring device, including but not limited to an infusion pump, a syringe pump, a patient-controlled analgesia (PCA) pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, or an intracranial pressure monitor, etc. The functional modules 18, 20 and / or 22 can be printers, scanners, barcode readers, or any other peripheral input, output, or input / output devices.

[0032] Each functional module 16, 18, 20, 22 communicates directly or indirectly with the interface unit 14, which provides overall monitoring and control of the device 12. Figure 1 As shown, or as detailed by Eggers et al., the functional modules 16, 18, 20, 22 can be physically and electronically connected to one or both ends of the interface unit 14 in a serial manner. However, it is recognized that there are other means for connecting the functional modules to the interface unit, which can be used without departing from the subject technology. It will also be appreciated that a device (such as a pump or patient monitoring device) that provides sufficient programmability and connectivity may be able to operate as a stand-alone device and communicate directly with the network without being connected through a separate interface unit or control unit 14. As described above, additional medical devices or peripheral devices can be connected to the patient care device 12 via one or more auxiliary interfaces 62.

[0033] Each functional module 16, 18, 20, 22 may include a module-specific component 76, a microprocessor 70, a volatile memory 72, and a non-volatile memory 74 for storing information. Figure 1 14 , but any number of devices may be connected directly or indirectly to the central controller 14 . The number and type of functional modules described herein are intended to be illustrative and in no way limit the scope of the subject technology. Module-specific components 76 include specially configured components necessary to operate a particular module, such as a pumping mechanism for an infusion pump module 16 .

[0034] Although each functional module may be capable of at least some degree of independent operation, interface unit 14 monitors and controls the overall operation of device 12. For example, as will be described in more detail below, interface unit 14 provides programming instructions to functional modules 16, 18, 20, 22 and monitors the status of each module.

[0035] The patient care device 12 can operate in several different modes or personalities, each of which is defined by a configuration database. The configuration database can be a database 56 internal to the patient care device, or an external database 37. A particular configuration database is selected based at least in part on patient-specific information (such as patient location, age, physical characteristics, or medical characteristics). Medical characteristics include, but are not limited to, patient diagnosis, treatment prescriptions, medical history, medical records, patient care provider identity, physiological characteristics, or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., doctor identity) or the location of the patient care device 10 in a hospital or hospital computer network. Patient care information can be input through interface devices 52, 54, 60, or 62, and can originate from anywhere in the network 10, such as, for example, from a pharmacy server, an admission server, a laboratory server, etc.

[0036] Medical devices incorporating aspects of the subject technology may be equipped with a network interface module (NIM) that allows the medical device to participate as a node in a network. Although for purposes of clarity, the subject technology will be described as operating in an Ethernet network environment using the Internet Protocol (IP), it will be understood that the concepts of the subject technology are equally applicable to other network environments, and such environments are intended to be within the scope of the subject technology.

[0037] Data from and to various data sources can be converted to network-compatible data using existing techniques, and information movement between medical devices and the network can be achieved by various means. For example, patient care devices 12 and network 10 can communicate via automatic interaction, manual interaction, or a combination of automatic and manual interaction. Automatic interaction can be continuous or intermittent, and can be achieved through direct network connection 54 (such as Figure 1 ), or occurs via an RS232 link, MIB system, RF link (such as BLUETOOTH), IR link, PANS, LANS, WLANS, digital cable system, telephone modem or other wired or wireless communication means. Manual interaction between the patient care device 12 and the network 10 involves the physical transfer of data between the systems intermittently or periodically using, for example, a user interface device 54, a coded data input device 60, a bar code, a computer disk, a portable data assistant, a memory card or other medium for storing data. The communication means in various aspects are bidirectional, with data accessed from as many points of distributed data sources as possible. Decision making can occur in various places within the network 10. For example, and not by way of limitation, decisions can be made at the HIS server 30, decision support 48, a remote data server 49, a hospital department or unit station 46, or within the patient care device 12 itself.

[0038] All direct communications with medical devices operating on a network according to the subject technology may be performed through an information system server 30, referred to as a remote data server (RDS). According to aspects of the subject technology, a network interface module incorporated into a medical device (such as, for example, an infusion pump or a vital sign measurement device) ignores all network traffic that does not originate from an authenticated RDS. The primary responsibility of the RDS of the subject technology is to track the location and status of all networked medical devices with a NIM and maintain open communications.

[0039] In some embodiments, the drug delivery modules 16, 18, 20, 22 include an insertion port for expansion. Thus, a new drug delivery module can be attached to the PCU 12 by coupling a connector via the insertion port, which can include electrical terminals so that the added drug delivery module 16, 18, 20, 22 can transmit information to and receive information from the control module 14. In some embodiments, the added drug delivery module 16, 18, 20, 22 can also receive power from the control module 14 via the insertion port. The control module 14 can include a main display, memory, and a processor (see Fig.10 ), and can be configured to display operating parameters and drug delivery status, as well as further information associated with each of the drug delivery modules 16, 18, 20, 22. According to various embodiments, the module display can also display physiological data (e.g., vital signs) associated with the patient.

[0040] The main display (e.g., I / O 54) can be configured to display one or more user interfaces for displaying operating parameters or other data associated with the modules 16, 18, 20, 22, and / or physiological parameters associated with the patient. The main display can include multiple user interfaces, each individual user interface graphically displaying information of a corresponding one of the medication modules, including information also displayed on the corresponding module display. In some embodiments, the control module 14 includes a communication module (including, for example, an antenna) that is configured to communicate wirelessly with the controller or with a network.

[0041] Reference Figure 1, when the drug delivery modules 16, 18, 20, 22 begin infusing a drug into a patient, the control module 14 is configured to create and manage an infusion session within the memory of the control module (or associated module). For purposes of the present disclosure, an infusion session includes state information of the PCU 12, its control module 14, and / or its associated modules, which is recorded and saved to the memory during a specific time period. The state information includes, but is not limited to, a record of parameter values ​​utilized by the PCU, its control modules, and / or its associated modules during a time period, and / or a record of physiological data collected during the time period. During the infusion, physiological data associated with the patient is recorded in the session, and operating parameter values ​​and modifications to operating parameters of the PCU, its control modules, and / or modules are also recorded in the session.

[0042] If not logged into the PCU 12, the clinician can approach a sensor (e.g., 54, 60) on the PCU 12 to scan his or her badge, and the PCU can attempt to authenticate the clinician by sending the clinician's scanned identification to the server 30. The clinician's badge can incorporate a radio frequency identification device (RFID) that is read by a scanner integrated with the PCU or a portable scanner associated with the PCU. The clinician can scan his or her badge at the control module 14 to identify and authorize the clinician to initiate medication. Once the clinician is associated with the PCU and / or one or more modules, the clinician's identity is associated with the session. The same applies to the patient. The clinician can use a portable scanner to scan the patient's wristband, or use a sensor on the PCU 14 (or its control module) to associate the patient with the PCU and / or module (and session).

[0043] The control unit 14 of the PCU 12 is configured to generate and display (e.g., in a display) a graphical representation of the infusion session that includes all parameters infused during the session and a graphical visualization of the parameters and physiological data obtained during the session. The graphical representation may include pseudo-identifiers for unknown data until such data is replaced with known identifiers. At this point, the graphical representation is displayed with the known patient identifier.

[0044] Figure 22 is a conceptual diagram showing an example system architecture according to various aspects of the subject technology, the example architecture including an example crew resource management unit. In the depicted example, the care providing system 200 includes an intelligent control module (ICM) 202. The ICM 202 provides direct control of the connected medical equipment to assist clinicians in providing more centralized control and management of the equipment. The ICM 202 provides a modular interface system through which various biometric sensors 216 used in a medical environment can be connected in a universal manner to facilitate control of the connected medical equipment. For example, the biometric sensor 216 may include one or more of a heart rate monitor, an oxygen sensor, and an intravenous (IV) flow rate monitor, all of which may be connected to the ICM 202 to facilitate centralized control of one or more infusion devices in addition to the input of the clinician. The ICM 202 may also be connected to a server and / or a cloud-based system for further data entry, data coordination, and reporting. Examples of cloud-based systems include a cloud-based drug information database 224 (or prescription set) and a hospital network 226 including an electronic medical record (EMR) system or database 228.

[0045] The hospital network 226 may also include a code team 230 system and / or network that responds to code alerts. The code team 230 includes experts 232 (human or AI), pharmacies 234, biomedical technicians 236, crisis management resources 242, supply infrastructure 240, and additional resources 238 for responding to requests made to the code team 230.

[0046] In the depicted example, the ICM 202 includes a control unit 208 that provides processing of control algorithms, as well as connecting circuits and / or software to enable closed-loop and semi-closed-loop control capabilities for one or more medical devices at the point of use. In some embodiments, the ICM 202 provides an external interface, such as a user interface 204, for interaction between an IV infusion pump 214 and one or more different physiological or biometric sensors 216, and for providing input parameters that can be used to control the titration of an IV infusion of a drug to a patient. For example, the syringe pumps 220 and 222 can contain drugs (derived from an IV infusion bag 218) that can be titrated and provided to the patient. In this regard, the ICM 202 can incorporate control software (including, for example, one or more algorithms in unit 208) that can be customized for specific or general medical treatments.

[0047] A closed-loop control system as described herein generally refers to a system that does not rely on external manual input to deliver treatment. Once configured, the closed-loop system is able to provide treatment autonomously, receive feedback from one or more sensors 216, and automatically adjust the treatment as needed based on the feedback. A treatment profile associated with a patient and one or more medical devices involved in the treatment can be generated and / or updated based on the adjustments made by the closed-loop system. A semi-closed-loop control system as described herein is similar to a closed-loop control system, except that in some cases, adjustments to the treatment can depend on external input. In some embodiments, a semi-closed-loop control system can be referred to as a decision support system. Similar to a closed-loop system, a treatment profile associated with a patient and / or one or more medical devices involved in the treatment can be generated and / or updated based on the adjustments made by the semi-closed-loop control system.

[0048] The ICM provides several advantages as a unit separate from the medical device. For example, the advancement of sensors (e.g., one or more biometric sensors 216) may be much faster than the development of infusion pump systems (e.g., pump system 214), and therefore the control system can adapt to these changes more quickly. It is expected that the control algorithm will be updated to address changes in treatment methods, available drugs, and patient physiology. For this reason, it is expected that the algorithm resides in a component different from the pump system in order to adapt to more frequent changes. In addition, machine learning and artificial intelligence can account for patient changes related to physiological parameters, such as age, genetics, health history, and other characteristics and environmental factors. Systems that include such capabilities can involve large databases and complex programs that require powerful microprocessors and data storage capabilities to perform the required timely and accurate calculations. These systems are generally not able to run on systems that currently only use IV pumps, but can reside on servers 30 or other cloud-based systems that can be accessed from the ICM.

[0049] In addition, the ICM 202 of the subject technology can be adapted to a variety of pump systems and sensor inputs. The ICM 202 can also be configured to add wireless, Bluetooth, and LAN connections to pump systems where current wireless, Bluetooth, and LAN connections are not available. For example, Figure 2 An ICM 202 is shown with a wireless connection 212 for communicating with a network system 244 at the hospital. Adding such communications to the pump system 214 can enable other functions, such as remote monitoring and control of the infusion pump, and facilitate access to the EHR 228. Thus, by integrating electrical and processing components separate from the pump, the subject technology facilitates the integration of additional capabilities without modifying the housing and electronics of the pump. Separating the physiological sensing and control system from the infusion pump system can further provide a more streamlined regulatory approval process.

[0050] According to various embodiments, the ICM 202 facilitates separation of control software from embedded firmware of pumps and sensors, which can facilitate a scalable and rapidly configurable system to provide closed-loop control of medical treatments. In addition, the ICM 202 can be configured to operate with multiple sensors via electrical connectors and / or wireless communications. The ICM 202 can include one or more microprocessors and algorithms to provide signal conditioning and / or convert sensor signals into appropriate physiological parameters for the connected medical device. These parameters can then be used in a control algorithm to provide control to, for example, an infusion pump to deliver the desired drug or fluid to achieve the desired clinical outcome. As used herein, "connecting" a device or "operably connecting" a device may include establishing a physical (e.g., wired) or virtual (e.g., wireless) connection between the devices.

[0051] The user interface 204 of the ICM 202 may include a display module or a touch-sensitive display module configured to provide a user interface for displaying information related to the patient's physiological state and the system control state. In some embodiments, the user interface 204 includes circuitry within the housing of the ICM 202 that provides display information to an external display device. An example of such an external display device includes a multi-parameter monitor (MPM) 210. The MPM 210 may, for example, display various vital statistics of a patient in the operating room (e.g., electrocardiogram (ECG), oxygen saturation (SpO 2 )) so that these vital statistics are visible to clinicians (e.g., all clinicians) in the operating room. The display on the ICM 202 can be mirrored via the associated MPM 210 to provide information to devices connected to the MPM 210 and / or clinicians involved in the treatment.

[0052] The ability of ICM 202 to connect to another display (e.g., MPM 210) provides modular scalability. For example, in some use cases, a wider user interface may be beneficial. A wider user interface may include the display of data and graphics, for which a larger high-resolution display may be used. Some use cases may benefit from a display with minimal information and a corresponding user interface to support such a configuration. A smaller, space-saving and / or lower-cost locally connected display may then be used.

[0053] According to various embodiments, the ICM 202 includes a crew resource management unit (CRM) 206. The CRM 206 stores protocol information (e.g., information about processes and steps associated with treatments and patients), making the information easily accessible in the ICM 202. In some embodiments, the CRM 206 provides information to the user interface 204, allowing the system to more efficiently (e.g., using less device resources such as memory, power, processing cycles, user interface area, etc.) present and navigate through relevant information (e.g., using touch input on a touch screen). According to various embodiments, the CRM 206 guides the user to select a sequence of steps and the required information at the appropriate time, thereby avoiding consuming resources on information that is inappropriate or irrelevant to the current detected situation.

[0054] In some embodiments, the ICM 202 can access additional resources through the communication capabilities of the CRM 206. For example, the CRM 206 can access additional resources related to drug information and dosage calculations from internal or remote storage (e.g., from the drug information database 224, from centralized storage). In some embodiments, when a particular drug is to be administered, the CRM 206 can cause the user interface 204 and / or other operably connected user devices to display a patient's dosage calculator. In some embodiments, the dosage calculator is a weight-based calculator that takes into account the patient's weight (e.g., the patient's weight is provided to the ICM 202 by manual input by a clinician or based on information received from the EHR database 228). In some embodiments, the calculation of weight-based drugs can be easily accessed through the user interface 204 or one or more user devices communicatively connected to the ICM 202. The patient's electronic health record can also be directly accessed through the ICM 202 to provide key health and allergy information to the clinician. Additional resources related to the drug information accessed by the ICM 202 via the CRM 206 may include information about the compatibility of the drugs that the patient is prescribed to receive. In some embodiments, the CRM 206 can cause the user interface 204 and / or other user device to display mixing ratio instructions. For example, the CRM 206 can cause the user interface 204 to specify the current or programmed flow rate of the first fluid from the syringe pump 220, the current or programmed flow rate of the second fluid from the syringe pump 222, and the current or programmed flow rate of the infusion fluid from the infusion bag 218, so as to administer the appropriate mixture to the patient during the infusion.

[0055] In one example, the CRM 206 can access additional resources by allowing the clinician to electronically deliver or place a pharmacy request to the pharmacy 234 via the ICM 202. The CRM 206 can cause the user interface 204 to display controls that allow the clinician to call in one or more specialists for a consultation (e.g., virtually using a camera and / or data from a biometric sensor 216 that is communicatively connected to the ICM 202; or requesting a face-to-face consultation at the patient's location). In some embodiments, the CRM 206 can connect the clinician to the AI. The CRM 206 can cause the user interface 204 to display controls that allow the clinician to send a code alert so that additional resources and personnel (e.g., humans or AI) can respond to the medical problem. The CRM 206 can cause the user interface 204 to display controls for equipment requests or other resources required by the patient. Thus, in the event that a hospital code needs to be issued, the clinician can simply use the CRM 206 to call up a list, which will then present the appropriate codes that can be used for a specific request sent via the hospital network 244. In some implementations, the user interface may include a control element that, when activated, transmits a control message to a device in communication with the CRM 206 to request a resource.

[0056] Figure 3 6 is a conceptual flow diagram of a code call placed via a user interface control in accordance with aspects of the subject technology. Example user interface 204 includes a control 602 for triggering a code call. In some implementations, user input to control 602 causes a code blue control button 604, a code red control button 606, a code yellow control button 608, a code orange control button 610, and a control button 612 for clearing a code call to be displayed in an updated user interface. In some implementations, control 602 and code blue control button 604, code red control button 606, code yellow control button 608, code orange control button 610, and a control button 612 for clearing a code call are displayed simultaneously.

[0057] In some embodiments, upon receiving user input to a code blue button 604, the ICM 202 accesses a code team 230 in the hospital network 226 via a wireless connection 212 to a network system 244 at the hospital. Based on the various inputs, the CRM 206 can make a decision based on the user input and / or trained artificial intelligence as to whether a code call should be sent to an appropriate team within the hospital organization. For example, the CRM 206 can direct a code blue request to a cardiac arrest response team. Thus, a code call can be automatically determined and sent, or a clinician can be suggested for confirmation. When a user interaction is indicated, the user interface 204 can display one or more code buttons 604 to 612 to facilitate the user's action on the code call.

[0058] In some embodiments, upon receiving user input to the code red code button 606, the CRM 206 directs the code red request to a fire response team within the code team 230 in the hospital network 226 via the wireless connection 212 with the network system 244 at the hospital. In some embodiments, upon receiving user input to the code yellow code button 608, the CRM 206 directs the code yellow request to a triage response team within the code team 230 in the hospital network 226 via the wireless connection 212 with the network system 244 at the hospital. In some embodiments, upon receiving user input to the code orange code button 608, the CRM 206 directs the code orange request to an electronic health record (EHR) down response team via the wireless connection 212 with the network system 244 at the hospital. Such a team is triggered when the EHR database 228 is down and / or inaccessible. When a clinician accidentally sends a code request when one is not needed, control button 612 allows the CRM 206 to clear the call, and / or communicate with the code team 230 so that the code request call will be cleared.

[0059] The CRM 206 may include or be operably connected to decision making algorithms for determining whether a code call should be made or suggested. These algorithms may be in the form of a neural network that is centrally located on the hospital organization's network 10 so as to communicate with the CRM 206 and the medical devices 12 and other systems on the network. For example, such algorithms may be updated by downloading updated software to the ICM 202 or to a server 30 responsible for executing at least a portion of the algorithms. In this way, the CRM decision making capabilities may be updated independently of the devices that it monitors and / or controls. According to various embodiments, new CRM programs or changes may be implemented in a more timely and efficient manner through software updates performed on the institution's network (e.g., network 244).

[0060] The ICM 202 includes one or more microprocessors to facilitate the execution of closed-loop algorithms, control infusion pumps, receive biometric sensor inputs, and provide a user interface (UI) 204 including a touch screen display. The user interface allows the input of patient and procedural information, based on which the control loop operates to control the infusion pump and receive sensor inputs. The CRM 206 can be part of the firmware and can be called up manually or automatically in response to an event through the user interface 204 when an emergency occurs. In addition to the CRM 206, there can also be a setup function that provides an inventory of all connected systems to ensure that they are operational before starting closed-loop control.

[0061] In an emergency situation, CRM 206 is used to provide information for handling various situations. In some embodiments, CRM 206 is invoked by a clinician (e.g., by manually navigating through user interface 204, or navigating through a user interface on a clinician's user device that is communicatively connected to CRM 206). In some embodiments, protocol information from CRM 206 is automatically provided to the clinician without user input (e.g., automatically displayed on user interface 204 when an emergency situation is detected).

[0062] According to various embodiments, the CRM 206 can provide dynamic variable substitution in the context of closed-loop control therapy. In this manner, the CRM can review sensor data and adjustments made to medical devices connected to the ICM 202 and determine whether variables associated with the management control of the medical devices should be replaced and / or changed. In some embodiments, the variables can be presented to the clinician via a display device (e.g., MPM 210 or a display screen associated with the clinician) during treatment, and inputs are received via the display device or associated inputs from the clinician.

[0063] During treatment (e.g., during surgery), messages (e.g., notifications or "tooltips") may be provided to one or more clinicians at the correct time based on the stage of the closed-loop algorithm. For example, cardiac-related notifications may be presented to the clinician responsible for cardiac treatment (e.g., logged into the ICM / CRM and associated with the treatment), and anesthesia notifications may be presented to the anesthesiologist responsible for anesthesia (e.g., logged into the ICM / CMR and associated with the treatment). Treatments may include, for example, surgery in a surgical care area, intubation in an intensive care unit, cardiac resuscitation in an emergency room, or physical therapy in a general hospital or clinical ward.

[0064] In some embodiments, depending on the program, the CRM 206 can attempt to correct the problem by dynamically adjusting the operating parameters and / or closed-loop algorithms of the corresponding medical device before displaying a message or alert to the clinician. In one example where the CRM detects a loss of a sensor signal, the CRM can attempt to reconnect the sensor (e.g., biometric sensor 216) or other device (e.g., display system) by reinitializing or restarting circuits associated with sensor or device communications, and if unsuccessful, make a recoverable recommendation to the clinician.

[0065] In some embodiments, different control signals may be sent to different devices based on different criteria and at different times. For example, a CRM may manage devices associated with a treatment procedure. The CRM may be pre-programmed with a workflow for the procedure and may be aware of one or more clinicians and one or more devices involved in performing or associated with the procedure. In addition to monitoring the closed-loop system, the CRM will also receive dynamic parameters passed in based on the workflow. The CRM may then provide different forms of information to each clinician based on the clinician's role in the procedure. For example, an anesthesiologist may receive only the information needed to make anesthesia decisions (e.g., bispectral sensor information related to the patient's trance state), and a cardiologist may receive only the information needed to make cardiology decisions (e.g., cardiac output). Similarly, each clinician may receive only suggestions and input prompts related to their specialty in the procedure. In addition, the CRM's algorithm may also provide messages at different times to coordinate adjustments to medications and other treatment decisions, thereby maintaining coordination between participating clinicians in accordance with the best practices of the healthcare organization. Whether the protocol information provided by the CRM 206 is manually called by the clinician or automatically provided by the CRM 206, the CRM 206 may additionally provide a user interface including a selection panel, such as Figure 5 shown.

[0066] Figure 5 Depicted are example selection panels in accordance with aspects of the subject technology. Figure 5 , the CRM 206 can display a selection panel 400 based on a hierarchy of emergency situations. In some embodiments, for the most critical emergency situations, advanced cardiac life support (ACLS) (402) is provided. The CRM 206 can automatically provide a display indicated on the selection panel 400 for ACLS (402) in response to detecting an adverse event associated with the patient (e.g., from a signal originating from the biometric sensor 216, a signal from another medical device connected to the patient). Alternatively, the display indicated on the selection panel 400 for ACLS (402) can be provided in response to a clinician navigating through the user interface 204, or in response to a user interface provided on a clinician's user device (e.g., the clinician detects that an adverse event associated with the patient is occurring and seeks further guidance from the ICM 202 for responding to the adverse event in a timely manner). In some embodiments, ACLS involves treatment of four conditions: asystole / pulseless electrical activity (PEA) (404); bradycardia (406); supraventricular tachycardia (SVT) (408); and ventricular tachycardia or ventricular fibrillation (410).

[0067] In some embodiments, the clinician selects an indicator (e.g., "1") associated with asystole / pulseless electrical activity (PEA) (404) to cause the CRM 206 to provide protocol information regarding treatment of asystole / PEA conditions. Alternatively, when the clinician selects an indicator (e.g., "2") associated with bradycardia (406), the CRM 206 causes protocol information regarding treatment of bradycardia conditions to be provided to be presented to one or more clinicians. When the clinician selects an indicator (e.g., "3") associated with supraventricular tachycardia (408), the CRM 206 causes protocol information regarding treatment of unstable and stable supraventricular tachycardias to be provided to be presented to one or more clinicians. When the clinician selects an indicator (e.g., "4") associated with ventricular tachycardia or ventricular fibrillation (410), the CRM 206 causes protocol information regarding treatment of ventricular tachycardia or ventricular fibrillation to be provided to be presented to one or more clinicians.

[0068] In some embodiments, after the clinician selects from a group of four conditions to be treated (e.g., by selecting an indicator corresponding to the condition), the CRM 206 causes a display of recommended steps for treating the selected condition. The display of recommended steps for treating the selected condition includes the order in which the steps are to be performed. In some embodiments, possible alternative steps are also displayed. In some embodiments, the tasks to be performed by each member of the group and the resources used to perform the steps are also displayed.

[0069] As previously described, the CRM 206 operating under the control of the AI ​​can analyze the sensor data and make at least one of the above-mentioned choices on behalf of the clinician. If a hard decision cannot be made (e.g., certain thresholds are not met), the CRM 206 can suggest a soft decision to the clinician using the selection panel 400. The clinician can then confirm, reject, or change the choice to treat the patient.

[0070] Figure 6 A selection catalog for other emergency situations according to aspects of the subject technology is shown. According to the depicted example selection panel 500, the CRM 206 causes the example selection panel 500 to display an emergency situation that may be less severe than ACLS. As described above, the CRM 206 can operate entirely under the control of the clinician, or can make decisions independently of the clinician based on analysis of input parameters (e.g., patient data, sensor data, etc.) in the clinical environment. In this way, decisions to display the panel 400 and / or selections related to the panel 400 can be made by the CRM, or suggested to the clinician by the CRM.

[0071] The CRM 206 can automatically provide a display indicated on the selection panel 400 for ACLS (402) in response to detecting an adverse event associated with the patient (e.g., from a signal originating from the biometric sensor 216, from a signal from another medical device connected to the patient). Alternatively, the display indicated on the selection panel 400 for ACLS (402) can be provided in response to the clinician navigating through the user interface 204, or in response to a user interface provided on the clinician's user device (e.g., the clinician detects that an adverse event associated with the patient is occurring and seeks further guidance from the ICM 202 for responding to the adverse event in a timely manner). In some embodiments, ACLS involves treatment of four conditions: asystole / pulseless electrical activity (PEA) (404); bradycardia (406); supraventricular tachycardia (SVT) (408); and ventricular tachycardia or ventricular fibrillation (410).

[0072] In some embodiments, the CRM 206 causes display of a checklist coordination interface (e.g., checklist coordinator) that allows a clinician (e.g., anesthesiologist, physician, nurse) to enter information and verify that steps have been completed (e.g., during a safety check). Verification information can be provided to and / or stored in the CRM 206. Examples of verification information include, for example, the identity of medical devices provided to the patient (e.g., infusion pumps, biometric sensors), information about the patient's anesthetic risk (e.g., values ​​previously calculated for the patient, multiple parameters used to calculate anesthetic risk), the presence of airway equipment (e.g., oxygen, ventilator), medications or drugs that have been or will be provided to the patient, medical devices that will be provided to the patient, emergency medications, equipment, and assistance that may be provided to the patient, and confirmation of the availability of equipment, assistance, and medications, and confirmation that the equipment is functioning. In some embodiments, a treatment profile associated with a patient is constructed based at least in part on the verification information provided to and / or stored in the CRM 206. During the setup process of the ICM 202, as described below with reference to Figure 4 As described in greater detail, the one or more medical device identifications and adjustments made are also recorded and logged by the ICM 202 to further build and update a treatment profile associated with the patient.

[0073] Figure 4An example process performed before starting closed-loop control according to aspects of the subject technology is depicted. According to the depicted example setup checklist process 300, the CRM 206 can cause the display of protocol information for pump setup (302). In some embodiments, the CRM 206 causes the user interface 204 to display a checklist during the setup process. Such a checklist provides a clear and orderly list of steps to be performed. In addition, additional screens can be displayed to provide troubleshooting assistance, and additional information can be displayed as needed. In some embodiments, the software in the ICM 202 provides self-checks and verifications before starting the procedure to ensure that the device is connected and operating normally. For example, the setup checklist 300 can start with setting up an infusion pump (302). The CRM 206 causes the protocol information to be displayed on the user interface 204 and / or on other user devices. In some embodiments, textual protocol information (e.g., "Make sure the AC is connected and the battery is fully charged," "Connect the pump to the ICM," "Perform a power-on self-test," "Set the pump for two-way control," "Verify communication between the ICM and the pump," "Start and install the IV device") is displayed. In some embodiments, the ICM 202 performs steps without further input from the user. For example, a power-on self-test is performed without active input from the user. While performing the steps described in the pump setup 302, the ICM 202 monitors whether an error or alarm is triggered (304). If an error or alarm is detected, the ICM 202 will continue to perform pump troubleshooting. In some embodiments, pump troubleshooting is performed automatically using closed-loop control without further user input. Examples of such automatic troubleshooting processes include: restarting or resetting the communication interface when no communication is detected between the ICM and the pump, resetting the MPM 210, resetting the biometric sensor 216. In some embodiments, pump troubleshooting includes identifying adjustments to one or more medical devices (e.g., setting the pump to bidirectional control, adjusting an IV device connected to the pump). Bidirectional communication technology allows the pump to receive medication orders directly from the EHR database 228 and allows the pump to send infusion data (drugs, rates, doses, volumes) to the patient's EHR infusion record in the EHR database 228.

[0074] According to the depicted example, when all steps associated with the pump setup (302) are completed, the ICM 202 causes the display of protocol information for the sensor setup (306) at the user interface 204 and / or on other user devices. In some embodiments, textual protocol information is displayed (e.g., "Connect sensor to patient," "Connect sensor to ICM," "Verify communication between sensor and ICM," "Perform calibration of sensor"). In some embodiments, the ICM 202 performs the steps without further input from the user. For example, calibration of the sensor is performed without active input from the user. While performing the steps described in the sensor setup 306, the ICM 202 monitors whether an error or alarm (308) is triggered. If an error or alarm is detected, the ICM 202 proceeds with sensor troubleshooting. In some embodiments, sensor troubleshooting is automatically performed using closed-loop control without further user input. Examples of such automatic troubleshooting procedures include restarting or resetting the communication interface when no communication is detected between the sensor and the ICM 202. In some embodiments, pump troubleshooting includes identifying adjustments to one or more medical devices (eg, recalibrating a sensor when a calibration error is detected in the sensor).

[0075] When all steps associated with the sensor setup (306) are completed, the ICM 202 causes the protocol information for the ICM setup (310) to be displayed at the user interface 204 and / or on other user devices. In some embodiments, textual protocol information is displayed (e.g., "Select Argus closed-loop control algorithm," "Enter patient parameters," "Verify all entries are software validated," "Connect IV device to venous access site"). In some embodiments, the ICM 202 performs the steps without further input from the user. For example, verify that all entry inputs regarding patient parameters are software validated without active input from the user. While executing the steps described in the ICM setup 310, the ICM 202 monitors whether an error or alarm is triggered (312). If an error or alarm is detected, the ICM 202 proceeds with sensor troubleshooting. In some embodiments, the ICM and / or closed-loop troubleshooting is performed automatically without further user input. Once all steps in the setup checklist 300 are completed, the ICM 202 is ready to begin closed-loop control.

[0076] In some embodiments, one or more of the steps (302, 306, 310) may be performed separately from the other steps and may be performed by one or more different processors or devices. Additionally, for purposes of explanation, the steps of setup checklist 300 are described as occurring serially or linearly. However, multiple steps of setup checklist 300 may occur in parallel. Additionally, the steps of setup checklist 300 need not be performed in the order shown and / or one or more steps of setup checklist 300 need not be performed.

[0077] Fig. 7A Depicted are example processes for intelligently responding to urgent clinical conditions in accordance with aspects of the subject technology. For purposes of explanation, this document refers to Fig. 7A and 7B and the components and / or processes described herein describe various blocks of the example process 700. One or more blocks of the process 700 may be implemented by a control device, such as, for example, one or more computing devices including, for example, the ICM 202 or components thereof. As previously described, the example process 700 may operate under the control of an AI, which may analyze sensor data and make one or more decisions within the example process 700 on behalf of a clinician. If a hard decision cannot be made (e.g., certain thresholds are not met), the CRM 206 may suggest a soft decision to the clinician, who may then confirm, reject, or change the choice to treat the patient.

[0078] According to the depicted example process 700, in response to Advanced Cardiac Life Support (ACLS) (404) being triggered upon registration of cardiac arrest, the CRM 206 causes the ICM 202 to provide a timed sequence of protocol information. In some embodiments, the triggering of the detection of cardiac arrest (404) is caused by user input (e.g., when the ACLS selection screen is presented, the user selects the cardiac arrest option). In some embodiments, the ICM 202 automatically detects cardiac arrest (404) without user input. For example, the ICM 202 detects a signal from the biometric sensor 216 indicating cardiac arrest. The user interface 204 can display an explanatory characteristic of cardiac arrest (702) in text form (e.g., "no pulse and non-shockable rhythm on ECG") to allow the clinician to confirm that the patient presents a condition consistent with cardiac arrest. Alternatively or additionally, the user interface 204 can display sensor information (704) associated with the condition. The additional display of text and sensor information improves safety in potentially stressful emergency situations and helps the clinician confirm the presence of cardiac arrest. A user may navigate to a display of textual interpretations or sensor information 704 by interacting directly with the ICM 202 , or with a user device (eg, tablet, smartphone, laptop, computer) that is in electronic communication with the ICM 202 .

[0079] The ICM 202 provides crisis resources to one or more clinicians (706). In some embodiments, the crisis resources are provided as text protocol information (e.g., "Notify Team," "Call Code," "Identify Leader," "Call Code Cart," "Assign Member to Read Aloud Cognitive Aid Tool"). In some embodiments, the text protocol information is provided on the user interface 204 of the ICM 202. In some embodiments, the text protocol information is provided to a user device (e.g., tablet, smartphone, laptop, computer) of one or more clinicians. In some embodiments, the CRM 206 associates specific protocol information with one or more corresponding clinicians and selectively provides the protocol information to the corresponding clinicians. For example, instead of displaying the text protocol information "Identify Leader," the CRM 206 automatically sends a message identifying the most senior clinician in the team of clinicians handling the medical emergency as the leader. Thus, after the emergency is triggered, the CRM 206 can provide decision information and team management guidance. As another example, without further input from the clinician, the CRM 206 can automatically call the code and direct the code to the relevant parties in the care environment based on input from the biometric sensor 216.

[0080] After all tasks associated with the crisis resource have been completed, the CRM 206 causes display of protocol information for performing CPR (708). For example, the protocol information includes specific numeric ranges for various procedures or maneuvers (e.g., "rate 100 to 120 compressions / minute, minimize interruptions," "depth ≥ 5 cm, allow chest recoil; consider use of backboard," "maintain EtCO 2 >10 mmHg, and diastolic blood pressure >20 mmHg", "rotate the compressor every 2 minutes to check rhythm", "place defibrillator pads, if VF / VT becomes shockable: use 200J biphasic or 360J monophasic defibrillation", "only when there are signs of ROSC (sustained increase in EtCO 2, spontaneous arterial waveform, rhythm changes), "If the airway is secure, perform prone CPR at the lower edge of the scapula", "Place defibrillator pads and check rhythm every 2 minutes"). In some embodiments, tasks associated with the protocol information are automatically assigned to corresponding members of the clinician team, allowing tasks to be completed faster and more efficiently. In some embodiments, the protocol information presented by the ICM 202 is recorded. In some embodiments, the protocol information presented by the ICM 202 is recorded and made available for subsequent verification. For example, the protocol information displayed on the user interface 204 is displayed by the ICM 202 records, which allows clinicians to analyze, check or verify whether processes and procedures are correctly performed according to the protocol information. In some embodiments, the protocol information displayed on the user device of the corresponding clinician is recorded locally on the user device, or recorded and saved in a cloud storage server associated with the hospital network 244, so that the presented protocol information can be retrieved later. In some embodiments, in addition to recording the protocol information presented to the clinician, or the ICM202 does not record the presented protocol information, but records information about the actual steps performed by the clinician. For example, the amount of medication provided to the patient, the code request sent from the ICM 202 to the code team 230, the type and number of medical devices operably connected to the ICM 202 (e.g., biometric sensors 216), and information recorded by the medical devices.

[0081] ICM 202 may determine that the patient's medical condition has changed to a different ACLS condition (710) after performing one or more steps (708) of the CPR procedure. For example, ICM 202 may determine based on the (updated) input that the patient's condition has changed to VFIB / VTACH (710), which has its own associated set of protocol information. ICM 202 then causes the protocol information for VFIB / VTACH to be provided to the clinician in a seamless manner.

[0082] According to the depicted example, after all tasks associated with CPR (708) have been completed, CRM 206 causes display of protocol information for performing an airway check (712). For example, the protocol information includes specific numerical ranges for various procedures or maneuvers (e.g., "100% O at 10 to 15 L / min"). 2 ”, “If mask ventilation: ratio of 30 compressions to 2 breaths”, “If airway secure: 10 breaths / minute with tidal volume 6-mL / kg”). In some embodiments, tasks associated with the protocol information are automatically assigned to corresponding members of the clinician team.

[0083] Figure 7B Describes various aspects of the subject technology Fig. 7A . After all tasks associated with the airway check (712) have been completed, the CRM 206 causes display of protocol information for IV (intravenous) access (714). For example, the protocol information includes textual protocol information (e.g., "Ensure functional IV or IO access").

[0084] After all tasks associated with the IV access (714) have been completed, the CRM 206 causes display of protocol information for the medication (716). For example, the protocol information includes text protocol information (e.g., "Turn off volatile anesthetic and vasodilator drips," "IV injection of 1 mg of epinephrine every 3 to 5 minutes," "If hyperkalemia occurs: IV calcium chloride 1 g; IV sodium bicarbonate 1 ampoule (50 mEq); IV 5 to 10 units of regular insulin and IV 1 ampoule of dextrose / D50 (50 mEq)," "If acidosis occurs: IV sodium bicarbonate 1 ampoule (50 mEq)," "If hypocalcemia occurs: IV magnesium chloride 1 g," "If hypoglycemia occurs: IV 1 ampoule of dextrose / D50 (50 mEq)"). In some embodiments, the CRM 206 causes display of an infusion calculator that calculates the infusion amount based on the patient's weight (718).

[0085] After all tasks associated with the medication (716) have been completed, the CRM 206 causes display of protocol information for extracorporeal membrane oxygenation (ECMO) / CPB (720). For example, the protocol information includes textual protocol information (eg, "Consider ECMO or CPB").

[0086] After all tasks associated with EMCO / CPB (720) have been completed, the CRM 206 causes display of post-arrest (722) protocol information. Return of spontaneous circulation (ROSC) refers to the restoration of a sustained heart rhythm that perfuses the body after cardiac arrest. For example, the protocol information includes textual protocol information (e.g., "If ROSC: arrange ICU care and consider cooling"). In some embodiments, after the post-arrest (722) protocol information has been displayed, the process 700 terminates.

[0087] Fig. 8A Depicted is an example process for intelligently responding to an emergency clinical condition in accordance with aspects of the subject technology. As previously described, the various blocks of process 700 may be implemented by ICM 202, an associated computing device, or components thereof, and may also operate under the control of algorithms that may make decisions and / or recommend actions to clinicians.

[0088] According to the depicted example process 800, when advanced cardiac life support (ACLS) is triggered due to recording bradycardia (406), the CRM 206 causes a timed sequence of protocol information provided by the ICM 202. In some embodiments, the triggering of bradycardia detection (406) is caused by user input (e.g., when the ACLS selection screen is presented, the user selects the bradycardia option). In some embodiments, the ICM 202 automatically detects bradycardia (406) without user input. For example, the ICM 202 detects a signal from the biometric sensor 216 indicating bradycardia. The user interface 204 can display an explanatory characteristic of bradycardia (802) in text form (e.g., "Pulse present, heart rate <50bpm, poor perfusion"), or the user interface 204 can display sensor information associated with the condition (804). The additional display of text and sensor information helps the clinician confirm the presence of bradycardia. A user may navigate to a display of textual interpretations or sensor information 804 by interacting directly with the ICM 202 , or with a user device (eg, tablet, smartphone, laptop, computer) that is in electronic communication with the ICM 202 .

[0089] The ICM 202 provides crisis resources to one or more clinicians (806). In some embodiments, the crisis resources are provided in the form of text protocol information (e.g., "Notify Team," "Call Code," "Identify Leader," "Call Code Cart"). In some embodiments, the text protocol information is provided on the user interface 204 of the ICM 202. In some embodiments, the text protocol information is provided to a user device (e.g., tablet, smartphone, laptop, computer) of one or more clinicians. In some embodiments, the CRM 206 associates specific protocol information with one or more corresponding clinicians and selectively provides the protocol information to the corresponding clinicians. For example, instead of displaying the text protocol information "Identify Leader," the CRM 206 automatically sends a message identifying the most senior clinician in the team of clinicians handling the medical emergency as the leader. Thus, after the emergency is triggered, the CRM 206 can provide decision information and team management guidance. As another example, without further input from the clinician, the CRM 206 can automatically call the code and direct the code to the relevant parties in the care environment based on input from the biometric sensor 216.

[0090] After all tasks associated with the crisis resources have been completed, the CRM 206 causes display of protocol information for checking the patient's pulse (808). In response to a determination of no pulse, protocol information for initiating CPR is displayed. In some embodiments, the CRM 206 automatically switches to displaying information for a cardiac arrest (404) condition without input from the clinician.

[0091] In response to determining that a pulse is present, protocol information for the airway check (812) is displayed. For example, the protocol information includes specific numerical ranges for various procedures or maneuvers (e.g., "10 to 15 L / min of 100% O 2 ”, “Confirm adequate ventilation and oxygenation”) In some embodiments, tasks associated with the protocol information are automatically assigned to the corresponding members of the clinician team, thereby allowing tasks to be completed faster and / or more efficiently. In some embodiments, the protocol information presented by the ICM 202 is recorded and made available for subsequent verification. For example, the protocol information displayed on the user interface 204 is recorded by the ICM 202, which allows the clinician to analyze, check or verify whether the process and procedures are correctly performed according to the protocol information. In some embodiments, the protocol information displayed on the user device of the corresponding clinician is recorded locally on the user device, or recorded and saved in a cloud storage server associated with the hospital network 244, so that the presented protocol information can be retrieved later. In some embodiments, in addition to recording the protocol information presented to the clinician, or the ICM 202 does not record the presented protocol information, but records information about the actual steps performed by the clinician. For example, the amount of medication provided to the patient, the code request sent from the ICM 202 to the code team 230, the type and number of medical devices operably connected to the ICM 202 (e.g., biometric sensors 216), and information recorded by the medical devices.

[0092] After all tasks associated with the airway check (812) have been completed, the CRM 206 causes display of protocol information for discontinuing vagus nerve stimulation (814). For example, the protocol information includes textual protocol information (e.g., "Deflate abdomen," "Relieve pressure on eyes, neck, ears, and brain," "Remove retractors, sponges, and padding," "Empty bladder"). In some embodiments, tasks associated with the protocol information are automatically assigned to corresponding members of the clinician team.

[0093] After all tasks associated with stopping vagus nerve stimulation (814) have been completed, CRM 206 causes display of protocol information for IV access (816). For example, the protocol information includes textual protocol information (eg, "Ensure functional IV or IO access").

[0094] Figure 8B Describes various aspects of the subject technology Fig. 8A , which is a subsequent portion of the example process shown in . After all tasks associated with IV access (816) have been completed, CRM 206 causes display of protocol information for medication (818). For example, the protocol information includes textual protocol information and / or the protocol information includes specific numeric ranges for various procedures or manipulations (e.g., "Consider reducing anesthetics or analgesics," "Intravenous (IV) atropine 0.5 to 1 mg every 3 minutes. Repeatable, up to 3 mg," "If atropine is ineffective: epinephrine 5 to 10 mcg / kg / minute," "Consider dopamine infusion 5 to 20 mcg / kg / minute," "Consider epinephrine 0.02 to 0.3 mcg / kg / minute," "If stable, consider intravenous (IV) glycopyrrolate 0.2 to 0.4 mg"). In some embodiments, CRM 206 causes display of an infusion calculator that calculates the infusion amount based on the patient's weight (820).

[0095] After all tasks associated with the medication (818) have been completed, the CRM 206 causes display of protocol information for pacing (822). For example, the protocol information includes textual protocol information (e.g., "place defibrillator pads," "consider temporary transcutaneous, transvenous, or esophageal pacing," "set pacemaker rate to at least 80 bpm," "increase current (mA) until electrical capture," "confirm mechanical capture with patient pulse," "set pacemaker output 10 mA above mechanical capture," "consult ICU and / or cardiology").

[0096] After all tasks associated with pacing (822) are completed, CRM 206 causes display of protocol information for the arterial line (824). For example, the protocol information includes textual protocol information (eg, "Consider arterial line placement").

[0097] After all tasks associated with arterial line (824) have been completed, CRM 206 causes display of protocol information for lab (826). For example, the protocol information includes textual protocol information (eg, "Send ABG, Hgb, Electrolytes, Troponin").

[0098] After all tasks associated with the lab (826) have been completed, the CRM 206 causes display of protocol information for the ischemia exam (828). For example, the protocol information includes textual protocol information (e.g., "obtain 12-lead ECG," "consider checking BNP and serial troponins"). In some embodiments, after the protocol information for the ischemia exam (828) has been displayed, the process 800 terminates.

[0099] In the depicted example, the ICM 202 is operably connected to the infusion device 206a (302). For example, the ICM 202 can be operably connected to the infusion device via wireless pairing or a wired connection.

[0100] According to various aspects of the subject technology, the application of ICM 202 for controlling infusion pumps and / or other medical devices can be used for closed-loop treatment of various conditions, such as anesthesia, blood conditions, transfusions, nursing or drug conversion, chemotherapy, enteral therapy, effusion, fluid balance conditions, blood glucose conditions, hemodynamic conditions, hydration, infiltration, nutritional care, patient-controlled analgesia, patient or fluid temperature conditions, or vasopressor ventilation. CRM 206 can be used for all of the above-mentioned use cases, and protocol information and / or other instructions are presented to the clinician in a manner specific to the use case.

[0101] For example, in anesthesia, the ICM 202 can monitor the anesthetic administered to the patient (e.g., the amount, flow rate, time interval of the anesthetic administered), while using the biometric sensor 216 to monitor and / or display the patient's blood pressure, blood oxygen level, cardiac function, and breathing pattern. Anesthesia may require a predetermined amount of drug administration to achieve the desired endpoint of hypnosis, immobility, and reflex inhibition during the procedure. Examples of the procedure include, for example, surgery in a surgical care area, intubation in an intensive care unit, cardiac resuscitation in an emergency room, or physical therapy in a general hospital or clinical ward. It can be administered as a combination of a hypnotic and an opioid, where the anesthesiologist manually titrates the dose or infusion rate of the two drugs to provide the best balance. Using a bispectral index sensor (BIS), the ICM 202 can monitor the depth of anesthesia and use closed-loop control of the infusion device to administer one or more appropriate amounts of IV drugs while preventing recovery of consciousness or excessive depth of anesthesia during medical treatment, thereby improving the patient's treatment outcome. For the anesthesia closed loop control use case as well as other use cases, the CRM 206 enables the anesthesiologist to command and control all resources at hand to perform anesthesia as planned and respond to problems that may arise. This approach allows knowledge of the actions required for the patient to be transformed into efficient team actions. In some embodiments, the CRM 206 divides the process to be performed into one of two types: information for decision elements and team management components, which allows for more efficient problem solving in complex, unstructured environments.

[0102] As another example, the ICM 202 can be connected to a biometric sensor 216 that is configured as a blood glucose monitor and maintains the patient's blood glucose by controlling the administration of insulin and / or one or more glucose solutions by an infusion device based on intelligent modeling and continuous blood glucose measurements. Blood glucose (BG) disorders, such as stress hypoglycemia and hyperglycemia, can be common complications for ICU patients. In addition, patients with type 1 and type 2 diabetes may be susceptible to hyperglycemia, as well as severe hypoglycemia caused by overcorrection of insulin. Therefore, insulin IV infusion controlled by the ICM 202 using a closed-loop configuration and input from continuous BG measurements is an ideal application for IV infusion of insulin and glucose to keep BG levels within a desired range.

[0103] As another example, vasopressor-based therapy may require frequent boluses, with appropriate adjustment of the infusion rate to avoid harmful periods of hypotension or hypertension. The above embodiments may also be used to manage sepsis treatments that require antibiotic administration and fluid resuscitation to correct hypotension. Such IV fluid management is important for sepsis patients, and controlling the timing, type, and amount of fluid administration is critical, as excess IV fluids can also be harmful.

[0104] In various embodiments, the ICM 202 may receive input based on one or more intelligent models and specific use cases and / or protocols and / or simulations to make decisions for controlling an infusion device. Such models, protocols, and simulations may be based at least in part on a machine learning algorithm that processes training data input based on a population of patients with similar conditions to the patient being treated.

[0105] In some embodiments, the ICM 202 can host multiple simultaneous closed-loop therapies (e.g., IV glucose control and hemodynamic stability) while running one or more closed-loop algorithms in synchronous connection with different sensors and actuators. An alternative embodiment can use multiple ICMs, each running a single closed-loop therapy.

[0106] In some embodiments, the ICM 202 obtains (e.g., downloads) a first algorithm from a server based on determining that one or more sensor devices are operably connected to the ICM 202. The ICM 202 may first confirm that the one or more sensor devices are associated with the first treatment and the type of infusion device before downloading the first algorithm. The ICM 202 may also download additional algorithms after determining that a new sensor is operably connected. The first algorithm may be configured to operate the infusion device based on real-time data received from the one or more sensor devices. For example, the first algorithm may be configured to operate the infusion device in a closed-loop mode based on real-time data received from the one or more sensor devices. The ICM 202 may also receive configuration parameters associated with the operation of the one or more infusion devices.

[0107] According to various embodiments, the modularity of the system provides scalability and a longer life cycle through dynamic updates. For example, a new sensor can be operably connected to the ICM 202. After the ICM 202 detects the new sensor, the ICM 202 can download a second algorithm associated with the new sensor and update the user interface to display a new data module associated with the new sensor. Data can then be received from the new sensor and displayed via the new data module. The infusion device can then be controlled in a closed-loop mode based on the real-time data received from the new sensor and one or more sensor devices, the downloaded first and second algorithms, and the received configuration parameters.

[0108] In various implementations, the ICM 202 builds a treatment profile associated with the patient and the medical devices based on the identified adjustments made to one or more medical devices. In some implementations, the identified adjustments are made by a closed-loop control system without additional user input.

[0109] The ICM 202 can identify adverse events associated with a patient or a corresponding medical device operably connected to the ICM 202. For example, data received from the biometric sensor 216 can indicate that a patient who is receiving a medical fluid (e.g., an anesthetic, insulin or other medication for blood sugar control, a vasopressor for infusion fluids) has abnormal readings for one or more of: blood pressure, blood oxygen level or heart function, or breathing pattern. Prior to and / or during treatment (e.g., receiving one or more medical fluids based on a particular use case), the ICM 202 creates and refines a treatment profile associated with the patient. In some embodiments, the ICM 202 monitors one or more medical devices operably connected to the ICM 202 and adjusts these medical devices during a time period during and / or after treatment.

[0110] In response to identifying an adverse event, the ICM 202 may generate one or more continuous control signals based on the treatment profile to correct the adverse event. Figure 5 ACLS events described in or Figure 6 Each of the continuous control signals is associated with a different one of the medical devices or a different user. In some embodiments, the continuous control signals include a display control signal. For example, the display control signal is a first control signal that causes a first message to be displayed on a first device (e.g., "Call Code," "Notify Team," "Call Code Car"), and a second control signal in the plurality of control signals causes a second message to be displayed on a second device at a different time than when the first message was displayed on the first device (e.g., "Keep EtCo 2 >10mmHg and diastolic pressure>20mmHg”). The display control signal causes 7A to 8B In some embodiments, the continuous control signal generates display control signals at different clinician's user devices (eg, an anesthesiologist's user device and a nurse's user device).

[0111] The systems and methods described herein may also provide context-sensitive help and / or checklists during different stages of use of the ICM 202, including initial setup and operation. For example, a user may be guided through initial setup of the ICM 202 using a web page or application program interface, or through initial setup of a medical device (to be operably connected to the ICM 202). In some embodiments, prior to installing and / or starting the ICM 202, an initial setup guide may be provided on one or more medical device and / or web page screens for use by a technician or staff member responsible for setting up the medical device and / or the ICM 202.

[0112] In some embodiments, installation includes assembling a kit for a specific use case (e.g., a glucose monitor for glucose control, a biometric sensor for vasopressor therapy). The kit may include an identification tag, such as a barcode, an AprilTag (e.g., a visual reference system that can be used for various tasks, including augmented reality, robotics, and camera calibration), a near field communication (NFC) tag, a non-fungible token (NFT). In some embodiments, the identification tag can interact with the ICM 202 (e.g., via an NFC communication device, Bluetooth, etc.). When scanned by a user, the identification tag causes the user to be displayed with instructions for connecting the kit to the ICM 202. In some embodiments, the CRM 206 provides a user interface for displaying a list and / or receiving input from a user to check the components in the assembled kit (e.g., by recording serial numbers, batch numbers of disposables).

[0113] During operation, the CRM 206 can be easily accessed on a web screen on the ICM 202 or on an external device (e.g., external tablet, phone, computer). In some embodiments, when a clinician is about to process a component of a treatment that is not electronically paired with the ICM 202 (e.g., a disposable kit, a disconnected or malfunctioning sensor), the clinician is able to scan the component (e.g., an identification tag on the component) and receive context-sensitive instructions associated with the component. For example, if a disconnected or malfunctioning sensor was previously paired and operated (e.g., poor sensor signal quality), scanning the AprilTag associated with the sensor will now provide instructions to restore the sensor or replace the sensor with a new sensor. In other words, once an identification tag associated with a particular tool is received, the CRM 206 is able to present tool-related prompts that are relevant to the user.

[0114] In some embodiments, when the system (e.g., an algorithm) identifies a user, such as through a login or other type of identity management, the system may choose to switch to providing setup instructions using an "expert mode" and skip more basic instructions. In some embodiments, the system determines which steps the user has completed during the setup process and jumps to a specific step by skipping all previously completed steps. In some embodiments, different installation instructions are provided to different users, and the system routes different messages to different people at the right time and in the right order, which may significantly shorten the setup process. For example, the user no longer needs to actively track his position in the setup process in order to proceed to the next step in the process - the system will automatically provide the necessary information to the user at the right time and in the right order. In some embodiments, the system also allows real-world modifications during the installation process. For example, the system may determine that a medical device has been accidentally unplugged during the installation process, and the system may directly provide instructions to resolve the error triggered by the disconnection, presenting instructions to the user at the right time, rather than troubleshooting the error at a later point in time.

[0115] In some embodiments, a medical device (e.g., biometric sensor 216) may include a microcontroller that communicates with a microcontroller of the ICM 202 to facilitate a secure handshake with the ICM 202 and / or the infusion device. The ICM 202, together with the corresponding infusion device and accessory device, forms a smart accessory system that improves safety by reducing human error and accessory damage. In some embodiments, the CRM 206 may include software instructions configured to facilitate automatic setting of infusion parameters associated with the connected accessories (e.g., on the infusion device). In some embodiments, each accessory may include software or firmware that is configured to provide self-diagnosis of hardware / firmware problems, which may then be communicated to the infusion device via the ICM 202. The ICM 202 may also communicate with each connected medical device to ensure proper functionality (e.g., via reports from the medical device) and automatically disable medical devices that do not report an efficient state, thereby preventing users from using incorrect or damaged medical devices.

[0116] According to various embodiments, the ICM 202 can be used as an intelligent device hub (IDH) with multiple hardware ports, each of which includes a universal connector. All connected medical devices communicate via a universal internal bus, thereby alleviating the need for dedicated ports; that is, various medical devices can be connected to the I / O ports to communicate with the infusion device via a common digital communication protocol. In this regard, a universal protocol associated with the IDH is implemented, and new medical devices utilizing the connector can be implemented without updating the IDH or the infusion device. Software updates can be pushed to the medical devices via the IDH.

[0117] Fig. 9 Depicted is an example process for medical device resource management according to aspects of the subject technology. For purposes of explanation, this document refers to Figures 1 to 8B and the components and / or processes described herein describe various blocks of the example process 900. One or more blocks of the process 900 may be implemented by, for example, one or more computing devices including the server 30, the ICM 202, or components thereof. Additionally or in the alternative, as previously described, the example process 900 may operate under the control of an AI, which may analyze the sensor data and make one or more decisions within the example process 900 on behalf of the clinician. If a hard decision cannot be made (e.g., certain thresholds are not met), the CRM 206 may suggest a soft decision to the clinician, who may then confirm, reject, or change the choice to treat the patient.

[0118] In some embodiments, one or more blocks can be implemented separately from other blocks and can be implemented by one or more different processors or devices. Also for explanation purposes, the blocks of the example process 900 are described as occurring in series or linearly. However, multiple blocks of the example process 900 can occur in parallel. In addition, the blocks of the example process 900 do not need to be executed in the order shown and / or one or more blocks in the example process 900 do not need to be executed.

[0119] The system performing the example process 900 includes an ICM 202 including a CRM 206 and an infusion device in communication with the ICM 202 via one of its ports.

[0120] In the depicted example, the ICM 202 monitors a plurality of medical devices operably connected to the ICM 202 for adjustments to the medical devices during a time period ( 902 ).

[0121] The ICM 202 makes one or more adjustments to the medical device during the time period based on monitoring the identification (904). In this regard, the ICM 202 may identify and / or record the adjustments to the medical device during the time period. The ICM 202 builds a treatment profile associated with the patient and the medical device based on the identified multiple adjustments (906). The ICM 202 identifies an adverse event associated with the patient or a corresponding medical device in the multiple medical devices (908). After identifying the adverse event, the ICM 202 (e.g., CRM 206) generates multiple continuous control signals based on the treatment profile to correct the adverse event, each control signal being associated with a different medical device in the medical device or a different user (910).

[0122] In some embodiments, ICM 202 sends each of a plurality of continuous control signals to different devices associated with different users. There may be more than one clinician in a clinical environment. For example, one or more doctors may work with one or more nurses and / or surgical technicians to provide treatment to patients (e.g., in an operating room). Therefore, CRM 206 may monitor the medical devices associated with the procedures performed during the time period and provide advice or instructions to each clinician individually. Examples of the procedures include, for example, surgery in a surgical care area, intubation in an intensive care unit, cardiac resuscitation in an emergency room, or physical therapy in a general hospital or clinical ward. In some embodiments, each clinician may receive instructions from different devices or display screens or sections of a user interface in MPM 210. In this regard, CRM may provide a first control signal (in a continuous control signal) to a first device, which causes a first message to be displayed on the first device, and a second control signal in a plurality of continuous control signals causes a second message to be displayed on a second device. For example, the second message may be displayed at a different time than when the first message is displayed on the first device. In some embodiments, the second control signal is sent to a device outside of an area associated with the procedure. When the adverse event includes a sensor failure, the ICM can send one of the continuous control signals to the medical device. In other words, the control signal includes a message for adjusting one of the medical devices. In some embodiments, a first control signal in the plurality of continuous control signals can include a reset command configured to cause operation of the medical device to restart.

[0123] According to various aspects, the disclosed medical device resource management system 202 includes a communication interface configured to exchange information with multiple medical devices and to exchange information with at least one of multiple user devices. The medical device may include, for example, at least one infusion device 214, and the user device may include an MPM 210 connected to the disclosed ICM 202 and / or one or more displays or associated devices associated with the corresponding clinician. In this regard, the system 202 includes a processor and a non-transitory computer-readable medium having instructions stored thereon, which, when executed by the processor, cause the medical device resource management system to monitor multiple medical devices for adjustments to multiple medical devices during a time period. For example, during a medical procedure, a closed-loop system or a semi-closed-loop system may adjust the medical device to stabilize the patient during the medical procedure. The clinician may make further adjustments to one or more medical devices during the procedure. In this regard, the ICM 202 identifies adjustments to multiple medical devices during a time period based on monitoring, and constructs a treatment profile associated with the patient and multiple medical devices based on the identified multiple adjustments. The ICM may then identify adverse events associated with the patient or a corresponding medical device in the multiple medical devices. For example, the ICM may determine via one or more biometric sensors that the patient has become unstable. For example, the cardiac monitor 216 may indicate that the patient has entered an abnormal rhythm, or the dual spectrum sensor 216 may indicate that the patient is no longer in a hypnotic state or is waking up. After identifying an adverse event, the ICM 202 may generate multiple continuous control signals based on the treatment profile to correct the adverse event, each control signal being associated with a different medical device or a different user in the medical device. In a closed-loop system, the corresponding control signal may be directed to adjust the infusion of vasopressors to stabilize the patient's cardiac output, or to adjust the amount of anesthetic drugs to keep the patient in a hypnotic state. In a semi-closed-loop system, the control signal may be a suggestion sent to a device associated with a clinician responsible for supervising the corresponding drug. For example, a notification regarding the adjustment of cardiac output and vasopressors may be sent to a cardiac surgeon, while a notification regarding anesthetic drugs may be sent to an anesthesiologist.

[0124] Therefore, the medical device resource management system can be configured to send each of the multiple continuous control signals to a different device associated with a different user. In some embodiments, monitoring multiple medical devices includes monitoring medical devices associated with procedures executed during the time period. In some embodiments, a first control signal in the multiple continuous control signals causes a first message to be displayed on a first device, and a second control signal in the multiple continuous control signals causes a second message to be displayed on a second device at a different time than when the first message is displayed on the first device. In some embodiments, the second control signal is sent to a device outside the area associated with the procedure. In some embodiments, the adverse event includes a sensor failure. As previously described, the continuous control signal may include a message for adjusting one of the medical devices.

[0125] In some embodiments, the medical device resource management system is configured to receive information about the role of the corresponding user associated with the corresponding user device. Such information can be obtained from the user device or from the hospital information server 30, which is responsible for the user's authorization of the user device and / or ICM 202 according to various embodiments. The ICM 202 can display different protocol information on the corresponding user device based on the role of the corresponding user based on multiple continuous control signals. In some embodiments, the continuous control signal can cause the display of the protocol information after receiving the user's selection of treatment (e.g., during the setting 310 of the ICM of the program). The treatment selected by the user may include treatment of one of cardiac arrest, bradycardia, ventricular tachycardia, or ventricular fibrillation.

[0126] ICM 202 may receive verification of one or more actions performed in response to a user selection of a treatment, and cause dynamic protocol information to be displayed based on the verification of the one or more actions. The protocol information may include emergency protocol information, and the emergency protocol information may be provided based on ICM 202 determining that a closed-loop control algorithm associated with and controlling the medical device failed to correct an abnormality detected during the time period. ICM 202 may update, delete, or download the emergency protocol information via the communication interface.

[0127] In another aspect, an exemplary machine-implemented method includes: monitoring multiple medical devices for adjustments to the medical devices during a time period, identifying multiple adjustments to the multiple medical devices during the time period based on the monitoring, building a treatment profile associated with a patient and the medical devices based on the identified adjustments, identifying an adverse event related to the patient or a corresponding medical device in the multiple medical devices; after identifying the adverse event, generating multiple continuous control signals based on the treatment profile to correct the adverse event, each control signal being associated with a different medical device in the medical devices or a different user. As previously described, the method may also include receiving information about a role of a corresponding user associated with the corresponding user device from multiple user devices, and based on the multiple continuous control signals, displaying different protocol information based on the role of the corresponding user at the corresponding user device.

[0128] According to various aspects described herein, the subject technology also includes a non-transitory machine-readable medium storing instructions thereon, which, when executed by a device, cause the device to perform the above-described machine-implemented method. In some embodiments, the device includes the disclosed ICM 202. Additionally or in the alternative, one or more devices may include an infusion control device.

[0129] Many of the above examples 900 and related features and applications may also be implemented as dedicated software processes, which are specified as sets of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium) and can be automatically executed (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, cores of processors, or other processing units), they cause the one or more processing units to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or via wired connections.

[0130] The term "software" is intended to include, where appropriate, firmware residing in a read-only memory or applications stored in magnetic storage that can be read into memory for processing by a processor. In addition, in some embodiments, multiple software aspects of the subject disclosure can be implemented as sub-parts of a larger program while maintaining different software aspects of the subject disclosure. In some embodiments, multiple software aspects can also be implemented as separate programs. Finally, combinations of separate programs that jointly implement the software aspects described herein are within the scope of the subject disclosure. In some embodiments, the software program (when installed to operate on one or more electronic systems) defines one or more specific machine implementations that implement and execute the operations of the software program, which machines cause one or more devices to implement the described fleet resource management features.

[0131] A computer program (also referred to as a program, software, software application, script, or code) may be written in a programming language (including compiled or interpreted languages, declarative or procedural languages), and it may be deployed for execution (including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment). A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions). A computer program can be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0132] Fig.10 900 is a conceptual diagram illustrating an example electronic system 1000 for intelligent operation of an infusion accessory device according to aspects of the subject technology. The electronic system 1000 may be a specially configured computing device for executing software associated with one or more portions or steps of the process 900, or Figures 1 to 9 The components and processes provided include, but are not limited to, the information system server 30, the database 37, the computing hardware within the patient care device 12 or the remote device 32 (e.g., a mobile device). The electronic system 1000 may be representative, in combination with Figure 1-Figure 9 In this regard, the electronic system 1000 may be a personal computer or a mobile device such as a smartphone, tablet computer, laptop computer, PDA, augmented reality device, wearable device (such as a watch or band or glasses), or a combination thereof, or other touch screen or television having one or more processors embedded therein or coupled thereto, or a specially configured computer-related electronic device with network connectivity.

[0133] The electronic system 1000 may include computer-readable media and interfaces for computer-readable media. In the depicted example, the electronic system 1000 includes a bus 1008, one or more processing units 1012, a system memory 1004, a read-only memory (ROM) 1010, a permanent storage device 1002, an input device interface 1014, an output device interface 1006, and one or more network interfaces 1016. In some embodiments, the electronic system 1000 may include or be integrated with other computing devices or circuits for operating the various components and processes described previously.

[0134] Bus 1008 collectively represents a system, peripheral, and chipset bus that communicatively connects the numerous internal devices of electronic system 1000. For example, bus 1008 communicatively connects one or more processing units 1012 with ROM 1010, system memory 1004, and permanent storage device 1002.

[0135] From these various memory units, the one or more processing units 1012 retrieve instructions to execute and data to process in order to perform the processes of the subject disclosure. In various implementations, the one or more processing units may be a single processor or a multi-core processor.

[0136] ROM 1010 stores static data and instructions required by one or more processing units 1012 and other modules of the electronic system. On the other hand, permanent storage device 1002 is a read-write memory device. Such a device is a non-volatile memory unit that stores instructions and data even when the electronic system 1000 is turned off. Some embodiments of the subject disclosure use a mass storage device (such as a magnetic disk or optical disk and its corresponding disk drive) as permanent storage device 1002.

[0137] Other embodiments use removable storage devices (such as floppy disks, flash drives and their corresponding disk drives) as permanent storage devices 1002. Like permanent storage devices 1002, system memory 1004 is a read-write memory device. However, unlike storage devices 1002, system memory 1004 is a volatile read-write memory, such as random access memory. System memory 1004 stores some instructions and data that the processor needs at runtime. In some embodiments, the processes disclosed in the subject matter are stored in system memory 1004, permanent storage devices 1002, and / or ROM 1010. From these various memory units, one or more processing units 1012 retrieve instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0138] The bus 1008 is also connected to input and output device interfaces 1014 and 1006. The input device interface 1014 enables a user to communicate information and select commands to the electronic system. Input devices used with the input device interface 1014 include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 1006 enables, for example, the display of images generated by the electronic system 1000. Output devices used with the output device interface 1006 include, for example, a printer and a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Some embodiments include devices such as a touch screen that function as both an input and an output device.

[0139] In addition, if Fig.10As shown, bus 1008 also couples electronic system 1000 to a network (not shown) via network interface 1016. Network interface 1016 may include, for example, a wireless access point (e.g., Bluetooth or WiFi) or a radio circuit for connecting to a wireless access point. Network interface 1016 may also include hardware (e.g., Ethernet hardware) for connecting a computer to a portion of a computer network (such as a local area network ("LAN"), a wide area network ("WAN"), a wireless LAN, or an intranet), or a network of networks (such as the Internet). Any or all of the components of electronic system 1000 may be used in conjunction with the subject disclosure.

[0140] The functions described above can be implemented in computer software, firmware, or hardware. The technology can be implemented using one or more computer program products. Programmable processors and computers can be included in mobile devices or packaged as mobile devices. Processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuits. General and special computing devices and storage devices can be interconnected through a communication network.

[0141] Some embodiments include electronic components such as microprocessors, memory, and storage that store computer program instructions in machine-readable or computer-readable media (also referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, compact disk-read only (CD-ROM), compact disk-recordable (CD-R), compact disk-rewritable (CD-RW), read-only digital versatile disks (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini SD card, micro SD card, etc.), magnetic and / or solid-state hard drives, read-only and recordable Diskette, ultra-density compact disk, other optical or magnetic media, and floppy disk. Computer-readable media can store a computer program that can be executed by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code (such as produced by a compiler), and files including higher-level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

[0142] Although the above discussion refers primarily to microprocessors or multi-core processors that execute software, some implementations are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions stored on the circuits themselves.

[0143] As used in the specification and claims of this application, the terms "computer", "server", "processor" and "memory" refer to specially configured electronic or other technical devices. These terms do not include people or groups of people. For the purpose of this specification, the terms display or being displayed mean displayed on an electronic device. As used in the specification and claims of this application, the terms "computer-readable medium" and "computer-readable medium" are entirely limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, and any other transient signals.

[0144] To provide interaction with a user, embodiments of the subject matter described in this specification may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received, such as acoustic input, voice input, gesture input, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0145] Embodiments of the subject matter described in this specification may be implemented in a specially configured computing system that includes a back-end component (e.g., as a data server), or includes a middleware component (e.g., an application server), or includes a front-end component (e.g., a client computer with a graphical user interface or a web browser through which a user can interact with embodiments of the subject matter described in this specification), or a combination of one or more such back-end, middleware, or front-end components. The components of the system may be interconnected by various forms or media of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0146] A computing system may include a client and a server. The client and the server are usually remote from each other and may interact via a communication network. The relationship between the client and the server is generated by computer programs running on respective computers and having a client-server relationship with each other. In some embodiments, the server transmits data (e.g., an HTML page) to a client device (e.g., to display data to a user interacting with the client device and to receive user input from a user interacting with the client device). Data generated at the client device (e.g., the result of a user interaction) may be received from the client device at the server.

[0147] Those skilled in the art will appreciate that various illustrative blocks, modules, elements, parts, methods and algorithms described herein can be implemented as specially configured electronic hardware, computer software or a combination of the two. In order to illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, parts, methods and algorithms are generally described above with regard to their functions. Whether this function is implemented as hardware or software depends on specific applications and the design constraints imposed on the overall system. For each specific application, the described function can be implemented in different ways. Various parts and blocks can be arranged differently (for example, arranged in different orders, or partitioned in different ways), and all can not deviate from the scope of subject technology.

[0148] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an example approach. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps can be performed simultaneously. The attached method requires that the elements of each step are presented in an example order, and is not meant to be limited to the specific order or hierarchy presented.

[0149] Description of the subject technology in article form:

[0150] For convenience, various examples of aspects of the present disclosure are described as numbered clauses (1, 2, 3, etc.). These are provided as examples and do not limit the subject technology. The identification of the figures and reference numbers provided below is for example and illustrative purposes only, and the clauses are not limited by these identifications.

[0151] Clause 1. A method for medical device resource management, the method comprising, under the control of one or more processing devices: monitoring multiple medical devices for adjustments to the medical devices during a time period; based on the monitoring, identifying adjustments to the multiple medical devices during the time period; constructing a treatment profile associated with a patient and the medical devices based on the identified adjustments; identifying an adverse event related to the patient or a corresponding medical device among the multiple medical devices; after identifying the adverse event: generating multiple continuous control signals based on the treatment profile to correct the adverse event, each control signal being associated with a different medical device among the medical devices or a different user.

[0152] Clause 2. The method of clause 1, further comprising: sending each of the plurality of consecutive control signals to a different device associated with a different user.

[0153] Clause 3. The method of clause 1 or clause 2, wherein monitoring a plurality of medical devices comprises monitoring medical devices associated with procedures performed during the time period.

[0154] Clause 4. A method according to clause 1 or clause 2, wherein a first control signal among a plurality of continuous control signals causes a first message to be displayed on a first device, and a second control signal among a plurality of continuous control signals causes a second message to be displayed on a second device at a time different from when the first message is displayed on the first device.

[0155] Clause 5. The method of clause 4, wherein the second control signal is sent to a device outside of a region associated with a program executed during the time period.

[0156] Clause 6. The method of any one of clauses 1 to 5, wherein the adverse event comprises a sensor failure, and wherein one of the continuous control signals comprises a message to adjust one of the medical devices.

[0157] Clause 7. The method of any one of clauses 1 to 5, wherein a first control signal of the plurality of consecutive control signals comprises a reset command configured to cause operation of the medical device to be restarted.

[0158] Item 8. A medical device resource management system, the system comprising: a communication interface configured to exchange information with multiple medical devices and to exchange information with at least one of multiple user devices; a processor; and a non-transitory computer-readable medium comprising instructions, which, when executed by the processor, causes the medical device resource management system to: monitor multiple medical devices for adjustments to the multiple medical devices during a time period; based on the monitoring, identify multiple adjustments to the multiple medical devices during the time period; construct a treatment profile associated with a patient and multiple medical devices based on the identified multiple adjustments; identify an adverse event related to the patient or a corresponding medical device among the multiple medical devices; and after identifying the adverse event: generate multiple continuous control signals based on the treatment profile to correct the adverse event, each control signal being associated with a different medical device among the medical devices or a different user.

[0159] Clause 9. The medical device resource management system of clause 8, wherein the medical device resource control system is configured to send each of the plurality of consecutive control signals to a different device associated with a different user.

[0160] Clause 10. The medical device resource management system of clause 8 or clause 9, wherein monitoring the plurality of medical devices comprises monitoring medical devices associated with procedures performed during the time period.

[0161] Clause 11. A medical device resource management system according to Clause 8 or Clause 9, wherein a first control signal among a plurality of continuous control signals causes a first message to be displayed on a first device, and a second control signal among a plurality of continuous control signals causes a second message to be displayed on a second device at a time different from when the first message is displayed on the first device.

[0162] Clause 12. The medical device resource management system of clause 11, wherein the second control signal is sent to a device outside of an area associated with the procedure.

[0163] Clause 13. The medical device resource management system of any one of clauses 8 to 12, wherein the adverse event comprises a sensor failure, and wherein one of the plurality of continuous control signals comprises a message for adjusting one of the medical devices.

[0164] Clause 14. A medical device resource management system according to any one of clauses 8 to 13, wherein the medical device resource management system is configured to: receive information about roles of corresponding users associated with corresponding user devices from multiple user devices; and based on multiple continuous control signals, display different protocol information based on the roles of the corresponding users at the corresponding user devices.

[0165] Clause 15. A medical device resource management system according to any one of clauses 8 to 14, wherein, upon receiving a user selection of a treatment, a plurality of consecutive control signals result in display of protocol information.

[0166] Clause 16. The medical device resource management system of clause 15, wherein the user's selection of treatment includes treatment for one of cardiac arrest, bradycardia, ventricular tachycardia, or ventricular fibrillation.

[0167] Clause 17. A medical device resource management system according to any one of clauses 8 to 16, wherein the medical device resource management system is further configured to: receive verification of one or more actions performed in response to a user's selection of a treatment; and cause dynamic protocol information to be displayed based on the verification of the one or more actions.

[0168] Clause 18. A medical device resource management system according to Clause 15, wherein the protocol information includes emergency protocol information, and wherein the emergency protocol information is provided based on the medical device resource control system determining that a closed-loop control algorithm of the medical device has failed to correct an anomaly detected during the time period.

[0169] Clause 19. The medical device resource management system according to any one of clauses 8 to 18, wherein the medical device resource management system is configured to update, delete or download emergency protocol information via the communication interface.

[0170] Clause 20. A machine-implemented method, the method comprising: monitoring multiple medical devices during adjustments to the medical devices over a time period; based on the monitoring, identifying multiple adjustments to the multiple medical devices during the time period; constructing a treatment profile associated with a patient and the medical devices based on the identified adjustments; identifying an adverse event associated with the patient or a corresponding medical device among the multiple medical devices; and after identifying the adverse event: generating multiple continuous control signals based on the treatment profile to correct the adverse event, each control signal being associated with a different medical device among the medical devices or a different user.

[0171] Clause 21. A machine-implemented method according to Clause 20, wherein the method further comprises: receiving information about roles of corresponding users associated with the corresponding user devices from multiple user devices; and displaying different protocol information based on the roles of the corresponding users at the corresponding user devices based on multiple continuous control signals.

[0172] Clause 22. A non-transitory machine-readable medium having stored thereon instructions which, when executed by an apparatus, cause the apparatus to perform the machine-implemented method of any of clauses 20-21.

[0173] Clause 23. The non-transitory machine-readable medium of clause 22, wherein the device is an infusion control device.

[0174] Clause 24. An infusion control device configured to perform the method of any one of clauses 1 to 7.

[0175] Further considerations:

[0176] It is understood that the specific order or hierarchy of steps in the process disclosed herein is an illustration of an example approach. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps can be performed simultaneously. The claims of the accompanying methods present elements of various steps in a sample order and are not meant to be limited to the specific order or hierarchy presented.

[0177] The preceding description is provided to enable any person skilled in the art to practice the various aspects described herein. The preceding description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but to be given the full scope consistent with the language claims, wherein unless specifically so stated, otherwise referring to an element in the singular is not intended to mean "one and only one", but "one or more". Unless otherwise specifically stated, the term "some" refers to one or more. Positive pronouns (e.g., his) include feminine and neutral genders (e.g., her and its), and vice versa. Titles and subtitles (if any) are used only for convenience and do not limit the invention described herein.

[0178] The predicates "configured to", "operable to", and "programmed to" do not imply any particular tangible or intangible modification of the subject, but are intended to be used interchangeably. For example, a processor being configured to monitor and control an operation or component may also mean that the processor is programmed to monitor and control the operation or that the processor is operable to monitor and control the operation. Similarly, a processor configured to execute code may be interpreted as a processor programmed to execute code or operable to execute code.

[0179] The term automatically, as used herein, may include being performed by a computer or machine without user intervention; for example, by being responsive to instructions of a predicate action by a computer or machine or other initiating mechanism. The word "exemplary" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0180] Phrases such as "aspects" do not mean that such aspects are essential to the subject technology, or that such aspects apply to all configurations of the subject technology. Disclosures related to aspects may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. Phrases such as aspects may refer to one or more aspects, and vice versa. Phrases such as "embodiments" do not mean that such embodiments are essential to the subject technology, or that such embodiments apply to all configurations of the subject technology. Disclosures related to embodiments may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. Phrases such as "embodiments" may refer to one or more embodiments, and vice versa. Phrases such as "configurations" do not mean that such configurations are essential to the subject technology, or that such configurations apply to all configurations of the subject technology. Disclosures related to configurations may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. Phrases such as "configurations" may refer to one or more configurations, and vice versa.

[0181] As used herein, a "user interface" (also referred to as an interactive user interface, graphical user interface, or UI) may refer to a web-based interface that includes data fields and / or other control elements for receiving input signals or providing electronic information, and / or providing information to a user in response to any received input signals. Control elements may include dials, buttons, icons, selectable areas, or other perceptible indicia presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiate data exchange for the device presenting the UI. The UI may be presented in whole or in part using a web-based interface such as Hypertext Markup Language (HTML), Flash, or other web-based applications. TM , JAVA TM , .NET TM , C, C++, web services, or rich site summary (RSS) technology implementation. In some embodiments, the UI can be included in a separate client (e.g., thick client, fat client) that is configured to communicate (e.g., send or receive data) according to one or more aspects described. The communication can be communication with the medical device or a server communicating with it, or communication from the medical device or server.

[0182] As used herein, the term "determining" or "determining" includes a variety of actions. For example, "determining" may include calculating, computing, processing, deriving, generating, acquiring, searching (e.g., searching in a table, database, or other data structure), determining, etc. via a hardware element without user intervention. In addition, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. via a hardware element without user intervention. "Determining" may include parsing, selecting, choosing, establishing, etc. via a hardware element without user intervention.

[0183] As used herein, the term "providing" or "providing" encompasses a wide variety of actions. For example, "providing" may include storing a value at a location on a storage device for subsequent retrieval, transmitting a value directly to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, etc. "Providing" may also include encoding, decoding, encrypting, decrypting, validating, verifying, etc. via a hardware element.

[0184] As used herein, the term "message" encompasses various formats for conveying (e.g., transmitting or receiving) information. A message may include a machine-readable summary of information such as an XML document, a fixed field message, a comma-delimited message, JSON, a custom protocol, etc. In some embodiments, a message may include a signal that is utilized to transmit one or more representations of information. Although described in the singular, it is understood that a message may be composed of multiple parts, transmitted, stored, received, etc.

[0185] As used herein, the term "optionally" or "selective" may encompass a wide variety of actions. For example, a "selective" process may include determining an option from a plurality of options. A "selective" process may include one or more of: a dynamically determined input, a preconfigured input, or a user-initiated input for making the determination. In some embodiments, n input switches may be included to provide a selective functionality, where n is the number of inputs used to make the selection.

[0186] As used herein, the term "corresponds" or "corresponds to" encompasses a structural, functional, quantitative and / or qualitative association or relationship between two or more objects, data sets, information and / or the like, preferably wherein the correspondence or relationship can be used to translate the two or more objects, information and / or the like so as to appear the same or equal. The correspondence can be evaluated using one or more of a threshold, a value range, fuzzy logic, pattern matching, an ML evaluation model, or a combination thereof.

[0187] In any embodiment, the generated or detected data can be forwarded to a "remote" device or location, where "remote" refers to a location or device other than the location or device where the program is executed. For example, the remote location can be another location in the same city (e.g., an office, a laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. Therefore, when an item is indicated as being "remote" from another item, it means that the two items can be in the same room, but separated, or at least in different rooms or different buildings, and can be at least one mile, ten miles, or at least one hundred miles apart. "Communicating" information refers to transmitting data representing the information as electrical signals through an appropriate communication channel (e.g., a private or public network). "Forwarding" an item refers to any means of transferring the item from one location to the next, whether by physical transmission or otherwise (if possible), and at least in the case of data, includes physically transmitting the medium that carries the data or transmits the data. Examples of communication media include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet, or include email transmissions and information recorded on websites, etc.

Claims

1. A method for medical device resource management, the method comprising, under the control of one or more processing devices: monitoring a plurality of medical devices for adjustments to the medical devices during a time period; based on the monitoring, identifying adjustments to the plurality of medical devices during the time period; constructing a treatment profile associated with the patient and the medical device based on the identified adjustments; identifying an adverse event associated with the patient or a corresponding medical device from the plurality of medical devices; as well as Following identification of the adverse event: A plurality of sequential control signals are generated based on the treatment profile to correct the adverse event, each control signal being associated with a different one of the medical devices or a different user.

2. The method according to claim 1, further comprising: include: Each control signal of the plurality of consecutive control signals is sent to a different device associated with a different user.

3. The method according to claim 1 or 2, in, Monitoring the plurality of medical devices includes monitoring medical devices associated with procedures performed during the time period.

4. The method according to claim 1 or 2, in, A first control signal in the plurality of consecutive control signals causes a first message to be displayed on a first device, and a second control signal in the plurality of consecutive control signals causes a second message to be displayed on a second device at a different time than when the first message is displayed on the first device.

5. The method according to claim 4, in, The second control signal is sent to a device outside of a region associated with a program executed during the time period.

6. The method according to any one of claims 1 to 5, in, The adverse events included sensor failure, One of the continuous control signals comprises a message for adjusting one of the medical devices.

7. The method according to any one of claims 1 to 5, in, A first control signal of the plurality of consecutive control signals comprises a reset command configured to cause operation of the medical device to restart.

8. A medical equipment resource management system, the medical equipment resource management system include: a communication interface configured to exchange information with a plurality of medical devices and to exchange information with at least one user device among a plurality of user devices; Processor; and A non-transitory computer readable medium comprising instructions which, when executed by the processor, cause the medical device resource management system to: monitoring the plurality of medical devices for adjustments to the plurality of medical devices during a time period; based on the monitoring, identifying a plurality of adjustments to the plurality of medical devices during the time period; constructing a treatment profile associated with the patient and the plurality of medical devices based on the identified plurality of adjustments; identifying an adverse event associated with the patient or a corresponding medical device from the plurality of medical devices; as well as Following identification of the adverse event: generating a plurality of continuous control signals based on the treatment profile to correct the adverse event, Each control signal is associated with a different one of the medical devices or a different user.

9. The medical equipment resource management system according to claim 8, in, The medical device resource control system is configured to send each of the plurality of consecutive control signals to a different device associated with a different user.

10. The medical equipment resource management system according to claim 8 or 9, in, Monitoring the plurality of medical devices includes monitoring medical devices associated with procedures performed during the time period.

11. The medical equipment resource management system according to claim 8 or 9, in, A first control signal in the plurality of consecutive control signals causes a first message to be displayed on a first device, and a second control signal in the plurality of consecutive control signals causes a second message to be displayed on a second device at a different time than when the first message is displayed on the first device.

12. The medical equipment resource management system according to claim 11, in, The second control signal is sent to a device outside of a region associated with the program.

13. The medical equipment resource management system according to any one of claims 8 to 12, in, The adverse events included sensor failure, Among them, one of the multiple continuous control signals includes a message for adjusting one of the medical devices.

14. The medical equipment resource management system according to any one of claims 8 to 13, in, The medical equipment resource control system is configured as follows: receiving, from a plurality of user devices, information regarding roles of respective users associated with corresponding user devices; as well as Based on the plurality of continuous control signals, different protocol information is displayed at the corresponding user equipment based on the role of the corresponding user.

15. The medical equipment resource management system according to any one of claims 8 to 14, in, Upon receipt of a user selection of a therapy, the plurality of sequential control signals results in display of protocol information.

16. The medical equipment resource management system according to claim 15, in, The user selection of therapy includes therapy for one of asystole, bradycardia, ventricular tachycardia, or ventricular fibrillation.

17. The medical equipment resource management system according to any one of claims 8 to 16, in, The medical equipment resource control system is further configured to: receiving verification of one or more actions performed in response to the user's selection of a treatment; and Dynamic protocol information is caused to be displayed based on verification of the one or more actions.

18. The medical equipment resource management system according to claim 15, in, The protocol information includes emergency protocol information, and wherein the emergency protocol information is provided based on the medical device resource management system determining that a closed-loop control algorithm of the medical device failed to correct an anomaly detected during the time period.

19. The medical equipment resource management system according to any one of claims 8 to 18, in, The medical device resource management system is configured to update, delete or download emergency protocol information via the communication interface.

20. A machine-implemented method, the method include: monitoring a plurality of medical devices for adjustments to the medical devices during a time period; based on the monitoring, identifying a plurality of adjustments to the plurality of medical devices during the time period; constructing a treatment profile associated with the patient and the medical device based on the identified adjustments; identifying an adverse event associated with the patient or a corresponding medical device from the plurality of medical devices; as well as Following identification of the adverse event: A plurality of sequential control signals are generated based on the treatment profile to correct the adverse event, each control signal being associated with a different one of the medical devices or a different user.

21. The machine-implemented method of claim 20, in, The method also includes receiving information about roles of respective users associated with the respective user devices from the plurality of user devices; and displaying different protocol information based on the roles of the respective users at the respective user devices based on the plurality of continuous control signals.

22. A non-transitory machine-readable medium having stored thereon instructions which, when executed by a device, cause the device to perform the machine-implemented method according to any one of claims 20 to 21.

23. The non-transitory machine-readable medium of claim 22, in, The device is an infusion control device.

24. An infusion control device configured to perform the method according to any one of claims 1 to 7.

Images