EP4690223A1

EP4690223A1 - Systems and methods for automated protocol guidance

Info

Publication number: EP4690223A1
Application number: EP23719151.5A
Authority: EP
Inventors: Lisa Diggett; Michael K. WORKMAN; Claire Ellen KNIGHT
Original assignee: CareFusion 303 Inc
Current assignee: CareFusion 303 Inc
Priority date: 2023-03-28
Filing date: 2023-03-28
Publication date: 2026-02-11
Also published as: WO2024205577A1; CN120898250A

Abstract

An infusion system includes a first therapy device and an infusion control unit. The infusion control unit is configured to receive a protocol-based automated programming request (pAPR). The pAPR also instructs the infusion control unit to cause the first therapy device to perform a primary operation associated with the therapy if a medical test result satisfies a criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion. The infusion control unit is also configured to obtain the medical test result from the first electronic device based on the pAPR. Additionally, the infusion control unit is configured to select the primary operation responsive to determining that the medical test result satisfies the criterion, or otherwise select the secondary operation. Further, the infusion control unit is configured to perform the selected operation based on the pAPR.

Description

SYSTEMS AND METHODS FOR AUTOMATED PROTOCOL GUIDANCE

BACKGROUND

[0001] Many modern infusion devices are configured to receive infusion parameter packages sometimes referred to as automated programming requests (APRs). These APRs contain much of the information necessary for performing an infusion therapy, thereby alleviating the need for clinicians to manually program parameters into infusion devices for therapies performed thereby.

[0002] Current APR technology allows clinicians to initiate individual therapies, but it does not account for the complexities of multi-step medical protocols. Rather, existing systems treat each infusion as an isolated event, instead of a step within a multi-step process. Healthcare information systems are at present incapable of transmitting, executing, and monitoring series of therapies, especially those that involve multiple steps. For example, a chemotherapy treatment may require the sequential infusion of multiple different drugs, with other medical tests or procedural events interspersed throughout the infusions. There is no APR analogue for such a procedure.

[0003] Accordingly, managing multi-step medical protocols requires extensive clinician intervention and documentation. All of these manual processes raise potential safety concerns, as each step must be independently programmed and executed - creating risks for data entry errors, clinician oversight, non-compliance, and so on. This is increasingly true in overwhelmed or understaffed healthcare environments, where the minutiae of medical protocols might be overlooked.

SUMMARY

[0004] There is a need for an APR-type technology for multi-step medical protocols. The present disclosure provides protocol-based APRs (pAPRs) capable of incorporating the infusion parameters of APRs in addition to other parameters, requirements, and instructions for a given medical protocol. The integration of pAPRs into a healthcare environment is expected to improve compliance with said parameters, requirements, and instructions - not to mention decreasing the amount of time spent by clinicians in keeping track of it all. Additionally, decreasing time spent in ensuring compliance with a particular protocol is also expected to increase time spent at the patient bedside, thus improving patient treatment and experience. [0005] According to various aspects of the subject technology, an infusion system includes an infusion control unit configured to receive a protocol-based automated programming request (pAPR). The pAPR includes a criterion for a therapy. Additionally, the pAPR instructs the infusion control unit to obtain a medical test result from a first electronic device. The pAPR also instructs the infusion control unit to cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion. In addition to receiving the pAPR, the infusion control unit is also configured to obtain the medical test result from the first electronic device based at least in part on the pAPR. The infusion control unit is further configured to select the primary operation responsive to determining that the medical test result satisfies the criterion or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion. Moreover, the infusion control unit is configured to perform the selected operation based at least in part on the pAPR.

[0006] According to various aspects of the subj ect technology, a non-transitory, computer- readable medium includes instructions that, when executed by an infusion control unit, cause the infusion control unit to perform various functions. The functions include receiving a pAPR. The pAPR includes a criterion for a therapy. Additionally, the pAPR instructs the infusion control unit to obtain a medical test result from a first electronic device. The pAPR also instructs the infusion control unit to cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion. In addition to receiving the pAPR, the functions also include obtaining the medical test result from the first electronic device based at least in part on the pAPR. The functions further include selecting the primary operation responsive to determining that the medical test result satisfies the criterion or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion. Moreover, the functions include performing the selected operation based at least in part on the pAPR.

[0007] According to various aspects of the subject technology, a computer-implemented method for handling a pAPR includes receiving a pAPR at an infusion control unit. The pAPR includes a criterion for a therapy. Additionally, the pAPR instructs the infusion control unit to obtain a medical test result from a first electronic device. The pAPR also instructs the infusion control unit to cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion. In addition to receiving the pAPR, the method also includes obtaining, at the infusion control unit, the medical test result from the first electronic device based at least in part on the pAPR. The method further includes selecting, at the infusion control unit, the primary operation responsive to determining that the medical test result satisfies the criterion or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion. Moreover, the method includes performing, at the infusion control unit, the selected operation based at least in part on the pAPR.

[0008] 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

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

[0010] FIGS. 1A-1B depict an example patient care system that includes infusion pumps mounted to a control unit, according to various aspects of the subject technology.

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

[0012] FIG. 3 depicts an example system for automatically programming a medical device, according to various aspects of the subject technology.

[0013] FIGS. 4 A and 4B depict example flow diagrams for automatically programming one or more medical devices, according to various aspects of the subject technology.

[0014] FIGS. 5A-5C depict example flow diagrams for automatically programming one or more medical devices according to a given medical protocol (e.g., a pAPR), according to various aspects of the subject technology. [0015] FIG. 6 depicts an example process for administering a protocol (e.g., a pAPR), according to various aspects of the subject technology.

[0016] FIG. 7 depicts an example control unit and example screens displayed thereon for administering a protocol, according to various aspects of the subject technology.

[0017] FIG. 8 is a flow diagram illustrating example screens presented to a clinician regarding patients and corresponding protocols, according to various aspects of the subject technology.

[0018] FIG. 9 is a conceptual diagram illustrating an example electronic system for automatically programming one or more medical devices to operate according to a given medical protocol, 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 some 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] The present disclosure solves the unmet need of providing a central device for coordinating not just the delivery of a single infusion order by a single device but rather of an entire medical protocol across potentially multiple devices. Whereas an APR assists in coordinating a single infusion treatment, a protocol-based automated programming request (pAPR) coordinates a medical protocol - improving clinician efficiency and compliance with the requirements of the protocol. As used herein, “protocol-based automated programming request” or “pAPR” refers to a data structure that includes the parameters and steps required for administration of a given medical protocol that is not restricted to actions of a single device.

[0021] For example, a pAPR may include information regarding the infusion of two different drugs from two different infusion pumps, as well as the total volume and flow rates for each of the drugs. The pAPR may also include a step indicating that the patient ought to walk around for a certain amount of time between the two infusions, and that the clinician ought to confirm that the patient’s blood pressure does not exceed a predetermined threshold prior to administration of the second infusion therapy. In some implementations, the pAPR may instruct a blood pressure device to measure the blood pressure of the patient and adjust an infusion pump’s delivery of a drug based on the measured pressure.

[0022] Further, as used herein, “order” may refer to a single infusion delivery (e.g., delivering an amount of a fluid via an infusion pump). Moreover, as used herein, “therapy” may refer to a collection of drugs that can be used for multiple different protocols. A “protocol” can include several different steps, some of which may be performed by an infusion pump whereas other steps may be performed off-pump.

[0023] In most instances, pAPRs are defined at a server level. For example, a server may receive an order to execute a protocol (e.g., an open-heart surgery) for a patient. The protocol may include gates, times, drug orders, vital sign readings, patient checks and corresponding confirmations, other electronic medical record (EMR) data, and the like. In order to administer the protocol, the server can leverage one or more infusion control units (or patient care units) to present the protocol steps to a clinician. Further, the server can leverage the infusion control unit to track times, alert the clinician of steps, and so on. Additionally, or alternatively, the server can send protocol-related information to a portable electronic device of the clinician.

[0024] In some implementations, the infusion control unit is configured to administer one or more steps of the protocol. As discussed in more detail below, the infusion control unit may also be configured to collect responses or confirmations from the clinician and to provide said responses or confirmations to EMR for documentation. Moreover, the infusion control unit can collect and/or have emergency or contingencies for the protocol cached, for example, in case the patient enters a danger zone. For instance, if the patient’s heart rate begins to drop below a certain threshold during a particular protocol, the infusion control unit may administer a particular drug to the patient. The infusion control unit may also re-order protocol steps or parameters based on the circumstances (e.g., based on physiological measurements of the patient).

