Infusion connectivity gateway for augmenting infusion alarm messages

Abstract

An infusion connectivity gateway configured to receive an alarm message from an in-fusion pump, the alarm message regarding an alarm triggered during an infusion therapy per-formed by the infusion pump. The gateway is further configured to determine whether the alarm message should be augmented based on whether one or more augmentation factors sat-isfy one or more augmentation rules. The augmentation factors may include, for example, a care area where the infusion pump is located, a fluid administered during the infusion therapy, a type of the alarm, a type of the infusion pump, and a state of the infusion pump. Additionally, the gateway is configured to augment the alarm message with additional data regarding the infusion therapy or a recipient of the infusion therapy and then transmit the alarm message to a clinician associated with the infusion pump.

Description

INFUSION CONNECTIVITY GATEWAY FOR AUGMENTING INFUSION ALARM MESSAGESTECHNICAL FIELD

[0001] The present disclosure relates, generally, to infusion technologies and, more specifically, to infusion pump alarms and backend services for managing the same.BACKGROUND

[0002] For safety purposes, infusion devices are oftentimes equipped with alarm systems. These systems are designed to inform clinicians regarding the status of infusion therapies, whether through an audible alert or a notification transmitted directly to the clinician. An infusion alarm can be configured, for instance, to trigger upon detection of a potential issue with an ongoing therapy or following the completion of such a therapy.

[0003] Though these alarms are useful, they are rudimentary. They provide clinicians with little more than an indication that something demands their attention. Accordingly, when faced with repeated or simultaneous alarms, clinicians may struggle to respond effectively. This can lead to alarm fatigue, improper alarm prioritization, and other problems.

[0004] It has been suggested that alarm communications can be contextualized with other data to aid clinicians in managing infusion alarms. However, current technologies have yet to implement this concept and instead continue to rely on traditional alarm reporting methodologies.SUMMARY

[0005] Many of the aforenoted problems arise from clinicians not having the information they need to determine how best to respond to infusion alarms, thus creating a need for more robust infusion alarm systems, as well as more fine-tuned systems for handling and reporting infusion alarms. The present disclosure recognizes that clinicians would benefit greatly from information relevant to the alarm notifications they receive - referred to herein as “infusion alarm messages” or simply “alarm messages.” Such information may regard, for instance, the infusion therapy associated with the triggered alarm or the patient receiving the infusion therapy.

[0006] This disclosure provides various devices, systems, and methods for augmenting alarm messages with relevant, contextual information (e.g., adding said information to the alarm messages) that can assist clinicians in determining how best to respond to alarm messages. As discussed in more detail below, alarm augmentation is a selective process that requires first determining which information should be provided to the clinician in order to best serve them in determining how to respond to the alarm (e.g., rather than including a standard set of information with the alarm message, which may prove overwhelming or unhelpful).

[0007] Example implementations of the subject technology include:

[0008] An infusion connectivity gateway configured to receive an alarm message from an infusion pump, where the alarm message regards an alarm triggered during an infusion therapy performed by the infusion pump. The infusion connectivity gateway is also configured to retrieve one or more augmentation factors from the infusion pump or from a server connected to the infusion pump. The one or more augmentation factors include one or more of a care area where the infusion pump is located, a fluid administered during the infusion therapy, a type of the alarm, a type of the infusion pump, and a state of the infusion pump. Additionally, the infusion connectivity gateway is configured to determine whether the one or more augmentation factors satisfy one or more augmentation rules. Further, the infusion connectivity gateway is configured to, when the one or more augmentation factors satisfy the one or more augmentation rules, (i) retrieve additional data from the infusion pump or from another server connected to the infusion pump, where the additional data regarding the infusion therapy or a recipient of the infusion therapy; (ii) augment the alarm message with the additional data after determining that the alarm message should be augmented; and (iii) transmit the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.

[0009] An infusion system includes an infusion pump and an infusion connectivity gateway. The infusion connectivity gateway is configured to receive an alarm message from the infusion pump, where the alarm message regards an alarm triggered during an infusion therapy performed by the infusion pump. The infusion connectivity gateway is also configured to retrieve one or more augmentation factors from the infusion pump or from a server connected to the infusion pump. The one or more augmentation factors include one or more of a care area where the infusion pump is located, a fluid administered during the infusion therapy, a type of the alarm, a type of the infusion pump, and a state of the infusion pump. Additionally, theinfusion connectivity gateway is configured to determine whether the one or more augmentation factors satisfy one or more augmentation rules. Further, the infusion connectivity gateway is configured to, when the one or more augmentation factors satisfy the one or more augmentation rules, (i) retrieve additional data from the infusion pump or from another server connected to the infusion pump, where the additional data regarding the infusion therapy or a recipient of the infusion therapy; (ii) augment the alarm message with the additional data after determining that the alarm message should be augmented; and (iii) transmit the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.

[0010] A computer-implemented method for augmenting infusion alarm messages, the method including receiving an alarm message from an infusion pump. The alarm message regards an alarm triggered during an infusion therapy performed by the infusion pump. The method also includes retrieving one or more augmentation factors from the infusion pump or from a server connected to the infusion pump. The one or more augmentation factors include one or more of a care area where the infusion pump is located, a fluid administered during the infusion therapy, a type of the alarm, a type of the infusion pump, and a state of the infusion pump. Additionally, the method includes determining whether the one or more augmentation factors satisfy one or more augmentation rules. Further, the method includes, when the one or more augmentation factors satisfy the one or more augmentation rules, (i) retrieving additional data from the infusion pump or from another server connected to the infusion pump, where the additional data regards the infusion therapy or a recipient of the infusion therapy; (ii) augmenting the alarm message with the additional data after determining that the alarm message should be augmented; and (iii) transmitting the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.

[0011] It is understood that other configurations of the subject technology will become readily apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] For a better understanding of the various described implementations, reference should be made to the Detailed Description, below, in conjunction with the following drawings. Like reference numerals refer to corresponding parts throughout the figures and description.

[0013] FIG. 1 depicts an example patient care device that includes infusion pumps mounted to a control unit, according to various aspects of the subject technology.

[0014] FIG. 2 depicts an example institutional patient care system of a healthcare organization, according to various aspects of the subject technology.

[0015] FIG. 3 depicts an example operational environment for handling infusion alarm messages, according to various aspects of the subject technology.

[0016] FIG. 4 depicts an example system diagram of an infusion connectivity gateway, according to various aspects of the subject technology.

[0017] FIG. 5 depicts an example process for augmenting infusion alarm messages, according to various aspects of the subject technology.

[0018] FIG. 6 is a conceptual diagram that depicts an example electronic system for augmenting infusion alarm messages, according to various aspects of the subject technology.DETAILED DESCRIPTION

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

