Devices, systems, and methods for verifying automatic programming requests

Abstract

An infusion device includes a fluid pump and a processor. The processor is configured to receive an automatic programming request (APR) from a device manager, wherein the APR includes an indicated medical advice type. The processor is further configured to determine an implicit doctor's advice type for the APR based in part on whether the fluid pump is active. Further, the processor is configured to determine whether the indicated order type is compatible with an implicit order type. If it is indicated that the doctor's advice type is compatible with the implicit doctor's advice type, the processor sends an acknowledgement message to the device manager and programs the fluid pump according to the operating parameters. However, if it is indicated that the order type is not compatible with the implicit order type, the processor sends a non-acknowledgement message and an error message to the device manager and denies commands to automatically program the fluid pump according to the operating parameters.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 417,662, filed on October 19, 2022, the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to the automatic programming of infusion devices, and more particularly, to the verification of automatic programming requests for infusion devices. Background Art

[0004] In the modern healthcare field, the precise and controllable management of drugs and fluids is crucial for patient health and recovery. Infusion pumps play a key role in this regard, providing a reliable method for intravenous infusions. The integration of automated programming has further advanced infusion technology by improving treatment accuracy and streamlining healthcare procedures.

[0005] Despite the many benefits of automated programming, the increased reliance on it has made a rigorous verification process necessary to ensure patient safety and regulatory compliance. Current verification methods are typically manual, time - consuming, and prone to human error. There is a need for computer - driven verification systems to improve the accuracy and reliability of automated programming. Summary of the Invention

[0006] The present disclosure provides devices, systems, and methods that solve some of the foregoing problems and other problems associated with the automatic programming of infusion devices. These devices, systems, and methods rely on computer - driven APR verification of infusion devices, including various "quick - fail" methods, which will be discussed in more detail below. Example embodiments of the advancements discussed herein include:

[0007] An infusion device includes a fluid pump and a processor. The processor is configured to receive an APR from a device manager. The APR includes (i) an indication of an order type, (ii) an identifier of the fluid pump, (iii) operating parameters including a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters. The processor is also configured to detect an active state of the fluid pump indicating whether the fluid pump is active. Additionally, the processor is configured to determine an implied order type of the APR based in part on the detected active state. The implied order type includes an initial order, a subsequent order, a modified order, a bolus order, or a secondary order. Further, the processor is configured to determine whether the indicated order type is compatible with the implied order type and the fluid pump based in part on whether the indicated order type matches the implied order type. Additionally, the processor is configured to, in response to determining that the indicated order type is compatible with the implied order type and the fluid pump, (i) send a confirmation message to the device manager and (ii) program the fluid pump according to the operating parameters. Additionally, the processor is configured to, in response to determining that the indicated order type is not compatible with the implied order type or the fluid pump, (i) send an error message to the device manager and (ii) reject the command to automatically program the fluid pump according to the operating parameters.

[0008] A computer-implemented method for validating an APR includes receiving an APR from a device manager. The APR includes (i) an indication of an order type, (ii) an identifier of a fluid pump of an infusion device, (iii) operating parameters including a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters. The method also includes detecting an active state of the fluid pump indicating whether the fluid pump is active. Additionally, the method includes determining an implied order type of the APR based in part on the detected active state. The implied order type includes an initial order, a subsequent order, a modified order, a bolus order, or a secondary order. Further, the method includes determining whether the indicated order type is compatible with the implied order type and the fluid pump based in part on whether the indicated order type matches the implied order type. Additionally, the method includes, in response to determining that the indicated order type is compatible with the implied order type and the fluid pump, (i) sending a confirmation message to the device manager and (ii) programming the fluid pump according to the operating parameters. Additionally, the method includes, in response to determining that the indicated order type is not compatible with the implied order type or the fluid pump, (i) sending an error message to the device manager and (ii) rejecting the command to automatically program the fluid pump according to the operating parameters.

[0009] A non - transitory computer - readable storage medium including instructions that, when executed by an electronic device, cause the electronic device to receive an APR from a device manager. The APR includes (i) an indication of an order type, (ii) an identifier of a fluid pump of an infusion device, (iii) operating parameters including a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters. The instructions also cause the electronic device to detect an active state of the fluid pump, indicating whether the fluid pump is active. In addition, the instructions cause the electronic device to determine an implied order type of the APR based in part on the detected active state. The implied order type includes an initial order, a subsequent order, a modified order, a bolus order, or a secondary order. In addition, the instructions cause the electronic device to determine whether the indicated order type is compatible with the implied order type and the fluid pump based in part on whether the indicated order type matches the implied order type. In addition, in response to determining that the indicated order type is compatible with the implied order type and the fluid pump, the instructions cause the electronic device (i) to send a confirmation message to the device manager and (ii) to program the fluid pump according to the operating parameters. In addition, in response to determining that the indicated order type is not compatible with the implied order type or the fluid pump, the instructions cause the electronic device (i) to send an error message to the device manager and (ii) to reject the command to automatically program the fluid pump according to the operating parameters.

[0010] It should be understood that, through the following detailed description, other configurations of the subject technology will become apparent to those skilled in the art, in which various configurations of the subject technology are shown and described by way of illustration. As will be recognized, the subject technology is capable of having other configurations and different configurations, and several details thereof can be modified in various other aspects, all without departing from the scope of the subject technology. Therefore, the drawings and the detailed description are to be regarded as illustrative in nature and not restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] To better understand the various described embodiments, the following detailed description should be referred to in conjunction with the following drawings. Throughout the drawings and the description, the same reference numerals refer to corresponding parts.

[0012] Figure 1A and Figure 1B Depicts an example patient care system including an infusion pump installed to a control unit according to various aspects of the subject technology.

[0013] Figure 2 Depicts an example institutional patient care system of a healthcare institution according to various aspects of the subject technology.

[0014] Figure 3 Depicts an example system for automatically programming a medical device according to various aspects of the subject technology.

[0015] Figure 4 An example sequence diagram for automatically verifying an automatic programming request (APR) in accordance with various aspects of the subject technology is shown.

[0016] Figure 5A Depicted are example processes for validating an APR in accordance with various aspects of the subject technology. In addition, Figure 5B and Figure 5C Depicted are example processes for determining an implied order type for an APR and an active infusion type for a fluid pump, respectively, in accordance with various aspects of the subject technology.

[0017] Figure 6 is a conceptual diagram illustrating an example electronic system for validating an APR in accordance with various aspects of the subject technology. DETAILED DESCRIPTION

[0018] Reference will now be made to embodiments, 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 embodiments described. However, it will be apparent to one of ordinary skill in the art that the various described embodiments may be practiced without these specific details. In other cases, well-known methods, procedures, components, circuits, and networks are not described in detail in order to avoid unnecessarily obscuring various aspects of the embodiments.

[0019] The following figure shows some of the aforementioned devices, systems and methods, which can be used to supplement or replace the manual verification process of automatic programming requests (APRs). These devices, systems and methods rely on computer-driven verification, which may be more accurate and efficient than human-driven verification. The APR verification described herein combines various fast-fail methods to further improve its efficiency. Therefore, the teachings of the present disclosure may improve healthcare environments that rely on automatic programming of infusion devices.

[0020] Many of the fast-fail validation methods discussed herein involve a comparison between an APR's indicated order type and an implied order type. As used herein, an "indicated order type" refers to an order type that is explicitly indicated in an APR. For example, when requesting an APR, a user can indicate a request for a particular type of order. The APR can indicate, for example, whether it is intended to correspond to an initial order (e.g., a new order for an inactive fluid pump), a subsequent order (e.g., an order following an ongoing infusion), a modified order (e.g., a modification to an ongoing infusion), a bolus order (e.g., a temporary increase in the flow rate of an ongoing infusion), or a secondary order (e.g., an order in parallel with an ongoing infusion).

[0021] In contrast, an "implied order type" is an order type suggested by the operating parameters of the APR and other contextual cues determined by the infusion device receiving the APR (e.g., whether the target fluid pump is active and what type of infusion therapy it is implementing). For example, if the APR designates a channel of the infusion device (e.g., a fluid pump), and that channel is not currently active, the infusion device may determine that the implied order type is an initial order because there is no active infusion currently. This determination can be independent of whether the APR explicitly indicates another order type, such as a bolus order or a secondary order.

[0022] As described above, in some embodiments, the APR is partially verified by determining whether the indication of the APR and the implied order type are compatible with each other. For example, if the APR indicates that it is for an initial order, and the operating parameters and other contextual cues imply that the APR corresponds to an initial order, then the APR may be verified because the two order types match. However, if the indication and the implied order type are different, the infusion device may need to determine whether the indication and the implied order type are compatible and / or whether the APR can still be implemented on the infusion device. This compatibility determination may be based on, for example, whether the target fluid pump is active and, if so, what type of infusion it is performing. Potential infusion types include continuous infusion (e.g., delivering a certain amount of drug over a period of time), intermittent infusion (e.g., delivering a certain amount of drug), fluid infusion (e.g., delivering a certain volume of fluid, such as saline), and drug infusion (e.g., delivering a certain volume of drug, such as anesthetic).

[0023] Figure 1A and Figure 1B depicts an example patient care system 100 including infusion pumps 130 - 133 ( Figure 1B 131 - 132 of which) mounted to a control unit 104 in accordance with various aspects of the present subject matter technology. Figure 1A The illustrated patient care system 100 includes four infusion pumps 130 - 133, each infusion pump operatively engaged with a corresponding administration device 120 - 123 (e.g., a silicone tube). The administration devices 120 - 123 connect the infusion pumps 130 - 133 to fluid supply devices 110 - 113, which are inverted and suspended above the infusion pumps 130 - 133. The fluid supply devices 110 - 113 are Figure 1A depicted as bottles in the figure, but they may also take other forms (e.g., bags). The fluid supply devices 110 - 113 and the patient care device 102 are both mounted on a roller stand 108.

[0024] The fluid supply devices 110 - 113 and their orientation within the care area (e.g., installation location, installation height, installation type) can generate one or more interaction records. For example, an interaction record for a device can be generated in part by detecting a scannable code associated with the device or by detecting a physical structure on the device that encodes identification information for the device prior to use.

[0025] As Figure 1A shown, each administration device 120 - 123 is connected between a corresponding fluid supply device 110 - 113 and a patient 106 so that the patient 106 can receive fluid from any or all of the fluid supply devices 110 - 113. Each of the administration devices 120 - 123 can be identified either actively (e.g., by a clinician scanning) or passively (e.g., by wireless or optical detection). Generally, medical administration devices have more components than Figure 1A shown. Many have check valves, drip chambers, valved ports, connectors, and other devices well known to those skilled in the art. For the sake of clarity of illustration, these other devices are not included in the figures.

[0026] In the depicted example, separate infusion pumps 130 - 133 are used to infuse each fluid from the fluid supplies 110 - 113 into the patient 106. The infusion pumps 130 - 133 are flow control devices that will act on the corresponding tubing or fluid conduits of the corresponding administration devices 120 - 123 to transfer fluid from the fluid supply devices 110 - 113 through the conduits to the patient. Because separate infusion pumps 130 - 133 are used, each of the infusion pumps 130 - 133 can be individually set to the pumping or operating parameters required to infuse a specific medical fluid from the corresponding fluid supply device 110 - 113 into the patient at a specific rate prescribed by a clinician for that fluid.