[0025] Upon receipt of a pAPR, for example, an infusion control unit can initiate an infusion and then take additional steps to continue the protocol. In some implementations, the may include a gating item that must be completed before initiating an infusion for the patient. The infusion control unit may, for example, display a reminder of the gating item and query whether the gating item has been completed. Example gating items include obtaining a lab test (e.g., and receiving a particular result), moving the patient (e.g., walking for ten minutes), waiting for an amount of time (e.g., five minutes), checking the patient’s vital signs or hemodynamics, checking the patient’s respiratory status, monitoring the patient’s reaction (e.g., to the first infusion therapy), and querying electronic medical records (EMR) documentation.

[0026] Additionally, in some implementations, the pAPR includes steps that do not directly involve the infusion control unit. In these instances, the infusion control unit may still be involved, for example, as follows: For gating events, such as those noted above, the infusion control unit may display a prompt or a reminder of the gating event. Additionally, for information needed by the infusion control unit (e.g., lab results, medical test results), the infusion control unit can initiate an application programming interface (API) call to request or otherwise obtain said information. Also, the infusion control unit can initiate a timer - for example, for steps that require something to occur after a predetermined amount of time (e.g., walking a patient for ten minutes prior to an infusion therapy, as discussed above).

[0027] In some implementations, analytics associated with a pAPR may allow for enforcement of protocol. These can, for example, be implemented as an added layer of guardrails (e.g., in a drug library) to ensure the sequence required by the pAPR is performed within requisite safety parameters. Additionally, or alternatively, the aforesaid analytics may be used to collect data regarding compliance with pAPR steps in order to collect data regarding compliance (e.g., with respect to a particular therapy, a particular clinician, a particular healthcare facility, etc.).

[0028] An example clinician workflow implementing aspects of the pAPR technology disclosed herein might include: reviewing patient infusion orders at the start of the clinician’s shift, selecting a therapy “profile” for each patient, determining whether the therapy profiles deviate from standard profiles (e.g., to accommodate for patient needs), and sending the respective multi-step infusion therapies and associated pAPRs to the respective infusion control units. For the remainder of the clinician’s shift, all parts of each therapy for each patient would be available to the clinician (e.g., via the clinician’s portable electronic device, via a device terminal, or via the respective infusion control units). Moreover, if any of the infusion control units are interrupted, the clinician can pull up a list of the steps remaining for the respective pAPR and resume therapy accordingly.

[0029] FIG. 1A depicts an example patient care system 100 that includes infusion pumps 130-133 mounted to a control unit 104, according to various aspects of the subject technology. The patient care system 100 shown in FIG. 1 A includes four infusion pumps ISO- 133, each of which is in operative engagement with a respective administration set 120-123 (e.g., silicon tubing). The administration sets 120-123 connect the infusion pumps 130-133 to fluid supplies 110-113, which are inverted and suspended above the infusion pumps 130-133. The fluid supplies 110-113 are depicted as bottles in FIG. 1A, but they may also take other forms (e.g., bags, other containers). Both the fluid supplies 110-113 and the patient care device 102 are mounted to a roller stand 108.

[0030] The fluid supplies 110-113, as well as their orientation (e.g., mount location, mount height, mounting type, etc.) within the care area, may generate one or more interaction records. The interaction record for a set, for example, may be generated in part by detecting a scannable code associated with the set or by detecting a physical structure on the set that encodes identifying information for the set prior to use.

[0031] As shown in FIG. 1A, each administration set 120-123 is connected between a respective fluid supply 110-113 and a patient 106 so that the patient 106 may receive the fluids in any or all the fluid supplies 110-113. Each of the administration sets 120-123 may be identified either actively (e.g., by clinician scanning) or passively (e.g., by wireless or optical detection).

[0032] In the depicted example, a separate infusion pump 130-133 is used to infuse each of the respective fluids of the fluid supplies 110-113 into the patient 106. The infusion pumps 130-133 are flow control devices that will act on the respective tube or fluid conduit of the respective administration set 120-123 to move fluid from the fluid supply 110-113, through the conduit, and to the patient. Because individual infusion pumps 130-133 are used, each of the infusion pumps 130-133 may be individually set to the pumping or operating parameters required for infusing the particular medical fluid from the respective fluid supply 110-113 into the patient at the particular rate prescribed for that fluid by the clinician.

[0033] Typically, medical administration sets have more parts than are shown in FIG. 1 A. Many have check valves, drip chambers, valved ports, connectors, and other devices well known to those skilled in the art. These other devices have not been included in the drawings so as to preserve clarity of illustration.

[0034] FIG. IB depicts a closer view of a portion of the example patient care system 100 shown in FIG. 1A, according to various aspects of the subject technology. FIG. IB shows the control module 104, with two of the infusion pumps 131-132 mounted at either side of the control unit 104 (also referred to herein as an infusion control unit). In some implementations, the control unit 104 is configured for programming each of the infusion pumps 130-133. FIG. IB also shows the displays and controls of each of the infusion pumps, such as display 124 and controls 126A-D of infusion pump 132.

[0035] Each of the infusion pumps 130-133 includes a door and a handle. For example, infusion pump 132 includes door 128 and handle 134. The handle 134 operates to lock the door 128 in a closed position during operation. The handle 134 also operates unlock and open the door for loading an administration set (e.g., administration set 122) and for accessing the internal pumping and sensing mechanisms of the infusion pump 132. While the door 128 is open, the administration set 122 can be connected with the pump 132. While the door 128 is closed, the administration set 122 is brought into operating engagement with the pumping mechanism, the upstream and downstream pressure sensors, and/or the other equipment of the infusion pump 132.

[0036] The display 124 of the infusion pump 132 (e.g., an LED display) is located in plain view on the door 128 in the depicted embodiment and may be used to visually communicate information regarding the infusion pump 132. For example, the display 124 can communicate alert indications (e.g., alarm messages). Additionally, the control keys 126A-D exist for programming and controlling operations of the infusion pump as desired. In some implementations, the control keys may be presented as interactive elements on the display 124 (e.g., a touchscreen display). The patient care device 102 and/or infusion pump 132 may also include audio alert equipment in the form of a speaker.

[0037] The control unit 104 of the patient care device 102 includes a display 114 for visually communicating various information, such as the operating parameters of a connected pump or alert indications and alert messages. The control unit 104 also includes control keys 116A-C for selecting or setting control parameters and/or options for controlling the control module 104 and modules connected thereto (e.g., infusion pumps 130-133).

[0038] 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. 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. [0039] The control unit 104 may include a communications system by which the control unit 104 can communicate with external equipment, such as a medical facility server, a handheld communication device, a laptop-type computer, or other information device that a clinician may have to transfer information as well as to download drug libraries to the control unit.

[0040] The communication module may be used to transfer access or interaction information for clinicians encountering the control unit 104 or a device coupled thereto (e.g., infusion pumps 130-133, or bar code scanner). The communications system may include one or more of a radio frequency (RF) system, an optical system such as infrared, a BLUETOOTH™ system, or other wired or wireless system. The bar code scanner and communications system may alternatively be included integrally with the infusion pumps 130- 133, such as in cases where a control unit is not used, or in addition to one with the control unit 104. Further, information input devices need not be hard-wired to medical instruments, information may be transferred through a wireless connection as well. Additionally, other types of modules may be connected to the infusion pumps 130-133 or to the control unit 104 such as a syringe pump module, patient controlled analgesic module, end-tidal CO2 monitoring module, oximeter monitoring module, or the like.

[0041] In some embodiments, pressure measurements from upstream and/or downstream pressure sensors in the infusion pumps 130-133 are transmitted to a server or other coordination device, and the methods disclosed herein are implemented on the server or other coordination device. For example, more sophisticated and computationally intensive approaches like machine-learning can be implemented on the server (or on a PCU with a larger memory and/or CPU resources). In some embodiments, machine learning is used to identify empty conditions based on pressure signals received from the pump.

[0042] FIG. 2 depicts an example institutional patient care system 200 of a healthcare organization, according to various aspects of the subject technology. In FIG. 2, a patient care device 202 (e.g., patient care device 102 of FIGS. 1 A-1B) is connected to an internal healthcare network 236. The term patient care device, or “PCD,” may be used interchangeably with the term patient care unit, or “PCU,” either of which may include various ancillary medical devices such as an infusion pump (e.g., infusion pumps 130-133 of FIG. 1A), a vital signs monitor, a medication dispensing device (e.g., cabinet, tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned (e.g., a syringe pump module coupled with an infusion pump), or other similar devices. Each element of the patient care device 202 is connected to an internal healthcare network 236 by a transmission channel 234. Transmission channel 234 is any wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN).

[0043] In some implementations, the internal healthcare network 236 also includes computer systems located in various departments throughout a hospital. For example, the 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. As described further below, the internal healthcare network 236 may include discrete subnetworks. In the depicted example, network 10 includes a device network 238 by which the patient care device 202 and other devices communicate in accordance with normal operations.