[0020] FIG. 1 depicts an example patient care device 100 that includes infusion pumps 131-132 mounted to a control unit 104, according to various aspects of the subject technology. The term patient care device may be used interchangeably with the term patient care unit, either of which may include various ancillary medical devices, such as an infusion pump(e.g., infusion pumps 131-132), a vital signs monitor, a medication dispensing device (e.g., a cabinet, a tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned devices, and so on.

[0021] As illustrated, the patient care device 100 includes two infusion pumps 131-132, each of which is mounted to the control unit 104. The first infusion pump 131 is a peristaltic pump and is in operative engagement with a respective administration set (not pictured). This administration set connects the first infusion pump 131 to a fluid supply (not pictured) at one end and to a patient (not pictured) at the other end. The second infusion pump 132 is a syringe pump with a syringe 134. Like the first pump 131, the second pump 132 is associated with a respective administration set (not pictured) for connecting the syringe 134 to the patient.

[0022] The infusion pumps 131-132 are flow control devices configured to provide fluids (e.g., medications, saline solutions) to the patient. The first infusion pump 131 can acts on its respective administration set to move fluid therethrough. And the second infusion pump 132 applies a force to the drive head of the syringe 134 to force fluid through its respective administration set. Because the patient care device 100 includes multiple infusion pumps 131-132, each of the pumps 131-132 can be set individually to the pumping or operating parameters required for infusing their respective fluids (e.g., a flow rate, a volume to be infused) as programmed by a clinician.

[0023] The aforenoted control unit 104, in some implementations, is configured for programming the infusion pumps 131-132. As illustrated, the control unit 104 can include a display 114 and controls 116A-C (e.g., buttons, touchscreen controls), which allow a clinician to interface with the control unit 104. In some implementations, the display 114 is implemented as a touchscreen display. In such implementations, the control keys 116A-C may be omitted or reduced in number by providing corresponding interactive elements via a graphical user interface presented via the display 114. In some implementations, the control keys 116A-C may select a corresponding option displayed in display 114. In addition to the display 114 and the control keys 116A-C, the control unit 104 may also include a speaker to provide audible alerts.

[0024] In some implementations, the infusion pumps 131-132 include their own displays and / or controls. For example, in the depicted implementation, the display 124 of the syringe pump 132 (e.g., an LED or a touchscreen display) is located in plain view and may be used tovisually communicate information regarding the infusion pump 132. The display 124, for instance, can communicate alert indications or alarm messages. Additionally, the control keys 126 of the pump 132 allow for programming and controlling operations of the infusion pump as desired. In some implementations, the control keys 126 may be presented as interactive elements on the display 124. The infusion pumps 131-132 may also include audio alert equipment in the form of a speaker.

[0025] FIG. 2 depicts an example institutional patient care system 200 of a healthcare organization, according to various aspects of the subject technology. The system 200 includes a patient care device 202, such as the patient care device 100 of FIG. 1. The patient care device 202 is connected to an internal healthcare network 236. Each element of the patient care device 202 is connected to the healthcare network 236 via a transmission channel 234. The transmission channel 234 can be a wired or wireless transmission channel, such as an 802.11 wireless local area network (WLAN).

[0026] In some implementations, the internal healthcare network 236 also includes computer systems located in various departments throughout a hospital or healthcare center. For example, the internal healthcare network 236 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. In some implementations, the internal healthcare network 236 includes discrete subnetworks. In the depicted example, for instance, the internal healthcare network 236 includes a device network 238 by which the patient care device 202 and other devices can communicate in accordance with normal operations.

[0027] The institutional patient care system 200 may also incorporate a separate information system server 242 (e.g., a health information system server). Although the information system server 242 is shown as a separate server, the functions and programming of the information system server 242 may be incorporated into another computer. The institutional patient care system 200 may further include a device terminal 240 for connecting and communicating with information system server 242. The device terminal 240 may include personal computers, personal data assistants, or mobile devices (e.g., laptops, tablet computers, augmented reality devices, or smartphones) configured with software for communications with information system server 242 via the internal healthcare network 236.

[0028] The patient care device 202 includes a system for providing patient care, and it may include or incorporate infusion pumps (e.g., infusion pumps 131-132 of FIG. 1), physiological monitors (e.g., a heart rate monitor, a blood pressure monitor, an electrocardiogram, an electroencephalogram, a pulse oximeter, and / or other monitors), therapy devices, and / or other drug delivery devices that may be utilized according to the teachings set forth herein.

[0029] In the depicted example, the patient care device 202 includes a control unit 204 (e.g., control unit 104 of FIG. 1), which is connected to one or more functional modules 206- 209 (e.g., infusion pumps 131-132 of FIG. 1). Control unit 204 includes a central processing unit (CPU) 218 connected to a memory, for example, random access memory (RAM) 222, and one or more interface devices such as user interface device 230, a coded data input device 232, a network connection 220, and an auxiliary interface 226 for communicating with additional modules or devices. Control unit 204 also, although not necessarily, includes a main non-volatile storage unit 228, such as a hard disk drive or non-volatile flash memory, for storing software data. Additionally, control unit 204 may include one or more internal buses 224 for interconnecting the aforementioned elements.

[0030] In various implementations, user interface device 230 is a touch screen for displaying information to a user and allowing a user to input information by touching defined areas of the screen. Additionally, or in the alternative, user interface device 230 could include any means for displaying and inputting information, such as a monitor, a printer, a keyboard, soft- keys, a mouse, a track ball, and / or a light pen.

[0031] Data input device 232 may be a bar code reader capable of scanning and interpreting data printed in bar coded format. Additionally, or in the alternative, data input device 232 can be any device for entering coded data into a computer, such as a device(s) for reading magnetic strips, radio-frequency identification (RFID) devices whereby digital data encoded in RFID tags or smart labels (defined below) are captured by the data input device 232 via radio waves, PCMCIA smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog or digital storage media. Other examples of the data input device 232 include a voice activation or recognition device or a portable personal data assistant (PDA). Depending upon the types of interface devices used, the user interface device 230 and the data input device 232 may be the same device. Although the data input device 232 is shown in FIG. 2 as being disposed within the control unit 204, the data input device 232 may be external to the control unit 204 (e.g., at the device terminal 240).

[0032] Auxiliary interface 226 may be an RS-232 communications interface, however any other means for communicating with a peripheral device (e.g., a printer, a patient monitor, an infusion pump, or another medical device) may be used without departing from the subject technology. Additionally, the data input device 232 may be a separate functional module (e.g., functional modules 206-207) configured to communicate with the control unit 204 or any other system on the network using suitable programming and communication protocols.

[0033] Network connection 220 may be a wired or wireless connection, such as by Ethernet, Wi-Fi, BLUETOOTH, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem or a cable modem. Any direct or indirect network connection may be used, including, but not limited to a telephone modem, an MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link or a WLANS connection or other wireless connection.

[0034] The functional modules 206-209 are devices for providing care to a patient or for monitoring patient conditions. At least one of the functional modules 206-209 may be an infusion pump module, such as an intravenous infusion pump for delivering medication or other fluid to a patient. For the purposes of this discussion, functional module 206 is an infusion pump module. Each of functional modules 206-209 may be any patient treatment or monitoring device including, but not limited to, an infusion pump (e.g., a syringe pump), a PC A pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, an intracranial pressure monitor, or the like. Additionally, the functional modules 206-209 may include a printer, a scanner, a bar code reader, a near- field communication reader, an RFID reader, or any other peripheral input, output or input / out- put device.

[0035] Each functional module 206-209 communicates directly or indirectly with the control unit 204, providing overall monitoring and control of the patient care device 202. Additionally, the functional modules 206-209 may be connected physically and electronically in serial fashion to one or both ends of control unit 204 as shown in FIG. 2. However, it is recognized that there are other means for connecting the functional modules 206-209 with the control unit 204 that may be utilized without departing from the subject technology. It is also appreciated that devices such as pumps or patient monitoring devices that provide sufficient programmability and connectivity may be capable of operating as stand-alone devices and may communicate directly with the internal healthcare network 236 without being connected throughthe control unit 204 or a separate interface unit. As described above, additional medical devices or peripheral devices may be connected to the patient care device 202 through one or more auxiliary interfaces 226.

[0036] Each of the functional modules 206-209 may include various internal components such as those illustrated in FIG. 2. For example, the first functional module includes a microprocessor 216, a volatile memory 214, a nonvolatile memory 212, and other module-specific components 210. It should be noted that while four functional modules are shown in FIG. 2, any number of devices may be connected directly or indirectly to the control unit 204. The number and type of functional modules described herein are intended to be illustrative, and they in no way limit the scope of the subject technology. The module-specific components 210 include any components necessary for operation of a particular module, such as a pumping mechanism for the functional module 206.

[0037] While each of the functional modules 206-209 may be capable of a least some level of independent operation, the control unit 204 monitors and controls overall operation of the patient care device 202. For example, as will be described in more detail below, the control unit 204 provides programming instructions to the functional modules 206-209 and monitors the status of each of the functional modules 206-209.

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

[0039] Data to and from the various data sources can be converted into network-compatible data with existing technology, and movement of the information between the medical device and network can be accomplished by a variety of means. For example, the patient care device 202 and the internal healthcare network 236 may communicate via automated interaction, manual interaction, or a combination of both automated and manual interaction. Automated interaction may be continuous or intermittent and may occur through the network connection 220, as shown in FIG. 2, or through RS232 links, MIB systems, RF links such as BLUETOOTH,IR links, WLANS, digital cable systems, telephone modems, or other wired or wireless communication means.

[0040] Manual interaction between the patient care device 202 and the internal healthcare network 236 involves physically transferring, intermittently or periodically, data between systems using, for example, the user interface device 230, the coded data input device 232, bar codes, computer disks, portable data assistants, memory cards, or any other media for storing data. The communication means in various aspects is bidirectional with access to data from as many points of the distributed data sources as possible. Decision-making can occur at a variety of places within the internal healthcare network 236. For example, and not by way of limitation, decisions can be made in the information system server 242, decision support, a remote data server, hospital department or unit stations, or within the patient care device 202 itself.

[0041] According to various implementations, the information system server 242 includes a formulary and / or pharmacy information system. Pharmacy information systems may enable a safer physician medication order process. A pharmacy website (e.g., provided by the information system server 242) may provide the physician with a list of available drugs from which the physician may select. The pharmacy website may contain a drug library having the list of available drugs but may also contain and present to the physician the drug names associated with recommended dosages and dose limits that have been established or adopted by the healthcare facility. In such a case where the physician need only select items from the computer screen rather than having to manually type in drug names and drug administration numbers (such as infusion rates, infusion times, etc.) associated with administration of the medication, a more accurate medication process should result.

[0042] If a clinical order is for administration of a particular medication regimen, the order will be transmitted to the pharmacy’s system server (e.g., information system server 242). The pharmacy reviews the order, and once the order has been prepared, the order may be transmitted to the nurse station for matching with the appropriate patient. Within a formulary, there may be indication for use information and / or concentrations and drug ranges approved for the facility. A formulary is an approved list of drugs for use (e.g., available to order for a patient) within a medical facility. As will be described further, a formulary may be used to define one or more medical device drug libraries, which may then be provided to infusion pumps within a hospital network (e.g., internal healthcare network 236).

[0043] Inside the drug library, there is medication information such as drug names, concentration, diluent volume, strength, minimum or maximum infusion parameters for a drug, and other parameters. The establishment of these parameters, along with parameters for off- formulary orders, via the information pharmacy’s system server is useful for maintaining consistency across the healthcare environment and ensuring an order is intelligible and executed according to expectations by other devices (e.g., patient care device 202) within the pharmacy’s system server.

[0044] The memory of the control unit 204 (e.g., RAM 222 or the main non-volatile storage unit 228) may contain a drug library, an event log, and / or infusion pump configuration settings, such as profiles to be used in particular practice areas (e.g., ICU, PED, etc.). The control unit 204 memory may be electronically loadable memory, such as non-volatile memory (e.g., EEPROM). Drug libraries stored on pumps, which illustratively contain such information as the drug names, ranges of delivery parameter values such as proper concentrations, dosage units, and dose limits, can be used to perform drug-calculation-based infusions in a clinical setting.

[0045] A drug library stored within the pump’s memory may include clinical order settings such as limits set by the clinical institution for each drug of the library (also termed as “guardrails” herein). Such limits may take the form of maximum and minimum dosages for each drug which may be made dependent on patient factors or other factors associated with delivery of the drug. For example, the dosage limits may vary depending on the weight of the patient or body surface area (“BSA”), depending on the unit or ward of the medical institution in which the drug is being used (for example neonatal care unit (NCU), the intensive care unit (ICU), etc.), and / or other factors. The limits may also include maximum and minimum flow rates, infusion times, or other infusion parameters for a given drug. As with the dosage limits, these limits may also vary depending on the weight or other physiological parameters of the patient. In some implementations, the drug library and / or guardrails are stored elsewhere, such as on the device terminal 240, the external database 244, or another device connected to the internal healthcare network 236.

[0046] An alarm may be provided if the nurse sets the pump to operate outside the range between the limits for a particular drug. In some cases, the alarm may be overridden and in other cases it may not. The medical facility may establish “soft” limits for each drug, which may be overridden by the nurse, and “hard” limits which may not. In either case where a limitis exceeded, a pump data log or other processor in communication with the infusion pump may record each such limit event for later analysis where the attempted setting is higher than the maximum or lower than the minimum dosage.

[0047] The pump may also include a display (e.g., display 114 of FIG. IB) for displaying a user interface, which may include a control panel through which the user can program the programmable controller and a display screen for displaying drug entries from the drug library. Each of the associated sets of drug delivery parameters includes information selected from a group of parameters including drug concentration, drug delivery rate, drug dose, and bolus size. The electronically loaded drug library contains a list of available mode options specifying the units available for expressing drug delivery information, and the drug infusion pump offers the user the list of available mode options from which to make a selection when the electronically loaded drug library is in the pump.

[0048] In the case of a peristaltic pump, the electronically loaded drug library may include a list of infusion set manufacturers. A loaded drug library may include a set of features, each of which is either be toggled on or off, and the pump offers the user only the features from among the set of features that are toggled on when the electronically loaded drug library is in said pump.

[0049] FIG. 3 depicts an example operational environment 300 for handling infusion alarm messages, according to various aspects of the subject technology. The operational environment 300 includes an infusion device 314, such as the patient care device 100 of FIG. 1 or the patient care device 202 of FIG. 2. The infusion device 314 is configured to generate one or more infusion alarms, for instance, upon completion of an infusion therapy performed by the infusion device 314 or upon detection of an issue with the infusion therapy. These infusion alarms cause the infusion device 314 to provide a connectivity gateway 302 with corresponding infusion alarm messages.

[0050] Upon receipt of an infusion alarm message, the connectivity gateway 302 then determines whether to augment the alarm message with additional information and then augments it accordingly. Afterwards, the connectivity gateway 302 forwards the alarm message to a device (e.g., device terminal 240 of FIG. 2) linked to a clinician associated with the infusion device 314 or associated with a patient receiving an infusion therapy performed by the infusion device 314.

[0051] In some implementations, the connectivity gateway 302 is configured to verify the alarm message before proceeding with augmentation-related determinations. Verification can include one or more operations to ensure that the alarm associated with the alarm message is legitimate. For instance, for an occlusion alarm, verification can include instructing the infusion device 314 to perform a pressure back-off for determining whether there is in fact an occlusion at the infusion device 314. If the connectivity gateway 302 is unable to verify the alarm message, then it may forgo augmenting the alarm message and / or augment the alarm message with an indicator regarding the verification failure.

[0052] The connectivity gateway 302 can be implemented as a computing device remote from the infusion device 314 (e.g., a server connected to the infusion device 314 via internal healthcare network 236 of FIG. 2); however, in some implementations, the connectivity gateway 302 is a hardware and / or software module onboard the infusion device 314 (e.g., one of functional modules 206-209 of FIG. 2, stored in non-volatile storage unit 228 and executed by CPU 218 of FIG. 2).

[0053] The connectivity gateway 302 is part of a connectivity solution 304 that also includes a drug library 306, a fleet management system 308, and a provisioning service 310. The drug library 306, the fleet management system 308, and the provisioning service 310 can be stored with the connectivity gateway 302 or stored elsewhere in a location accessible by the connectivity gateway 302. For example, if the connectivity gateway 302 is implemented as a server remote from but connected to the infusion device 314, the drug library 306 can be stored on the infusion device 314 (e.g., in RAM 222 or storage 228 of a control unit 204, as discussed for FIG. 2) and configured such that the connectivity gateway 302 can access it. As another example, the fleet management system 308 can be implemented as another server remote from the connectivity gateway 302 but configured for access thereby.

[0054] The depicted operational environment 300 also includes hospital information systems 316, such as the information system server 242 of FIG. 2, which can be implemented as a health information system server as discussed above. In some implementations, the connectivity gateway 302 retrieves data from the hospital information systems 316 to determine whether to augment alarm messages received from the infusion device 314. Moreover, the connectivity gateway 302 may augment alarm messages with information retrieved, for example, from the hospital information systems 316. Data for determining whether to augment the alarm messages and / or information augmented into the alarm messages may include, for example,data regarding: a care area (e.g., ICU, general care) where the infusion pump is located, a fluid administered during the infusion therapy, a type of the alarm, a type of the infusion pump (e.g., LVP, PC A, syringe pump), a state of the infusion pump (e.g., power level, power source, motor speed, temperature, number of connected modules), a physiological attribute of a recipient of the infusion therapy, and / or an ailment of the recipient intended for treatment by the infusion therapy.

[0055] Additionally, the operational environment 300 may include other elements 318, such as system safety, monitoring, analytics, and so on. For example, the operational environment 300 may include a multi-patient monitor (MPM) to simultaneously monitor the vital signs and other physiological parameters of multiple patients. In this regard, the MPM may include information regarding a patient receiving an infusion therapy for which an alarm message (e.g., heart rate, blood pressure) is generated, and may further display information pertaining to the alarm message.

[0056] As will be described further, the MPM (and other elements 318) may exchange data with the connectivity gateway 302 to aid the connectivity gateway 302 in determining whether and how to augment the alarm message. After the gateway 302 determines how to augment the alarm message (e.g., with additional information or an adjusted priority level), the connectivity gateway 302 (and / or another component of solution 304) may silence the MPM (e.g., cause it to stop displaying the alarm message information, stop emitting an alert regarding the alarm message) or cause it to display certain alarm-related information, such as information added to the alarm message during the augmentation thereof.

[0057] According to some implementations, the operational environment 300 is configured to operate bidirectionally such that the infusion device 314 and the connectivity solution 304 communicate with each other (i.e., bidirectionally). For instance, the infusion device 314 can provide to the connectivity solution 304 alarm messages (e.g., including alarm conditions), fluid information (e.g., drug type), sensor information (e.g., from sensors used to detect alarm conditions), and / or user conditions (e.g., for which the infusion therapy is prescribed to treat). And the connectivity solution 304 can return an updated alarm priority score to the infusion device 314 after determining an alarm priority adjustment, as discussed in more detail hereinbelow.

[0058] In some implementations, communication between the infusion device 314 and the connectivity solution 304 is unidirectional, with the infusion device 314 providing the afore- noted information (alarm messages, etc.) to the connectivity solution 304. In these implementations, the connectivity solution 304 does not return information to the infusion device 314 but instead augments alarm messages from the infusion device 314 and forwards the augmented alarm messages to a device associated with the clinician responsible for the infusion device 314 and / or the corresponding infusion therapy. It is also noted that alarm priority levels can be adjusted by augmenting the adjusted priority level into the alarm message (as opposed to returning the adjusted priority level to the infusion device 314). Alarm level adjustments can be based, for instance, on patient-specific parameters (e.g., heart rate, age, blood pressure) and one or more algorithms. Thereafter, the alarm message - with an adjusted priority level and / or additional information added during augmentation - can be transmitted to the device associated with the clinician.

[0059] FIG. 4 depicts an example system diagram 400 of an infusion connectivity gateway (e.g., infusion connectivity gateway 302 of FIG. 3), according to various aspects of the subject technology. The illustrated elements of the system diagram 400 can be implemented using software and / or hardware solutions. Additionally, it is noted that the elements are provided merely for illustrative purposes and do not necessarily denote separate, individual components. For example, a single component (e.g., a transceiver) can be used to accomplish the functionality of multiple components described herein (e.g., message receiver 402 and message transmitter 408).

[0060] As illustrated in the example system diagram 400, an infusion connectivity gateway can include a message receiver 402, an augmentation detector 404, a message formatter 406, a message transmitter 408, and an augmentation engine 410. Additionally, the infusion connectivity gateway may include and / or be configured to retrieve data from an augmentation rules database 412 and one or more augmentation data databases 414. Dotted lines are used to signify that the databases 412 and 414 can be remote from the infusion connectivity gateway.

[0061] The message receiver 402 is configured to receive (e.g., electronically, wirelessly) alarm messages from an infusion device, such as the infusion device 314 of FIG. 3. After an alarm message is received, the augmentation detector 404 then determines whether the alarm message should be augmented. In the depicted implementation, this determination is based on augmentation rules stored in the augmentation rules database 412. In some implementations,the augmentation rules database 412 is stored in a drug library, such as the drug library stored in the patient care device 202 discussed for FIG. 2.

[0062] Generally, determining whether the message should be augmented includes determining whether one or more augmentation factors satisfy one or more augmentation rules. As used herein, “augmentation factors” denotes data relevant to whether an alarm message should be augmented. Augmentation factors can include data from the alarm message itself and / or data retrieved from other sources, as discussed in more detail below. Example augmentation factors include (i) a care area where the infusion pump is located, (ii) a fluid administered during the infusion therapy, (iii) a type of the alarm, (iv) a type of the infusion pump, and (v) a state of the infusion pump.

[0063] Further, “augmentation rules” refer herein to rules for determining whether an alarm message should be augmented, for example, based on one or more augmentation factors. These rules can include simple checks (e.g., is the infusion pump located in a NICU or ICU?), threshold comparisons (e.g., is the patient’s blood pressure greater than a predetermined blood pressure threshold?), and so on. For example, determining whether the alarm message should be augmented may include determining whether the infusion device is located in a particular care area (e.g., NICU, ICU) or whether the infusion device is in a particular state (e.g., a low-battery state).

[0064] With further reference to FIG. 4, in some implementations, the augmentation detector 404 is configured to determine whether the alarm message should be augmented based on a priority level of the alarm message (e.g., a default priority level associated with an alarm type of the alarm message). For example, if the augmentation detector 404 determines that the alarm message is set to a priority level (e.g., a default priority level) that is higher or lower than it ought to be (e.g., as determined based on various “priority factors” relevant to the priority of the alarm message), then the priority level can be adjusted accordingly. In this manner, augmentation of the alarm message can include adding information to the alarm message and / or adjusting the priority level of the alarm message. In implementations involving the latter, the alarm message may more accurately reflect the actual priority of the alarm message. For instance, some infusion devices by default set all alarm messages regarding occlusion alarms to high priority. However, an alarm message regarding an occlusion alarm for an infusion therapy involving an anesthetic or an analgesic is generally of higher priority than an alarm message regarding an occlusion alarm for an infusion therapy involving a saline solution. The priorityadjustments discussed herein can accommodate this sort of nuance by considering factors other than just the type of the infusion alarm (or other rudimentary factors).

[0065] If the augmentation detector 404 determines that augmentation is needed, then the augmentation engine 410 determines what data to add to the alarm message and then obtains said data from one or more data sources including, for example, the augmentation data databases 414. Determining what data to add to the alarm message can be defined by augmentation rules. As noted above, “augmentation rules” refers to rules for determining whether an alarm message should be augmented. However, “augmentation rules” can also refer to rules for determining how the alarm message should be augmented (e.g., what data should be added to the alarm message).

[0066] In some implementations, augmentation rules may require that if the rule is satisfied by a corresponding augmentation factor, then factors satisfying the rule should be added to the alarm message. As an example, one such rule may require (i) augmentation of an alarm message if the patient is diabetic and also (ii) that the patient’s status as a diabetic be added to the alarm message accordingly. However, in some implementations, augmentation is more complex and involves adding data to the alarm message other than or in addition to the augmentation factors. For example, an augmentation rule may require (i) augmentation of an alarm message if the patient is diabetic, as well as (ii) adding the patient’s blood-glucose level to the alarm message accordingly.

[0067] The previously described augmentation data databases 414 may be part of or hosted by, for example, information system server 242 of FIG. 2 or the hospital information systems 316 of FIG. 3. From there, the message formatter 406 prepares the alarm message for sending (e.g., highlighting the data added by the augmentation engine 410, ordering the added data to emphasize the most important data for the clinician to view), and the message transmitter 408 transmits the message to a device whereat a clinician can view the alarm message, such as the device terminal 240 of FIG. 2.

[0068] FIG. 5 depicts an example process 500 for augmenting infusion alarm messages, according to various aspects of the subject technology. For explanatory purposes, the present disclosure describes the blocks of the example process 500 with reference to FIGS. 1 through 4, including the components illustrated therein. One or more blocks of the processes 500 may be implemented, for example, by one or more of the computing devices described with respectto FIGS. 1 through 4, such as the patient care device 100 of FIG. 1, the patient care device 202 of FIG. 2, and / or a computing system such as the connectivity gateway 302 of FIG. 3.

[0069] For explanatory purposes, the blocks of the process 500 are described as occurring serially. However, in some implementations, multiple blocks may occur in parallel. Additionally, the blocks of the process 500 need not be performed in the order shown and one or more of the blocks of the process 500 need not be performed whatsoever. Moreover, in some implementations, one or more of the blocks may be implemented based on one or more machinelearning algorithms. Further, according to various implementations, one or more of the blocks may be implemented apart from other blocks or by one or more different processors or devices.

[0070] As illustrated, the example process 500 includes receiving an alarm message (502) (e.g., using message receiver 402 of FIG. 4). The alarm message is received from an infusion pump (e.g., patient care device 100, patient care device 202) and is associated with an alarm (e.g., an occlusion alarm, an end-of-infusion alarm, an air-in-line alarm) triggered during an infusion therapy performed by the infusion pump. For example, the alarm message may regard an occlusion alarm that recently triggered on an infusion pump. Additionally, the alarm message may include basic information regarding the triggered alarm, such as the alarm type (e.g., occlusion alarm), its priority level (e.g., high), and so on.

[0071] The process 500 includes retrieving one or more augmentation factors from the infusion pump or from a server (or other digital storage) connected to the infusion pump (504) (e.g., hospital information systems server 316). According to various implementations, the augmentation factors can include one or more of (i) a care area (e.g., ICU, NICU, general care) where the infusion pump is located, (ii) a fluid administered during the infusion therapy, (iii) a type of the alarm (e.g., occlusion, air-in-line), (iv) a type of the infusion pump (e.g., LVP, PCA, syringe pump), and (v) a state of the infusion pump (e.g., power level, power source, motor speed, temperature, number of connected modules).

[0072] Additionally, the process 500 includes determining whether the alarm message should be augmented (506) (e.g., using augmentation detector 404 of FIG. 4). This determination is based on whether one or more of the augmentation factors satisfies one or more augmentation rules. The augmentation rules can be stored in a database such as the augmentation rules database 412 of FIG. 4. For example, an augmentation rule may dictate that an alarm message should be augmented if the corresponding infusion device (e.g., infusion device 314of FIG. 3) is located in an ICU or NICU care area. Accordingly, if the augmentation factors indicate that the pump is located in an ICU or an NICU, then the alarm message will be augmented. As another example, another augmentation rule may dictate that an alarm message should be augmented if the type of the corresponding alarm is an occlusion alarm. If it is, then the alarm message will be augmented.

[0073] With regard to a recently triggered occlusion alarm, the disclosed system may determine whether that alarm message should be augmented based on comparing the augmentation factors for the alarm message against a standard set of augmentation rules specific to the alarm type of occlusion alarm. One of the augmentation factors considered in the determination according to the rule may include the location of the corresponding infusion therapy and, for example, indicate that the location is the ICU. And one of the augmentation rules may dictate that all alarm messages stemming from alarms triggered in the ICU should be augmented (e.g., modified to include additional data regarding the patient, such as the patient’s heart rate or the medication being provided to the patient). In this example, the process 500 may determine that the alarm message should e augmented based on an augmentation factor (i.e., the location of the infusion therapy - ICU) satisfying an augmentation rule (i.e., requiring alarm message augmentation for ICU alarm messages).

[0074] If the process 500 determines that the alarm message should be augmented (506- Y), then additional data may need to be retrieved for augmenting the alarm message (e.g., from augmentation data databases 414 of FIG. 4). Accordingly, in the depicted implementation, the process 500 also includes retrieving the additional data (i.e., the data to be augmented into the alarm message) from the infusion pump or from a server connected to the infusion pump (508). The additional server may be a hospital information systems server, such as the information system server 242 of FIG. 2 or the hospital information systems 316 of FIG. 3. Continuing with the above example, the process 500 can include retrieving the patient’s heart rate and / or the medication being provided to the patient. Thereafter, this additional data can be augmented into the alarm message.

[0075] Further, the example process 500 continues by augmenting the alarm message with the additional data (510) (e.g., using augmentation engine 410 of FIG. 4). As described previously, the alarm message may be augmented with one or more of the augmentation factors that satisfied corresponding augmentation rules. For example, if the rule(s) were satisfied based on the care area (e.g., ICU), then the alarm message may be augmented with the care area. In theabove example with regard to the occlusion alarm in the ICU, augmentation would include adding to the alarm message data regarding the alarm message originating from the ICU. However, in some implementations, data other than or in addition to the augmentation factors is added to the alarm message. For example, the augmentation rules may be independent of any physiological attributes (e.g., heart rate) of the patient receiving the infusion therapy, yet said physiological attributes can still be added to the alarm message during augmentation.

[0076] The example process 500 ends with the transmitting of the alarm message (512) (e.g., using message transmitter 408 of FIG. 4). According to various implementations, the alarm message is transmitted to a clinician device (e.g., a mobile device, a computer terminal).

[0077] As an additional example of augmentation factors and corresponding augmentation rules, in some implementations, the augmentation factors satisfy the one or more augmentation rules if (i) the one or more augmentation factors include the care area and the care area is an ICU or a NICU, (ii) the one or more augmentation factors include the fluid and the fluid includes an anesthetic agent or a chemotherapy agent, and / or (iii) the one or more augmentation factors include the alarm type and the alarm type includes an occlusion alarm or an air-in-line alarm.

[0078] Further, according to various implementations, the augmentation factors satisfy the one or more augmentation rules if the one or more augmentation factors include the type of the infusion pump and the infusion pump type is patient-controlled analgesic. In this instance, additional information can be added to the alarm message, such as an end-tidal CO2 level of the patient or a weight of the patient (e.g., for neonates). Moreover, in some implementations, the augmentation factors include the state of the infusion pump (e.g., active, stopped) or other information regarding the infusion pump (e.g., a current step of an ongoing infusion therapy; a type of the infusion therapy, such as bolus, continuous, keep vein open; whether the infusion pump is plugged in or battery powered; or relative channel status, such as whether another infusion pump neighboring the infusion pump is also alarming). The augmentation rules can dictate whether augmentation is needed based on the augmentation factors. Additionally, the augmentation rules can dictate the type of information to be added to the alarm message during the augmentation thereof.

[0079] As yet another example of augmentation factors and corresponding augmentation rules, in some implementations, the augmentation factors further include a physiological attribute of a recipient of the infusion therapy, an ailment of the recipient intended for treatment by the infusion therapy, an identifier of a clinician associated with the infusion pump, a medical history of the patient, a disease state of the patient, a pathophysiology of the patient, and / or aspects of the infusion therapy as configured in a drug library associated with the infusion device. In such implementations, the one or more augmentation factors satisfy the one or more augmentation rules if (i) the physiological attribute of the recipient indicates an age of the recipient that satisfies an age threshold, (ii) a body mass index (BMI) of the recipient that satisfies a BMI threshold, (iii) a blood-sugar level (BSL) of the recipient that satisfies a BSL threshold, and / or (iv) a pain level of the recipient that satisfies a pain threshold. Additionally, the one or more augmentation factors satisfy the one or more augmentation rules if the physiological attribute of the recipient indicates the recipient is pregnant, is immunocompromised, or is a high- risk patient. Moreover, the one or more augmentation factors satisfy the one or more augmentation rules if (i) the augmentation factors include a temperature of the patient that satisfies a temperature threshold (e.g., for patients with a fever), (ii) the augmentation factors include a blood pressure of the patient that satisfies a blood pressure threshold (e.g., for patients with certain cardiac conditions), (iii) the augmentation factors include a systolic pressure of the patient that satisfies a systolic pressure threshold (e.g., 120), and / or (iv) the augmentation factors include a pulse of the patient that satisfies a heart rate threshold or an irregularity threshold (e.g., for patients with certain cardiac conditions, in coma, or over medication risk).

[0080] The process may also involve augmenting a priority level of the infusion alarm message. For example, if it is determined that the alarm message is set to a priority level (e.g., a default priority level) that is higher or lower than it ought to be (e.g., as determined based on various “priority factors” relevant to the priority of the alarm message), then the priority level can be adjusted accordingly. Accordingly, in some implementations, the process includes, prior to transmitting the alarm message to the clinician, determining a priority score for the alarm message based on one or more priority factors, for example, the care area where the infusion pump is located, the fluid administered during the infusion therapy, the alarm type, the infusion pump type, the infusion pump state, a physiological attribute of the recipient of the infusion therapy, and / or an ailment of the recipient intended for treatment by the infusion therapy. Thereafter, the process can augment the alarm message with the priority score.

[0081] As a specific example of augmenting an infusion alarm message, in some implementations, the fluid includes an inotropic agent and the alarm type comprises an occlusion alarm. Accordingly, determining that the alarm message should be augmented may be based on the inotropic agent satisfying a first augmentation rule (e.g., requiring the fluid type to include an inotropic agent) and the occlusion alarm satisfying a second augmentation rule (e.g., requiring the alarm type to be an occlusion alarm). Further, augmenting the alarm message may include augmenting the alarm message with the inotropic agent, a blood pressure of a recipient of the infusion therapy, and a heart rate of a recipient.

[0082] The process can be used to manage the priority level of the alarm message based on various physiologic parameters, such as the heart rate and / or blood pressure of the patient. As yet another example of augmenting an infusion alarm message, the process may involve decreasing the priority of an occlusion alarm message from high priority (e.g., the default priority level) to medium priority after determining that the blood pressure and / or the heart rate of the patient are preserved (e.g., the current blood pressure and / or heart rate of the patient is within a predetermined amount of the blood pressure and / or heart rate of the patient pre-alarm). Alternatively, or additionally, the clinician can select heart failure as a pathophysiologic condition to treat (e.g., via a user interface of the infusion pump), and the process can thus use cardiac parameters (e.g., heart rate, blood pressure) for augmenting the alarm message.

[0083] The process can also accommodate multiple infusions. For example, the process may include receiving another alarm message from another infusion pump, where the other alarm message regards another alarm triggered during another infusion therapy performed by the other infusion pump. In such implementations, the process also includes determining another priority score for the other alarm message based on two or more of the aforenoted priority factors. Additionally, in such implementations, the process includes augmenting the other alarm message with the other priority score and transmit the alarm message to the clinician after augmenting the other alarm message with the other priority score, where the clinician is also associated with the other infusion pump.

[0084] Whereas alarm messages are typically reported on a first-in-first-out basis, in some implementations, the alarm messages are reported on a basis informed by the priority of the alarm, whether that is the default priority level or an augmented priority level. For example, if it is determined that the other alarm message is of a higher priority than the alarm message (e.g., based on the priority score and the other priority score), then the process may includequeuing the other alarm message for processing prior to the alarm message - even when the alarm message is received at a first time and the other alarm message is received at a second time subsequent to the first time. Queuing the other alarm message for processing prior to the alarm message may mean that the other alarm message is transmitted to the clinician prior to the alarm message.

[0085] According to some implementations, alarm messages cause automatic adjustments at corresponding infusion pumps (e.g., after processing at the infusion pump or an external system). In such implementations, processing the aforenoted other infusion alarm prior to the infusion alarm may cause the infusion pump to automatically adjust itself. As an example, certain alarms may implicate conditions in which the alarm may be remediated by adjustment to the speed of the pump or, in some instances, termination of the infusion. For example, the automatic adjustment may include adjusting (e.g., reducing) a speed of a motor of the infusion pump when the alarm is due to an occlusion in the infusion line. As another example, the automatic adjustment can include altering an annunciation (e.g., a beacon) of the corresponding alarm. Altering the annunciation may include adjusting a color of a visual annunciation or a volume of an audible annunciation. In some implementations, the automatic adjustment is made responsive to the other infusion alarm and before making adjustments responsive to the infusion alarm. In this manner, prioritizing processing of higher-priority infusion alarm messages can result in higher-priority infusion alarms being handled before lower-priority infusion alarms.

[0086] In some implementations, the alarm message comprises a priority score set to a default score for occlusion alarms. According to various implementations, the process further includes retrieving a first measure of the blood pressure of the recipient and a first measure the heart rate of the recipient at a first time subsequent to triggering of the alarm. Additionally, the process may include retrieving a second measure of the blood pressure of the recipient and a second measure of the heart rate of the recipient at a second time subsequent to the first time. Further, determining the priority score for the alarm message may include determining a reduced priority score less than the default score if a difference between the first and second measures of the blood pressure satisfies a stability threshold and a difference between the first and second measures of the heart rate satisfies another stability threshold. Alternatively, determining the priority score for the alarm message may include determining an increased priority score greater than the default score if the difference between the first and second measures ofthe blood pressure satisfies an instability threshold or the difference between the first and second measures of the heart rate satisfies another instability threshold.

[0087] Augmenting the infusion alarm can also include adding information regarding other active alerts or alarms on the same infusion device or for the same patient. For instance, if the alarm message corresponds to an occlusion alarm but an air-in-line alarm has also triggered at the same infusion device (e.g., at the same or another pump module), the alarm message can be augmented to include an indication regarding the air-in-line alarm. In such instances, an alarm message regarding the other active alarm (e.g., the air-in-line alarm) can be cancelled and / or not transmitted to the clinician.

[0088] As noted above, the additional data added to the alarm message during augmentation may correspond to an augmentation factor of the one or more augmentation factors that satisfies a respective augmentation rule of the one or more augmentation rules. Additionally, or alternatively, the additional data may regard a status of the infusion device. For example, the additional data car regard a motor speed, a temperature, a power level, a power source (e.g., battery or steady), a number of connected modules, a network connection status, an alarming module type (e.g., patient-controlled analgesic, syringe, or large-volume pump), a duration of the alarm, a module head height (e.g., a vertical distance between the module and the patient), a picture of the patient care unit and / or module set up with the module that is alarming highlighted so the nurse knows exactly where to look when going to the pump, and / or recommendations on how to resolve the alarm.

[0089] The additional data may also include drug library information for a drug programmed on the alerting module, such as a drug type, a drug name, whether the drug is designated high-risk, and / or drug library limits for the drug (or the recipient of the infusion therapy) (e.g., from a drug library of the infusion device or an electronic medical record drug library). Moreover, the additional data may include other programming parameters for the infusion device, such as a program type (e.g., continuous, intermittent, bolus), programming used for the module (e.g., APR or basic), an amount of detection for monitored event (e.g., air in line alarm limit, amount of air detected, occlusion alarm limit, detected pressure), an administration set identifier or type associated with the alerting module, and / or an amount of time an administration set has been used in the infusion therapy. Furthermore, the additional data may include patient information, such as a latest vital sign reading (e.g., heartrate, breath rate, EtCO2 level,pulse, temperature), a relevant lab reading (e.g., glucose level), or other nursing documentation from the electronic medical record (e.g., pain score or pain level).

[0090] According to certain implementations, a machine-learning model is used to perform one or more steps of the process, such as the determination regarding whether the alarm message should be augmented and / or the augmentation operation itself. For example, the infusion connectivity gateway may include a machine-learning model configured to generate augmented alarm messages corresponding to respective received alarm messages and based on training data including other alarm messages and corresponding other augmented alarm messages. Accordingly, the process can include providing the alarm message to the machine-learning model and receiving a generated alarm message from the machine-learning model. The process may further include transmitting the generated alarm message to the clinician after receiving the generated augmented alarm message. These steps may replace the corresponding operations in the process 500 described above (i.e., operations 506-510); however, in some implementations, the process includes both operations 506-510 and these machine-learning model operations.

[0091] FIG. 6 is a conceptual diagram that depicts an example electronic system 600 for augmenting infusion alarm messages, according to various aspects of the subject technology. The electronic system 600 may be implemented by a computing device for execution of software associated with portions or steps of the processes 400 and / or 450 of FIGS. 4A and 4B, respectively, or components provided by FIGS. 1 through 3B. In this regard, the electronic system 600 may include the patient care device 100 of FIG. 1, the patient care device 202 of FIG. 2, and / or the syringe pump module 300 of FIGS. 3A and 3B.

[0092] The electronic system 600 may also include a specifically-configured personal computer or a mobile device for infusion, such as a smartphone, tablet computer, laptop, PDA, an augmented reality device, a wearable such as a watch or band or glasses, or combination thereof, or other touch screen or television with one or more processors embedded therein or coupled thereto, or any other sort of computer-related electronic device having network connectivity.

[0093] Additionally, the electronic system 600 may include various types of computer- readable media and interfaces for various other types of computer-readable media. In the depicted example, the electronic system 600 includes a bus 608, a processing unit 612, a systemmemory 604, a read-only memory (ROM) 610, a permanent storage device 602, an input device interface 614, an output device interface 606, and a network interface 616. In some implementations, the electronic system 600 may include or be integrated with other computing devices or circuitry for operation of the various components and methods previously described.

[0094] The bus 608 collectively represents system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 600. For instance, the bus 608 communicatively connects processing unit 612 with the ROM 610, the system memory 604, and the permanent storage device 602. From these various memory units, the processing unit 612 retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure. The processing unit 612 can be a single processor or a multi-core processor in different implementations.

[0095] The ROM 610 stores static data and instructions that are needed by processing unit 612 and other modules of the electronic system. The permanent storage device 602, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 600 is powered off. Some implementations of the subject disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 602. Other implementations use a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) as the permanent storage device 602.