[0027] Figure 1B Depicted is Figure 1A a portion of the patient care device 102 shown in. The patient care device 102 shown includes a control unit 104 and two infusion pumps 131 and 132 mounted on either side of the control unit 104. In some embodiments, the control unit 104 is configured to program each of the infusion pumps 130 - 133 (see Figure 1A ). Figure 1B Also shown are the displays and controls of the infusion pumps 131 and 132, such as the display 124 and controls 126 of the infusion pump 132.

[0028] Each infusion pump 130 - 133 may include a door and a handle. For example, infusion pump 132 includes door 128 and handle 134. Handle 134 operates to lock door 128 in the closed position during operation. Handle 134 also operates to unlock and open the door for loading a drug delivery device (e.g., drug delivery device 122) and for accessing the internal pumping and sensing mechanisms of infusion pump 132. When door 128 is open, drug delivery device 122 may be connected to infusion pump 132. When door 128 is closed, drug delivery device 122 is operatively engaged with the pumping mechanism, upstream and downstream pressure sensors, and / or other devices of infusion pump 132.

[0029] Infusion pumps 130 - 133 may also include a display. For example, in the depicted embodiment, the display 124 (e.g., an LED display) of infusion pump 132 is located in a planar view on door 128 and may be used to visually convey information about infusion pump 32. For example, display 124 may convey an alert indication (e.g., an alert message). Additionally, control keys 126 allow programming and controlling the operation of the infusion pump as needed. In some embodiments, the control keys may be presented as interactive elements on display 124 (e.g., a touchscreen display). Patient care device 102 and / or infusion pump 132 may also include an audio alert device in the form of a speaker.

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

[0031] In addition to display 114 and control keys 116A - C, control unit 104 may also include a speaker to provide audible alerts. In some embodiments, display 114 is implemented as a touchscreen display. In such embodiments, the number of control keys 116A - C may be omitted or reduced by providing corresponding interactive elements via a graphical user interface presented via display 114. In some embodiments, control keys 116A - C may select corresponding options displayed in display 114.

[0032] Control unit 104 may also include a communication system through which control unit 104 may communicate with external devices, such as a medical facility server, a handheld communication device, a laptop computer, or other information devices from which a clinician may have to transmit information to control unit 104 or download a drug library.

[0033] The communication module can be used to transmit access or interaction information to a clinician who encounters the control unit 104 or a device coupled thereto (e.g., infusion pumps 130 - 133 or barcode scanners). The communication system can include one or more of a radio frequency (RF) system, an optical system such as infrared, a BLUETOOTH TM system, or other wired or wireless systems. The barcode scanner and the communication system can alternatively be integrated with the infusion pumps 130 - 133, such as without using the control unit, or in addition to being integrated with the control unit 104. Further, the information input device does not need to be hard - wired to the medical device, and the information can also be transmitted via a wireless connection. Additionally, other types of modules can be connected to the infusion pumps 130 - 133 or the control unit 104, such as an injection pump module, a patient - controlled analgesia module, an end - tidal CO2 monitoring module, a pulse oximeter monitoring module, etc.

[0034] Figure 2 An exemplary institutional patient care system 200 of a healthcare institution in accordance with various aspects of the present subject technology is depicted. In Figure 2 , a patient care device 202 (e.g., Figure 1A and Figure 1B the patient care device 102) is connected to an internal healthcare network 236. The term patient care device (“PCD”) can be used interchangeably with the term patient care unit (“PCU”), and either can include various ancillary medical devices, such as infusion pumps (e.g., Figure 1A the infusion pumps 130 - 133), vital sign monitors, medication dispensing devices (e.g., cabinets, suitcases), medication preparation devices, automated dispensing devices, modules coupled to one of the above - mentioned devices (e.g., an injection pump module coupled to an infusion pump), etc. Each element of the patient care device 202 is connected to the internal healthcare network 236 via a transmission channel 234. The transmission channel 234 can be a wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN).

[0035] In some embodiments, the internal healthcare network 236 also includes computer systems located in various departments of a hospital or healthcare center. For example, the internal healthcare network 236 optionally includes computer systems associated with an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit - station computers, and / or a medical decision - support system. As further described below, the internal healthcare network 236 can include discrete sub - networks. In the depicted example, the internal healthcare network 236 includes a device network 238 through which the patient care device 202 and other devices can communicate according to normal operation.

[0036] The institutional patient care system 200 may also include a separate information system server 242 (e.g., a health information system server). Additionally, although the information system server 242 is shown as a separate server, the functionality and programming of the information system server 241 may be incorporated into another computer. The institutional patient care system 200 may also include a device terminal 240 for connecting and communicating with the information system server 242. The device terminal 240 may include a personal computer, personal data assistant, or mobile device (e.g., a laptop computer, tablet computer, augmented reality device, or smartphone) configured with software for communicating with the information system server 242 via an internal healthcare network 236.

[0037] The patient care device 202 includes a system for providing patient care, and it may include or incorporate an infusion pump (e.g., Figure 1A the infusion pumps 130 - 133), physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other monitors), treatment devices, and other drug delivery devices that can be used in accordance with the teachings described herein.

[0038] In the depicted example, the patient care device 202 includes a control unit 204 (e.g., Figure 1A and Figure 1B the control unit 104), also referred to as the interface unit 204, connected to one or more functional modules 206 - 209 (e.g., Figure 1A the infusion pumps 130 - 133). The control unit 204 includes a central processing unit (CPU) 218 connected to a memory (e.g., random access memory (RAM) 222), and one or more interface devices, such as a user interface device 230, a coded data input device 232, a network connection 220, and a secondary interface 226 for communicating with additional modules or devices. The control unit 204 also includes a main non - volatile storage unit 228 for storing software data, such as a hard disk drive or non - volatile flash memory, although this is not required. Additionally, the control unit 204 may include one or more internal buses 224 for interconnecting the above - mentioned elements.

[0039] In various embodiments, the user interface device 230 is a touch screen for displaying information to the user and allowing the user to input information by touching a defined area of the screen. Additionally or alternatively, the user interface device 230 may include any device for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen.

[0040] The data input device 232 can be a barcode reader capable of scanning and interpreting data printed in barcode format. Additionally or alternatively, the data input device 232 can be any device for entering encoded data into a computer, such as a device for reading magnetic stripes, a radio frequency identification (RFID) device, whereby digital data encoded in an RFID tag or smart tag (defined below) is captured by the data input device 32 via radio waves, PCMCIA smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog or digital storage medium. Other examples of the data input device 232 include voice activation or recognition devices or portable personal data assistants (PDAs). Depending on the type of interface device used, the user interface device 230 and the data input device 232 can be the same device. Although the data input device 232 is shown in Figure 2 as being disposed within the control unit 204, the data input device 32 can be external to the control unit 204 (e.g., at the device terminal 240).

[0041] The auxiliary interface 226 can be an RS-232 communication interface. However, any other means for communicating with peripheral devices (e.g., printers, patient monitors, infusion pumps, or another medical device) can be used without departing from the subject technology. Additionally, the data input device 232 can 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 appropriate programming and communication protocols.

[0042] The network connection 220 can be a wired connection or a wireless connection, such as via Ethernet, Wi-Fi, Bluetooth, integrated services digital network (ISDN) connection, digital subscriber line (DSL) modem, or cable modem. Any direct or indirect network connection can be used, including but not limited to telephone modems, MIB systems, RS232 interfaces, auxiliary interfaces, optical links, infrared links, radio frequency links, microwave links, or WLAN connections or other wireless connections.

[0043] The functional modules 206-209 are devices for providing care to a patient or for monitoring a patient's condition (e.g., Figure 1A the infusion pumps 130-133). As Figure 2As shown, at least one of the functional modules 206-209 can be an infusion pump module, such as an intravenous infusion pump for delivering medications or other fluids to a patient. For the purposes of this discussion, functional module 206 is the infusion pump module. Each of the functional modules 206-209 can be any patient treatment or monitoring device, including but not limited to infusion pumps, syringe pumps, PCA pumps, epidural pumps, enteral pumps, blood pressure monitors, pulse oximeters, EKG monitors, EEG monitors, heart rate monitors, intracranial pressure monitors, etc. In addition, the functional modules 206-209 can include printers, scanners, barcode readers, near field communication readers, RFID readers, or any other peripheral input, output, or input / output device.

[0044] Each of the functional modules 206-209 communicates directly or indirectly with the control unit 204, providing overall monitoring and control of the patient care device 202. In addition, as Figure 2 shown, the functional modules 206-209 can be physically and electronically connected to one or both ends of the control unit 204 in a serial manner. However, it should be recognized that other means for connecting the functional modules 206-209 to the control unit 204 can be utilized without departing from the subject technology. It should also be understood that devices providing sufficient programmability and connectivity, such as pumps or patient monitoring devices, are capable of operating as stand-alone devices and can 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 peripherals can be connected to the patient care device 202 through one or more auxiliary interfaces 226.

[0045] Each of the functional modules 206-209 can include a microprocessor 216, volatile memory 214, non-volatile memory 212, and module-specific components 210. It should be noted that although Figure 2 four functional modules are shown, any number of devices can be directly or indirectly connected to the control unit 204. The number and type of functional modules described herein are intended to be illustrative and in no way limit the scope of the subject technology. The module-specific components 210 include any components required for the operation of a particular module, such as the pumping mechanism of functional module 206.

[0046] Although each of the functional modules 206-209 is capable of at least some degree of independent operation, the control unit 204 monitors and controls the 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.

[0047] Medical devices incorporating aspects of the present subject matter may be equipped with a Network Interface Module (NIM) that allows the medical device to participate in a network as a node. While, for clarity, the present subject matter will be described as operating in an Ethernet environment using Internet Protocol (IP), it should be understood that the concepts of the present subject matter are equally applicable to other network environments and such environments are intended to be within the scope of the present subject matter.

[0048] In the prior art, data going to and from various data sources can be converted to network-compatible data, and the movement of information between a medical device and a network can be achieved by various means. For example, the patient care device 202 and the internal healthcare network 236 can communicate via automated interaction, manual interaction, or a combination of automated and manual interaction. Automated interaction can be continuous or intermittent and can occur over a network connection 220, as Figure 2 shown, or via an RS232 link, a MIB system, an RF link (such as Bluetooth), an IR link, a WLAN, a digital cable system, a telephone modem, or other wired or wireless communication means.

[0049] Manual interaction between the patient care device 202 and the internal healthcare network 236 involves physically transferring data between the systems intermittently or periodically using, for example, a user interface device 230, a coded data input device 232, a barcode, a computer disk, a personal digital assistant, a memory card, or any other medium for storing data. The means of communication in each aspect is two-way and data can be accessed from as many distributed data source points as possible. Decisions can occur at various places within the internal healthcare network 236. For example, but not limited to, decisions can be made in an information system server 242, a decision support, a remote data server, a hospital department or unit station, or within the patient care device 202 itself.