[0044] Additionally, institutional patient care system 200 may incorporate a separate information system server 242 (e.g., a health information system (HIS) server). Moreover, 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. 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 assistances, and mobile devices such as laptops, tablet computers, augmented reality devices, or smartphones, configured with software for communications with information system server 242 via the internal healthcare network 236.

[0045] Patient care device 202 comprises a system for providing patient care, and may include or incorporate pumps (e.g., infusion pumps 130-133 of FIG. 1A), physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors), therapy devices, and other drug delivery devices may be utilized according to the teachings set forth herein.

[0046] In the depicted example, patient care device 202 comprises a control unit 204 (e.g., control unit 104 of FIGS. 1A-1B), also referred to as interface unit 204, connected to one or more functional modules 206-209 (e.g., infusion pumps 130-133 of FIG. 1 A). 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.

[0047] 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, softkeys, a mouse, a track ball, and/or a light pen.

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

[0049] 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, it is recognized that the data input device 232 may be external to the control unit 204 (e.g., at the device terminal 240).

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

[0051] Network connection 220 may be a wired or wireless connection, such as by Ethernet, WiFi, 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. [0052] The functional modules 206-209 are devices (e.g., infusion pumps 130-133 of FIG. 1A) for providing care to a patient or for monitoring patient conditions. As shown in FIG. 2, at least one of 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, a syringe pump, a PCA pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, an intracranial pressure monitor, or the like. Additionally, the functional modules 206-209 may be a printer, a scanner, a bar code reader, a near-field communication reader, an RFID reader, or any other peripheral input, output or input/output device.

[0053] Each functional module 206-209 communicates directly or indirectly with 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.

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

[0055] Each of the functional modules 206-209 may include a microprocessor 216, a volatile memory 214, a nonvolatile memory 212, and 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. [0056] 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.

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

[0058] 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 direct 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.

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

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

[0061] 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, times, etc.) associated with administration of the medication, a more accurate medication process should result.

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

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

[0064] With further reference to FIG. 2, the patient care device 202 is capable of operating in several different modes, or personalities, with each personality defined by a configuration database. The configuration database may be a database 226 internal to the patient care device 202, or an external database 244. A particular configuration database is selected based, at least in part, by patient-specific information such as patient location, age, physical characteristics, or medical characteristics. [0065] Medical characteristics include, but are not limited to, patient diagnosis, treatment prescription, medical history, medical records, patient care provider identification, physiological characteristics or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., physician identification) or the location of the patient care device 202 location in the hospital or hospital computer network. Patient care information may be entered through any of the network connection 220, the user interface device 230, the data input device 232, or the auxiliary interface 226. Additionally, patient care information may originate from anywhere in the internal healthcare network 236, such as from a pharmacy server, an admissions server, a laboratory, and the like.