[0096] Like the permanent storage device 602, the system memory 604 is a read-and-write memory device. However, unlike the storage device 602, the system memory 604 is a volatile read-and-write memory, such as random-access memory (RAM). The system memory 604 stores some of the instructions and data that the processor needs at runtime. In some implementations, the processes of the subject disclosure are stored in the system memory 604, the permanent storage device 602, and / or the ROM 610. From these various memory units, the processing unit 612 retrieves instructions to execute and data to process, in order to execute the processes of some implementations.

[0097] The bus 608 also connects to the input device interface 614 and the output device interface 606. The input device interface 614 enables the user to communicate information and select commands to the electronic system. Input devices used with the input device interface 614 include, for example, alphanumeric keyboards and pointing devices (also called “cursorcontrol devices”). The output device interface 606 enables, for example, the display of images generated by the electronic system 600. Output devices used with the output device interface 606 include, for example, printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices (e.g., touchscreens) that function as both input and output devices.

[0098] Furthermore, the bus 608 also couples the electronic system 600 to a network (not shown) through the network interface 616. The network interface 616 may include, for example, a wireless access point (e.g., Bluetooth or Wi-Fi) or radio circuitry for connecting to a wireless access point. The network interface 616 may also include hardware (e.g., ethemet hardware) for connecting the computer to a part of a network of computers such as a local area network (LAN), a wide area network (WAN), WLAN, an intranet, or a network of networks, such as the Internet. Components of the electronic system 600 can be used in conjunction with the subject disclosure when specifically configured with one of more of the features described.