[0050] According to various embodiments, the information system server 242 includes a formulary and / or a pharmacy information system. The pharmacy information system can implement a more secure doctor drug ordering process. A pharmacy website (e.g., provided by the information system server 242) can provide a list of available drugs to a doctor from which the doctor can select. The pharmacy website may contain a drug library with a list of available drugs, but may also contain and present to the doctor drug names associated with recommended dosages and dosage limits established or adopted by a healthcare facility. In such a case, the doctor only needs to select items from a computer screen rather than manually type in the drug name and administration numbers (such as infusion rate, time, etc.) associated with drug administration, which should result in more accurate drug handling.

[0051] If the clinical order is for the administration of a specific drug regimen, the order will be transmitted to the system server of the pharmacy (e.g., information system server 242). The pharmacy reviews the order, and once the order is ready, it may be transmitted to the nurse station for matching with the appropriate patient. Within the formulary, there may be usage information and / or indications of the concentrations and drug ranges approved for use in the facility. The formulary is a list of approved drugs used within a healthcare facility (e.g., available for patient ordering). As will be further described, the formulary can be used to define one or more medical device drug libraries, which can then be provided to infusion pumps within a hospital network (e.g., internal healthcare network 236).

[0052] In the drug library, there is drug information such as drug name, concentration, diluent volume, strength, minimum or maximum infusion parameters of the drug, and other parameters. Establishing these parameters, as well as the parameters for off-formulary orders, via the system server of the information pharmacy helps maintain consistency across the healthcare environment and ensures that the orders are understandable and executable by other devices (e.g., patient care device 202) within the system server of the pharmacy as intended.

[0053] Further reference Figure 2 to, the patient care device 202 is capable of operating in several different modes or personalities, each personality defined by a configuration database. The configuration database can be a database internal to the patient care device 202 or an external database 244. A specific configuration database is selected at least in part based on patient-specific information such as patient location, age, physical characteristics, or medical characteristics.

[0054] Medical characteristics include but are not limited to patient diagnosis, treatment prescription, medical history, medical record, patient care provider identity, physical characteristics, or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., doctor identity) or the location of the patient care device 202 within a hospital or hospital computer network. Patient care information can be input via any one of the network connection 220, user interface device 230, data input device 232, or auxiliary interface 226. Additionally, patient care information can come from anywhere within the internal healthcare network 236, such as from a pharmacy server, admission server, laboratory, etc.

[0055] The memory of the control unit 204 (e.g., RAM 222 or the main non-volatile storage unit 228) may contain a drug library, an event log, and / or infusion pump configuration settings, such as profile used in a particular practice area (e.g., ICU, PED, etc.). The memory of the control unit 204 may be an electronically loadable memory, such as a non-volatile memory (e.g., EEPROM). The drug library stored on the pump, which illustratively contains information such as drug name, range of delivery parameter values (such as appropriate concentration), dose unit, and dose limit, can be used to perform drug calculation-based infusions in a clinical setting.

[0056] The drug library stored within the pump memory may include clinical order sets, such as limits (also referred to herein as "guardrails") set by a clinical institution for each drug in the library. Such limits may take the form of maximum and minimum doses for each drug, which may depend on patient factors or other factors associated with drug delivery. For example, the dose limit may vary according to the patient's weight or body surface area ("BSA"), according to the unit or ward of the medical institution where the drug is used (e.g., Neonatal Care Unit (NCU), Intensive Care Unit (ICU), etc.) and / or other factors. The limits may also include maximum and minimum flow rates, infusion times, or other infusion parameters for a given drug. Like the dose limit, these limits may also vary according to the patient's weight or other physiological parameters. In some embodiments, the drug library and / or guardrails are stored elsewhere, such as on the device terminal 240, an external database 244, or another device connected to the internal healthcare network 236.

[0057] If a nurse sets the pump to operate outside the limit range for a particular drug, an alarm may be issued. In some cases, the alarm may be overridden, while in other cases it may not be overridden. A healthcare facility may establish "soft" limits for each drug, which can be ignored by the nurse, and "hard" limits, which cannot be ignored by the nurse. In any case of exceeding the limit, a pump data log or other processor communicating with the infusion pump can record each such limit event for subsequent analysis in the case where the attempted setting is above the maximum dose or below the minimum dose.

[0058] The pump may also include a display for presenting a user interface (e.g., Figure 1Ba display 114), the user interface may include a control panel through which the user can program the programmable controller and a display screen for displaying drug entries from the drug library. Each set of associated drug delivery parameters includes information selected from a set of parameters that includes drug concentration, drug delivery rate, drug dose, and bolus size. The electronically loaded drug library contains a list of available mode options that specify the units that can be used to express drug delivery information, and the drug infusion pump provides the user with a list of available mode options from which the user can select when the electronically loaded drug library is in the pump.

[0059] In the case of an infusion pump, the electronically loaded drug library may include a list of the names of syringe manufacturers that identify the syringes that can be used with the drug infusion pump, and the drug infusion pump provides the user with a list of the names of syringe manufacturers from which the user can select when the electronically loaded drug library is in the pump. The loaded drug library may include a list of syringe sizes that identify the syringes that can be used with the drug infusion pump, and the drug infusion pump provides the user with a list of syringe sizes from which the user can select when the electronically loaded drug library is in the pump. In the case of a peristaltic pump, the electronically loaded drug library may include a list of infusion device manufacturers. The loaded drug library may include a set of features, each of which is either turned on or off, and when the electronically loaded drug library is in the pump, the pump only provides the user with the features in the set that are turned on.

[0060] Figure 3 An example system 300 for automatically programming a medical device (e.g., using supplemental APR) in accordance with various aspects of the present subject matter is depicted. Interoperability between a hospital EMR server (e.g., Figure 2 an information system server 242) and a medical device (e.g., Figure 1A patient care device 102 of -B or Figure 2 patient care device 202) enables pre-population of infusion parameters. Pre-population of infusion parameters can reduce the number of programming screens and keystrokes required to manually program the pump. Implementation of interoperability does not preclude clinicians from manually programming the infusion device. Manual programming may be required if any component of the interface system fails.

[0061] Although features may be described with reference to an EMR server, these features apply to the automatic programming of medical devices using similar hospital information systems such as patient data management systems (PDMS). Additionally, although an infusion pump may be used as an example medical device to describe these features, these features apply to the automatic programming of other medical devices associated with barcodes, such as patient monitors, patient association management systems, or alert management systems.

[0062] The medication formulary 304 determines which medications can be dispensed within a hospital network (e.g., Figure 2 the internal healthcare network 236). A hospital committee can be formed to determine how the medications in the formulary will be applied to infusion devices 310 (e.g., Figure 1A and Figure 1B patient care devices 102 or Figure 2 patient care devices 202). Configuration definitions (e.g., by hospital units such as ICU, NICU, pediatrics, oncology, surgery, etc.) are agreed upon and medications and typical infusion protocols are established in a medical device drug library.

[0063] In addition, restrictive or "guardrail" conditions may be defined in the drug library. Once the definitions are complete, the configuration including the drug library can be published. Then, the infusion devices at an institution can be updated by transmitting the configuration database to some or all of the pumps at the institution. Corresponding updates to the medication formulary 304 can be shared with other hospital systems such as a pharmacy ordering system or an EMR system 302, which can use the formulary information to generate patient orders to deliver specific medications to specific patients (320).

[0064] In the clinical area, a clinician can scan medical items such as an infusion bag using a scanner associated with a medical device such as an infusion device 310. For example, a barcode reader (or other data input device) is used to scan a coded medication label, a coded ID band of a patient, and an ID badge of a caregiver, as well as optional supplementary prescription information or medical device configuration instructions (including a configuration database ID) printed on a label or an accompanying order.

[0065] The reader / scanner does not need to be integrated with the medical device. The scanner can be part of a separate device such as an EMR terminal 306 (e.g., Figure 2 device terminal 240), which is connected to the same network as the infusion device 310 (e.g., Figure 2 the device network 238 in

[0066] Scanning initiates a process by which information related to an item (e.g., scanned from a code affixed to or transmitted by the item) is automatically sent via a network (e.g., an internal healthcare network 236) to an EMR system 302 (322). The EMR system 302 can identify the item and generate (324) and send an Automatic Programming Request (APR) to an infusion device 310 to load parameters related to the item. The parameters can be stored in the infusion device 310 but are loaded in response to an identifier received from a server. Although the examples here relate to an infusion device, any medical device can be configured in the same or a similar manner and employ the automatic programming error mitigation described herein.

[0067] In the depicted embodiment, a coordination engine 308 coordinates messages sent from the EMR system 302 to the infusion device 310. In the depicted embodiment, the EMR system 302 transmits the APR along with a device identifier (326) (also referred to as a “device ID”) of the infusion device 310 to the coordination engine 308 to receive the APR. The 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 (328). When the infusion device 310 receives the APR, the infusion device 310 programs itself according to the parameters of the APR (or parameters associated with the APR). The coordination engine 308 can also supplement the APR before sending it to the infusion device 310, as discussed in more detail below with reference to FIG. 5.

[0068] In some embodiments, the APR activates a drug library stored on the infusion device 310 and programs the infusion device 210 according to parameters stored in the drug library for the drug identified in the APR. In some embodiments, after successful programming, the infusion device can automatically self-configure and, in some cases, initiate an operation based on the parameters. In some embodiments, the infusion device 310 can confirm the automatically entered parameters (330). The confirmation can include presenting one or more user interface screens including the parameters and values and control elements (e.g., buttons) that, when activated, cause the infusion device to begin operating based on the parameters. The user interface can include additional or alternative control elements to allow a clinician to adjust the automatically entered parameters based on, for example, professional judgment or changes in the patient's condition.

[0069] Figure 4 An example sequence diagram for automatically validating an APR is depicted in accordance with various aspects of the present subject matter. For purposes of explanation, the various blocks of the example sequence diagram 400 are described with reference to Figures 1A to 3 and the components and / or processes described therein.

[0070] As described above, it is possible to scan an identifier (e.g., a barcode) of an infusion device 402 (e.g., a patient care device 102 of Figure 1A and Figure 1B , a patient care device 202 of Figure 2 , or an infusion device 310 in Figure 3 ) on an EMR terminal 404 (e.g., a device terminal 240 of Figure 2 or an EMR terminal 306 of Figure 3 ). This can initiate a process by which information related to the infusion device 402 is automatically sent to a connection gateway 406, as shown in Figure 4 . The connection gateway 406 (or a server performing a similar function) can perform certain actions related to the infusion device 402 and ultimately result in an APR being transmitted to the infusion device 404. After receiving the APR, the infusion device 402 can then verify the APR and respond accordingly. In some embodiments, the identifier of the infusion device 402 is scanned from a barcode attached to the device in combination with parameters entered into the EMR terminal 404 to select and / or generate an APR.

[0071] A hospital system implementing the subject technology can include the aforementioned infusion device 402, EMR terminal 404, and connection gateway 406. In some embodiments, the connection gateway 406 can include one or more computing devices, such as a server (e.g., an EMR server, such as the EMR system 302 of Figure 3 ). In some embodiments, the connection gateway 406 is implemented by or interchangeable with a coordination engine 308 of Figure 3 . Additionally, in some embodiments, an information system server 242 of Figure 2 represents the connection gateway 406.

[0072] In the example depicted in Figure 4 , a clinician interacts (411) with the EMR terminal 404. Such interaction can include, for example, the clinician scanning a badge or authentication device associated with the clinician. As described with respect to Figure 3 , the EMR terminal 404 can obtain the identity of the clinician through an authentication process. Additionally, the clinician can enter a care area identifier, patient identifier, drug identifier, identifier of the infusion device 402, and / or other identification information for requesting that an APR be sent to the infusion device 404. After the clinician interacts with the EMR terminal 404, the EMR terminal then transmits (412) an APR request to the connection gateway 406.

[0073] Additionally, in some embodiments, the infusion device 402 (e.g., via a control unit, such as Figure 1A and Figure 1B )​​​​​​​​​​​​​​​​​​​​​​​​​​​The control unit 104) sends (413) a message to the connection gateway 406 indicating that the infusion device 404 is ready to receive automatic programming. The message can include, for example, parameters such as the identifier of the infusion device 402 (e.g., serial number), the identifier of the clinician assigned to the infusion device 404 (e.g., the clinician logged into the device), the identifier of the care area where the infusion device 420 is located, the identifier of the control unit of the infusion device 402 (e.g., Figure 1A and Figure 1B the control unit 104 or Figure 2 the control unit 204) of, the identifier of the patient associated with the infusion device 402, and / or any other identification information required by the connection gateway 406 to send the APR to the infusion device 302.