[0066] The memory of the control unit 204 (e.g., RAM 222 or the disk 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.

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

[0068] 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 limit is 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. [0069] The pump also includes a display for displaying a user interface, including 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.

[0070] In the case of a syringe pump, the electronically loaded drug library may include a list of names of syringe manufacturers identifying syringes that can be used in the drug infusion pump, and the drug infusion pump offers the user the list of names of syringe manufacturers from which to make a selection when the electronically loaded drug library is in the pump. The loaded drug library may include a list of syringe sizes identifying syringes that can be used in the drug infusion pump, and the drug infusion pump offers the user the list of syringe sizes from which to make a selection when the electronically loaded drug library is in said pump. 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.

[0071] FIG. 3 depicts an example system 300 for automatically programming a medical device, according to various aspects of the subject technology. Interoperability between a hospital electronic medical records (EMR) server (e.g., information system server 242 of FIG. 2) and medical devices (e.g., patient care device 102 of FIGS. 1A-B, patient care device 202 of FIG. 2) enable pre-population of infusion parameters. Pre-population of infusion parameters may reduce the number of programming screens and key presses required with manually programming a pump. The implementation of interoperability does not preclude a clinician from manually programming the infusion device. Manual programming may be required in the event of a failure in any component of the interfaced system.

[0072] While features may be described with reference to an EMR server, the features are applicable to provide scan-less auto-programming of medical devices using similar hospital information systems such as pharmacy data management systems (PDMS). Furthermore, while the features may be described using an infusion pump as the example medical device, the features are applicable to provide scan-less auto-programming of other medical devices using barcodes for association such as patient monitors, patient association management systems, or alarms management systems.

[0073] A drug formulary 304 determines which medications can be dispensed within a hospital network (e.g., internal healthcare network 236 of FIG. 2). A hospital committee may be formed to determine how medications within that formulary would be applied to an infusion device 310 (e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2). Configuration definitions (e.g., by hospital unit such as ICU, NICU, Pediatrics, Oncology, Surgery, etc.) are agreed upon and the drugs and typical infusion protocols are established in a medical device drug library.

[0074] In addition, limitation conditions (or “guardrail” conditions) are defined in the drug library. When the definitions are complete, a configuration can then be released including the drug library. Infusion devices at the institution are then updated by transferring the configuration databases into some or all of their pumps. Corresponding updates to the drug formulary 304 may be shared with other hospital systems such as the pharmacy ordering system or an EMR system 302 which may use formulary information to generate a patient order to deliver a particular drug to a particular patient (see operation 320).

[0075] In the clinical field, a clinician may scan a medical item such as an infusate package using a scanner associated with a medical device, such as the infusion device 310. For example, a bar code reader (or other data input device) is used to scan the coded drug label, the patient’s coded ID band and the caregiver’s ID badge, and optionally supplementary prescription information or medical device configuration instructions (including configuration database ID) printed on the label or an accompanying order.

[0076] The reader/scanner is not required to be integrated with a medical device. The scanner may be part of a separate device such as an EMR terminal 306 (e.g., device terminal 240 of FIG. 2) connected to the same network (e.g., device network 238 of FIG. 2) as the infusion device 310 and configured with software to function in an overall workflow involving the infusion device 310.

[0077] The scanning initiates a process by which information pertaining to the item (e.g., scanned from a code affixed to or transmitted by the item) is automatically sent to the hospital EMR system 302 via a network (e.g., internal healthcare network 236) (see operation 322). The EMR system 302 may confirm the item and generate (see operation 324) and send an automated programming request (APR) to the infusion device 310 to load parameters pertaining to the item. The parameters may be stored in the infusion device 310, but loaded in response to an identifier received from the server. While the examples herein involve an infusion device, any medical device may be configured in the same or similar manner and employ the automated programming error mitigation described herein.

[0078] In the depicted implementation, a coordination engine 308 coordinates messages sent from the EMR system 302 to the infusion device 310. In the depicted implementation, the EMR system 302 transmits an APR (see operation 326) to the pump coordination engine 308 with a device identifier, also known as a “device ID,” of the infusion device 310 to receive the APR. The pump coordination engine 308 then determines whether the infusion device 310 identified by the EMR system 302 is available and, if so, forwards the APR to the infusion device 310 (see operation 328). When an APR received by the infusion device 310, the infusion device 310 programs itself according to the parameters of the APR.

[0079] In some implementations, the APR activates a drug library stored on the infusion device 310, and the infusion device 310 is programmed according to parameters stored in the drug library for medication identified in the APR. In some implementations, upon successful programming, the infusion device may automatically initiate operation based on the parameters. In some implementations, the infusion device 310 may confirm the automatically entered parameters (see operation 330). The confirmation may include presenting one or more user interface screens including the parameters and values along with a control element (e.g., a button) that, when activated, causes the infusion device to begin operation based on the parameters. The user interface may include additional or alternative control elements to allow a clinician to adjust an automatically entered parameter based on, for example, professional judgement or changes in patient condition.

[0080] FIGS. 4A and 4B depict example flow diagrams 400 and 450 for automatically programming one or more medical devices, according to various aspects of the subject technology. For explanatory purposes, the various blocks of example flow diagrams 400 and 450 are described herein with reference to FIGS. 1 A-3, as well as the associated components and/or processes described herein.

[0081] FIG. 4A depicts a first example flow diagram 400 for automatically programming one or more medical devices using an automated programming request (APR), according to various aspects of the subject technology. As described above, an identifier of a patient and/or a medical device (e.g., infusion device 310 of FIG. 3) may be entered (e.g., via scanning; see operation 322 of FIG. 3) at an EMR terminal 404 (e.g., device terminal 240 of FIG. 2, or EMR terminal 306 of FIG. 3). For example, an identifier of the medical device may be scanned from a barcode affixed to the medical device in conjunction with parameters entered into the terminal for selecting and generating an APR (see operation 322 of FIG. 3).

[0082] Entering the patient or medical device identifier initiates a process whereby information pertaining to the patient and/or the medical device is automatically sent to an EMR server 406 (e.g., information system server 242 of FIG. 2, or EMR system 302 of FIG. 3) of a hospital, and the EMR server 406 performs certain actions pertaining to the patient and/or the medical device and generates and sends an APR to the medical device to configure the medical device.

[0083] The subject technology provides a mechanism to automatically program a medical device without a scanner or manual translation of identifiers between the medical device and a terminal such as the EMR terminal 404. The scan-less device identification functionality of the subject technology enables a user to explicitly publish a message from a medical device to any data consumer (e.g., the EMR server 406) based on automated device identification propagation. The identifier is automatically sent to the consumer, which then correlates the identifier with other data to generate the APR and send the APR instructions back to the medical device.

[0084] Using infusion devices as an example, a hospital system implementing the subject technology may include one or more infusion devices 402 (e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2, or infusion device 310 of FIG. 3). It should be noted that the infusion device(s) 402 may additionally or alternatively include other devices for carrying out a medical protocol, such as a syringe pump, or a smartphone or tablet computer (e.g., for monitoring the medical protocol). These devices may also be referred to as “protocol devices” or “therapy devices.”

[0085] The hospital system may also include the EMR terminal 404 and the EMR server 406 connected to a connectivity gateway 408. In some implementations, the connectivity gateway 408 is part of or associated with a coordination engine (e.g., pump coordination engine 308 of FIG. 3). In some implementations, the connectivity gateway 408 is a separate system. [0086] In some implementations, the connectivity gateway 408 may include one or more computing devices such as servers apart from the EMR server 406. In some implementations, the connectivity gateway 408 may be implemented by or interchangeable with the pump coordination engine 308 of FIG. 3. In some implementations, the EMR server 406 and the connectivity gateway 408 may co-exist as a single server or group of servers. Additionally, the information system server 242 of FIG. 2 may be representative of the EMR server 406 and/or the connectivity gateway 408.

[0087] According to various implementations, the infusion device(s) 402 includes a user interface element that, when activated, is configured to transmit, via a communication network (e.g., internal healthcare network 236 of FIG. 2), a message indicating that the infusion device is ready to receive automated programming. For example, the infusion device(s) 402 may display on its display screen (e.g., display 114 of FIG. IB) a virtual button as the interface element. The virtual button may be activated by touch activation in implementations where the display screen is a touch screen, or may be activated by selecting a corresponding control key (e.g., control keys 116A-C of FIG. IB).

[0088] In the depicted example of FIG. 4A, a clinician interacts with (e.g., authenticates at) the EMR terminal 404 (see operation 410). The EMR terminal 404 may then obtain the clinician’s identification by way of the clinician interaction. In some implementations, the clinician inputs additional identifiers, such as a care area identifier, a patient identifier, a drug identifier, or other identifying information for requesting an APR be sent to the infusion device(s) 402. The identifying information obtained via the terminal 404 is then transmitted to the EMR server 406 as a request to automatically program an infusion device (see operation 411). In some implementations, the request does not include an identification of the infusion device(s) 402 to be programmed. Accordingly, the infusion device to programmed may not yet be known by the system.

[0089] Separately, via messaging (see operation 411), the interface element is activated and the infusion device(s) 402 or a module connected thereto sends a message to the connectivity gateway 408 indicating that the infusion device(s) 402 is ready to receive automated programming. The message may include, for example, parameters such as an identifier of the infusion device(s) 402 (e.g., a serial number), an identifier of a clinician assigned to the infusion device 402 (e.g., an identifier of a clinician logged into the device), a care area of the device, a patient care unit identifier (e.g., if the device is part of a PCU device), and/or an identifier of a patient associated with the infusion device, and the like. [0090] In some implementations, the interface element is activated after a determination is made (e.g., by the infusion device(s) 402, by a hospital information system) that the infusion device(s) 402 is in an operational state to be programmed for performing a therapy (e.g., administration of a medication to a patient). In some implementations, the interface element is a virtual button displayed on a touchscreen (e.g., display 114 of FIG. IB). In some implementations, the interface element includes a control key (e.g., control keys 116A-C of FIG. IB) associated with the option of sending the message indicating that the device is ready to receive automated programming. In some implementations, each active channel on the infusion device(s) 402 (e.g., each module 16, 18, 20, 22) may be associated with a virtual button and/or a control key, and the clinician may select the appropriate interface element to send the message on behalf of the channel.

[0091] The connectivity gateway 408 informs the EMR server 406 that the infusion device(s) 402 is ready to receive automated programming via messaging (see operation 413). The EMR server 406, based on the request sent by the EMR terminal 404, searches for and identifies all active medical devices that have indicated they are ready to receive automated programming (see operation 414) and returns a list of the active and ready devices to the EMR terminal 404 (see operation 415). The clinician then finds the infusion device(s) 402 within the list and selects the infusion device(s) 402 for automated programming according to the previously entered request. Once selected, the EMR terminal 404 sends the selected identification of the infusion device(s) 402 to the connectivity gateway 408 (see operation 416), and the connectivity gateway 408 associates the device identifier with the APR and sends the APR to the infusion device(s) 402 (see operation 417).

[0092] After the APR has been accepted and processed by the infusion device(s) 402 without failure, the infusion device(s) 402 will start and begin to infuse a medication according to the programming provided by the APR. After the infusion has begun, the infusion device(s) 402 will send one or more status messages to the EMR server 406. A status message informs the EMR system what was started and includes certain values on which the infusion device(s) 402 is reporting. This information may reflect the APR data and/or may include changes made at the device. The EMR server 406 may wait for the status message and, upon receiving the message, close out the workflow pertaining to the APR.

[0093] FIG. 4B depicts a second example flow diagram 450 for automatically programming one or more medical devices using an APR, according to various aspects of the subject technology. In the depicted second example flow diagram 450, a request for APR originating at the EMR terminal 404 and the APR is associated with one or more infusion device(s) 402 at the connectivity gateway 408 automatically rather than at the EMR server 406 as shown in FIG. 4 A. In this regard, the EMR terminal 404 may request auto-programming for a patient or a drug order for a patient, for example, without including a device identifier (see operation 460). The connectivity gateway 408 receives the request from the terminal 206 (see operation 461) in addition to separate indications that one or more infusion devices 402 are ready to receive an APR (see operation 462). In this regard, multiple available devices may be identified (425) by the connectivity gateway for execution of a given protocol.

[0094] Based at least in part on the received request and indication (see operations 461- 462), the connectivity gateway 408 automatically associates the infusion device(s) 402 and the EMR terminal 404 (see operation 463). This allows the previously unassociated APR request from the EMR terminal 404 to be routed to the infusion device(s) 402. For example, the medical device(s) 402 may provide a clinician identifier, a care area identifier, and/or a patient identifier. Similarly, the clinician may enter the same information at the EMR terminal 404. If these data points correspond, then the connectivity gateway 408 may automatically provide the APR without further human interaction.

[0095] In some implementations, the association may be based on therapies required by a given medical order and/or protocol. For example, as will be describe with regard to FIGS. 5A- 5C, a protocol may be identified for a patient, and the system may then determine available medical devices for the protocol based on the patient identifier and/or protocol requirements or other information within the protocol.

[0096] FIGS. 5A-5C depict example flow diagrams for automatically programming one or more medical devices according to a given medical protocol (e.g., a pAPR), according to various aspects of the subject technology. For example, FIG. 5 A depicts a first example flow diagram 500 for automatically programming one or more medical devices using a protocolbased APR (pAPR), according to various aspects of the subject technology.

[0097] In the depicted first flow diagram 500, one or more infusion devices 502 are associated with a patient (see operation 520). For example, the infusion device(s) 502 may be associated with a patient when a clinician enters an identifier of the patient into the infusion device(s) 502. When associated, the data pertaining to the association (e.g., identifiers of the infusion device(s), the patient care unit, or the patient) is sent to the connectivity gateway 508. [0098] Additionally, a clinician (e.g., the clinician who entered the patient identifier, or another clinician) interacts with a health information system (HIS) terminal 504 (e.g., an EMR terminal) (see operation 521) and selects a protocol via the HIS terminal 504 (see operation 522). For example, the protocol may be a chemotherapy treatment or a multi-step infusion protocol. Also, the protocol may correspond to a protocol-based automated programming request (pAPR) that includes instructions for instructing infusion device(s) 502 and/or other therapy devices for administering the protocol. Interaction with the HIS terminal 504 may occur before or after associating the infusion device(s) 502 with the patient (see operation 520).

[0099] Selecting the protocol may cause the HIS terminal 504 to send information relevant to the protocol to an HIS server 506 (e.g., an EMR server). For example, as depicted in the flow diagram 500, the HIS terminal 504 may send to the HIS server 506 a clinician identifier, a care area identifier, a patient identifier, a protocol identifier, and/or option indicators (e.g., indicating preference with regard to optional aspects of the protocol).

[00100] In the depicted example, after receipt of the information, the HIS terminal 504 identifies one or more medical devices, such as the infusion device(s) 502 (see operation 523). For example, the HIS terminal 504 may identify the medical device as a device required for performing the protocol. In this manner, the HIS terminal 504 can indicate that the medical device is required for the protocol after the protocol is selected. As another example, the HIS terminal 504 may identify devices that are associated with the patient (see operation 520) for which the protocol was selected.

[00101] In either event, after identifying the one or more medical devices, the HIS terminal 504 may send the protocol (e.g., a pAPR; see operation 524) to the HIS server 506 for eventual transmission to the medical devices. In some implementations, the HIS terminal 504 sends a patient identifier and/or a device identifier along with the protocol. Either of these identifiers may be used (e.g., by the HIS server 506 or the connectivity gateway 508) to determine which devices ought to receive the protocol.

[00102] The HIS server 506 may send the protocol along to a connectivity gateway 508 (e.g., connectivity gateway 408 of FIGS. 4A-4B) (see operation 525). In some implementations, the HIS server 506 also sends an identifier of the one or more medical devices to the connectivity gateway 508. Accordingly, the connectivity gateway 508 can then send the protocol to the devices for which the connectivity gateway 508 received identifiers (see operation 526). While FIGS. 5A-5C depict the HIS server 506 and gateway 508 as separate devices, in some implementations, these devices may be incorporated into a single device. In this regard, the HIS server 506 may send the protocol to the devices identified at the HIS terminal 504.

[00103] FIG. 5B depicts a second example flow diagram 530 for automatically programming one or more medical devices using a pAPR, according to various aspects of the subject technology. In the depicted example flow diagram 530, one or more infusion device(s) 502 is associated with a patient (see operation 550). For example, the infusion device(s) 502 may be associated with a patient when a clinician enters an identifier of the patient into the infusion device(s) 502. When associated, the data pertaining to the association (e.g., identifiers of the infusion device(s), the patient care unit, or the patient) is sent to the connectivity gateway 508.

[00104] Additionally, a clinician (e.g., another clinician) interacts with an HIS terminal 504 (e.g., an EMR terminal) (see operation 551) and selects a protocol via the HIS terminal 504 (see operation 552). For example, the protocol may be a chemotherapy treatment or a multi- step infusion protocol. Also, the protocol may correspond to a protocol-based automated programming request (pAPR) that includes instructions for instructing infusion device(s) 502 and/or other therapy devices for administering the protocol. Interaction with the HIS terminal 504 may occur before or after associating the infusion device(s) 502.

[00105] Selecting the protocol may cause the HIS terminal 504 to send information relevant to the protocol to the HIS server 506. For example, as depicted in the second flow diagram 530, the HIS terminal 504 may send to the HIS server 506 a clinician identifier, a care area identifier, a patient identifier, a protocol identifier, and/or option indicators (e.g., indicating preference with regard to optional aspects of the protocol).

[00106] The HIS server 506 identifies steps and device types associated with the protocol identifier (e.g., received from the HIS terminal 504) (see operation 553). For example, a protocol identifier (e.g., a pAPR identifier) for a given protocol may be associated with steps including an infusion treatment, a blood pressure measurement, and a blood pressure report (e.g., via a smartphone or tablet computer). Accordingly, the protocol identifier may also be associated with device types including infusion devices, blood-pressure monitors, and/or smartphones or tablet computers. [00107] The HIS server 506 also identifies devices of the device type that are associated with the protocol identifier (see operation 554). Further to the example above, the HIS server 506 may identify infusion devices, blood-pressure monitors, and/or smartphones or tablet computers (e.g., that are available for use, that are suitable for the protocol, that are within a certain distance of the intended treatment location).

[00108] After gathering necessary information (e.g., regarding steps or device types), the HIS server 506 sends a pAPR to the connectivity gateway 508 (see operation 555). Sending the pAPR to the connectivity gateway 508 may include sending a device identifier. For example, the HIS server 506 may send device identifiers for devices required or suggested for use in executing the pAPR. From there, the connectivity gateway 508 then sends the pAPR to the infusion device(s) 502 and/or other therapy devices (e.g., devices identified in operation 555) (see operation 556). In some embodiments, the HIS server 506 sends the pAPR directly to the infusion device(s) 502 and/or other therapy devices (e.g., rather than sending the pAPR to the connectivity gateway 508 and the connectivity gateway 508 sending the pAPR to the infusion device(s) 502).

[00109] FIG. 5C depicts a third example flow diagram 560 for automatically programming one or more medical devices using a pAPR, according to various aspects of the subject technology. In some instances, a device may not be associated with a patient or protocol at the same time as others. In the depicted third flow diagram 560, a first protocol device 510 (e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2, or infusion device 310 of FIG. 3) reports a protocol event to a protocol gateway 514 (e.g., connectivity gateway 408 or connectivity gateway 508) (see operation 580). Reporting the protocol event may include sending to the protocol gateway 514 a protocol identifier, a device identifier, a patient identifier, and/or information regarding the protocol event. For example, the first protocol device 510 may report the completion of an event (e.g., an infusion therapy) that is part of a protocol (e.g., a chemotherapy treatment).

[00110] The flow diagram 560 also depicts the protocol gateway 514 reporting the protocol event to an HIS server 506 (see operation 581). For example, after the protocol gateway 514 receives information from the first protocol device 510 regarding the completion of the protocol event, the protocol gateway 514 may report the protocol event’s completion to the HIS server 506. In this manner, the first protocol device 514 administering a protocol (e.g., as instructed by a pAPR) can stay in sync with other devices involved in administering the protocol, such as a second protocol device 512. [00111] After receiving the report of the protocol event from the protocol gateway 514, the HIS server 506 identifies one or more other devices associated with the patient identifier (see operation 582). For example, as discussed above, certain protocols and their corresponding pAPRs require multiple therapy devices (e.g., infusion devices, sensor devices, or other electronic devices). Accordingly, the HIS server 506 may identify each device associated with the given patient identifier (e.g., in conjunction with the provided protocol identifier, or other provided identifiers) to determine devices associated with the protocol for which an event was reported by the first protocol device 510. In the depicted flow diagram 560, the HIS server 506 identifies the second protocol device 512 as being associated with the protocol event reported by the first protocol device 510.

[00112] The HIS server 506 then sends a pAPR (e.g., corresponding to the aforementioned protocol) to the protocol gateway 514 (see operation 583). Sending the pAPR to the protocol gateway 514 may include sending a device identifier. For example, the device identifier may indicate a device to which the pAPR or information regarding the pAPR ought to be sent, such as the first protocol device 510. After receiving the pAPR from the HIS server 506, the protocol gateway 514 then sends the pAPR to the first protocol device 510 (e.g., identified by device identifiers sent from the HIS server 506 to the protocol gateway 514) (see operation 584).

[00113] In some implementations, the second protocol device 512 then associates with the patient identifier (see operation 585). For example, the second protocol device 512 may associate with the patient identifier after transmission of the pAPR from the protocol gateway 514. Alternatively, or additionally, the second protocol device 512 may associate with the patient identifier when a clinician enters the patient identifier into the second protocol device 512 or scans a barcode associated with the patient identifier at the second protocol device 512. For example, a clinician may enter a patient identifier into the second protocol device 512 to check whether there any active protocols (e.g., pAPRs) for the patient associated with the patient identifier (e.g., prior to the second protocol device 512 receiving the pAPR). In some implementations, associating with the patient identifier includes sending information from the second protocol device 512 to the protocol gateway 514 (e.g., an indication that the second protocol device 512 is administering a protocol to the patient associated with the patient identifier).

[00114] In some implementations, after receiving the information from the second protocol device 512, the protocol gateway 514 identifies protocols (e.g., active protocols, pending protocols, complete protocols) associated with the patient identifier (see operation 586). Then, in some implementations, the protocol gateway 514 sends one or more of the identified protocols (e.g., pAPRs) to the second protocol device 512 (see operation 587). In this manner, a clinician can use the second protocol device 512 to locate protocols associated with a patient by entering the patient’s identifier into the second protocol device 512 - thus providing alternative or additional means whereby the second protocol device 512 may receive pAPRs associated with a given patient identifier (e.g., as compared with operations 580-584).

[00115] For example, a clinician may want to check for ongoing protocols (e.g., corresponding to ongoing procedures, therapies, and the like) for a given patient prior to beginning a new protocol with the patient. As another example, the clinician may want to check for completed protocols for the patient to determine a detailed treatment history for the patient (e.g., which procedures, therapies, and the like the patient has completed).

[00116] In addition, or in the alternative, the pAPR received by the second protocol device 512 (e.g., via messaging 587) may automatically configure the second protocol device 512 to carry out one or more steps of the protocol.

[00117] FIG. 6 depicts an example process 600 for administering a protocol (e.g., a pAPR), according to various aspects of the subject technology. For explanatory purposes, the various blocks of example process 600 are described herein with reference to FIGS. 1 A-5C, as well as the components and/or processes described herein. The one or more of the blocks of process 600 may be implemented, for example, by one or more computing devices (e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2, or infusion device 310 of FIG. 3).

[00118] In some implementations, one or more of the blocks may be implemented based on one or more machine learning algorithms. In some implementations, one or more of the blocks may be implemented apart from other blocks, and by one or more different processors or devices. Further for explanatory purposes, the blocks of example process 600 are described as occurring in serial, or linearly. However, multiple blocks of example process 600 may occur in parallel. In addition, the blocks of example process 600 need not be performed in the order shown and/or one or more of the blocks of example process 600 need not be performed.

[00119] The example process 600 includes receiving (602) a protocol -based automated programming request (pAPR) that includes instructions and a criterion (e.g., a predetermined criterion). For example, the pAPR may be received at an infusion control unit (e.g., control unit 104 of FIGS. 1A-1B, control unit 204 of FIG. 2). [00120] In some implementations, the instructions included in the pAPR instruct the infusion control unit to obtain a medical test result from a first electronic device (e.g., information system server 242 of FIG. 2, EMR server 406 of FIGS. 4A-4B, HIS server 506 of FIGS. 5A-5C). In some implementations, the instructions further instruct the infusion control unit to cause a first therapy device (e.g., infusion pumps 130-133 of FIG. 1, functional modules 206-209 of FIG. 2, first and/or second protocol devices 510/512 of FIG. 5C) to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion

[00121] The process 600 also includes obtaining (604) a medical test result from the first electronic device (e.g., based on the pAPR). In some implementations, the medical test result is not obtainable from the first electronic device. For example, the medical test result may be stored on a server external to a main hospital server (e.g., on an HIS server of another medical care facility). Accordingly, responsive to determining that the medical test result cannot be obtained from the first electronic device, the process 600 may include determining that the medical test result can be obtained from a second electronic device (e.g., on the HIS server of the other medical care facility) (e.g., based on the pAPR). The process 600 may further include obtaining the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device.

[00122] Additionally, the process 600 includes determining (606) whether the medical test result satisfies (e.g., exceeds) the criterion included in the pAPR. For example, the medical test result may include a heart rate, a blood sugar level, a blood pressure level, a weight, or another physiological metric of a patient.

[00123] Responsive to determining (606) that the medical test result satisfies the criterion, the process 600 includes selecting a primary operation. Moreover, responsive to determining (606) that the medical test result does not satisfy the criterion, the process 600 includes selecting a secondary operation. After selecting the primary or secondary operation, the process 600 includes performing (612) the selected operation (e.g., based on the pAPR).

[00124] For example, the first therapy device may include a first infusion pump. Accordingly, the primary operation may include activating the first infusion pump to administer a primary amount of a primary intravenous (IV) fluid. In some implementations, the secondary operation involves administering a different amount of the primary IV fluid, such that the secondary operation includes activating the first infusion pump to administer a secondary amount of the primary IV fluid. In some implementations, the secondary operation involves administering a different IV fluid, such that the secondary operation includes activating an infusion pump (e.g., the first infusion pump, a second infusion pump) to administer to administer an amount (e.g., the primary amount, the secondary amount) of a secondary IV fluid.

[00125] In some implementations, the amount or type of the IV fluid administered is selected or determined based on the medical test result. For example, the medical test result may indicate that the patient should receive an amount of the primary IV fluid (e.g., an analgesic) less than the primary amount (e.g., based on the patient’s weight, blood pressure, etc.). As another example, the medical test result may indicate that the patient should not receive the primary IV fluid and should instead receive the secondary IV fluid (e.g., based on an allergy of the patient to the primary IV fluid).

[00126] In some implementations, the pAPR may require completion of an action prior to advancing the protocol. For example, the pAPR may require that the patient take a ten minute walk in between a first and second infusion therapy. Accordingly, the process 600 may include displaying a prompt inquiring whether the action (e.g., the ten minute walk) has been completed. The medical test result may include the response received to the prompt. If the response indicates that the patient has walked for ten minutes, then the primary operation (e.g., activating an infusion device to administer the second infusion therapy) will be selected. Alternatively, if the response indicates that the patient has not yet walked for ten minutes, then the second operation (e.g., displaying a reminder of to walk the patient for ten minutes) will be selected. The second operation may include continuing to display the reminder until the infusion control unit receives an indication of completion of the action. Thereafter, the process 600 may include performing the primary operation. In this manner, the secondary operation can act as an intermediary operation, performed prior to the primary operation in certain circumstances.

[00127] In some implementations, the process 600 includes providing a list of workflow protocols for display on a display device (e.g., display 114 of FIG. IB, user interface device 230 of FIG. 2, a smartphone or tablet computer) associated with the infusion control unit. The process 600 may further include receiving a patient identifier and a selected workflow protocol from the list. Additionally, the process 600 may include identifying, based on the received patient identifier, the first therapy device and one or more second therapy devices. Moreover, in some implementations, the process 600 includes sending the pAPR to the first therapy device and the one or more second therapy devices responsive to identifying the first therapy device and the one or more second therapy devices based on the received patient identifier, wherein the pAPR provides the selected workflow protocol to the first therapy device and the one or more second therapy devices.

[00128] Similarly, in some implementations, the process 600 includes providing a list of patients (e.g., screen 810 of FIG. 8) for display on a display device associated with the infusion control unit. The process 600 may also include receiving a selected patient from the list. Additionally, the process can include determining that the pAPR is associated with the selected patient. Further, the process 600 may include activating, before the pAPR is received, a first graphically displayed control for display of a current status of the pAPR for the patient.

[00129] In some implementations, the process 600 includes receive two or more selected patients from the aforementioned list of patients. Further, the process 600 may include providing, for each respective patient of the two or more selected patients, a second graphically displayed control for activating the pAPR for the respective patient, wherein selection of the second graphically displayed control initiates a display of a protocol definition interface for configuring one or more parameters of the pAPR including setting the criterion for the therapy.

[00130] In addition to the operations performed at the infusion control unit, the process 600 may also include performing operations at a server (e.g., information system server 242 of FIG. 2, EMR system 302 of FIG. 3, EMR server 406 of FIGS. 4A-4B, or HIS server 506 of FIGS. 5A-5C). For example, the process 600 may include identifying a second therapy device (e.g., infusion pumps 130-133 of FIG. 1, functional modules 206-209 of FIG. 2, first and/or second protocol devices 510/512 of FIG. 5C) being newly associated with a patient identifier. The process 600 may also include determining, responsive to the identification, that the pAPR is active and in a current state on the first therapy device for the patient identifier. Further, the process 600 may include sending, responsive to the determination, the pAPR and an indication of the current state to the second therapy device. Moreover, the process 600 may include causing the second therapy device to perform a tertiary operation associated with the therapy and the current state. In some implementations, the second therapy device is configured to display an indication of the pAPR and the current state after receiving the pAPR, as depicted in screen 702 of FIG. 7. [00131] The above-described example process 600, as well as related features and applications, may also be implemented as software processes that are specified as a set of specific instructions recorded on a computer readable storage medium (also referred to as computer readable medium), and may be executed automatically (e.g., without user intervention). When these specific instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[00132] The term “software” is meant to include, where appropriate, firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some implementations, multiple software aspects of the subject disclosure can be implemented as sub-parts of a larger program while remaining distinct software aspects of the subject disclosure. In some implementations, multiple software aspects can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software aspect described here is within the scope of the subject disclosure. In some implementations, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.

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

[00134] FIG. 7 depicts an example control unit (e.g., control unit 104 of FIGS. 1A-1B, control unit 204 of FIG. 2) and example screens 702, 704, 706, and 708 displayed thereon for administering a protocol (e.g., a pAPR), according to various aspects of the subject technology. As discussed above with respect to FIGS. 5A-5C, in some implementations, a clinician can use a control unit to access protocols (e.g., pending pAPRs) for a given user.

[00135] In screen 702, the clinician is prompted to enter a patient identifier. In some implementations, the clinician can enter the patient identifier manually (e.g., using buttons or touch inputs). In some implementations, the clinician can enter the patient identifier by scanning a barcode associated with the patient identifier. As described previously with regard to FIGS. 5A-5C, the server may determine that a medical protocol is associated with the patient and/or medical device. In screen 704, the device indicates that the medical protocol (e.g., a pAPR) is pending. For example, medical the protocol may be pending for a patient identifier entered at screen 702. In this manner, the device can warn the clinician of pending or ongoing protocols for a patient prior to the clinician beginning a new protocol for the patient.

[00136] In screen 706, steps of the protocol are displayed, with the protocol including multiple infusions and a test (e.g., a biometric test). In some implementations, the screen 706 also includes progress information regarding the steps. For example, the screen 706 can indicate which of the steps are completed, which are ongoing (e.g., 50% complete, 75% complete), and which are yet to begin. For steps that are not started and are administrable by the device presenting the interface, a control element such as a softkey or graphical user interface icon may be activated. When the control element is interacted with, the device may use pAPR information to configure one or more parameters for administration of the selected step.

[00137] In screen 708, detailed information regarding one of the steps is displayed (e.g., an infusion), with information regarding a volume to be infused (VTBI) and the corresponding flow rate. For example, the screen 708 may regard one of the multiple infusion steps displayed in screen 706. If the step was previously initiated, the screen 708 may provide a status of the step. If the step was not under execution by another device, the screen 708 may allow for review of automatic configuration parameters to be executed by the device.

[00138] FIG. 8 is a flow diagram illustrating example screens 810 and 812 presented to a clinician (e.g., via a control unit or an EMR terminal) regarding patients and corresponding protocols, according to various aspects of the subject technology. As illustrated, in some implementations, after a clinician logs into a system (e.g., via device terminal 240 of FIG. 2, EMR terminal 404 of FIGS. 4A-B, or HIS terminal 504 of FIGS. 5A-5B) at step 802, the system shows a list of patients (e.g., patients to which the clinician is assigned) in step 804. For example, the system may present a first screen 810 to the clinician (e.g., via a tablet computer or a smartphone) that includes the names of the patients in a list (e.g., ordered by priority).

[00139] Furthermore, the system can also present a second screen 812 that introduces additional information regarding the patients. For example, the information may indicate whether a patient has an ongoing protocol, whether the protocol requires immediate or urgent attention, whether the protocol is complete or nearing completion, and so on. This information is suggested in the second screen 812 by the check mark (e.g., indicating completion) and the exclamation point (e.g., indicating urgency). The second screen 812 also includes addition signs for each of the patients, suggesting that the clinician can add a new protocol or add a new step to an ongoing protocol for the respective patient.

[00140] Presentation of the second screen 812 may occur, for example, after the device at which the screen is displayed receives one or more protocols (e.g., pAPRs) for the respective patients. This is indicated by step 806, which relates to receiving the protocols. Additionally, step 808 describes adjusting the screen content to include the indicators regarding the received protocols - thus switching from displaying the first screen 810 to displaying the second screen 812.

[00141] FIG. 9 is a conceptual diagram illustrating an example electronic system 900 for automatically programming one or more medical devices to operate according to a given medical protocol, according to various aspects of the subject technology. Electronic system 900 may be a computing device for execution of software associated with one or more portions or steps of the processes outlined in FIGS. 4A-6. Additionally, electronic system 900 may be a computing device including components provided by FIGS. 1 A-8, including but not limited to computing hardware within patient care device 102, patient care device 202, device terminal 240, infusion device(s) 402, infusion device(s) 502, protocol device 1, protocol device 2, EMR terminal 404, EMR server 406, connectivity gateway 408, HIS terminal 504, HIS server 506, connectivity gateway 508, protocol gateway 514, and/or any computing devices or associated terminals disclosed herein.

[00142] In this regard, electronic system 900 may be a specifically configured personal computer or a mobile device 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 similar computer-related electronic device having network connectivity.

[00143] The electronic system 900 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 900 includes a bus 908, one or more processing unit(s) 912, a system memory 904, a read-only memory (ROM) 910, a permanent storage device 902, an input device interface 914, an output device interface 906, and one or more network interfaces 916. In some implementations, the electronic system 900 may include or be integrated with other computing devices or circuitry specifically configured for operation of the various components and methods previously described.

[00144] The bus 908 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 900. For instance, bus 908 communicatively connects processing unit(s) 912 with the ROM 910, the system memory 904, and the permanent storage device 902.

[00145] From these various memory units, the processing unit(s) 912 retrieves instructions to execute and data to process, in order to execute the processes of the subject disclosure. The processing unit(s) 912 can be a single processor or a multi-core processor in different implementations.

[00146] The ROM 910 stores static data and instructions that are needed by processing unit(s) 912 and other modules of the electronic system. Permanent storage device 902, 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 electronic system 900 is 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 permanent storage device 902.

[00147] Other implementations use a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) as permanent storage device 902. Like permanent storage device 902, system memory 904 is a read-and-write memory device. However, unlike storage device 902, system memory 904 is a volatile read-and-write memory (e.g., randomaccess memory). System memory 904 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 system memory 904, permanent storage device 902, and/or ROM 910. From these various memory units, the processing unit(s) 912 retrieves instructions to execute and data to process in order to execute the processes of some implementations.