[0099] The functions described above can be implemented in computer software, firmware, or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.

[0100] Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (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, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD- ROM, dual-layer DVD-ROM), a variety of recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and / or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, other optical or magnetic media, and floppy disks. The computer-readable media can store a computer program that is executable 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 is produced by a compiler, and filesincluding higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

[0101] While the above discussion primarily refers to microprocessor 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 that are stored on the circuit itself.

[0102] As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices specifically configured with one or more of the features described above. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer-readable medium” and “computer-readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

[0103] To provide for interaction with a user, implementations of the subject matter described in this specification can 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 a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, tactile feedback), and input from the user can be received in forms such as acoustic, speech, gesture, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user (e.g., by sending web pages to a web browser on a user’s client device in response to requests received from the web browser).

[0104] Implementations of the subject matter described in this specification can be implemented in a specifically configured computing system that includes a back end component (e.g., a data server), or that includes a specifically configured middleware component (e.g., an application server), or that includes a specifically configured front end component (e.g., a clientcomputer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification), or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by one or more forms or mediums of digital data communication, such as a communication network. Examples of communication networks include a LAN and a WAN, an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0105] The computing system can include specifically configured clients and servers. A client and server are generally remote from each other and may interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some implementations, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.

[0106] Those of skill in the art will appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or a combination thereof. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality may be implemented in varying ways for each particular application. Various components and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different way) all without departing from the scope of the subject technology.