[0074] After receiving the APR request from the EMR terminal 412 (and / or in some embodiments, an indication from the device 402), the connection gateway 406 sends (414) the APR to the infusion device 402. The APR can include, for example, an indication of the order type, which represents the type of order associated with the APR (e.g., initial order, follow-up order, modified order, bolus order, or secondary order). The APR can also include the identifier of the fluid pump of the infusion device 402 (e.g., Figure 1A any one of the infusion pumps 130 - 133). In addition, the APR can include operating parameters for managing the order, such as fluid type, dose unit (e.g., dose), flow rate, and / or volume to be infused (VTBI). Further, the APR can include a command to automatically program the infusion device 402 based on the operating parameters.

[0075] According to various embodiments described herein, the infusion device 402 attempts to verify (415) the APR after receiving the APR. In some embodiments, the APR verification process includes a "quick fail" process that attempts to identify high-level errors (e.g., compatibility issues between the indication and the implied order type of the APR) before determining whether the APR includes more difficult-to-detect errors. In this way, the APR verification process can quickly determine whether the APR is defective and / or should be rejected. An example APR verification process including the quick fail process will be discussed in more detail below with reference to Figures 5A to 5C more detail.

[0076] If the infusion device 402 successfully validates the APR, the infusion device 404 accepts (416A) the APR. This may include, for example, transmitting an acknowledgement message or "ACK" message to the connectivity gateway 406. Additionally, after validating the APR, the infusion device 402 may automatically program itself (416B) according to the APR (e.g., according to the operating parameters). On the other hand, if the infusion device 402 is unable to validate the APR (e.g., due to an error in the APR), the infusion device 404 rejects (417) the APR, for example, by transmitting a non-acknowledgement message or "NAK" message and / or an error message that indicates any errors identified with the APR during the validation process. The non-acknowledgement and / or error message may be sent to the connectivity gateway 406, which may forward the message to another device (e.g., an EMR server, an EMR terminal, or a computing device associated with the requesting clinician).

[0077] Figure 5A Depicts an example process 500 for validating an APR in accordance with various aspects of the present subject matter. For purposes of explanation, this disclosure refers to Figure 1A-4 blocks of the example process 500, including the components and / or processes described therein. One or more blocks of process 500 may be implemented by one or more of the computing devices described therein, such as Figure 1A and Figure 1B patient care device 102 of Figure 2 patient care device 202 of Figure 3 infusion device 310 of Figure 4 and / or infusion device 402 of

[0078] In some embodiments, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be implemented separately from other blocks and by one or more different processors or devices. Additionally, for purposes of explanation, the blocks of process 500 are described as occurring serially or linearly. However, multiple blocks of process 500 may occur in parallel. Additionally, the blocks of process 500 need not be executed in the order shown, and one or more blocks of process 500 need not be executed.