[00148] The bus 908 connects to input and output device interfaces 914 and 906. Input device interface 914 enables the user to communicate information and select commands to the electronic system 900. Input devices used with input device interface 914 include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”). Output device interfaces 906 enables, for example, display of images generated by the electronic system 900. Output devices used with output device interface 906 include, for example, printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices such as a touchscreen that functions as both input and output devices.

[00149] Also, as shown in FIG. 9, the bus 908 also couples the electronic system 900 to a network through the network interfaces 916. The network interfaces 916 may include, for example, a wireless access point (e.g., a Bluetooth or WiFi access point) or radio circuitry for connecting to a wireless access point. The network interfaces 916 may also include hardware (e.g., Ethernet hardware or a network interface module) for connecting the computer to a part of a network of computers such as a local area network (“LAN”), a wide area network (“WAN”), wireless LAN, or an Intranet, or a network of networks, such as the Internet. Any or all components of the electronic system 900 can be specially configured to be used in conjunction with the subject disclosure.

[00150] These 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.

[00151] 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 files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

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

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

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

[00155] 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 client computer 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).

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

[00157] 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. [00158] 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.

[00159] Illustration of Subject Technology as Clauses:

[00160] Various examples of aspects of the disclosure are described as numbered clauses (1, 2, 3, etc.) 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.