[0107] It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order and are not meant to be limited to the specific order or hierarchy presented.

[0108] Illustration of Subject Technology as Clauses:

[0109] Various examples of aspects of the disclosure are described as numbered clauses (e.g., 1, 2, 3) for convenience. These are provided as examples, and do not limit the subject technology. Identifications of the figures and reference numbers are provided below merely as examples and for illustrative purposes, and the clauses are not limited by those identifications.

[0110] Clause 1. An infusion connectivity gateway configured to: receive, from an infusion pump, an alarm message associated with an alarm triggered during an infusion therapy performed by the infusion pump; retrieve, from the infusion pump or from a server connected to the infusion pump, one or more augmentation factors comprising one or more of (i) a care area where the infusion pump is located, (ii) a fluid administered during the infusion therapy, (iii) a type of the alarm, (iv) a type of the infusion pump, and (v) a state of the infusion pump; determine whether the one or more augmentation factors satisfy one or more augmentation rules; when the one or more augmentation factors satisfy the one or more augmentation rules: retrieve, from the infusion pump or from another server connected to the infusion pump, additional data regarding the infusion therapy or a recipient of the infusion therapy; augment the alarm message with the additional data after determining that the alarm message should be augmented; and transmit the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.[OHl] Clause 2. The infusion connectivity gateway of Clause 1, wherein: the one or more augmentation factors satisfy the one or more augmentation rules if: the one or more augmentation factors comprise the care area, and the care area is an intensive care unit or a neonatal intensive care unit; the one or more augmentation factors comprise the fluid, and the fluid comprises an anesthetic agent or a chemotherapy agent; or the one or more augmentation factors comprise the alarm type, and the alarm type comprises an occlusion alarm or an air-in-line alarm.