[0079] In the depicted example, a processor of an electronic device (e.g., Figure 1A and Figure 1B patient care device 102 of Figure 2 patient care device 202 of Figure 3 infusion device 310 of Figure 4 or infusion device 402 of Figure 4 receives (502) the APR from a device manager (e.g., Figure 4of 414). The APR includes an indication of the order type (e.g., initial order, follow-up order, modified order, bolus order, or secondary order), an identifier of the fluid pump of the infusion device (e.g., a channel indicator specifying the fluid pump), such as the fluid pumps 130 - 133 of Figure 1A the infusion device, operation parameters, and a command to automatically program the infusion device based on the operation parameters.

[0080] The indication of the order type of the APR can be selected by a clinician, e.g., when the clinician requests automatic programming of the infusion device at an EMR terminal (e.g., Figure 4 the EMR terminal 404 of Figure 4 see 411). In this way, the indication of the order type may indicate that the clinician desires the APR to result in the administration of a particular type of order via the infusion device. In some embodiments, the order types include initial orders, follow-up orders, modified orders, bolus orders, and secondary orders.

[0081] In addition, the operation parameters of the APR may include, for example, the desired fluid type to be administered via the fluid pump. The operation parameters may also include the desired dose unit for operating the fluid pump (e.g., the desired dose). Additionally, the operation parameters may include VTBI, flow rate, and / or other parameters for administering an infusion therapy via the fluid pump.

[0082] The processor also detects (504) the active state of the fluid pump. The active state can be, for example, an idle state indicating that the fluid pump is not pumping fluid, or an active state indicating that the fluid pump is pumping fluid. Additionally, the processor determines (506) the implied order type of the APR based in part on the detected active state. Similar to the indication of the order type of the APR, in some embodiments, the implied order type may include an initial order, a follow-up order, a modified order, a bolus order, or a secondary order. However, unlike the indication of the order type, the implied order type may not be selected by the clinician or otherwise indicated by the user. Instead, the implied order type may include the order type suggested by the operation parameters of the APR, as well as other context parameters that imply the order type to be administered according to the APR. For further discussion of this determination, see Figure 5B and the corresponding disclosure below.

[0083] After determining the implied order type, the processor determines (508) whether the indication of the order type is compatible with the implied order type (and in some embodiments, the fluid pump) (see Figure 4of 415). This determination can be based, for example, on indicating whether the order type matches the implicit order type, and in some embodiments, the active state of the target fluid pump and / or the type of the active infusion being administered by the target fluid pump. If the order type is compatible with the implicit order type (and the fluid pump), the processor sends (510) a confirmation message to the device manager (see Figure 4 of 416A), and programs the fluid pump according to the operating parameters (see Figure 4 in 416B). However, if the order type is not compatible with the implicit order type (or the fluid pump), the processor sends (512) a non-confirmation message and / or an error message (see Figure 4 of 417), and rejects the command to automatically program the fluid pump.

[0084] The processor can also determine the type of active infusion, and use the type of active infusion to determine whether the indicated order type is compatible with the implicit order type and the fluid pump. For example, the processor can determine the type of active infusion of the fluid pump in response to detecting that the active state includes an active state, based in part on the active dose unit (e.g., the active dose) or the active fluid type. The type of active infusion represents the type of infusion therapy actively administered by the infusion device via the fluid pump. Potential infusion types include liquid infusion, drug infusion, continuous infusion, and intermittent infusion. The determination of the type of active infusion is discussed in more detail below with reference to Figure 5C more detailed discussion of the determination of the type of active infusion.

[0085] Determining whether the indicated order type and the implicit order type are compatible can include various determinations based in part on whether the indicated order type matches the implicit order type and / or based on the type of active infusion of the fluid pump. In some embodiments, in response to determining that the implicit order type is an initial order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: (i) in response to determining whether the indicated order type is an initial order or a subsequent order, determining that the indicated order type is compatible with the implicit order type and the fluid pump, and (ii) in response to determining that the indicated order type is a modified order, a bolus order, or a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump.

[0086] In some embodiments, in response to determining that the implicit order type is a subsequent order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: (i) in response to determining whether the indicated order type is an initial order or a subsequent order, determining that the indicated order type is compatible with the implicit order type and the fluid pump, and (ii) in response to determining that the indicated order type is a modified order, a bolus order, or a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump.

[0087] In some embodiments, in response to determining that the implicit order type is a modification order, determining whether an indicated order type is compatible with the implicit order type and the fluid pump includes: (i) in response to determining that the implicit order type is a modification order, determining that the indicated order type is compatible with the implicit order type and the fluid pump; and in response to determining that the indicated order type is an initial order, a subsequent order, a bolus order, or a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump.

[0088] In some embodiments, in response to determining that the implicit order type is a bolus order, determining whether an indicated order type is compatible with the implicit order type and the fluid pump includes: (i) in response to determining that the indicated order type is a bolus order: (a) determining whether the fluid pump is configured to support a bolus order, (b) in response to determining that the fluid pump is configured to support a bolus order, determining that the indicated order type is compatible with the implicit order type and the fluid pump, and (c) in response to determining that the fluid pump is not configured to support a bolus order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump, and (ii) in response to determining that the indicated order type is an initial order, a subsequent order, a modification order, or a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump.

[0089] In some embodiments, a comparison between an indicated order type and an implicit order type using APR is made during the manufacture and calibration of an infusion device. For example, an APR of an indicated order type that is not compatible with the implicit order type of the APR (e.g., based on its operating parameters) may be provided to the infusion device. Based on whether and / or how the infusion device rejects the APR (e.g., returns a message indicating an APR compatibility issue), the infusion device may be considered to be properly calibrated for APR verification. The calibration process may also include providing an APR to the infusion device, where the indicated and implicit order types of the APR are different, but compatible and / or the same and compatible.

[0090] In some embodiments, in response to determining that the implicit order type is a secondary order, determining whether an indicated order type is compatible with the implicit order type and the fluid pump includes: (i) in response to determining that the indicated order type is a secondary order: (a) determining whether the fluid pump is configured to support a secondary order, (b) in response to determining that the fluid pump is configured to support a secondary order, determining that the indicated order type is compatible with the implicit order type and the fluid pump, and (c) in response to determining that the fluid pump is not configured to support a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump, and (ii) in response to determining that the indicated order type is an initial order, a subsequent order, a modification order, or a bolus order, determining that the indicated order type is not compatible with the implicit order type.

[0091] The processor may also via a display device associated with the infusion device (e.g., Figure 1B the display 114 of Figure 2The user interface device 230) displays a notification. The notification may include, for example, information regarding the verification of the APR. If the APR is successfully verified, the information may indicate a successful verification. However, if the APR cannot be verified, the information may indicate one or more reasons for the APR verification failure (e.g., due to (i) an incompatibility between the indicated order type and (ii) the implied order type and / or the fluid pump).

[0092] For example, the processor may determine that the operating parameters of the APR are incompatible with the fluid pump or that the implied order type is incompatible with the active infusion type of the fluid pump in response to determining that the indicated order type is incompatible with the implied order type or the fluid pump. Thus, the processor may display a first notification via the display device, where the first notification indicates, for example, that the APR is rejected and the operating parameters of the APR are incompatible with the fluid pump. Alternatively, the processor may display a second notification via the display device, where the second notification indicates that the APR is rejected, the implied order type is incompatible with the active infusion type of the fluid pump, and the active infusion type of the fluid pump. The processor may also display alternative or additional information based on error messages that are also sent to the device manager. For example, if the implied order type is a bolus order, the indicated order type is a bolus order, and the active fluid pump does not support the bolus step, the processor may display information via the display device indicating that the operating parameters of the APR are not supported by the fluid pump. The processor may also display the error message and / or error indicator contained therein.

[0093] In some embodiments, the processor is configured to display information indicating, for example, (i) the APR is rejected, e.g., at the target fluid pump specified by the APR, (ii) the operating parameters or other parameters included in the APR are not supported by the target fluid pump, (iii) the target fluid pump is busy and thus cannot be programmed according to the APR (e.g., including an estimate of the time when the target fluid pump will be ready and / or an indication of the infusion type currently being administered by the target fluid pump), (iv) the order type of the APR (e.g., the indicated order type and / or the implied order type) does not match the current fluid type of the fluid pump, (v) the APR is missing relevant information (e.g., necessary operating parameters), and / or (vi) the APR includes invalid information.

[0094] The error message sent by the processor to the device manager in response to determining that the indicated order type is incompatible with the implied order type or the fluid pump may be partially based on, for example, the determination made during the compatibility determination. The error message may include a program session identifier and / or a revision identifier of another channel (e.g., a fluid pump) that matches the infusion set (e.g., is compatible with the APR).

[0095] The error message may also include an error indicator indicating the type of error encountered. For example, if the implicit order type is an initial order and the indicated order type is a modified order, the error message may include a titration idle channel error indicator. As another example, if the implicit order type is an initial order and the indicated order type is a bolus order, the error message may include a bolus idle channel error indicator. As another example, if the implicit order type is an initial order and the indicated order type is a secondary order, the error message may include a secondary idle channel error indicator. As yet another example, if the implicit order type is a follow-up, modified, or bolus order, the indicated order type is a bolus or secondary order, and the bolus, secondary, or base is currently active on the infusion device, the error message may include a bolus, secondary, or base execution error indicator, respectively. As yet another example, if the implicit order type is a secondary, modified, or bolus order, the indicated order type is a bolus or secondary order, and the bolus, secondary, or base order is not currently active on the infusion device, the error message may include a channel program mismatch error indicator.

[0096] As another example, if the implicit order type is a secondary order and the indicated order type is a modified order, the error message may include an invalid information error indicator. As another example, if the implicit order type is a modified order and the indicated order type is an initial or follow-up order, the error message may include an invalid information error indicator (e.g., along with an identifier of any violating element). As another example, if the implicit order type is a bolus order and the specified fluid channel (e.g., fluid pump) does not support the bolus step, the error message may include a bolus not supported error indicator. As another example, if the implicit order type is a secondary order and the specified fluid channel (e.g., fluid pump) does not support the secondary step, the error message may include a secondary not supported error indicator. As yet another example, if the implicit order type is a secondary order, the indicated order type is an initial, follow-up, modified, or bolus order, and the bolus, secondary, or base is currently active on the infusion device, the error message may include a bolus, secondary, or base execution error indicator, respectively. As another example, if the implicit order type is a secondary order, the indicated order type is an initial, follow-up, modified, or bolus order, and the bolus, secondary, or base order is not currently active on the infusion device, the error message may include a channel program mismatch error indicator.

[0097] Figure 5B and Figure 5CIllustrates example processes 520 and 540 for determining the type of implicit order for an APR and the type of active infusion for a fluid pump, respectively, in accordance with various aspects of the present subject matter. Similar to the example processes described above, one or more blocks of processes 520 and 540 may be implemented by one or more of the computing devices described herein, such as Figure 1A and Figure 1B patient care device 102 of Figure 2 patient care device 202 of Figure 3 infusion device 310 of Figure 4 and / or infusion device 402 of

[0098] Figure 5B As shown, determination of the type of implicit order may be based on various factors, including, for example, whether the target channel (e.g., the target fluid pump) is active, whether the requested fluid type matches the active fluid type, whether the requested dose unit (e.g., the requested dose) matches the active dose unit (e.g., the active dose), and / or whether the APR includes VTBI.

[0099] Figure 1A For example, in the illustrated embodiment, process 520 for determining the type of implicit order for an APR includes determining (522) (e.g., detecting) whether the channel (e.g., infusion pumps 130 - 133 of

[0100] specified by the APR) is active (e.g., in an active state). If the channel is inactive (e.g., in an idle state), the processor may determine that the type of implicit order is an initial order. Additionally, process 520 may include, in response to detecting that the channel is active, determining (524) whether the requested fluid type (e.g., as requested in the APR) matches the fluid type being actively pumped by the channel. If the requested fluid type does not match the active fluid type, the processor may determine that the type of implicit order is a secondary order. Additionally, process 520 may include, in response to determining that the requested fluid type matches the active fluid type, determining (526) whether the requested dose unit (e.g., as requested in the APR) matches the active dose unit of the channel (e.g., milliliters per hour or milligrams). In some embodiments, determining whether the requested dose unit matches the active dose unit includes determining whether the type of the requested dose unit matches the type of the active dose unit. Example types of dose units include intermittent units (e.g., specifying the amount of active ingredient), continuous units (e.g., specifying the amount of time and the amount of active ingredient), drug units (e.g., specifying the volume of a drug such as an analgesic), and fluid units (e.g., specifying the volume of a fluid such as saline).If the requested dose unit does not match the active dose unit, the processor may determine that the implied order type is a bolus order. Additionally, process 520 may include, in response to determining that the requested dose unit matches the active dose unit, determining (528) whether the operating parameters of the APR also include the requested VTBI (e.g., as requested in the APR). If the operating parameters do not include the requested VTBI, the processor may determine that the implied order type is a modification order. However, if the operating parameters do include the requested VTBI, the processor may determine that the implied order type is a subsequent order.

[0101] Now referring to Figure 5C , an example process 540 for determining the active infusion type of a fluid pump (e.g., Figure 1A infusion pumps 130 - 133) includes determining (542) whether the active dose unit of the fluid pump is an intermittent unit. As used herein, an "intermittent unit" refers to a dose unit that includes a quantity (e.g., in milligrams) of an active ingredient but does not specify a quantity of time (e.g., in seconds, minutes, or hours). Similarly, an intermittent infusion refers to infusing a quantity of an active ingredient (e.g., a bolus) over a short period of time. If the active dose unit is an intermittent unit, the processor may determine that the active infusion type is an intermittent infusion.

[0102] In response to determining that the active dose unit is not an intermittent unit, process 520 also includes determining (544) whether the active dose unit consists only of volume units (e.g., mL). If the active dose unit does not consist only of volume units, the processor may determine that the active infusion type is a continuous infusion. As used herein, a "continuous infusion" describes an infusion type in which a quantity of an active ingredient (e.g., in milligrams) is administered over a specific quantity of time. Process 520 may also include, in response to determining that the active dose unit consists only of volume units, determining (546) whether the active fluid pumped by the fluid pump is a drug (e.g., an analgesic or anesthetic). If the active fluid is not a drug (e.g., saline), the processor may determine that the active infusion type is a fluid infusion. However, if the active fluid is a drug, the processor may determine that the active infusion type is a drug infusion.

[0103] Figure 6 is a conceptual diagram showing an example electronic system 600 for validating an APR according to various aspects of the present subject matter technology. The electronic system 600 may be implemented by a computing device for executing software associated with portions or steps of Figure 6 process 600, or by the components and methods provided in FIGS. 1 - 5. In this regard, the electronic system 600 may include Figure 1A and Figure 1B patient care device 102, Figure 2 patient care device 202, Figure 3infusion device 310 and / or Figure 4 infusion device 402.

[0104] The electronic system 600 may also include a specially configured personal computer or a mobile device for infusion, such as a smart phone, a tablet computer, a laptop computer, a PDA, an augmented reality device, a wearable device (such as a watch or a strap or glasses), or a combination thereof, or other touch screens or televisions embedded or coupled with one or more processors, or any other type of computer-related electronic device having network connectivity.

[0105] In addition, the electronic system 600 may include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, the electronic system 600 includes a bus 608, a processing unit 612, a system memory 604, a read-only memory (ROM) 610, a permanent storage device 602, an input device interface 614, an output device interface 606, and a network interface 616. In some embodiments, the electronic system 600 may include or integrate other computing devices or circuits for operating the various components and methods described previously.

[0106] The bus 608 collectively represents a system, a peripheral device, and a chipset bus that communicatively connect the numerous internal devices of the electronic system 600. For example, the bus 608 communicatively connects the processing unit 612 to the ROM 610, the system memory 604, and the permanent storage device 602. From these different storage units, the processing unit 612 retrieves the instructions to be executed and the data to be processed in order to perform the processing of the present disclosure. In different embodiments, the processing unit 612 may be a single processor or a multi-core processor.

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

[0108] Similar to the permanent storage device 602, the system memory 604 is a read-write storage device. However, unlike the storage device 602, the system memory 604 is a volatile read-write memory, such as random access memory (RAM). The system memory 604 stores some instructions and data that the processor needs during operation. In some embodiments, the processes disclosed in this subject matter are stored in the system memory 604, the permanent storage device 602, and / or the ROM 610. From these different storage units, the processing unit 612 retrieves the instructions to be executed and the data to be processed in order to execute the processes of some embodiments.

[0109] The bus 608 is also connected to an input device interface 614 and an output device interface 606. The input device interface 614 enables a user to convey information to and select commands for the electronic system. Input devices used in conjunction with the input device interface 614 include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 606 is capable of displaying, for example, images generated by the electronic system 600. Output devices used in conjunction with the output device interface 606 include, for example, a printer and a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Some embodiments include devices that function as both input devices and output devices (e.g., a touch screen).

[0110] In addition, the bus 608 also connects the electronic system 600 to a network (not shown) via a network interface 616. The network interface 616 can include, for example, a wireless access point (e.g., Bluetooth or Wi-Fi) or radio circuitry for connecting to a wireless access point. The network interface 616 can also include hardware for connecting a computer to a portion of a computer network, such as a local area network (LAN), a wide area network (WAN), a wireless LAN, an intranet, or a network of networks, such as the Internet. When one or more of the described features are specifically configured, the components of the electronic system 600 can be used in conjunction with the disclosure of this subject matter.

[0111] The above functions can be implemented in computer software, firmware, or hardware. These techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as a mobile device. Processes and logical flows can be executed by one or more programmable processors and programmable logic circuits. General and special purpose computing devices and storage devices can be interconnected via a communication network.

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

[0113] Although the foregoing discussion has focused mainly on microprocessors or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored on the circuit itself.

[0114] As used in this specification and in any claims of this application, the terms "computer," "server," "processor," and "memory" refer to an electronic or other technical device specifically configured with one or more of the above features. These terms do not include a person or group of people. For the purposes of the specification, the term "display" or "display device" refers to being displayed on an electronic device. As used in this specification and in any claims of this application, the terms "computer-readable medium" and "computer-readable media" are entirely limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, and any other transient signals.

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

[0116] Embodiments of the subject matter described in this specification may be implemented in a computing system of a particular configuration that includes backend components (e.g., data servers), or that includes middleware components of a particular configuration (e.g., application servers), or that includes frontend components of a particular configuration (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 backend, middleware, or frontend components. The components of the system may be interconnected by digital data communication in one or more forms or media, such as a communication network. Examples of communication networks include LANs and WANs, the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0117] The computing system may include clients and servers of a particular configuration. The clients and servers are typically located remotely from each other and may interact through a communication network. The relationship between the client and the server arises from computer programs running on their respective computers and has a client-server relationship with each other. In some embodiments, the server transmits data (e.g., HTML pages) to the client device (e.g., to display data to and receive user input from a user interacting with the client device). Data generated at the client device (e.g., the result of a user interaction) may be received at the server from the client device.

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

[0119] It should be understood that the specific order or hierarchy of steps in the disclosed processes is an illustration of example methods. Based on design preferences, it is understood that the specific order or hierarchy of steps in the processes can be rearranged. Some steps can be performed simultaneously. The appended method claims present elements of the steps in an example order and do not mean to be limited to the specific order or hierarchy presented.

[0120] Illustrative of the claimed subject matter as a clause:

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

[0122] Clause 1. An infusion device, comprising: a fluid pump; and a processor configured to: receive an automatic programming request (APR) from a device manager, the APR including (i) an indication of an order type, (ii) an identifier of the fluid pump, (iii) operating parameters including a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters; detect an active state of the fluid pump, the active state including (i) an idle state indicating that the fluid pump is not pumping fluid or (ii) an active state indicating that the fluid pump is pumping fluid; determine an implied order type of the APR based at least in part on the detected active state, wherein the implied order type includes an initial order, a follow-up order, a modified order, a bolus order, or a secondary order; determine whether the indicated order type is compatible with the implied order type and the fluid pump based at least in part on whether the indicated order type matches the implied order type; in response to determining that the indicated order type is compatible with the implied order type and the fluid pump, (i) send a confirmation message to the device manager, and (ii) program the fluid pump according to the operating parameters; and in response to determining that the indicated order type is not compatible with the implied order type or the fluid pump, (i) send an error message to the device manager, and (ii) reject the command to automatically program the fluid pump according to the operating parameters.

[0123] Clause 2. The infusion device according to Clause 1, wherein the operating parameters further include the requested dose unit, and determining the implicit order type includes: in response to detecting that the active state of the fluid pump includes an idle state, determining that the implicit order type includes an initial order; in response to detecting that the active state includes an active state, determining whether the requested fluid type matches the active fluid type being pumped by the fluid pump; in response to determining that the requested fluid type does not match the active fluid type, determining that the implicit order type includes a secondary order; in response to determining that the requested fluid type matches the active fluid type, determining whether the requested dose unit matches the active dose unit of the fluid pump; in response to determining that the requested dose unit does not match the active dose unit, determining that the implicit order type includes a bolus order; in response to determining that the requested dose unit matches the active dose unit, determining whether the operating parameters of the APR also include the requested VTBI; in response to determining that the operating parameters do not include the requested VTBI, determining that the implicit order type includes a modified order; and in response to determining that the operating parameters include the requested VTBI, determining that the implicit order type includes a follow-up order.

[0124] Clause 3. The infusion device according to any one of Clauses 1 or 2, wherein: the processor is further configured to, in response to detecting that the active state includes an active state, determine the active infusion type of the fluid pump based at least in part on the active dose unit or the active fluid type, the active infusion type including fluid infusion, continuous infusion, or intermittent infusion; and determine whether the order type indicated is compatible with the implicit order type and the fluid pump further based on the active infusion type.

[0125] Clause 4. The infusion device according to Clause 3, wherein determining the active infusion type includes: determining whether the active dose unit of the fluid pump includes an intermittent unit; in response to determining that the active dose unit includes an intermittent unit, determining that the active infusion type includes intermittent infusion; in response to determining that the active dose unit does not include an intermittent unit: determining whether the active dose unit is composed of volume units; in response to determining that the active dose unit is not composed of volume units, determining that the active infusion type includes continuous infusion; and in response to determining that the active dose unit is composed of volume units, determining whether the active fluid being pumped by the fluid pump is a drug, wherein when the active fluid is not a drug, the active infusion type includes fluid infusion, and when the active fluid is a drug, the active infusion type includes drug infusion.

[0126] Clause 5. The infusion device according to any one of Clauses 1 to 4, wherein, in response to determining that the implicit order type includes an initial order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: in response to determining that the indicated order type includes an initial order or a follow-up order, determining that the indicated order type is compatible with the implicit order type and the fluid pump; and in response to determining that the indicated order type includes a modified order, a bolus order, or a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump.

[0127] Clause 6. The infusion device according to Clause 3 or 4, wherein, in response to determining that the implicit order type includes a follow-up order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: in response to determining that the indicated order type includes an initial order or a follow-up order, determining that the indicated order type is compatible with the implicit order type and the fluid pump; and in response to determining that the indicated order type includes a modified order, a bolus order, or a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump.

[0128] Clause 7. The infusion device according to any one of Clauses 3, 4, or 6, wherein, in response to determining that the implicit order type includes a modified order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: in response to determining that the implicit order type includes a modified order, determining that the indicated order type is compatible with the implicit order type and the fluid pump; and in response to determining that the indicated order type includes an initial order, a follow-up order, a bolus order, or a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump.

[0129] Clause 8. The infusion device according to any one of Clauses 3, 4, 6, or 7, wherein, in response to determining that the implicit order type includes a bolus order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: in response to determining that the indicated order type includes a bolus order: determining whether the fluid pump is configured to support a bolus order; in response to determining that the fluid pump is configured to support a bolus order, determining that the indicated order type is compatible with the implicit order type and the fluid pump; and in response to determining that the fluid pump is not configured to support a bolus order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump; and in response to determining that the indicated order type includes an initial order, a follow-up order, a modified order, or a secondary order, determining that the indicated order type is not compatible with the implicit order type or the fluid pump.

[0130] Clause 9. The infusion device according to any one of Clauses 3, 4, or 6 to 8, wherein determining whether the indicated order type is compatible with the implied order type and the fluid pump in response to determining that the implied order type includes a secondary order comprises: in response to determining that the indicated order type includes a secondary order: in response to determining that the fluid pump is configured to support secondary orders, determining that the indicated order type is compatible with the implied order type and the fluid pump; and in response to determining that the fluid pump is not configured to support secondary orders, determining that the indicated order type is not compatible with the implied order type or the fluid pump; and in response to determining that the indicated order type includes a primary order, a follow-up order, a modified order, or a bolus order, determining that the indicated order type is not compatible with the implied order type.

[0131] Clause 10. The infusion device according to any one of Clauses 1 to 9, wherein the indicated order type is not compatible with the implied order type or the fluid pump, and the processor is further configured to, in response to determining that the indicated order type is not compatible with the implied order type or the fluid pump: determine (i) that the operating parameters of the APR are not compatible with the fluid pump, or (ii) that the implied order type is not compatible with the active infusion type of the fluid pump; and in response to determining that the operating parameters of the APR are not compatible with the fluid pump, display a first notification at a display device associated with the infusion device, the first notification indicating (i) that the APR is rejected and (ii) that the operating parameters of the APR are not compatible with the fluid pump; or in response to determining that the implied order type is not compatible with the active infusion type of the fluid pump, display a second notification at the display device, the second notification indicating (i) that the APR is rejected, (ii) that the implied order type is not compatible with the active infusion type of the fluid pump, and (iii) the active infusion type of the fluid pump.

[0132] Clause 11. A computer-implemented method for verifying an APR, the method comprising: receiving an APR from a device manager, the APR including (i) an indication of an order type, which includes an initial order, a follow-up order, a modified order, a bolus order, or a secondary order, (ii) an identifier of a fluid pump of an infusion device, (iii) operating parameters, which include a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters; detecting an active state of the fluid pump, the active state including (i) an idle state indicating that the fluid pump is not pumping fluid or (ii) an active state indicating that the fluid pump is pumping fluid; determining an implied order type of the APR based at least in part on the detected active state, wherein the implied order type includes an initial order, a follow-up order, a modified order, a bolus order, or a secondary order; determining whether the indicated order type is compatible with the implied order type and the fluid pump based at least in part on whether the indicated order type matches the implied order type; in response to determining that the indicated order type is compatible with the implied order type and the fluid pump, (i) sending an acknowledgment message to the device manager, and (ii) programming the fluid pump according to the operating parameters; and in response to determining that the indicated order type is not compatible with the implied order type or the fluid pump, (i) sending a non-acknowledgment message and an error message to the device manager, and (ii) rejecting the command to automatically program the fluid pump according to the operating parameters.

[0133] Clause 12. The computer-implemented method according to Clause 11, wherein the operating parameters further include a requested dose unit, and determining the implied order type includes: in response to detecting that the active state of the fluid pump includes an idle state, determining that the implied order type includes an initial order; in response to detecting that the active state includes an active state, determining whether the requested fluid type matches the active fluid type being pumped by the fluid pump; in response to determining that the requested fluid type does not match the active fluid type, determining that the implied order type includes a secondary order; in response to determining that the requested fluid type matches the active fluid type, determining whether the requested dose unit matches the active dose unit of the fluid pump; in response to determining that the requested dose unit does not match the active dose unit, determining that the implied order type includes a bolus order; in response to determining that the requested dose unit matches the active dose unit, determining whether the operating parameters of the APR further include a requested VTBI; in response to determining that the operating parameters do not include the requested VTBI, determining that the implied order type includes a modified order; and in response to determining that the operating parameters include the requested VTBI, determining that the implied order type includes a follow-up order.

[0134] Clause 13. The computer-implemented method according to Clause 11 or 12 further includes: in response to detecting that the active state includes an active state, determining an active infusion type of the fluid pump based in part on an active dose unit or an active fluid type, the active infusion type including fluid infusion, continuous infusion, or intermittent infusion; wherein determining whether the indicated order type is compatible with the implied order type and the fluid pump is further based on the active infusion type.

[0135] Clause 14. The computer-implemented method according to Clause 13, wherein determining the active infusion type includes: determining whether the active dose unit of the fluid pump includes an intermittent unit; in response to determining that the active dose unit includes an intermittent unit, determining that the active infusion type includes intermittent infusion; in response to determining that the active dose unit does not include an intermittent unit: determining whether the active dose unit consists of volume units; in response to determining that the active dose unit does not consist of volume units, determining that the active infusion type includes continuous infusion; and in response to determining that the active dose unit consists of volume units, determining whether the active fluid pumped by the fluid pump is a drug, wherein when the active fluid is not a drug, the active infusion type includes fluid infusion, and when the active fluid is a drug, the active infusion type includes drug infusion.

[0136] Clause 15. The computer-implemented method according to any one of Clauses 11 to 14, wherein in response to determining that the implied order type includes an initial order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: in response to determining that the indicated order type includes an initial order or a follow-up order, determining that the indicated order type is compatible with the implied order type and the fluid pump; and in response to determining that the indicated order type includes a modified order, a bolus order, or a secondary order, determining that the indicated order type is compatible with the implied order type or the fluid pump not.

[0137] Clause 16. The computer-implemented method according to any one of Clauses 13 or 14, wherein in response to determining that the implied order type includes a follow-up order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: in response to determining that the indicated order type includes an initial order or a follow-up order, determining that the indicated order type is compatible with the implied order type and the fluid pump; and in response to determining that the indicated order type includes a modified order, a bolus order, or a secondary order, determining that the indicated order type is not compatible with the implied order type or the fluid pump.

[0138] Clause 17. The computer-implemented method according to any one of Clauses 13, 14, or 16, wherein, in response to determining that the implied order type includes a modified order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: in response to determining that the indicated order type includes a modified order, determining that the indicated order type is compatible with the implied order type and the fluid pump; and in response to determining that the indicated order type includes an initial order, a follow-up order, a bolus order, or a secondary order, determining that the indicated order type is not compatible with the implied order type or the fluid pump.

[0139] Clause 18. The computer-implemented method according to any one of Clauses 13, 14, 16, or 17, wherein, in response to determining that the implied order type includes a bolus order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: in response to determining that the indicated order type includes a bolus order: determining whether the fluid pump is configured to support a bolus order; in response to determining that the fluid pump is configured to support a bolus order, determining that the indicated order type is compatible with the implied order type and the fluid pump; and in response to determining that the fluid pump is not configured to support a bolus order, determining that the indicated order type is not compatible with the implied order type or the fluid pump; and in response to determining that the indicated order type includes an initial order, a follow-up order, a modified order, or a secondary order, determining that the indicated order type is not compatible with the implied order type or the fluid pump.

[0140] Clause 19. The computer-implemented method according to any one of Clauses 13, 14, or 16 to 18, wherein, in response to determining that the implied order type includes a secondary order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: in response to determining that the indicated order type includes a secondary order: determining whether the fluid pump is configured to support a secondary order; in response to determining that the fluid pump is configured to support a secondary order, determining that the indicated order type is compatible with the implied order type and the fluid pump; and in response to determining that the fluid pump is not configured to support a secondary order, determining that the indicated order type is not compatible with the implied order type or the fluid pump; and in response to determining that the indicated order type includes an initial order, a follow-up order, a modified order, or a bolus order, determining that the indicated order type is not compatible with the implied order type.

[0141] Clause 20. The computer-implemented method according to any one of Clauses 11 to 19 further includes, in response to determining that the indicated medical order type is incompatible with the implied medical order type or the fluid pump: determining (i) that the operating parameters of the APR are incompatible with the fluid pump, or (ii) that the implied medical order type is incompatible with the active infusion type of the fluid pump; and in response to determining that the operating parameters of the APR are incompatible with the fluid pump, displaying a first notification at a display device associated with the infusion device, the first notification indicating (i) that the APR is rejected and (ii) that the operating parameters of the APR are incompatible with the fluid pump; or, in response to determining that the implied medical order type is incompatible with the active infusion type of the fluid pump, displaying a second notification at the display device, the second notification indicating (i) that the APR is rejected, (ii) that the implied medical order type is incompatible with the active infusion type of the fluid pump, and (iii) the active infusion type of the fluid pump; wherein it is indicated that the medical order type is incompatible with the implied medical order type or the fluid pump.

[0142] Clause 21. A non-transitory computer-readable storage medium including instructions that, when executed by a processor of an electronic device, cause the electronic device to: receive an APR from a device manager, the APR including (i) an indicated medical order type including an initial medical order, a subsequent medical order, a modified medical order, a bolus medical order, or a secondary medical order, (ii) an identifier of a fluid pump of an infusion device, (iii) operating parameters including a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters; detect an active state of the fluid pump, the active state including (i) an idle state indicating that the fluid pump is not pumping fluid or (ii) an active state indicating that the fluid pump is pumping fluid; determine an implied medical order type of the APR based in part on the detected active state, wherein the implied medical order type includes an initial medical order, a subsequent medical order, a modified medical order, a bolus medical order, or a secondary medical order; determine whether the indicated medical order type is compatible with the implied medical order type and the fluid pump based in part on whether the indicated medical order type matches the implied medical order type; in response to determining that the indicated medical order type is compatible with the implied medical order type and the fluid pump, (i) send a confirmation message to the device manager, and (ii) program the fluid pump according to the operating parameters; and in response to determining that the indicated medical order type is incompatible with the implied medical order type or the fluid pump, (i) send an error message to the device manager, and (ii) reject the command to automatically program the fluid pump according to the operating parameters.

[0143] Clause 22. The non-transitory computer-readable medium of Clause 21 further includes instructions that, when executed by the processor, cause the electronic device to perform the computer-implemented method according to any one of Clauses 12 to 20.

[0144] Further consider:

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

[0146] The foregoing description is provided to enable a person skilled in the art to practice the various aspects described herein. The foregoing description provides various examples of the subject matter technology, and the subject matter technology is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects. 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, where the elements in the singular form are not intended to mean "one and only one" but rather "one or more" unless specifically stated otherwise. The term "some" is meant to mean one or more unless specifically stated otherwise. Masculine pronouns (e.g., his) include feminine and neuter (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.

[0147] The recitations "configured to," "operable to," and "programmed to" do not imply any particular tangible or intangible modification of the subject matter, but are intended to be used interchangeably. For example, a processor configured to monitor and control operations or components can also be represented as a processor programmed to monitor and control operations, or operable to monitor and manage operations. Similarly, a processor configured to execute code can be interpreted as a processor programmed to execute code or operable to execute code.

[0148] The term "automatically" as used herein can include execution by a computer or machine without user intervention; e.g., by instructions in response to a prerequisite action of a computer or machine or other initiating mechanism. The word "example" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as an "example" is not necessarily to be construed as preferred or superior to other aspects or designs.

[0149] Phrases such as "aspect" do not mean that the aspect is essential to the subject technology, nor that the aspect is applicable to all configurations of the subject technology. The disclosure related to an aspect can apply to all configurations, or one or more configurations. An aspect can provide one or more examples. Phrases such as "aspect" can refer to one or more aspects, and vice versa. Phrases such as "embodiment" do not mean that such an embodiment is essential to the subject technology, nor that such an implementation is applicable to all configurations of the subject technology. The disclosure related to an embodiment can apply to all embodiments, or one or more embodiments. An embodiment can provide one or more examples. Phrases such as "embodiment" can mean one or more embodiments, and vice versa. Phrases such as "configuration" do not mean that such a configuration is essential to the subject technology, nor that such a configuration is applicable to all configurations of the subject technology. The disclosure related to a configuration can apply to all configurations, or one or more configurations. A configuration can provide one or more examples. Phrases such as "configuration" can refer to one or more configurations, and vice versa.

[0150] As used herein, a "user interface" (also referred to as an interactive user interface, graphical user interface, or UI) can refer to a web-based interface that includes data fields and / or other control elements for receiving input signals or providing electronic information and / or providing information to a user in response to any received input signal. The control elements can include dials, buttons, icons, selectable areas, or other perceivable markers presented via the UI that initiate a data exchange for the device presenting the UI when interacted with (e.g., clicked, touched, selected, etc.). The UI can be implemented in whole or in part using technologies such as HyperText Markup Language (HTML), FLASH TM , JAVA TM , NET TM , C, C++, web services, or Rich Site Summary (RSS) technology. In some embodiments, the UI can be included in a stand-alone client (e.g., thick client, fat client) that is configured to communicate (e.g., send or receive data) according to one or more of the aspects described. The communication can be to or from a medical device or server with which it communicates.

[0151] As used herein, the term "determine" or "determining" includes a variety of actions. For example, "determine" can include performing operations, calculations, processing, derivation, generation, obtaining, looking up (e.g., looking up in a table, database, or another data structure), ascertaining, etc. via a hardware component without user intervention. Additionally, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. via a hardware component without user intervention. "Determine" can include parsing, selecting, picking, establishing, etc. via a hardware component without user intervention.

[0152] As used herein, the term "provide" or "providing" includes a variety of actions. For example, "provide" can include storing a value in a location in a storage device for subsequent retrieval, directly transmitting the value to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to the value, etc. "Provide" can also include encoding, decoding, encrypting, decrypting, authenticating, validating, etc. via a hardware component.

[0153] As used herein, the term "message" includes various formats for conveying (e.g., sending or receiving) information. A message can include an aggregation of machine-readable information, such as an XML document, a fixed-field message, a comma-separated message, JSON, or a custom protocol, etc. In some embodiments, a message can include a signal for conveying one or more representations of information. Although recited in the singular, it is understood that a message can be composed, transmitted, stored, received, etc. in multiple parts.

[0154] As used herein, the term "selectively" or "selective" can include a variety of actions. For example, a "selective" process can include determining one option from a plurality of options. A "selective" process can include one or more of the following: dynamically determined input, pre-configured input, or user-initiated input for making a determination. In some embodiments, an n-input switch can be included to provide a selective function, where n is the number of inputs for making a selection.

[0155] As used herein, the terms "correspond" or "corresponding" include a structural, functional, quantitative, and / or qualitative correlation or relationship between two or more objects, data sets, and / or information, etc., preferably, wherein the corresponding relationship or relationship can be used to translate one or more of the two or more objects, data groups, and / or information, etc., so that they appear the same or equal. One or more of a threshold, a value range, fuzzy logic, pattern matching, a machine learning evaluation model, or a combination thereof can be used to evaluate the corresponding relationship.

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

Claims

1. An infusion device, comprising: A fluid pump; And A processor configured to: Receive an automatic programming request (APR) from a device manager, the APR including (i) an indication of an order type, (ii) an identifier of the fluid pump, (iii) operating parameters including a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters; Detect an active state of the fluid pump, the active state including (i) an idle state indicating that the fluid pump is not pumping fluid or (ii) an active state indicating that the fluid pump is pumping fluid; Determine an implied order type of the APR based at least in part on the detected active state, wherein the implied order type includes an initial order, a follow-up order, a modification order, a bolus order, or a secondary order; Determine whether the indicated order type is compatible with the implied order type and the fluid pump based at least in part on whether the indicated order type matches the implied order type; In response to determining that the indicated order type is compatible with the implied order type and the fluid pump, (i) send a confirmation message to the device manager and (ii) program the fluid pump according to the operating parameters; and In response to determining that the indicated order type is not compatible with the implied order type or the fluid pump, (i) send an error message to the device manager and (ii) reject the command to automatically program the fluid pump according to the operating parameters.

2. The infusion device according to claim 1, wherein, The operating parameters further include a requested dose unit, and determining the implied order type includes: In response to detecting that the active state of the fluid pump includes an idle state, determining that the implied order type includes the initial order; In response to detecting that the active state includes an active state, determine whether the requested fluid type matches the active fluid type being pumped by the fluid pump; In response to determining that the requested fluid type does not match the active fluid type, determine that the implied order type includes the secondary order; In response to determining that the requested fluid type matches the active fluid type, determine whether the requested dose unit matches the active dose unit of the fluid pump; In response to determining that the requested dose unit does not match the active dose unit, determine that the implied order type includes the bolus order; In response to determining that the requested dose unit matches the active dose unit, determine whether the operating parameters of the APR further include a requested volume to be infused (VTBI); In response to determining that the operating parameters do not include the requested VTBI, determine that the implied order type includes the modification order; and In response to determining that the operating parameters include the requested VTBI, determine that the implied order type includes the follow-up order.

3. The infusion device according to claim 1, wherein: The processor is further configured to determine an active infusion type of the fluid pump, partially based on an active dose unit or an active fluid type, in response to detecting that the active state includes an active status, the active infusion type including fluid infusion, continuous infusion, or intermittent infusion; and determine whether the indicated order type is compatible with the implied order type, and the fluid pump is further based on the active infusion type.

4. The infusion device according to claim 3, wherein, Determining that the active infusion type includes: Determine whether the active dose unit of the fluid pump includes an intermittent unit; In response to determining that the active dose unit includes the intermittent unit, determine that the active infusion type includes the intermittent infusion; In response to determining that the active dose unit does not include the intermittent unit: Determine whether the active dose unit is composed of volume units; In response to determining that the active dose unit is not composed of the volume units, determine that the active infusion type includes the continuous infusion; and In response to determining that the active dose unit is composed of the volume units, determine whether the active fluid pumped by the fluid pump is a drug, wherein when the active fluid is not a drug, the active infusion type includes the fluid infusion, and when the active fluid is a drug, the active infusion type includes the drug infusion.

5. The infusion device according to claim 1, wherein, In response to determining that the implied order type includes an initial order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: In response to determining that the indicated order type includes the initial order or the subsequent order, determine that the indicated order type is compatible with the implied order type and the fluid pump; and In response to determining that the indicated order type includes the modified order, the bolus order, or the secondary order, determine that the indicated order type is not compatible with the implied order type or the fluid pump.

6. The infusion device according to claim 3, wherein, In response to determining that the implied order type includes the subsequent order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: In response to determining that the indicated order type includes the initial order or the subsequent order, determine that the indicated order type is compatible with the implied order type and the fluid pump; and In response to determining that the indicated order type includes the modified order, the bolus order, or the secondary order, determine that the indicated order type is not compatible with the implied order type or the fluid pump.

7. The infusion device according to claim 3, wherein, In response to determining that the implied order type includes the modified order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: In response to determining that the indicated order type includes the modified order, determine that the indicated order type is compatible with the implied order type and the fluid pump; and In response to determining that the indicated order type includes the initial order, the subsequent order, the bolus order, or the secondary order, determine that the indicated order type is not compatible with the implied order type or the fluid pump.

8. The infusion device according to claim 3, wherein, In response to determining that the implied order type includes the bolus order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: In response to determining that the indicated order type includes the bolus order: Determine whether the fluid pump is configured to support the bolus order; In response to determining that the fluid pump is configured to support the bolus order, determine that the indicated order type is compatible with the implied order type and the fluid pump; and In response to determining that the fluid pump is not configured to support the bolus order, determine that the indicated order type is not compatible with the implied order type or the fluid pump; and In response to determining that the indicated order type includes the initial order, the subsequent order, the modified order, or the secondary order, determine that the indicated order type is not compatible with the implied order type or the fluid pump.

9. The infusion device according to claim 3, wherein, In response to determining that the implied order type includes the secondary order, determining whether the indicated order type is compatible with the implied order type and the fluid pump includes: In response to determining that the indicated order type includes the secondary order: Determine whether the fluid pump is configured to support the secondary order; In response to determining that the fluid pump is configured to support the secondary order, determine that the indicated order type is compatible with the implied order type and the fluid pump; and In response to determining that the fluid pump is not configured to support the secondary order, determine that the indicated order type is not compatible with the implied order type or the fluid pump; and In response to determining that the indicated order type includes the initial order, the subsequent order, the modified order, or the bolus order, determine that the indicated order type is not compatible with the implied order type.

10. The infusion device according to claim 1, wherein, The indicated order type is not compatible with the implied order type or the fluid pump, and the processor is further configured to, in response to determining that the indicated order type is not compatible with the implied order category or the fluid pump: Determine (i) that the operating parameters of the APR are not compatible with the fluid pump, or (ii) that the implied order type is not compatible with the active infusion type of the fluid pump; And In response to determining that the operating parameters of the APR are not compatible with the fluid pump, display a first notification at a display device associated with the infusion device, the first notification indicating (i) that the APR is rejected and (ii) that the operating parameters of the APR are not compatible with the fluid pump; Or In response to determining that the implied order type is not compatible with the active infusion type of the fluid pump, display a second notification at the display device, the second notification indicating (i) that the APR is rejected, (ii) that the implied order type is not compatible with the active infusion type of the infusion pump, and (iii) the active infusion type of the infusion pump.

11. A computer-implemented method for validating an APR, the method comprising: Receiving an APR from a device manager, the APR including (i) an indicated order type, (ii) an identifier of a fluid pump of an infusion device, (iii) operating parameters including a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters; Detect an active state of the fluid pump, the active state including (i) an idle state indicating that the fluid pump is not pumping fluid or (ii) an active state indicating that the fluid pump is pumping fluid; Determine an implied order type of the APR based at least in part on the detected active state, wherein the implied order type includes an initial order, a follow-up order, a modification order, a bolus order, or a secondary order; Determine whether the indicated order type is compatible with the implied order type and the fluid pump based at least in part on whether the indicated order type matches the implied order type; In response to determining that the indicated order type is compatible with the implied order type and the fluid pump, (i) send an acknowledgement message to the device manager, and (ii) program the fluid pump according to the operating parameters; and In response to determining that the indicated order type is not compatible with the implied order type or the fluid pump, (i) send a non-acknowledgement message and an error message to the device manager, and (ii) reject a command to automatically program the fluid pump according to the operating parameters.

12. The computer-implemented method according to claim 11, wherein, The operating parameters further include a requested dose unit, and determining the implied order type includes: In response to detecting that the active state of the fluid pump includes an idle state, determining that the implied order type includes the initial order; In response to detecting that the active state includes an active state, determine whether the requested fluid type matches the active fluid type being pumped by the fluid pump; In response to determining that the requested fluid type does not match the active fluid type, determining that the implied order type includes the secondary order; In response to determining that the requested fluid type matches the active fluid type, determine whether the requested dose unit matches the active dose unit of the fluid pump; In response to determining that the requested dose unit does not match the active dose unit, determining that the implied order type includes the bolus order; In response to determining that the requested dose unit matches the active dose unit, determine whether the operating parameters of the APR further include the requested VTBI; In response to determining that the operating parameters do not include the requested VTBI, determining that the implied order type includes the modification order; and In response to determining that the operating parameters include the requested VTBI, determining that the implied order type includes the follow-up order.

13. The computer-implemented method of claim 11, further comprising: In response to detecting that the active state includes an active state, determine an active infusion type of the fluid pump based at least in part on the active dose unit or the active fluid type, the active infusion type including fluid infusion, continuous infusion, or intermittent infusion; wherein determining whether the indicated order type is compatible with the implied order type and the fluid pump is further based on the active infusion type.

14. The computer-implemented method according to claim 13, wherein, Determining the active infusion type includes: Determine whether the active dose unit of the fluid pump includes an intermittent unit; In response to determining that the active dose unit includes the intermittent unit, determine that the active infusion type includes the intermittent infusion; In response to determining that the active dose unit does not include the intermittent unit: Determine whether the active dose unit consists of a volume unit; In response to determining that the active dose unit does not consist of the volume unit, determine that the active infusion type includes the continuous infusion; and In response to determining that the active dose unit consists of the volume unit, determine whether the active fluid pumped by the fluid pump is a drug, wherein when the active fluid is not a drug, the active infusion type includes the fluid infusion, and when the active fluid is a drug, the active infusion type includes the drug infusion.

15. The computer-implemented method according to claim 11, wherein, In response to determining that the implicit order type includes the initial order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: In response to determining that the indicated order type includes the initial order or the follow-up order, determine that the indicated order type is compatible with the implicit order type and the fluid pump; and In response to determining that the indicated order type includes the modification order, the bolus order or the secondary order, determine that the indicated order type is not compatible with the implicit order type or the fluid pump.

16. The computer-implemented method according to claim 13, wherein, In response to determining that the implicit order type includes the follow-up order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: In response to determining that the indicated order type includes the initial order or the follow-up order, determine that the indicated order type is compatible with the implicit order type and the fluid pump; and In response to determining that the indicated order type includes the modification order, the bolus order or the secondary order, determine that the indicated order type is not compatible with the implicit order type or the fluid pump.

17. The computer-implemented method according to claim 13, wherein, In response to determining that the order type includes the modification order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: In response to determining that the indicated order type includes the modification order, determine that the indicated order type is compatible with the implicit order type and the fluid pump; and In response to determining that the indicated order type includes the initial order, the follow-up order, the bolus order or the secondary order, determine that the indicated order type is not compatible with the implicit order type or the fluid pump.

18. The computer-implemented method according to claim 13, wherein, In response to determining that the implicit order type includes the bolus order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: In response to determining that the indicated order type includes the bolus order: Determine whether the fluid pump is configured to support the bolus order; In response to determining that the fluid pump is configured to support the bolus order, determine that the indicated order type is compatible with the implicit order type and the fluid pump; and In response to determining that the fluid pump is not configured to support the bolus order, determine that the indicated order type is not compatible with the implicit order type or the fluid pump; and In response to determining that the indicated order type includes the initial order, the follow-up order, the modification order or the secondary order, determine that the indicated order type is not compatible with the implicit order type or the fluid pump.

19. The computer-implemented method according to claim 13, wherein, In response to determining that the implicit order type includes the secondary order, determining whether the indicated order type is compatible with the implicit order type and the fluid pump includes: In response to determining that the indicated order type includes the secondary order: Determine whether the fluid pump is configured to support the secondary order; In response to determining that the fluid pump is configured to support the secondary order, determine that the indicated order type is compatible with the implicit order type and the fluid pump; and In response to determining that the fluid pump is not configured to support the secondary order, determine that the indicated order type is not compatible with the implicit order type or the fluid pump; and In response to determining that the indicated order type includes the initial order, the follow-up order, the modification order, or the bolus order, determine that the indicated order type is not compatible with the implicit order type.

20. A non-transitory computer-readable storage medium including instructions that, when executed by a processor of an electronic device, cause the electronic device to: Receive an APR from a device manager, the APR including (i) an indicated order type, (ii) an identifier of a fluid pump of an infusion device, (iii) operating parameters including a requested fluid type and a requested dose, and (iv) a command to automatically program the infusion device according to the operating parameters; Detect an active state of the fluid pump, the active state including (i) an idle state indicating that the fluid pump is not pumping fluid or (ii) an active state indicating that the fluid pump is pumping fluid; Determine an implicit order type of the APR based at least in part on the detected active state, wherein the implicit order type includes an initial order, a follow-up order, a modification order, a bolus order, or a secondary order; Determine whether the indicated order type is compatible with the implicit order type and the fluid pump based at least in part on whether the indicated order type matches the implicit order type; In response to determining that the indicated order type is compatible with the implicit order type and the fluid pump, (i) send an acknowledgement message to the device manager and (ii) program the fluid pump according to the operating parameters; and In response to determining that the indicated order type is not compatible with the implicit order type or the fluid pump, (i) send a non-acknowledgement message and an error message to the device manager and (ii) reject the command to automatically program the fluid pump according to the operating parameters.

Images