[00161] Clause 1. An infusion system, comprising: a first therapy device; and an infusion control unit configured to: receive a protocol-based automated programming request (pAPR) that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause the first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtain the medical test result from the first electronic device based at least in part on the pAPR; select the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and perform the selected operation based at least in part on the pAPR.

[00162] Clause 2. The infusion system of clause 1, wherein the infusion control unit is further configured to: determine that the medical test result cannot be obtained from the first electronic device; determine that the medical test result can be obtained from a second electronic device different from the first electronic device based at least in part on the pAPR; and obtain the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device.

[00163] Clause 3. The infusion system of any one of clauses 1 or 2, wherein the first therapy device and the pAPR are associated with a patient identifier, and the infusion system further comprises a second therapy device and a server configured to: identify the second therapy device being newly associated with the patient identifier; determine, responsive to the identification, that the pAPR is active and in a current state on the first therapy device for the patient identifier; and send, responsive to the determination, the pAPR and an indicator of the current state to the second therapy device; and cause the second therapy device to perform a tertiary operation associated with the therapy and the current state.

[00164] Clause 4. The infusion system of clause 3, further comprising the second therapy device, wherein the second therapy device is configured to display an indication of the pAPR and the current state after receiving the pAPR.

[00165] Clause 5. The infusion system of any one of clauses 1 through 4, wherein the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary intravenous (IV) fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.