[0112] Clause 3. The infusion connectivity gateway of either Clause 1 or 2, wherein: the augmentation factors further comprise (i) a physiological attribute of a recipient of the infusion therapy and (ii) an ailment of the recipient intended for treatment by the infusion therapy; and the one or more augmentation factors satisfy the one or more augmentation rules if: the physiological attribute of the recipient indicates an age of the recipient that satisfies an age threshold, a BMI of the recipient that satisfies a BMI threshold, a BSL of the recipient that satisfies a BSLthreshold, or a pain level of the recipient that satisfies a pain threshold; or the physiological attribute of the recipient indicates the recipient is pregnant, is immunocompromised, or is a high-risk patient.

[0113] Clause 4. The infusion connectivity gateway of any one of Clauses 1 through 3, wherein: the infusion connectivity gateway is further configured to, prior to transmitting the alarm message to the clinician: determine a priority score for the alarm message based on two or more priority factors comprising (i) the care area where the infusion pump is located, (ii) the fluid administered during the infusion therapy, (iii) the alarm type, (iv) the infusion pump type, (v) the infusion pump state, (vi) a physiological attribute of the recipient of the infusion therapy, and (vii) an ailment of the recipient intended for treatment by the infusion therapy; and augment the alarm message with the priority score.

[0114] Clause 5. The infusion connectivity gateway of Clause 4, wherein: the infusion connectivity gateway is further configured to: receive another alarm message from another infusion pump, the other alarm message regarding another alarm triggered during another infusion therapy performed by the other infusion pump; determine another priority score for the other alarm message based on two or more other priority factors comprising (i) a care area where the other infusion pump is located, (ii) a fluid administered during the other infusion therapy, (iii) a type of the other alarm, (iv) a type of the other infusion pump, (v) a state of the other infusion pump, (vi) a physiological attribute of a recipient of the other infusion therapy, and (vii) an ailment of the recipient intended for treatment by the infusion therapy; augment the other alarm message with the other priority score; and transmit the alarm message to the clinician after augmenting the other alarm message with the other priority score, wherein the clinician is also associated with the other infusion pump.

[0115] Clause 6. The infusion connectivity gateway of Clause 5, wherein: the alarm message is received at a first time; the other alarm message is received at a second time subsequent to the first time; the infusion connectivity gateway is further configured to: determine that the other alarm message is higher priority than the alarm message based on the priority score and the other priority score; and responsive to determining that the other alarm message is higher priority than the alarm message, queue the other alarm message for processing prior to the alarm message.

[0116] Clause 7. The infusion connectivity gateway of any one of Clauses 4 through 6, wherein: the fluid comprises an inotropic agent; the alarm type comprises an occlusion alarm; determining that the alarm message should be augmented is based on (i) the inotropic agent satisfying a first augmentation rule and (ii) the occlusion alarm satisfying a second augmentation rule; and augmenting the alarm message comprises augmenting the alarm message with (i) the inotropic agent, (ii) a blood pressure of a recipient of the infusion therapy, and (iii) a heart rate of a recipient.

[0117] Clause 8. The infusion connectivity gateway of Clause 7, wherein: the alarm message comprises a priority score set to a default score for occlusion alarms; the infusion connectivity gateway is further configured to: retrieve a first measure of the blood pressure of the recipient and a first measure the heart rate of the recipient at a first time subsequent to triggering of the alarm; and retrieve a second measure of the blood pressure of the recipient and a second measure of the heart rate of the recipient at a second time subsequent to the first time; determining the priority score for the alarm message comprises: determining a reduced priority score less than the default score if (i) a difference between the first and second measures of the blood pressure satisfies a stability threshold and (ii) a difference between the first and second measures of the heart rate satisfies another stability threshold; or determining an increased priority score greater than the default score if (i) the difference between the first and second measures of the blood pressure satisfies an instability threshold or (ii) the difference between the first and second measures of the heart rate satisfies another instability threshold.

[0118] Clause 9. The infusion connectivity gateway of any one of Clauses 1 through 8, wherein: the additional data corresponds to an augmentation factor of the one or more augmentation factors that satisfies a respective augmentation rule of the one or more augmentation rules; and the additional data indicates a physiological attribute of a recipient of the infusion therapy, the physiological attribute comprising a heart rate of the recipient or a blood pressure of the recipient.

[0119] Clause 10. The infusion connectivity gateway of any one of Clauses 1 through 3, wherein: the infusion connectivity gateway comprises a machine-learning model configured to generate augmented alarm messages (i) corresponding to respective received alarm messages and (ii) based on training data comprising other alarm messages and corresponding other augmented alarm messages; and the infusion connectivity gateway is further configured to: provide the alarm message to the machine-learning model; receive a generated alarm message from themachine-learning model responsive to providing the alarm message to the machine-learning model; and transmit the generated alarm message to the clinician after receiving the generated augmented alarm message.

[0120] Clause 11. An infusion system comprising: an infusion pump; and an infusion connectivity gateway configured to: receive, from the infusion pump, an alarm message associated with an alarm triggered during an infusion therapy performed by the infusion pump; retrieve, from the infusion pump or from a server connected to the infusion pump, one or more augmentation factors comprising one or more of (i) a care area where the infusion pump is located, (ii) a fluid administered during the infusion therapy, (iii) a type of the alarm, (iv) a type of the infusion pump, and (v) a state of the infusion pump; determine whether the one or more augmentation factors satisfy one or more augmentation rules; when the one or more augmentation factors satisfy the one or more augmentation rules: retrieve, from the infusion pump or from another server connected to the infusion pump, additional data regarding the infusion therapy or a recipient of the infusion therapy; augment the alarm message with the additional data after determining that the alarm message should be augmented; and transmit the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.

[0121] Clause 12. The infusion system of Clause 11, wherein: the one or more augmentation factors satisfy the one or more augmentation rules if: the one or more augmentation factors comprise the care area, and the care area is an intensive care unit or a neonatal intensive care unit; the one or more augmentation factors comprise the fluid, and the fluid comprises an anesthetic agent or a chemotherapy agent; or the one or more augmentation factors comprise the alarm type, and the alarm type comprises an occlusion alarm or an air-in-line alarm.

[0122] Clause 13. The infusion system of either Clause 1 or 2, wherein: the augmentation factors further comprise (i) a physiological attribute of a recipient of the infusion therapy and (ii) an ailment of the recipient intended for treatment by the infusion therapy; and the one or more augmentation factors satisfy the one or more augmentation rules if: the physiological attribute of the recipient indicates an age of the recipient that satisfies an age threshold, a BMI of the recipient that satisfies a BMI threshold, a BSL of the recipient that satisfies a BSL threshold, or a pain level of the recipient that satisfies a pain threshold; or the physiological attribute of the recipient indicates the recipient is pregnant, is immunocompromised, or is a high-risk patient.