[00166] Clause 6. The infusion system of any one of clauses 1 through 5, further comprising a second infusion pump wherein the secondary operation comprises activating the second infusion pump to provide a secondary IV fluid different from the primary IV fluid..

[00167] Clause 7. The infusion system of any one of clauses 5 or 6, wherein the secondary amount or the secondary IV fluid is selected based on the medical test result obtained from the first electronic device.

[00168] Clause 8. The infusion system of any one of clauses 1 through 7, further comprising a display device, wherein performing the secondary operation comprises displaying a notice requiring completion of an action, receiving an indication that the action was completed, and performing the primary operation responsive to receiving the indication.

[00169] Clause 9. The infusion system of any one of clauses 1 through 8, wherein the infusion control unit is further configured to: provide a list of workflow protocols for display on a display device associated with the infusion control unit; receive a patient identifier and a selected workflow protocol from the list; identify, based on the received patient identifier, the first therapy device and one or more second therapy devices; and send the pAPR to the first therapy device and the one or more second therapy devices responsive to identifying the first therapy device and the one or more second therapy devices based on the received patient identifier, wherein the pAPR provides the selected workflow protocol to the first therapy device and the one or more second therapy devices.

[00170] Clause 10. The infusion system of clause 1, wherein the infusion control unit is further configured to: provide a list of patients for display on a display device associated with the infusion control unit; receive a selected patient from the list; determine that the pAPR is associated with the selected patient; and activate, before the pAPR is received, a first graphically displayed control for display of a current status of the pAPR for the patient.