[0123] Clause 14. The infusion system of any one of Clauses 11 through 13, wherein: the infusion connectivity gateway is further configured to, prior to transmitting the alarm message to the clinician: determine a priority score for the alarm message based on two or more priority factors comprising (i) the care area where the infusion pump is located, (ii) the fluid administered during the infusion therapy, (iii) the alarm type, (iv) the infusion pump type, (v) the infusion pump state, (vi) a physiological attribute of the recipient of the infusion therapy, and (vii) an ailment of the recipient intended for treatment by the infusion therapy; and augment the alarm message with the priority score.

[0124] Clause 15. The infusion system of Clause 14, wherein: the infusion connectivity gateway is further configured to: receive another alarm message from another infusion pump, the other alarm message regarding another alarm triggered during another infusion therapy performed by the other infusion pump; determine another priority score for the other alarm message based on two or more other priority factors comprising (i) a care area where the other infusion pump is located, (ii) a fluid administered during the other infusion therapy, (iii) a type of the other alarm, (iv) a type of the other infusion pump, (v) a state of the other infusion pump, (vi) a physiological attribute of a recipient of the other infusion therapy, and (vii) an ailment of the recipient intended for treatment by the infusion therapy; augment the other alarm message with the other priority score; and transmit the alarm message to the clinician after augmenting the other alarm message with the other priority score, wherein the clinician is also associated with the other infusion pump.

[0125] Clause 16. The infusion system of Clause 15, wherein: the alarm message is received at a first time; the other alarm message is received at a second time subsequent to the first time; the infusion connectivity gateway is further configured to: determine that the other alarm message is higher priority than the alarm message based on the priority score and the other priority score; and responsive to determining that the other alarm message is higher priority than the alarm message, queue the other alarm message for processing prior to the alarm message.

[0126] Clause 17. The infusion system of any one of Clauses 14 through 16, wherein: the fluid comprises an inotropic agent; the alarm type comprises an occlusion alarm; determining that the alarm message should be augmented is based on (i) the inotropic agent satisfying a first augmentation rule and (ii) the occlusion alarm satisfying a second augmentation rule; and augmenting the alarm message comprises augmenting the alarm message with (i) the inotropicagent, (ii) a blood pressure of a recipient of the infusion therapy, and (iii) a heart rate of a recipient.

[0127] Clause 18. The infusion system of Clause 17, wherein: the alarm message comprises a priority score set to a default score for occlusion alarms; the infusion connectivity gateway is further configured to: retrieve a first measure of the blood pressure of the recipient and a first measure the heart rate of the recipient at a first time subsequent to triggering of the alarm; and retrieve a second measure of the blood pressure of the recipient and a second measure of the heart rate of the recipient at a second time subsequent to the first time; determining the priority score for the alarm message comprises: determining a reduced priority score less than the default score if (i) a difference between the first and second measures of the blood pressure satisfies a stability threshold and (ii) a difference between the first and second measures of the heart rate satisfies another stability threshold; or determining an increased priority score greater than the default score if (i) the difference between the first and second measures of the blood pressure satisfies an instability threshold or (ii) the difference between the first and second measures of the heart rate satisfies another instability threshold.

[0128] Clause 19. The infusion system of any one of Clauses 11 through 18, wherein: the additional data corresponds to an augmentation factor of the one or more augmentation factors that satisfies a respective augmentation rule of the one or more augmentation rules; and the additional data indicates a physiological attribute of a recipient of the infusion therapy, the physiological attribute comprising a heart rate of the recipient or a blood pressure of the recipient.

[0129] Clause 20. A computer-implemented method for augmenting infusion alarm messages, the method comprising: receiving, from an infusion pump, an alarm message associated with an alarm triggered during an infusion therapy performed by the infusion pump; retrieving, from the infusion pump or from a server connected to the infusion pump, one or more augmentation factors comprising one or more of (i) a care area where the infusion pump is located, (ii) a fluid administered during the infusion therapy, (iii) a type of the alarm, (iv) a type of the infusion pump, and (v) a state of the infusion pump; determining whether the one or more augmentation factors satisfy one or more augmentation rules; when the one or more augmentation factors satisfy the one or more augmentation rules: retrieving, from the infusion pump or from another server connected to the infusion pump, additional data regarding the infusion therapy or a recipient of the infusion therapy; augmenting the alarm message with the additionaldata after determining that the alarm message should be augmented; and transmitting the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.

[0130] Further Consideration:

[0131] It is understood that the specific order or hierarchy of steps in the processes disclosed herein is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0132] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. The previous 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 readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more”. Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the invention described herein.

[0133] The predicate words “configured to”, “operable to”, and “programmed to” do not imply any particular tangible or intangible modification of a subject, but, rather, are intended to be used interchangeably. For example, a processor configured to monitor and control an operation or a component may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation. Likewise, a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code.

[0134] The term automatic, as used herein, may include performance by a computer or machine without user intervention; for example, by instructions responsive to a predicate action by the computer or machine or other initiation mechanism. The word “example” is used hereinto mean “serving as an example or illustration”. Any aspect or design described herein as “example” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0135] A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as an “implementation” does not imply that such implementation is essential to the subject technology or that such implementation applies to all configurations of the subject technology. A disclosure relating to an implementation may apply to all implementations, or one or more implementations. An implementation may provide one or more examples. A phrase such as “implementations” may refer to one or more embodiments and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. A phrase such as a “configuration” may refer to one or more configurations and vice versa.

[0136] As used herein a “user interface” (also referred to as an interactive user interface, a graphical user interface or a UI) may refer to a network based interface including data fields and / or other control elements for receiving input signals or providing electronic information and / or for providing information to the user in response to any received input signals. Control elements may include dials, buttons, icons, selectable areas, or other perceivable indicia presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiates an exchange of data for the device presenting the UI. A UI may be implemented in whole or in part using technologies such as hyper-text mark-up language (HTML), FLASH™, JAVA™, .NET™, C, C++, web services, or rich site summary (RSS). In some implementations, a UI may be included in a stand-alone client (for example, thick client, fat client) configured to communicate (e.g., send or receive data) in accordance with one or more of the aspects described. The communication may be to or from a medical device or server in communication therewith.

[0137] As used herein, the terms “determine” or “determining” encompass a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, generating, obtaining, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like via a hardware element without user intervention. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like via a hardware element without user intervention. “Determining” may include resolving, selecting, choosing, establishing, and the like via a hardware element without user intervention.

[0138] As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” may include storing a value in a location of a storage device for subsequent retrieval, transmitting a value directly to the recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, and the like. “Providing” may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like via a hardware element.

[0139] As used herein, the term “message” encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information. A message may include a machine readable aggregation of information such as an XML document, fixed field message, comma separated message, JSON, a custom protocol, or the like. A message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.

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

[0141] As used herein, the terms “correspond” or “corresponding” encompasses a structural, functional, quantitative and / or qualitative correlation or relationship between two or more objects, data sets, information and / or the like, preferably where the correspondence or relationship may be used to translate one or more of the two or more objects, data sets, informationand / or the like so to appear to be the same or equal. Correspondence may be assessed using one or more of a threshold, a value range, fuzzy logic, pattern matching, a machine-learning assessment model, or combinations thereof.

[0142] In any implementation, data generated or detected can be forwarded to a “remote” device or location, where “remote”, means a location or device other than the location or device at which the program is executed. For example, a remote location could be another location (e.g., office, lab, etc.) in the same city, another location in a different city, another location in a different state, another location in a different country, etc. As such, when one item is indicated as being “remote” from another, what is meant is 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 references transmitting the data representing that information as electrical signals over a suitable communication channel (e.g., a private or public network). “Forwarding” an item refers to any means of getting that item from one location to the next, whether by physically transporting that item or otherwise (where that is possible) and includes, at least in the case of data, physically transporting a medium carrying the data or communicating the data. Examples of communicating media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the internet or including email transmissions and information recorded on websites and the like.

Claims

What is claimed is:

1. An infusion connectivity gateway configured to: receive, from an infusion pump, an alarm message associated with an alarm triggered during an infusion therapy performed by the infusion pump; retrieve, from the infusion pump or from a server connected to the infusion pump, one or more augmentation factors comprising one or more of (i) a care area where the infusion pump is located, (ii) a fluid administered during the infusion therapy, (iii) a type of the alarm, (iv) a type of the infusion pump, and (v) a state of the infusion pump; determine whether the one or more augmentation factors satisfy one or more augmentation rules; when the one or more augmentation factors satisfy the one or more augmentation rules: retrieve, from the infusion pump or from another server connected to the infusion pump, additional data regarding the infusion therapy or a recipient of the infusion therapy; augment the alarm message with the additional data after determining that the alarm message should be augmented; and transmit the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.

2. The infusion connectivity gateway of Claim 1, wherein: the one or more augmentation factors satisfy the one or more augmentation rules if: the one or more augmentation factors comprise the care area, and the care area is an intensive care unit or a neonatal intensive care unit; the one or more augmentation factors comprise the fluid, and the fluid comprises an anesthetic agent or a chemotherapy agent; or the one or more augmentation factors comprise the alarm type, and the alarm type comprises an occlusion alarm or an air-in-line alarm.

3. The infusion connectivity gateway of either Claim 1 or 2, wherein: the augmentation factors further comprise (i) a physiological attribute of a recipient of the infusion therapy and (ii) an ailment of the recipient intended for treatment by the infusion therapy; and the one or more augmentation factors satisfy the one or more augmentation rules if:the physiological attribute of the recipient indicates an age of the recipient that satisfies an age threshold, a body mass index (BMI) of the recipient that satisfies a BMI threshold, a blood-sugar level (BSL) of the recipient that satisfies a BSL threshold, or a pain level of the recipient that satisfies a pain threshold; or the physiological attribute of the recipient indicates the recipient is pregnant, is immunocompromised, or is a high-risk patient.

4. The infusion connectivity gateway of any one of Claims 1 through 3, wherein: the infusion connectivity gateway is further configured to, prior to transmitting the alarm message to the clinician: determine a priority score for the alarm message based on two or more priority factors comprising (i) the care area where the infusion pump is located, (ii) the fluid administered during the infusion therapy, (iii) the alarm type, (iv) the infusion pump type, (v) the infusion pump state, (vi) a physiological attribute of the recipient of the infusion therapy, and (vii) an ailment of the recipient intended for treatment by the infusion therapy; and augment the alarm message with the priority score.

5. The infusion connectivity gateway of Claim 4, wherein: the infusion connectivity gateway is further configured to: receive another alarm message from another infusion pump, the other alarm message regarding another alarm triggered during another infusion therapy performed by the other infusion pump; determine another priority score for the other alarm message based on two or more other priority factors comprising (i) a care area where the other infusion pump is located, (ii) a fluid administered during the other infusion therapy, (iii) a type of the other alarm, (iv) a type of the other infusion pump, (v) a state of the other infusion pump, (vi) a physiological attribute of a recipient of the other infusion therapy, and (vii) an ailment of the recipient intended for treatment by the infusion therapy; augment the other alarm message with the other priority score; and transmit the alarm message to the clinician after augmenting the other alarm message with the other priority score, wherein the clinician is also associated with the other infusion pump.

6. The infusion connectivity gateway of Claim 5, wherein: the alarm message is received at a first time; the other alarm message is received at a second time subsequent to the first time; the infusion connectivity gateway is further configured to: determine that the other alarm message is higher priority than the alarm message based on the priority score and the other priority score; and responsive to determining that the other alarm message is higher priority than the alarm message, queue the other alarm message for processing prior to the alarm message.

7. The infusion connectivity gateway of any one of Claims 4 through 6, wherein: the fluid comprises an inotropic agent; the alarm type comprises an occlusion alarm; determining that the alarm message should be augmented is based on (i) the inotropic agent satisfying a first augmentation rule and (ii) the occlusion alarm satisfying a second augmentation rule; and augmenting the alarm message comprises augmenting the alarm message with (i) the inotropic agent, (ii) a blood pressure of a recipient of the infusion therapy, and (iii) a heart rate of a recipient.

8. The infusion connectivity gateway of Claim 7, wherein: the alarm message comprises a priority score set to a default score for occlusion alarms; the infusion connectivity gateway is further configured to: retrieve a first measure of the blood pressure of the recipient and a first measure the heart rate of the recipient at a first time subsequent to triggering of the alarm; and retrieve a second measure of the blood pressure of the recipient and a second measure of the heart rate of the recipient at a second time subsequent to the first time; determining the priority score for the alarm message comprises: determining a reduced priority score less than the default score if (i) a difference between the first and second measures of the blood pressure satisfies a stability threshold and (ii) a difference between the first and second measures of the heart rate satisfies another stability threshold; ordetermining an increased priority score greater than the default score if (i) the difference between the first and second measures of the blood pressure satisfies an instability threshold or (ii) the difference between the first and second measures of the heart rate satisfies another instability threshold.

9. The infusion connectivity gateway of any one of Claims 1 through 8, wherein: the additional data corresponds to an augmentation factor of the one or more augmentation factors that satisfies a respective augmentation rule of the one or more augmentation rules; and the additional data indicates a physiological attribute of a recipient of the infusion therapy, the physiological attribute comprising a heart rate of the recipient or a blood pressure of the recipient.

10. The infusion connectivity gateway of any one of Claims 1 through 3, wherein: the infusion connectivity gateway comprises a machine-learning model configured to generate augmented alarm messages (i) corresponding to respective received alarm messages and (ii) based on training data comprising other alarm messages and corresponding other augmented alarm messages; and the infusion connectivity gateway is further configured to: provide the alarm message to the machine-learning model; receive a generated alarm message from the machine-learning model responsive to providing the alarm message to the machine-learning model; and transmit the generated alarm message to the clinician after receiving the generated augmented alarm message.

11. An infusion system comprising: an infusion pump; and an infusion connectivity gateway configured to: receive, from the infusion pump, an alarm message associated with an alarm triggered during an infusion therapy performed by the infusion pump; retrieve, from the infusion pump or from a server connected to the infusion pump, one or more augmentation factors comprising one or more of (i) a care area where the infusion pump is located, (ii) a fluid administered during the infusion therapy,(iii) a type of the alarm, (iv) a type of the infusion pump, and (v) a state of the infusion pump; determine whether the one or more augmentation factors satisfy one or more augmentation rules; when the one or more augmentation factors satisfy the one or more augmentation rules: retrieve, from the infusion pump or from another server connected to the infusion pump, additional data regarding the infusion therapy or a recipient of the infusion therapy; augment the alarm message with the additional data after determining that the alarm message should be augmented; and transmit the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.

12. The infusion system of Claim 11, wherein: the one or more augmentation factors satisfy the one or more augmentation rules if: the one or more augmentation factors comprise the care area, and the care area is an intensive care unit or a neonatal intensive care unit; the one or more augmentation factors comprise the fluid, and the fluid comprises an anesthetic agent or a chemotherapy agent; or the one or more augmentation factors comprise the alarm type, and the alarm type comprises an occlusion alarm or an air-in-line alarm.

13. The infusion system of either Claim 11 or 12, wherein: the augmentation factors further comprise (i) a physiological attribute of a recipient of the infusion therapy and (ii) an ailment of the recipient intended for treatment by the infusion therapy; and the one or more augmentation factors satisfy the one or more augmentation rules if: the physiological attribute of the recipient indicates an age of the recipient that satisfies an age threshold, a BMI of the recipient that satisfies a BMI threshold, a BSL of the recipient that satisfies a BSL threshold, or a pain level of the recipient that satisfies a pain threshold; or the physiological attribute of the recipient indicates the recipient is pregnant, is immunocompromised, or is a high-risk patient.

14. The infusion system of any one of Claims 11 through 13, wherein: the infusion connectivity gateway is further configured to, prior to transmitting the alarm message to the clinician: determine a priority score for the alarm message based on two or more priority factors comprising (i) the care area where the infusion pump is located, (ii) the fluid administered during the infusion therapy, (iii) the alarm type, (iv) the infusion pump type, (v) the infusion pump state, (vi) a physiological attribute of the recipient of the infusion therapy, and (vii) an ailment of the recipient intended for treatment by the infusion therapy; and augment the alarm message with the priority score.

15. The infusion system of Claim 14, wherein: the infusion connectivity gateway is further configured to: receive another alarm message from another infusion pump, the other alarm message regarding another alarm triggered during another infusion therapy performed by the other infusion pump; determine another priority score for the other alarm message based on two or more other priority factors comprising (i) a care area where the other infusion pump is located, (ii) a fluid administered during the other infusion therapy, (iii) a type of the other alarm, (iv) a type of the other infusion pump, (v) a state of the other infusion pump, (vi) a physiological attribute of a recipient of the other infusion therapy, and (vii) an ailment of the recipient intended for treatment by the infusion therapy; augment the other alarm message with the other priority score; and transmit the alarm message to the clinician after augmenting the other alarm message with the other priority score, wherein the clinician is also associated with the other infusion pump.

16. The infusion system of Claim 15, wherein: the alarm message is received at a first time; the other alarm message is received at a second time subsequent to the first time; the infusion connectivity gateway is further configured to: determine that the other alarm message is higher priority than the alarm message based on the priority score and the other priority score; andresponsive to determining that the other alarm message is higher priority than the alarm message, queue the other alarm message for processing prior to the alarm message.

17. The infusion system of any one of Claims 14 through 16, wherein: the fluid comprises an inotropic agent; the alarm type comprises an occlusion alarm; determining that the alarm message should be augmented is based on (i) the inotropic agent satisfying a first augmentation rule and (ii) the occlusion alarm satisfying a second augmentation rule; and augmenting the alarm message comprises augmenting the alarm message with (i) the inotropic agent, (ii) a blood pressure of a recipient of the infusion therapy, and (iii) a heart rate of a recipient.

18. The infusion system of Claim 17, wherein: the alarm message comprises a priority score set to a default score for occlusion alarms; the infusion connectivity gateway is further configured to: retrieve a first measure of the blood pressure of the recipient and a first measure the heart rate of the recipient at a first time subsequent to triggering of the alarm; and retrieve a second measure of the blood pressure of the recipient and a second measure of the heart rate of the recipient at a second time subsequent to the first time; determining the priority score for the alarm message comprises: determining a reduced priority score less than the default score if (i) a difference between the first and second measures of the blood pressure satisfies a stability threshold and (ii) a difference between the first and second measures of the heart rate satisfies another stability threshold; or determining an increased priority score greater than the default score if (i) the difference between the first and second measures of the blood pressure satisfies an instability threshold or (ii) the difference between the first and second measures of the heart rate satisfies another instability threshold.

19. The infusion system of any one of Claims 11 through 18, wherein: the additional data corresponds to an augmentation factor of the one or more augmentation factors that satisfies a respective augmentation rule of the one or more augmentation rules; and the additional data indicates a physiological attribute of a recipient of the infusion therapy, the physiological attribute comprising a heart rate of the recipient or a blood pressure of the recipient.

20. A computer-implemented method for augmenting infusion alarm messages, the method comprising: receiving, from an infusion pump, an alarm message associated with an alarm triggered during an infusion therapy performed by the infusion pump; retrieving, from the infusion pump or from a server connected to the infusion pump, one or more augmentation factors comprising one or more of (i) a care area where the infusion pump is located, (ii) a fluid administered during the infusion therapy, (iii) a type of the alarm, (iv) a type of the infusion pump, and (v) a state of the infusion pump; determining whether the one or more augmentation factors satisfy one or more augmentation rules; when the one or more augmentation factors satisfy the one or more augmentation rules: retrieving, from the infusion pump or from another server connected to the infusion pump, additional data regarding the infusion therapy or a recipient of the infusion therapy; augmenting the alarm message with the additional data after determining that the alarm message should be augmented; and transmitting the alarm message to a clinician associated with the infusion pump after augmenting the alarm message.

Images