[00171] Clause 11. The infusion system of clause 10, wherein the infusion control unit is further configured to: receive two or more selected patients from the list; and provide, for each respective patient of the two or more selected patients, a second graphically displayed control for activating the pAPR for the respective patient, wherein selection of the second graphically displayed control initiates a display of a protocol definition interface for configuring one or more parameters of the pAPR including setting the criterion for the therapy.

[00172] Clause 12. A non-transitory, computer-readable medium comprising instructions that, when executed by an infusion control unit, cause the infusion control unit to: receive a pAPR that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtain the medical test result from the first electronic device based at least in part on the pAPR; select the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and perform the selected operation based at least in part on the pAPR.

[00173] Clause 13. The non-transitory, computer-readable medium of clause 12, wherein the instructions further cause the infusion control unit to: determine that the medical test result cannot be obtained from the first electronic device; determine that the medical test result can be obtained from a second electronic device different from the first electronic device based at least in part on the pAPR; and obtain the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device. [00174] Clause 14. The non-transitory, computer-readable medium of any one of clauses 12 or 13, wherein the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary IV fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.

[00175] Clause 15. The non-transitory, computer-readable medium of any one of clauses 12 through 14, wherein the secondary operation comprises activating a second infusion pump to provide a secondary IV fluid different from the primary IV fluid.

[00176] Clause 16. The non-transitory, computer-readable medium of any one of clauses 14 or 15, wherein the secondary amount or the secondary IV fluid is selected based on the medical test result obtained from the first electronic device.

[00177] Clause 17. The non-transitory, computer-readable medium of any one of clauses 12 through 17, further comprising a display device, wherein performing the secondary operation comprises displaying a notice requiring completion of an action, receiving an indication that the action was completed, and performing the primary operation responsive to receiving the indication.

[00178] Clause 18. A computer-implemented method for handling a pAPR, comprising: receiving, at an infusion control unit, a pAPR that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtaining, at the infusion control unit, the medical test result from the first electronic device based at least in part on the pAPR; selecting, at the infusion control unit, the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and performing, at the infusion control unit, the selected operation based at least in part on the pAPR.

[00179] Clause 19. The computer-implemented method of clause 18, further comprising: determining, at the infusion control unit, that the medical test result cannot be obtained from the first electronic device; determining, at the infusion control unit, that the medical test result can be obtained from a second electronic device different from the first electronic device based at least in part on the pAPR; and obtaining, at the infusion control unit, the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device.

[00180] Clause 20. The computer-implemented method of any one of clauses 18 or 19, wherein the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary IV fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.

[00181] Further Consideration:

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

[00183] 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 subj ect technology, and the subj ect 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.

[00184] Thus, the claims are not intended to be limited to the aspects shown herein but are to be accorded the full scope consistent with the language of the claims. For example, 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.” Moreover, 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.

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

[00186] 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 herein to 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.

[00187] 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 an “implementation” may refer to one or more implementations 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.

[00188] 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 or other control elements for receiving input signals or providing electronic information 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.

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

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

[00191] 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 mode, 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.

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

[00193] 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, information and/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, fu5y logic, pattern matching, a machine learning assessment model, or combinations thereof.

[00194] In some implementations, 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 system, comprising: a first therapy device; and an infusion control unit configured to: receive a protocol-based automated programming request (pAPR) that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause the first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtain the medical test result from the first electronic device based at least in part on the pAPR; select the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and perform the selected operation based at least in part on the pAPR.

2. The infusion system of claim 1, wherein the infusion control unit is further configured to: determine that the medical test result cannot be obtained from the first electronic device; determine that the medical test result can be obtained from a second electronic device different from the first electronic device based at least in part on the pAPR; and obtain the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device.

3. The infusion system of claim 1, wherein the first therapy device and the pAPR are associated with a patient identifier, and the infusion system further comprises a second therapy device and a server configured to: identify the second therapy device being newly associated with the patient identifier; determine, responsive to the identification, that the pAPR is active and in a current state on the first therapy device for the patient identifier; and send, responsive to the determination, the pAPR and an indicator of the current state to the second therapy device; and cause the second therapy device to perform a tertiary operation associated with the therapy and the current state.

4. The infusion system of claim 3, further comprising the second therapy device, wherein the second therapy device is configured to display an indication of the pAPR and the current state after receiving the pAPR.

5. The infusion system of claim 1, wherein the first therapy device comprises a first infusion pump and the primary operation comprises activating the first infusion pump to administer a primary amount of a primary intravenous (IV) fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.

6. The infusion system of claim 1, further comprising a second infusion pump wherein the secondary operation comprises activating the second infusion pump to provide a secondary IV fluid different from the primary IV fluid.

7. The infusion system of any one of claims 5 or 6, wherein the secondary amount or the secondary IV fluid is selected based on the medical test result obtained from the first electronic device.

8. The infusion system of claim 1, further comprising a display device, wherein performing the secondary operation comprises displaying a notice requiring completion of an action, receiving an indication that the action was completed, and performing the primary operation responsive to receiving the indication.

9. The infusion system of claim 1, wherein the infusion control unit is further configured to: provide a list of workflow protocols for display on a display device associated with the infusion control unit; receive a patient identifier and a selected workflow protocol from the list; identify, based on the received patient identifier, the first therapy device and one or more second therapy devices; and send the pAPR to the first therapy device and the one or more second therapy devices responsive to identifying the first therapy device and the one or more second therapy devices based on the received patient identifier, wherein the pAPR provides the selected workflow protocol to the first therapy device and the one or more second therapy devices.

10. The infusion system of claim 1, wherein the infusion control unit is further configured to: provide a list of patients for display on a display device associated with the infusion control unit; receive a selected patient from the list; determine that the pAPR is associated with the selected patient; and activate, before the pAPR is received, a first graphically displayed control for display of a current status of the pAPR for the patient.

11. The infusion system of claim 10, wherein the infusion control unit is further configured to: receive two or more selected patients from the list; and provide, for each respective patient of the two or more selected patients, a second graphically displayed control for activating the pAPR for the respective patient, wherein selection of the second graphically displayed control initiates a display of a protocol definition interface for configuring one or more parameters of the pAPR including setting the criterion for the therapy.

12. A non-transitory, computer-readable medium comprising instructions that, when executed by an infusion control unit, cause the infusion control unit to: receive a pAPR that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtain the medical test result from the first electronic device based at least in part on the pAPR; select the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and perform the selected operation based at least in part on the pAPR.

13. The non-transitory, computer-readable medium of claim 12, wherein the instructions further cause the infusion control unit to: determine that the medical test result cannot be obtained from the first electronic device; determine that the medical test result can be obtained from a second electronic device different from the first electronic device based at least in part on the pAPR; and obtain the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device.

14. The non-transitory, computer-readable medium of claim 12, wherein the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary IV fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.

15. The non-transitory, computer-readable medium of claim 1, further comprising a second infusion pump wherein the secondary operation comprises activating the second infusion pump to provide a secondary IV fluid different from the primary IV fluid.

16. The non-transitory, computer-readable medium of any one of claims 14 or 15, wherein the secondary amount or the secondary IV fluid is selected based on the medical test result obtained from the first electronic device.

17. The non-transitory, computer-readable medium of claim 1, further comprising a display device, wherein performing the secondary operation comprises displaying a notice requiring completion of an action, receiving an indication that the action was completed, and performing the primary operation responsive to receiving the indication.

18. A computer-implemented method for handling a pAPR, comprising: receiving, at an infusion control unit, a pAPR that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtaining, at the infusion control unit, the medical test result from the first electronic device based at least in part on the pAPR; selecting, at the infusion control unit, the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and performing, at the infusion control unit, the selected operation based at least in part on the pAPR.

19. The computer-implemented method of claim 18, further comprising: determining, at the infusion control unit, that the medical test result cannot be obtained from the first electronic device; determining, at the infusion control unit, that the medical test result can be obtained from a second electronic device different from the first electronic device based at least in part on the pAPR; and obtaining, at the infusion control unit, the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device.

20. The computer-implemented method of claim 18, wherein the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary IV fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.