Apparatus, system, and method for supplementing automatic programming requests

Abstract

An infusion system includes an infusion device and electronic equipment. The electronic equipment is configured to receive an Automatic Programming Request (APR) including a fluid type, a disposable item type, and an infusion device identifier. The electronic equipment is also configured to determine, based on the APR, an alarm threshold for triggering an alarm on the infusion device or a flow rate for pumping a fluid of a specific type. Furthermore, the electronic equipment is configured to modify the APR to include the alarm threshold or the flow rate and then transmit the modified APR to the infusion device. The infusion device is configured to, upon receiving the modified APR, set an alarm to trigger at the alarm threshold, pump fluid at the specified flow rate, or acknowledge the alarm threshold or the flow rate via a user interface presented on a display associated with the infusion device.

Description

Technical Field

[0001] This disclosure generally relates to the automatic programming of infusion devices, and more specifically to requests for supplemental automatic programming. Background Technology

[0002] Many modern infusion devices are configured to receive an automated programming request (APR) to enable their automatic programming. An APR can include certain predetermined infusion parameters for the infusion device, such as the fluid type. Upon receiving an APR, the infusion device is automatically programmed according to the APR and can then be initialized with the infusion therapy based on the predetermined parameters associated with the APR, thereby minimizing manual input time and reducing the risk of incorrect parameter input.

[0003] While APR has its benefits, there is still room for improvement. Current APR technologies typically only include simple setup parameters and do not take into account most of the data available for medical devices in the healthcare system; clinicians remain responsible for setting up and monitoring safety and procedural limitations. Summary of the Invention

[0004] This disclosure relates to devices, systems, and methods for solving the aforementioned technical problems by supplementing and revising APRs based on various medical data. For example, an APR may be intercepted, supplemented, and then sent to the medical device for implementation before reaching it. The improved example implementations discussed herein include the following:

[0005] An infusion system includes an infusion device and a first electronic device. The first electronic device is configured to receive an Automatic Programming Response (APR) for automatically programming the infusion device according to a predetermined command from the second electronic device located remotely to the first electronic device. The received APR includes a programmed fluid type, a programmed disposable type, and a programmed infusion device identifier. The first electronic device is also configured to determine a recommended alarm threshold for triggering an alarm on the infusion device or a recommended flow rate for pumping fluid of the programmed fluid type based on the programmed fluid type, the programmed disposable type, and the programmed infusion device identifier. Furthermore, the first electronic device is configured to modify the received APR to include the recommended alarm threshold or the recommended flow rate. Additionally, the first electronic device is configured to transmit the APR to the infusion device. The infusion device is configured to receive the APR. The infusion device is also configured to: set an alarm to trigger at the recommended alarm threshold, pump fluid at the recommended flow rate, or confirm the recommended alarm threshold or recommended flow rate via a user interface presented on a display associated with the infusion device.

[0006] A computer-implemented method for supplementing an Automatic Programming Reception (APR) includes receiving, at a first electronic device and from a second electronic device remotely connected to the first electronic device, an APR for automatically programming an infusion device according to a predetermined command. The received APR includes a programmed fluid type, a programmed disposable type, and a programmed infusion device identifier. The method further includes determining, based on the programmed fluid type, the programmed disposable type, and the programmed infusion device identifier, a recommended alarm threshold for triggering an alarm on the infusion device or a recommended flow rate for pumping fluid of the programmed fluid type. Furthermore, the method includes modifying the received APR to include the recommended alarm threshold or the recommended flow rate. Additionally, the method includes transmitting the APR to the infusion device, wherein the infusion device is configured to receive the APR and set an alarm to trigger at the recommended alarm threshold, pump fluid at the recommended flow rate, or confirm the recommended alarm threshold or recommended flow rate via a user interface presented on a display associated with the infusion device.

[0007] A non-transitory computer-readable storage medium includes instructions that, when executed by a first electronic device, cause the first electronic device to perform operations. The operations include receiving an Automatic Programming Reception (APR) from a second electronic device remote from the first electronic device for automatically programming an infusion device according to predetermined commands. The APR includes a programmed fluid type, a programmed disposable type, and a programmed infusion device identifier. The operations also include determining a recommended alarm threshold for triggering an alarm on the infusion device or a recommended flow rate for pumping fluid of the programmed fluid type based on the programmed fluid type, the programmed disposable type, and the programmed infusion device identifier. Furthermore, the operations include modifying the received APR to include the recommended alarm threshold or the recommended flow rate. Additionally, the operations include transmitting the APR to the infusion device, wherein the infusion device is configured to receive the APR and set an alarm to trigger at the recommended alarm threshold, pump fluid at the recommended flow rate, or confirm the recommended alarm threshold or recommended flow rate via a user interface presented on a display associated with the infusion device.

[0008] It should be understood that other configurations of the present subject matter will become readily apparent to those skilled in the art from the following detailed description, in which various configurations of the present subject matter are illustrated and described. As will be appreciated, the present subject matter is capable of having other and different configurations and several details thereof can be modified in various other ways, all without departing from the scope of the present subject matter. Therefore, the accompanying drawings and detailed description should be considered illustrative in nature rather than limiting. Attached Figure Description

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

[0010] Figure 1A and Figure 1B An example of a patient care system according to various aspects of the technology of this subject is depicted, the patient care system including an infusion pump mounted to a control unit.

[0011] Figure 2 An example institutional patient care system of a healthcare organization is depicted based on various aspects of the technology in this subject matter.

[0012] Figure 3 An example system for automatically programming medical devices is described, based on various aspects of the technology in this subject matter.

[0013] Figure 4 Example data that can be used to supplement APR and example supplementary parameters that can be added to APR are described according to various aspects of the technology in this subject.

[0014] Figure 5 Example sequence diagrams of supplemental APR-based automated programming infusion devices are depicted according to various aspects of the technology in this subject matter.

[0015] Figure 6 Example processes for supplementing APR are described based on various aspects of the technology in this subject.

[0016] Figure 7 It is a conceptual diagram depicting an example electronic system for supplementing APR, based on various aspects of the technology of this subject. Detailed Implementation

[0017] Reference will now be made to embodiments, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following description to provide an understanding of the various described embodiments. However, it will be apparent to those skilled in the art that the various described embodiments can be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail to avoid unnecessarily obscuring aspects of the embodiments.

[0018] This disclosure provides various improvements to modern APR technology. These improvements primarily involve modifying the APR, for example, by supplementing the APR with additional or alternative parameters. Modifications can occur before the APR is sent to the infusion device for programming. Alternatively, the infusion device can receive the APR and then modify it itself or send the APR to another device for modification.

[0019] In addition to the parameters included in the APR, data used to modify the APR may include information from the electronic medical record (EMR) (e.g., for the patient specified in the APR), such as physiological data or medical history data. Data used to supplement the APR may also include safety or procedural limitations (e.g., for parameters specified in the APR), such as maximum or minimum limits for a given fluid (e.g., maximum volume, maximum infusion time, or minimum flow rate). Furthermore, this data may include performance data (e.g., for a medical device or medical instrument specified in the APR), such as flow resolution data for the infusion pump. As used herein, “flow resolution” corresponds to the minimum volume of fluid the infusion pump is capable of pumping (e.g., quantified as a bolus per milliliter).

[0020] Supplementing an APR can include replacing parameters with new ones or adding alternative parameters to the APR. For example, an APR could be supplemented with recommended fluid type, flow rate, volume, alarm threshold, etc. As another example, an APR for an infusion pump could be supplemented to include recommendations regarding the optimal syringe type (e.g., size or brand). For a specific prescription, optimal syringe parameters could be sent for a specific flow rate and drug combination. As yet another example, an APR for a large-volume pump could be supplemented to include the optimal delivery device (e.g., diameter or brand). Optimal motor parameters could also be added to the APR for a specific prescription. Additional examples of APR supplementation are discussed below.

[0021] Upon receiving a supplemental APR, the medical device can automatically incorporate additional or alternative parameters. However, in some implementations, the medical device may first confirm the parameters with the user. For example, if the medical device includes a default alarm threshold and the APR includes a recommended alarm threshold (or adjustments thereof), the medical device may confirm the alarm threshold change with the user before making the change. As another example, the medical device may confirm the parameter after determining that the difference between the parameter and the default parameter is sufficiently significant to warrant confirmation of the new parameter.

[0022] Figure 1A and Figure 1B An example of a patient care system according to various aspects of the technology of this subject is depicted, the patient care system including an infusion pump mounted to a control unit. Figure 1A The patient care system 100 shown includes four infusion pumps 130-133, each of which is operatively engaged with a corresponding drug delivery device 120-123 (e.g., silicone tubing). The drug delivery device 120-123 connects the infusion pumps 130-133 to fluid supply units 110-113, which are inverted and suspended above the infusion pumps 130-133. The fluid supply units 110-113 are... Figure 1A They are depicted as bottles, but they can also take other forms (e.g., bags). Both the fluid supply 110-113 and the patient care device 102 are mounted to the roller holder 108.

[0023] Fluid supplies 110-113 and their orientation within the care area (e.g., installation location, installation height, installation type) can generate one or more interaction records. Interaction records for the device can be generated, for example, in part by detecting a scannable code associated with the device or by detecting the physical structure of the device on which identification information is encoded prior to use.

[0024] like Figure 1A As shown, each drug delivery device 120-123 is connected between a corresponding fluid dispenser 110-113 and the patient 106, so that the patient 106 can receive fluid from any or all of the fluid dispensers 110-113. Each of the drug delivery devices 120-123 can be actively identified (e.g., by a clinician scan) or passively identified (e.g., by wireless or optical detection). Typically, medical drug delivery devices have a higher... Figure 1A More components are shown. Many have check valves, drip chambers, valve ports, connectors, and other devices well known to those skilled in the art. These other devices are not included in the drawings to maintain clarity.

[0025] In the depicted example, individual infusion pumps 130-133 are used to infuse each of the corresponding fluids from fluid dispensers 110-113 into patient 106. Infusion pumps 130-133 are flow control devices that act on the corresponding tubing or fluid conduit of the respective drug delivery device 120-123 to move fluid from fluid dispenser 110-113, through the conduit, and to the patient. Because individual infusion pumps 130-133 are used, each of the infusion pumps 130-133 can be independently set to the required pumping or operating parameters to pump a specific medical fluid from the corresponding fluid dispenser 110-113 to the patient at a specific rate prescribed by the clinician for that fluid.

[0026] Figure 1B Depicting Figure 1A This is a portion of the patient care device 102 shown. The illustrated patient care device 102 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 [link to documentation]). Figure 1A ). Figure 1BThe display and controls for each of the infusion pumps 131 and 132 are also shown, such as display 124 and controls 126A-D for infusion pump 132.

[0027] Each of infusion pumps 130-133 may include a door and a handle. For example, infusion pump 132 includes a door 128 and a handle 134. The handle 134 is operated to lock the door 128 in a closed position during operation. The 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 the door 128 is open, drug delivery device 122 can be connected to infusion pump 132. When the door 128 is closed, drug delivery device 122 is brought into operative engagement with the pumping mechanism, upstream and downstream pressure sensors, and / or other instruments of infusion pump 132.

[0028] Infusion pumps 130-133 may also include displays. For example, in the depicted embodiments, the display 124 (e.g., an LED display) of infusion pump 132 is located in a plan view on door 128 and can be used to visually convey information about infusion pump 132. For example, display 124 may convey alarm indications (e.g., alarm messages). Furthermore, control keys 126A-D allow for programming and control of 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 audio alarm instruments in the form of speakers.

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

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

[0031] The control unit 104 may also include a communication system through which the control unit 104 can communicate with external devices (such as medical facility servers), handheld communication devices, portable computers, or other information devices that clinicians may have for transmitting information or downloading drug databases to the control unit 104.

[0032] The communication module can be used to transmit access and interaction information to clinicians encountering control unit 104 and coupled devices (such as infusion pumps 130-133 or barcode scanners). The communication system may include radio frequency (RF) systems, optical systems (such as infrared), and bluetooth. TM Or one or more of other wired or wireless systems. Barcode scanners and communication systems may alternatively be included integrated with infusion pumps 130-133, such as without the use of control unit 104, or in addition to control unit 104. Therefore, information input devices do not require hardwired connection to the medical device, and information can be transmitted wirelessly. Furthermore, other types of modules may be connected to infusion pumps 130-133 or control unit 104, such as infusion pump modules, patient-controlled analgesia modules, end-tidal CO2 monitoring modules, pulse oximeter monitoring modules, or the like.

[0033] Figure 2 Example institutional patient care systems 200 for healthcare organizations are depicted according to various aspects of the technology in this subject matter. Figure 2 In the middle, patient care equipment 202 (e.g., Figure 1A and Figure 1B The patient care device 102 is connected to the internal healthcare network 236. The term "patient care device" (PCD) is used interchangeably with the term "patient care unit" (PCU), both of which can include various assistive medical devices, such as infusion pumps (e.g., Figure 1A The infusion pumps 130-133), vital sign monitors, medication dispensing devices (e.g., cabinets, cases), medication preparation devices, automated dispensing devices, modules coupled to one of the aforementioned medical devices (e.g., injection pump modules coupled to the infusion pump), or other similar devices. Each element of the patient care device 202 is connected to an 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).

[0034] In some implementations, the internal healthcare network 236 also includes computer systems located in various departments throughout the hospital or healthcare center. For example, the internal healthcare network 236 may optionally include computer systems associated with admissions departments, billing departments, biomedical engineering departments, clinical laboratories, central supply departments, one or more unit station computers, and / or medical decision support systems. As further described below, the internal healthcare network 236 may include discrete subnetworks. In the depicted example, the internal healthcare network 236 includes a device network 238 through which patient care devices 202 and other devices can communicate under normal operating conditions.

[0035] The institutional patient care system 200 may also include a separate information system server 242 (e.g., a health information system (HIS) server). Furthermore, although the information system server 242 is shown as a separate server, its functionality and programming can be integrated into another computer. The institutional patient care system 200 may also include device terminals 240 for connecting to and communicating with the information system server 242. Device terminals 240 may include personal computers, personal data assistants, mobile devices (such as laptops, tablets, augmented reality devices, or smartphones) configured with software for communicating with the information system server 242 via the internal healthcare network 236.

[0036] Patient care device 202 includes a system for providing patient care and may include or incorporate a pump (e.g., Figure 1A Infusion pumps 130-133), physiological monitors (such as heart rate, blood pressure, ECG, EEG, pulse oximeter and other patient monitors), therapeutic devices, and other drug delivery devices may be used in accordance with the teachings described herein.

[0037] 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 known as the interface unit 204, is connected to one or more functional modules 206-209 (e.g., Figure 1AThe infusion pumps 130-133 are described above. The control unit 204 includes a central processing unit (CPU) 218 ​​(e.g., random access memory (RAM) 222) connected to a memory, and one or more interface devices, such as a user interface device 230, an encoded data input device 232, a network connection 220, and an auxiliary interface 226 for communicating with additional modules or devices. Although not strictly necessary, the control unit 204 also includes a primary non-volatile storage unit 228 for storing software data, such as a hard disk drive or non-volatile flash memory. Furthermore, the control unit 204 may include one or more internal buses 224 for interconnecting the aforementioned components.

[0038] In various embodiments, the user interface device 230 is a touchscreen for displaying information to a 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 means for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen.

[0039] Data input device 232 may be a barcode reader capable of scanning and interpreting data printed in barcode format. Additionally or alternatively, data input device 232 may be any device for inputting coded data into a computer, such as one or more devices for reading magnetic stripes, radio frequency identification (RFID) devices, wherein digital data encoded in an RFID tag or smart tag (defined below) is captured by data input device 232 via radio waves, a PCMCIA smart card, an RFID card, a memory stick, a CD, a DVD, or any other analog or digital storage medium. Other examples of data input device 232 include voice-activated or recognition devices or portable personal data assistants (PDAs).

[0040] Depending on the type of interface device used, user interface device 230 and data input device 232 can be the same device. Although Figure 2 The diagram shows a data input device 232 located within the control unit 204, but it will be appreciated that the data input device 232 may be located outside the control unit 204 (e.g., at device terminal 240).

[0041] Auxiliary interface 226 may be an RS-232 communication interface; however, without departing from the subject matter, any other means for communicating with peripheral devices (such as printers, patient monitors, infusion pumps, or other medical devices) may be used. Furthermore, data input device 232 may be a separate functional module (e.g., functional modules 206-207) and configured to communicate with control unit 204 or any other system on the network using suitable programming and communication protocols.

[0042] Network connection 220 can be a wired or 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] Functional modules 206-209 are devices for providing care to patients or for monitoring patient conditions (e.g., Figure 1A Infusion pump 130-133). For example... Figure 2 As shown, at least one of functional modules 206-209 can be an intravenous infusion pump, such as one used for delivering medications or other fluids to a patient. For the purposes of this discussion, functional module 206 is an infusion pump module. Each of 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, or the like. Furthermore, functional modules 206-209 can be printers, scanners, barcode readers, near-field communication readers, RFID readers, or any other peripheral input, output, or input / output device.

[0044] Each functional module 206-209 communicates directly or indirectly with the control unit 204, providing overall monitoring and control of the patient care equipment 202. Furthermore, as... Figure 2 As shown, functional modules 206-209 can be physically and electronically connected in a serial manner to one or both ends of control unit 204.

[0045] However, it should be recognized that other means can be utilized to connect functional modules 206-209 to control unit 204 without departing from the subject matter. It should also be understood that devices such as pumps or patient monitoring devices, which provide sufficient programmability and connectivity, can operate as stand-alone devices and can communicate directly with the internal healthcare network 236 without connection via control unit 204 or a separate interface unit. As described above, additional medical devices or peripheral devices can be connected to patient care equipment 202 via one or more auxiliary interfaces 226.

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

[0047] While each of the functional modules 206-209 can operate independently to a certain extent, 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 modules 206-209.

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

[0049] Data from various data sources can be converted into network-compatible data using existing technologies, and information movement between medical devices and networks can be achieved through various devices. For example, patient care device 202 and 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 be achieved via network connection 220 (e.g., ...). Figure 2 (As shown) or via RS232 link, MIB system, RF link (such as BLUETOOTH), IR link, WLAN, digital cable system, telephone modem or other wired or wireless communication device.

[0050] Manual interaction between patient care device 202 and internal healthcare network 236 involves the intermittent or periodic physical transfer of data between systems using, for example, user interface device 230, coded data input device 232, barcodes, computer disks, portable data assistants, memory cards, or any other media used for data storage. Communication devices in all aspects are bidirectional and can access data from as many distributed data sources as possible. Decision-making can occur in multiple locations within internal healthcare network 236. For example, rather than in a restricted manner, decisions can be made within information system server 242, decision support, remote data servers, hospital departments or unit stations, or the patient care device 202 itself.

[0051] According to various implementations, the information system server 242 includes a prescription set and / or a pharmacy information system. The pharmacy information system enables a more secure physician medication ordering process. A pharmacy website (e.g., provided by the information system server 242) can provide physicians with a list of available medications from which they can select.

[0052] Pharmacy websites may contain drug libraries with a list of available medications, but they may also include and present the names of medications to doctors in relation to recommended dosages and dosage limits established or adopted by the healthcare facility. In this case, doctors should be able to simply select items from a computer screen instead of manually typing in the drug name and dosing number (such as infusion rate, time, etc.) associated with medication administration, which should result in more accurate medication handling.

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

[0054] The drug library contains drug information such as drug name, concentration, diluent volume, strength, minimum or maximum infusion parameters, and other parameters. Establishing these parameters, along with those for out-of-prescription orders, via the pharmacy's system server helps maintain consistency across the healthcare environment and ensures that orders are understandable and executed as intended by other devices within the pharmacy's system server (e.g., patient care device 202).

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

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

[0057] The memory of control unit 204 (e.g., RAM 222 or main nonvolatile memory unit 228) may contain a drug library, event logs, and / or infusion pump configuration settings, such as configuration files used in a specific practice area (e.g., ICU, PED, etc.). The memory of control unit 204 may be electronically loadable memory, such as nonvolatile memory (e.g., EEPROM). A drug library stored on the pump, which illustratively contains information such as drug name, delivery parameter value ranges (e.g., appropriate concentration), dose units, and dose limits, can be used to perform drug-based infusions in a clinical setting.

[0058] The drug library stored in the pump memory may include clinical prescription settings, such as limits (also referred to herein as “guardrails”) set by the clinical institution for each drug in the library. These 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, dose limits may vary based on a patient’s weight or body surface area (“BSA”), the unit or ward of the healthcare institution using the drug (e.g., neonatal intensive care unit, intensive care unit, etc.), and / or other factors. Limitations may also include maximum and minimum flow rates, infusion time, or other infusion parameters for a given drug. Like dose limits, these limits may also vary based on a patient’s weight or other physiological parameters. In some embodiments, the drug library and / or guardrails are stored elsewhere, such as on device terminal 240, external database 244, or another device connected to internal healthcare network 236.

[0059] An alarm may be triggered if a nurse sets the pump to operate outside the limits for a particular medication. In some cases, the alarm may be overridden, while in others it may not. Healthcare facilities can establish “soft” limits for each medication, which can be ignored by nurses, and “hard” limits, which cannot be ignored by nurses. In either case of exceeding the limit, the pump data log or other processor communicating with the infusion pump can record each such limit event for subsequent analysis in cases where the attempted setting is above the maximum dose or below the minimum dose.

[0060] The pump may also include a display for a user interface, which includes 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 associated set of drug delivery parameters includes information selected from a set of parameters, including drug concentration, drug delivery rate, drug dosage, and pill 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.

[0061] In the case of an infusion pump, the electronically loaded drug library may include a list of syringe manufacturers' names identifying syringes that can be used with the drug infusion pump, and the drug infusion pump provides the user with a list of syringe manufacturers' names from which the user can select when the electronically loaded drug library is in the pump. The loaded drug library may also include a list of syringe sizes identifying 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 can be turned on or off, and when the electronically loaded drug library is in the pump, the pump only provides the user with the features that are turned on from that set.

[0062] Figure 3 An example system 300 for automatically programming medical devices (e.g., using supplementary APR) according to various aspects of the technology of this subject is depicted. A hospital EMR server (e.g., Figure 2 Information system server 242) and medical devices (e.g., Figures 1A-1B Patient care equipment 102 or Figure 2Interoperability between the patient care devices (202) enables pre-filling of infusion parameters. Pre-filling of infusion parameters reduces the number of programming screens and buttons required for manually programming the pump. The implementation of interoperability does not preclude clinicians from manually programming the infusion devices. Manual programming may be necessary if any component of the interface system malfunctions.

[0063] While the characteristics described using an EMR server can be referenced, these characteristics are applicable to the automated programming of medical devices using similar hospital information systems, such as Patient Data Management Systems (PDMS). Furthermore, although an infusion pump can be used as an example medical device to describe these characteristics, they are applicable to the automated programming of other medical devices that use barcode association, such as patient monitors, patient association management systems, or alarm management systems.

[0064] Drug prescription set 304 determines which drugs are available in hospital networks (e.g., Figure 2 Distribution within the internal healthcare network (236). A hospital committee may be established to determine how medications in this prescription set will be used in infusion devices (310, e.g., Figure 1A and Figure 1B Patient care equipment 102 or Figure 2 Patient care equipment 202). Configuration definitions (e.g., agreed upon by hospital units such as ICU, NICU, pediatrics, oncology, surgery, etc.) and drug and typical infusion protocols are established in the medical device drug library.

[0065] In addition, restrictions or "guardrail" conditions may be defined in the drug library. Once defined, the configuration, including the drug library, can be published. The infusion equipment at the facility can then be updated by transferring the configuration database to some or all pumps in the facility. Corresponding updates to the drug prescription set 304 can be shared with other hospital systems, such as a pharmacy ordering system or an EMR system 302, which can use the prescription set information to generate patient orders to deliver specific medications to specific patients (320).

[0066] In the clinical field, clinicians can use scanners associated with medical devices (such as infusion devices 310) to scan medical items, such as infusion packs. For example, barcode readers (or other data input devices) are used to scan coded medication labels, patient coded ID bands and caregiver ID badges, as well as optional supplemental prescription information or medical device configuration instructions (including configuration database IDs) printed on labels or accompanying medical orders.

[0067] The reader / scanner does not need to be integrated with the medical device. The scanner can be part of a separate device, such as the EMR terminal 306 (e.g., Figure 2The device terminal 240), which is connected to the same network as the infusion device 310 (e.g., device terminal 240), ... which is connected to the same network as the infusion device 310 (e.g., device terminal 240), is connected to the same network as the infusion device 310. Figure 2 The device network 238 is configured with software to function throughout the entire workflow involving the infusion device 320.

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

[0069] In the depicted embodiment, the 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 an APR (Application Not Receiving) along with the device identifier (326) (also referred to as the "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, as identified by the EMR system 302, is available, and if available, 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 may also supplement the APR before sending it to the infusion device 310, as referenced below. Figure 5 To be discussed in more detail.

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

[0071] Figure 4Example data that can be used to supplement APRs according to various aspects of the techniques described herein, as well as example supplementary parameters that can be added to them, are depicted. Supplementing APRs can further simplify treatment setup by including additional parameters in the APR that clinicians may not be aware of or otherwise need to manually enter. The APR supplementation process can utilize data from various sources, such as parameters contained in the APR itself, EMR data, guardrails, or data specific to the medical device to which the therapy will be administered.

[0072] In the illustrated embodiment, electronic device 410 (e.g. Figure 1A and Figure 1B Patient care equipment 102, Figure 2 The patient care device 202, device terminal 240, or device connected to the internal healthcare network 236, or Figure 3 The infusion device 310 uses parameters from APR 402 to generate a supplemental APR 412. APR parameters may include, for example, fluid type (e.g., drug identifier), flow rate of the pumped fluid, volume to be infused (VTBI) of the fluid, type of disposable item (e.g., type of infusion device or type of syringe), infusion device identifier, and / or patient identifier.

[0073] In addition to the data from APR 402, electronic device 410 can also use data from EMR 404 to generate a supplementary APR 412 (also referred to herein as a “modified APR”). For example, electronic device 410 can use the patient identifier from APR 402 from the EMR server (e.g., Figure 3 The EMR system 302 obtains EMR 404 (or information therein). EMR 404 may include physiological information about the identified patient, such as the patient's age, height, or weight. EMR 404 may also include information about any diseases the patient has (e.g., diabetes, HIV, COVID-19) or the patient's medical history. EMR 404 may include A1C test results, blood glucose levels, current patient condition (e.g., hemorrhagic shock or heart failure), etc.

[0074] Supplementing APR 402 may include, for example, recommending an alternative fluid if EMR 404 indicates that the patient is allergic to the fluid type identified in APR 402. Or, if EMR 404 indicates that the patient has a specific medical condition in which over-infusion would prove particularly harmful, the electronic device 410 may slightly adjust the flow rate to avoid over-infusion.

[0075] Furthermore, electronic device 410 can identify and use guardrail 406 to supplement APR 402. Based on the fluid type identified in APR 402, electronic device 410 can determine a guardrail for a given fluid type. If APR 402 includes, for example, a flow rate, and guardrail 406 for the fluid type indicates that the flow rate would be unsafe for the application of that fluid, then electronic device 410 can adjust the flow rate (e.g., reduce the flow rate) until guardrail 406 is satisfied. The adjusted flow rate can then be included in the supplementary APR 412 as a replacement for the flow rate originally included in APR 402, or as a suggested replacement.

[0076] Additionally, electronic device 410 can use device data 408 to generate a supplemental APR 412. Device data 408 may include, for example, alarm thresholds (e.g., occlusion or in-line air alarm thresholds), performance data (e.g., regarding flow rate accuracy), or the dimensions of the device or instrument to be used for administering therapy according to the APR. Device data may also include operating conditions, such as the head height of the fluid source relative to the pumping mechanism of the infusion device (e.g., a drive head or peristaltic pumping mechanism), or the patient height relative to said pumping mechanism. If the flow rate, fluid type, or occlusion alarm threshold together indicate that administering therapy according to the APR is likely (e.g., greater than 50%, 75%, 90%) to not properly trigger an occlusion alarm of the medical device to be used for administering therapy, then electronic device 410 may provide a recommended flow rate, fluid type, or occlusion alarm threshold in the supplemental APR 412. The medical device can then determine whether to use the recommended parameters or the original parameters for administering therapy (e.g., after confirming changes with a clinician).

[0077] In some implementations, the supplementary APR 412 generated by the electronic device 410 includes each of the parameters in the original APR 402, as well as additional, recommended parameters as potential alternatives to the original parameters. However, in some implementations, parameters from the original APR 402 are replaced in the supplementary APR 412. For example, a flow rate deemed unsafe (e.g., a guardrail based on a given fluid type) may be replaced by another flow rate in the supplementary APR 412.

[0078] Figure 5 Example sequence diagram 500 depicts various aspects of the technology of this subject matter for a complementary APR-based automated programming medical device. For illustrative purposes, see reference [link to diagram 500]. Figures 1A to 4 And the components and / or processes described therein to describe the various interactions of sequence diagram 500.

[0079] As mentioned above Figure 3 As mentioned above, it can be done in EMR terminal 504 (e.g., Figure 2 Device terminal 240 or Figure 3 The medical device 502 (e.g., EMR terminal 306) is scanned on the EMR terminal 306. Figure 1A and Figure 1B Patient care equipment 102 Figure 2 Patient care equipment 202 or Figure 3 The identifier (e.g., barcode) of the infusion device 310 in the system. In the illustrated embodiment, this initiates a process in which information related to the medical device is automatically sent to the EMR server 506 (e.g., Figure 3 (EMR system 302). EMR server 506 performs certain actions related to medical device 502 and ultimately results in the transmission of an APR to medical device 502, which is then configured according to the APR. In some embodiments, the identifier of medical device 502 is scanned from a barcode attached to the device in conjunction with parameters input to EMR terminal 504 to select and / or generate an APR.

[0080] Hospital systems implementing this subject matter technology may include one or more medical devices 502 connected to the connection gateway 508 (e.g., Figure 1A and Figure 1B Patient care equipment 102 Figure 2 Patient care equipment 202, or Figure 3 The infusion device 310), EMR terminal 504, and EMR server 506 (incl., for example, one or more PDMs). In some embodiments, connection gateway 508 may include one or more computing devices, such as one or more servers other than EMR server 506. In some embodiments, connection gateway 508 may be provided by... Figure 3 The coordination engine 308 implementation may be interchangeable. In some implementations, the EMR server 506 and the connection gateway 508 can coexist as a single server or a group of servers. Furthermore, Figure 2 Information system server 242 can represent EMR server 506 and / or connection gateway 508.

[0081] exist Figure 5 In the example depicted, EMR terminal 504 sends an APR request (511) to EMR server 506. The APR request can be initiated by a clinician, for example, by the clinician providing EMR terminal 504 with a patient identifier, fluid type (e.g., drug identifier), device identifier (e.g., identifying medical device 502), prescription identifier, and / or other identifying information used to request that the APR be sent to medical device 502. For the clinician's convenience, and as discussed above, some of this information can be provided to EMR terminal 504 by scanning a barcode (e.g., associated with a patient, fluid, or medical device 502) (see also...). Figure 3(Step 322). The identification information is transmitted to the EMR server 506 in the request for automatic programming of the medical device 502. Upon receiving the APR request, the EMR server 506 forwards it to the connection gateway 508 (512). The APR request sent by the EMR server 506 to the connection gateway 508 includes APR information, such as the aforementioned APR parameters provided by the clinician to the EMR terminal 504. The APR information may also include an APR template (e.g., specific to the medical device 502) or an EMR for the identified patient.

[0082] Upon receiving an APR request (and the APR information sent with it), the connection gateway 508 prepares the APR using the received APR information (e.g., Figure 4 The APR (402) (513) may include, for example, a patient identifier, fluid type, device identifier, and / or any other information included in the APR request. The APR may also include guardrails related to the fluid type or EMR data used for the identified patient. After generating the APR, the connection gateway 508 retrieves, requests, or determines additional data to supplement the APR. For example, the connection gateway 508 may request EMR data from the EMR server 506 (e.g., EMR). Figure 4 EMR 404)(514)(e.g., if the EMR is not configured to request an APR request). As another example, connectivity gateway 508 can request or retrieve data about medical device 502, for example, from medical device 502, the internal memory of connectivity gateway 508, or from another device (e.g., Figure 2 Database 244). In some implementations, APR preparation (see 513) occurs at EMR server 506, and the resulting APR is sent along with the APR request (see 512). In this way, if the APR is prepared in advance, the connection gateway may not need to prepare the APR.

[0083] The connection gateway 508 then supplements the APR (516) with additional data. For example, the connection gateway 508 may replace the parameters of the APR with new parameters. Alternatively, the connection gateway 508 may include alternative parameters in the APR and allow the medical device 502 or its user to determine which parameters to use for the infusion therapy. After supplementing the APR, the connection gateway 508 then sends the supplemented APR to the medical device 502 for implementation.

[0084] Once the medical device 502 has received the supplemental APR, it then programs itself according to the parameters included therein (518). If the supplemental APR includes multiple options for a given parameter, the medical device 502 can first determine which of the parameters to use for programming. In doing so, the medical device 502 can, for example, compare the alternative parameter with the original parameter. If the difference between the two parameters is significant (e.g., greater than 2%, 5%, 10%, or 25%), the medical device 502 can reject the alternative parameter. Similarly, if the difference between the two parameters is negligible (e.g., less than 5% or 10%), the medical device 502 can automatically accept the alternative parameter to replace the original parameter. Alternatively, the medical device 502 can present each of the parameters to a clinician for the clinician to decide which parameter will be used for infusion therapy.

[0085] In some implementations, and regardless of whether the supplemental APR includes multiple options for a given parameter, after the medical device 502 has been configured according to the supplemental APR, the medical device 502 can then confirm the automatically entered parameters with the clinician.

[0086] In some implementations, the connection gateway 508 sends an APR to the medical device 502 (see 517) without supplementing the APR. In this way, the medical device 502 can supplement the APR itself, for example, based on an EMR received with the APR or requested from the EMR server 506. Alternatively or additionally, the medical device 502 can send the APR to another device for supplementation. In either instance, the medical device 502 or another device can perform the operations discussed herein (see, for example, 516) to supplement the APR.

[0087] Figure 6 Example process 600 for supplementing APR according to various aspects of the subject matter is depicted. For illustrative purposes, this disclosure refers to Figure 1- Figure 5 The document describes blocks of example process 600, including the components and / or processes described therein. One or more blocks of process 600 may be implemented by one or more computing devices described herein, such as... Figure 1A and Figure 1B Patient care equipment 102 Figure 2 Patient care equipment 202 Figure 3 Infusion equipment 310, Figure 4 Electronic devices 401 and / or Figure 5 Medical device 502 or connection gateway 508.

[0088] In some implementations, one or more blocks may be implemented based on one or more ML algorithms. In some implementations, one or more blocks may be separate from other blocks and implemented by one or more different processors or devices. Furthermore, for illustrative purposes, the blocks of process 600 are described as occurring serially or linearly. However, multiple blocks of process 600 may occur in parallel. Moreover, it is not necessary to execute the blocks of process 600 in the order shown, nor is it necessary to execute one or more blocks of process 600.

[0089] In the depicted example process 600, the processor of the first electronic device (e.g., Figure 5 The connection gateway 508 receives APR (e.g.) Figure 4 APR 402 (602). The APR in the depicted example is a request to automatically program an infusion device according to a predetermined command. In this respect, the received APR may include one or more parameters, such as the type of fluid to be programmed, the type of disposable item to be programmed, and / or the infusion device to be programmed (e.g., Figure 1A and Figure 1B Patient care equipment 102 Figure 2 Patient care equipment 202, or Figure 3 The infusion device 310) identifier. However, many embodiments discussed regarding process 600 are also related to embodiments involving APRs with additional or other parameters. For example, the received APR may also or alternatively include a programmed flow rate, a programmed VTBI, a patient identifier, an EMR (e.g., for the identified patient), or a guardrail (e.g., for the fluid type). The processor can be accessed from a second electronic device (e.g., remote from the first electronic device) Figure 5 The EMR server (506) receives the APR.

[0090] Upon receiving an APR, the processor can determine adjustment or alternative parameters for the APR. In example process 600, the processor determines a recommended alarm threshold for triggering an alarm on the infusion device or a recommended flow rate for pumping fluid of the programmed fluid type based on the programmed fluid type, the programmed disposable item type, and the programmed infusion device identifier (604).

[0091] As an example, an infusion device may include an occlusion alarm or an air-in-the-line (AIL) alarm. Therefore, the processor can determine a recommended threshold for triggering an occlusion alarm or AIL alarm in the infusion device. As another example, given specific parameters, a certain flow rate may be desired for pumping fluid into the patient. For example, a flow rate or flow rate range may be desired because it increases the efficacy of the infusion therapy, reduces the likelihood of triggering an alarm, or increases the expected flow rate accuracy.

[0092] Regarding alarms and thresholds, infusion devices can track various parameters to determine whether an alarm condition (e.g., occlusion, AIL) has occurred. For example, to estimate occlusion, the infusion device can track the delivery device (e.g., Figure 1A The pressure in the infusion device (120) is monitored. If the pressure meets or exceeds the occlusion threshold, the infusion device will assume an occlusion exists in the infusion device. However, the parameters used to determine the alarm condition can be influenced by various aspects of the infusion therapy, many of which can be known in advance, such as the viscosity of the infused fluid, the type of disposable supplies used (e.g., syringe or infusion device size), the fluid flow rate, and so on. Therefore, the processor can check the APR parameters and other data to determine whether the alarm threshold should be adjusted to avoid the infusion device failing to trigger the appropriate alarm.

[0093] As used herein, a “not properly triggered” alarm includes triggering an alarm when no alarm condition exists, as well as failing to trigger an alarm when the alarm condition exists. For example, an infusion unit that does not trigger a blockage alarm during a downstream blockage constitutes a not properly triggered blockage alarm. Similarly, an infusion unit that does trigger its blockage alarm when there is no blockage also constitutes a not properly triggered blockage alarm.

[0094] In some implementations, the processor determines a recommended alarm threshold, which includes a recommended occlusion alarm threshold for triggering an occlusion alarm on the infusion device. In this way, determining the recommended alarm threshold may include determining (e.g., based on a programmed infusion device identifier) ​​a default occlusion alarm threshold for the infusion device. The infusion device may be configured to trigger an occlusion alarm when a piping device (e.g., a line device coupled to the infusion device) Figure 1A A closure alarm is triggered when the pressure in the delivery device 120 meets a default closure alarm threshold. Determining the recommended alarm threshold may further include determining (e.g., based on a programmed fluid type, a programmed disposable item type, and / or a programmed flow rate) the expected pressure in the line device during operation of the infusion device (e.g., in the absence of closure). Furthermore, determining the recommended alarm threshold may include determining (e.g., based on the default closure alarm threshold and the expected pressure) that the infusion device is likely (e.g., greater than 50%, 75%, 90%) not to have correctly triggered the closure alarm. Additionally, determining the recommended alarm threshold may include determining a recommended closure alarm threshold (e.g., based on the expected pressure) in response to determining that the infusion device is likely not to have correctly triggered the closure alarm.

[0095] In some implementations, the processor determines a recommended alarm threshold, which includes a recommended AIL alarm threshold for triggering an AIL alarm on the infusion device. In this way, determining the recommended alarm threshold may include determining (e.g., based on a programmed infusion device identifier) ​​a default AIL alarm threshold for the infusion device. The infusion device may be configured to trigger an AIL alarm on a tubing device coupled to the infusion device (e.g., a line device). Figure 1AAn AIL alarm is triggered when the amount of air (e.g., volume, number of air bubbles) in the delivery device 120 meets a default AIL alarm threshold. Determining the recommended alarm threshold may further include determining (e.g., based on programmed fluid type, programmed single-use type, and / or programmed flow rate) the expected amount of air in the tubing during operation of the infusion device (e.g., in the absence of occlusion or other conditions that would result in a large amount of air in the delivery device). Furthermore, determining the recommended alarm threshold may include determining (e.g., based on the default AIL alarm threshold and the expected air amount) that the infusion device is likely (e.g., greater than 50%, 75%, 90%) not to correctly trigger the AIL alarm. Additionally, determining the recommended alarm threshold may include determining a recommended AIL alarm threshold (e.g., based on the expected air amount) in response to determining that the infusion device is likely not to correctly trigger the AIL alarm.

[0096] As described above, the processor can also determine a recommended flow rate for the infusion device. This flow rate can be recommended based on guardrails for the programmed fluid type indicated in the APR, particularly if, for example, the programmed flow rate included in the APR is outside the safety or programmable limits for the programmed fluid type. Alternatively, the flow rate can be recommended based on the fluid's half-life, fluid expiration time, infusion device alarm threshold, fluid viscosity, or any other parameters discussed herein.

[0097] In some implementations, the APR further includes a programmed flow rate, and the processor determines the recommended flow rate. As an example, determining the recommended flow rate may include determining the viscosity of the fluid based on a programmed fluid type. Determining the flow rate may also include determining the characteristics of a disposable item (such as a syringe or the aforementioned delivery device) based on a programmed disposable item type (e.g., the inner diameter of the disposable item, the elasticity of the disposable item, or the material of the disposable item). Additionally, determining the flow rate may include determining (e.g., based on a programmed infusion device identifier) ​​a default alarm threshold for triggering an alarm on the infusion device. Furthermore, determining the flow rate may include determining (e.g., based on the programmed flow rate, fluid viscosity, disposable item characteristics, and / or the default alarm threshold) that pumping fluid at the programmed flow rate (e.g., via the infusion device) is likely (e.g., greater than 50%, 75%, 90%) to trigger an alarm. Moreover, determining the flow rate may include determining a recommended flow rate (e.g., based on fluid viscosity, disposable item characteristics, and the default alarm threshold), wherein pumping fluid at the recommended flow rate instead of the programmed flow rate (e.g., via the infusion device) is unlikely to trigger an alarm.

[0098] Returning to example procedure 600, the processor can modify the APR to include adjusted or alternative parameters. In the illustrated implementation, the processor modifies the APR to include a recommended alarm threshold or a recommended flow rate (606). Modifying the APR can include replacing a parameter in the APR with a recommended parameter (e.g., a recommended alarm threshold or recommended flow rate). For example, if the APR already includes a flow rate, it can be modified to replace the flow rate with a recommended flow rate. However, the APR can also be modified to include both the original parameter and a recommended alternative. For example, if the APR already includes a VTBI, it can be modified to include the recommended VTBI in addition to the programmed VTBI.

[0099] In addition, the processor transmits the APR to the infusion device (608). The infusion device is configured to receive the APR and set the alarm to trigger at a recommended alarm threshold, pump fluid at a recommended flow rate, or confirm the recommended alarm threshold or recommended flow rate via a user interface presented on a display associated with the infusion device. The infusion device can also be configured to adjust its operation based on other parameters received in the APR.

[0100] In some implementations, the APR also includes a patient identifier, and the processor provides the patient identifier to the EMR device (e.g., before determining the recommended flow rate). Figure 3 EMR system 302 or Figure 5 The EMR server 506) retrieves the EMR from the EMR device in response to providing a patient identifier to the EMR device (e.g., Figure 4 (EMR 404). EMR can include, for example, patient-specific physiological data. Therefore, determining the recommended flow rate can be further based on the physiological data from EMR.

[0101] For example, if physiological data indicates that a patient is allergic to a programmed fluid type, the processor can determine a recommended fluid type based on the programmed fluid type and the physiological data, where the physiological data does not indicate that the patient is allergic to the recommended fluid type. The recommended fluid type may have therapeutic properties similar to those of the fluid type (e.g., analgesic or antibiotic properties) to ensure appropriate treatment for the patient.

[0102] In some implementations, the processor determines a recommended flow rate. Before modifying the APR, the processor may also determine flow rate limits (e.g., guardrails) based on the programmed fluid type, where the flow rate limits include upper and lower limits for the fluid used to apply the programmed fluid type. Furthermore, the processor may adjust the recommended flow rate in response to determining that the recommended flow rate does not meet the flow rate limits until the flow rate limits are met. The processor may also determine limits for other parameters, such as VTBI. In this way, the processor may also adjust the VTBI if it does not meet the VTBI limit.

[0103] The processor can also determine alternative parameters based on various aspects of the programmed fluid type. For example, if the programmed fluid type has a specific half-life or expiration time that may affect the infusion therapy, the processor can recommend alternative fluid types, flow rates, or infusion devices. The half-life of the fluid can affect the efficacy of the infusion therapy if the fluid has a short half-life, a low flow rate, and / or poor flow resolution of the infusion pump. When an infusion pump with low flow resolution delivers fluid to the patient at a low flow rate, the pump may only deliver boluses of fluid every few minutes. If the fluid has a short half-life, most of the fluid may lose its effectiveness between boluses, thus reducing the efficacy of the infusion therapy. On the other hand, if the fluid expires before the end of the infusion therapy, the expiration time of the fluid can affect the efficacy of the infusion therapy. In either case, the APR can be adjusted to avoid situations such as those described above.

[0104] In some embodiments, the infusion device is further configured to administer infusion therapy according to an APR, which further includes a programmed flow rate and a programmed VTBI, and the processor performs operations before modifying the APR. These operations include determining the expiration time of the fluid (e.g., based on the programmed fluid type). The operations also include determining the duration of the infusion therapy (e.g., based on the programmed flow rate and programmed VTBI). Furthermore, the operation includes, in response to determining that the expiration time of the fluid is less than the duration of the infusion therapy, determining (e.g., based on the programmed fluid type, fluid expiration time, programmed flow rate, programmed VTBI, and / or duration of the infusion therapy): (i) a recommended flow rate, wherein the recommended flow rate is greater than the programmed flow rate, and administering the infusion therapy at the recommended flow rate instead of the programmed flow rate would result in the fluid expiration time being greater than or equal to the duration of the infusion therapy; (ii) an alternative VTBI, wherein the alternative VTBI is less than the programmed VTBI, and administering the infusion therapy using the alternative VTBI instead of the programmed VTBI would result in the fluid expiration time being greater than or equal to the duration of the infusion therapy, and the processor is further configured to modify the APR to include the alternative VTBI; or (iii) an alternative fluid, wherein the expiration time of the alternative fluid is greater than or equal to the duration of the infusion therapy, and the processor is further configured to modify the APR to include the alternative fluid.

[0105] In some embodiments, the infusion device is further configured to administer the infusion therapy according to an APR, the APR further including a programmed flow rate, and the processor performs operations before modifying the APR. The operations include determining the half-life of a fluid based on a programmed fluid type. The operations also include determining the flow resolution of the infusion device based on a programmed infusion device identifier, wherein the flow resolution corresponds to the minimum fluid volume that the infusion device can pump. Furthermore, the operations include determining the efficacy of the infusion therapy (e.g., based on the programmed flow rate, fluid half-life, and infusion device flow resolution). Additionally, the operations include, in response to determining that the efficacy of the infusion therapy does not meet an efficacy threshold (e.g., based on the programmed flow rate, fluid half-life, and infusion device flow resolution): (i) a recommended flow rate, wherein administering the infusion therapy at the recommended flow rate instead of the programmed flow rate would result in the efficacy of the infusion therapy meeting the efficacy threshold; or (ii) an alternative infusion device identifier, wherein administering the infusion therapy using an alternative infusion device instead of the infusion device would result in the efficacy of the infusion therapy meeting the efficacy threshold, and the processor is further configured to modify the APR to include the alternative infusion device identifier.

[0106] In some implementations, the infusion device includes an infusion pump, and the processor determines a recommended syringe constant (e.g., based on a recommended flow rate, a programmed fluid type, a programmed single-use item type, and / or a programmed infusion device identifier) ​​before delivering the APR to the infusion device. Furthermore, the infusion device is configured to convert the recommended flow rate into an operating speed based on the recommended syringe constant, and pumping fluid at the recommended flow rate includes operating the drive head of the infusion pump at the operating speed.

[0107] In some embodiments, the infusion device is further configured to compare a recommended alarm threshold with a default alarm threshold, or compare a recommended flow rate with a programmed flow rate, before setting an alarm, pumping fluid, or confirming a recommended alarm threshold or recommended flow rate. The infusion device may also be configured to set an alarm to trigger at the recommended alarm threshold in response to determining that the difference between the recommended alarm threshold and the default alarm threshold does not meet an adjustment threshold. Furthermore, the infusion device may be configured to pump fluid at a recommended flow rate in response to determining that the difference between the recommended flow rate and the programmed flow rate does not meet an adjustment threshold. Additionally, the infusion device may be configured to confirm the recommended alarm threshold via a user interface in response to determining that the difference between the recommended alarm threshold and the default alarm threshold meets an adjustment threshold. Furthermore, the infusion device may be configured to confirm the recommended flow rate via a user interface in response to determining that the difference between the recommended flow rate and the programmed flow rate meets an adjustment threshold.

[0108] Figure 7 This is a conceptual diagram depicting an example electronic system 700 for supplementing APR, based on various aspects of the technology of this subject. Electronic system 700 can be implemented by a computing device for performing... Figure 6The software associated with part or step of process 600, or as shown in Figure 1- Figure 5 Any components or methods provided. In this respect, electronic system 700 may include, for example... Figure 1A and Figure 1B Patient care equipment 102 Figure 2 Patient care equipment 202 Figure 3 Infusion equipment 310, Figure 4 Electronic devices 410, and / or Figure 5 Medical device 502 or connection gateway 508.

[0109] The electronic system 700 may also include a specially configured personal computer or mobile device for infusion, such as a smartphone, tablet, laptop, PDA, augmented reality device, wearable device (such as a watch or watchband or glasses), or a combination thereof, or other touch screen or television embedded or coupled with one or more processors, or any other type of computer-related electronic device with network connectivity.

[0110] Furthermore, electronic system 700 may include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, electronic system 700 includes a bus 708, one or more processing units 712, system memory 704, read-only memory (ROM) 710, permanent storage device 702, one or more input device interfaces 714, one or more output device interfaces 706, and one or more network interfaces 716. In some embodiments, electronic system 700 may include or be integrated with other computing devices or circuitry for operating the various components and methods previously described.

[0111] Bus 708 collectively represents a system bus, peripheral bus, and chipset bus that communicatively connects numerous internal devices of electronic system 700. For example, bus 708 communicatively connects one or more processing units 712 to ROM 710, system memory 704, and permanent storage device 702. From these various memory units, one or more processing units 712 retrieve instructions to be executed and data to be processed in order to perform the processes disclosed in this subject matter. In different embodiments, the one or more processing units 712 may be a single-processor or a multi-core processor.

[0112] ROM 710 stores static data and instructions required by one or more processing units 712 and other modules of the electronic system. On the other hand, permanent storage device 702 is a read-write memory device. This device is a non-volatile memory cell that stores instructions and data even when the electronic system 700 is powered off. Some embodiments disclosed in this subject matter use mass storage devices (such as magnetic disks or optical disks and their corresponding disk drives) as permanent storage device 702. Other embodiments use removable storage devices (such as floppy disks, flash drives, and their corresponding disk drives) as permanent storage device 702.

[0113] Like permanent storage device 702, system memory 704 is a read-write memory device. However, unlike storage device 702, system memory 704 is volatile read-write memory, such as random access memory (RAM). System memory 704 stores some instructions and data required by the processor during operation. In some embodiments, the processes disclosed in this subject matter are stored in system memory 704, permanent storage device 702, and / or ROM 710. From these various memory units, one or more processing units 712 retrieve instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0114] Bus 708 is also connected to one or more input device interfaces 714 and one or more output device interfaces 707. The one or more input device interfaces 714 enable the user to communicate information and select commands to the electronic system. Input devices used with the one or more input device interfaces 714 include, for example, alphanumeric keypads and pointing devices (also referred to as "cursor control devices"). The one or more output device interfaces 706 enable, for example, the display of images generated by the electronic system 700. Output devices used with the one or more output device interfaces 706 include, for example, printers and display devices such as cathode ray tubes (CRTs) or liquid crystal displays (LCDs). Some implementations include devices that function as both input and output devices (e.g., touchscreens).

[0115] Furthermore, bus 708 couples electronic system 700 to a network (not shown) via one or more network interfaces 716. The one or more network interfaces 716 may include, for example, a wireless access point (e.g., Bluetooth or Wi-Fi) or radio circuitry for connecting to a wireless access point. The one or more network interfaces 716 may also include hardware (e.g., Ethernet hardware) for connecting the computer to a part of or multiple networks of a computer network (such as a local area network (LAN), wide area network (WAN), wireless LAN, intranet) or a network (such as the Internet). Components of electronic system 700 may be used in conjunction with this subject matter disclosure when specifically configured with one or more of the described features.

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

[0117] Some implementations include storing computer program instructions in electronic components, such as microprocessors, storage, and memory, 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). Examples of such computer-readable media include RAM, ROM, read-only optical disc (CD-ROM), recordable optical disc (CD-R), rewritable optical disc (CD-RW), read-only digital versatile optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini SD card, micro SD card, etc.), magnetic and / or solid-state hard disk drives, read-only and recordable Blu-ray discs, high-density optical discs, other optical or magnetic media, and floppy disks. The computer-readable medium may store a computer program executable by at least one processing unit and includes multiple sets of instructions for performing various operations. Examples of computer programs or computer code include machine code (such as that generated by a compiler), as well as files that include higher-level code executed by a computer, electronic component, or microprocessor using an interpreter.

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

[0119] As used in the specification and 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 features described above. These terms do not include people or groups of people. For the purposes of this specification, the terms "displayed" or "being displayed" mean displayed on an electronic device. As used in the specification and 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, or any other transient signals.

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

[0121] The embodiments of the subject matter described in this specification can be implemented in a specially configured computing system that includes back-end components (e.g., data servers), or specially configured middleware components (e.g., application servers), or specially configured front-end components (e.g., client computers with graphical user interfaces or web browsers through which users can interact with the embodiments of the subject matter described in this specification), or any combination of one or more such back-end, middleware, or front-end components. Components of the system can be interconnected via one or more forms or media of digital data communication (e.g., communication networks). 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).

[0122] A computing system may include specially configured clients and servers. Clients and servers are typically geographically separated but can interact via a communication network. The client-server relationship arises from computer programs running on their respective computers and having a client-server relationship with each other. In some implementations, the server transmits data (e.g., HTML pages) to the client device (e.g., to display data to a user interacting with the client device and to receive user input from the user interacting with the client device). Data generated at the client device (e.g., the result of user interaction) can be received from the client device at the server.

[0123] 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 between hardware and software, the various illustrative blocks, modules, elements, components, methods, and algorithms have been described above in general terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. For each specific application, the described functionality can be implemented in different ways. Various components and blocks can be arranged differently (e.g., in different orders or partitioned in different ways), all without departing from the scope of the subject matter.

[0124] It is understood that the specific order or hierarchy of steps in the disclosed process is illustrative of the method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps may be performed simultaneously. The appended method claims present the elements of each step in an exemplary order and are not intended to limit one to the specific order or hierarchy presented.

[0125] Subject matter technology as an explanation of the terms:

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

[0127] Clause 1. An infusion system comprising: an infusion device; and a first electronic device configured to: receive an automatic programming request (APR) from a second electronic device remotely connected to the first electronic device for automatically programming the infusion device according to a predetermined command, the received APR including a programmed fluid type, a programmed disposable item type, and a programmed infusion device identifier; determine, based on the programmed fluid type, the programmed disposable item type, and the programmed infusion device identifier: (i) a recommended alarm threshold for triggering an alarm on the infusion device, or (ii) a recommended flow rate for pumping fluid of the programmed fluid type; modify the received APR to include (i) the recommended alarm threshold or (ii) the recommended flow rate; and transmit the modified APR to the infusion device; wherein the infusion device is configured to receive the modified APR and (i) set the alarm to trigger at the recommended alarm threshold, (ii) pump fluid at the recommended flow rate, or (iii) confirm the recommended alarm threshold or the recommended flow rate via a user interface presented on a display associated with the infusion device.

[0128] Clause 2. The infusion system according to Clause 1, wherein the first electronic device is configured to determine a recommended alarm threshold, the recommended alarm threshold including a recommended closure alarm for triggering a closure alarm of the infusion device, and determining the recommended alarm threshold includes: determining a default closure alarm threshold of the infusion device based on a programmed infusion device identifier, wherein the infusion device is configured to trigger a closure alarm when the pressure in the piping system coupled to the infusion device meets the default closure alarm threshold; determining an expected pressure in the piping system during operation of the infusion device based on a programmed fluid type and a programmed disposable item type; determining that the infusion device is likely not correctly triggering the closure alarm based on the default closure alarm threshold and the expected pressure; and determining the recommended closure alarm threshold based on the expected pressure and in response to determining that the infusion device is likely not correctly triggering the closure alarm.

[0129] Clause 3. The infusion system according to Clause 1, wherein the first electronic device is configured to determine a recommended alarm threshold, the recommended alarm threshold including a recommended AIL alarm threshold for triggering an air in-line (AIL) alarm of the infusion device, and determining the recommended alarm threshold includes: determining a default AIL alarm threshold of the infusion device based on a programmed infusion device identifier, wherein the infusion device is configured to trigger an AIL alarm when the amount of air in the piping unit coupled to the infusion device meets the default AIL alarm threshold; determining an expected amount of air in the piping unit during operation of the infusion device based on a programmed fluid type and a programmed disposable item type; determining, based on the default AIL alarm threshold and the expected air amount, that the infusion device is likely not correctly triggering the AIL alarm; and determining a recommended AIL alarm threshold based on the expected air amount and in response to determining that the infusion device is likely not correctly triggering the AIL alarm.

[0130] Clause 4. The infusion system according to Clause 1, wherein the first electronic device is configured to determine a recommended flow rate, the received APR further including a programmed flow rate, and determining the recommended flow rate includes: determining the viscosity of the fluid based on a programmed fluid type; determining disposable item characteristics based on a programmed disposable item type, the disposable item characteristics including the inner diameter of the disposable item, the elasticity of the disposable item, or the material of the disposable item; determining a default alarm threshold for triggering an alarm for the infusion device based on a programmed infusion device identifier; determining, based on the programmed flow rate, fluid viscosity, disposable item characteristics, and the default alarm threshold, that pumping fluid at the programmed flow rate is likely to trigger an alarm; and determining the recommended flow rate based on the fluid viscosity, disposable item characteristics, and the default alarm threshold, wherein pumping fluid at the recommended flow rate instead of the programmed flow rate is unlikely to trigger an alarm.

[0131] Clause 5. The infusion system according to any one of Clauses 1 to 4, wherein the received APR further includes a patient identifier, and the first electronic device is further configured to: provide the patient identifier to an electronic medical record (EMR) device before determining the recommended flow rate; and retrieve an EMR from the EMR device in response to providing the patient identifier to the EMR device, the EMR including patient-specific physiological data; wherein the determination of the recommended flow rate is further based on the physiological data of the EMR.

[0132] Clause 6. The infusion system according to any one of Clauses 1 to 5, wherein the first electronic device is configured to determine a recommended flow rate, and the first electronic device is further configured to, before modifying the received APR: determine a flow rate limit based on a programmed fluid type, the flow rate limit including an upper and lower flow rate limit for the fluid used to pump the programmed fluid type; and adjust the recommended flow rate until it meets the flow rate limit in response to determining that the recommended flow rate does not meet the flow rate limit.

[0133] Clause 7. An infusion system according to any one of Clauses 1 to 6, wherein the infusion device is further configured to administer infusion therapy according to a modified APR, the received APR further including a programmed flow rate and a programmed volume to be infused (VTBI), and the first electronic device is further configured to, before modifying the received APR: determine a fluid expiration time based on a programmed fluid type; determine a duration of infusion therapy based on a programmed flow rate and a programmed VTBI; and in response to determining that the fluid expiration time is less than the duration of infusion therapy, and determine, based on at least two of the programmed fluid type, fluid expiration time, programmed flow rate, programmed VTBI, and duration of infusion therapy: (i) a recommended flow rate. (i) a VTBI, wherein the recommended flow rate is greater than the programmed flow rate, and administering the infusion therapy at the recommended flow rate instead of the programmed flow rate will result in the fluid's expiration time being greater than or equal to the duration of the infusion therapy; (ii) an alternative VTBI, wherein the alternative VTBI is less than the programmed VTBI, and administering the infusion therapy using the alternative VTBI instead of the programmed VTBI will result in the fluid's expiration time being greater than or equal to the duration of the infusion therapy, and the first electronic device is further configured to modify the received APR to include the alternative VTBI; or (iii) an alternative fluid, wherein the alternative fluid's expiration time is greater than or equal to the duration of the infusion therapy, and the first electronic device is further configured to modify the received APR to include the alternative fluid.

[0134] Clause 8. An infusion system according to any one of Clauses 1 to 7, wherein the infusion device is further configured to administer infusion therapy according to a modified APR, the received APR further including a programmed flow rate, and the first electronic device is further configured to, before modifying the received APR: determine a half-life of a fluid based on a programmed fluid type; determine a flow resolution of the infusion device based on a programmed infusion device identifier, the flow resolution corresponding to a minimum fluid volume that the infusion device can pump; determine the efficacy of the infusion therapy based on the programmed flow rate, the fluid half-life, and the flow resolution of the infusion device; and, in response to determining that the efficacy of the infusion therapy does not meet an efficacy threshold, and based on the programmed flow rate, the fluid half-life, and the flow resolution of the infusion device, determine: (i) a recommended flow rate, wherein administering the infusion therapy at the recommended flow rate instead of the programmed flow rate would result in the efficacy of the infusion therapy meeting the efficacy threshold; or (ii) an alternative infusion device identifier, wherein administering the infusion therapy using an alternative infusion device instead of the infusion device would result in the efficacy of the infusion therapy meeting the efficacy threshold, and the first electronic device is further configured to modify the received APR to include the alternative infusion device identifier.

[0135] Clause 9. An infusion system according to any one of Clauses 1 to 8, wherein the infusion device includes an infusion pump, and the first electronic device is further configured to, before delivering the modified APR to the infusion device: determine a recommended syringe constant based on at least two of a recommended flow rate, a programmed fluid type, a programmed disposable item type, and a programmed infusion device identifier; wherein the infusion device is further configured to convert the recommended flow rate into an operating speed based on the recommended syringe constant, and pumping fluid at the recommended flow rate includes operating the drive head of the infusion pump at the operating speed.

[0136] Clause 10. The infusion system according to any one of Clauses 1 to 9, wherein the infusion device is further configured to: compare (i) a recommended alarm threshold and a default alarm threshold or (ii) a recommended flow rate and a programmed flow rate before setting an alarm, pumping fluid, or confirming a recommended alarm threshold or a recommended flow rate; and, in response to determining that the difference between the recommended alarm threshold and the default alarm threshold does not meet an adjustment threshold, set an alarm to trigger at the recommended alarm threshold; and, in response to determining that the difference between the recommended flow rate and the programmed flow rate does not meet an adjustment threshold, pump fluid at the recommended flow rate; or, via a user interface: (i) confirm the recommended alarm threshold in response to determining that the difference between the recommended alarm threshold and the default alarm threshold meets an adjustment threshold, or (ii) confirm the recommended flow rate in response to determining that the difference between the recommended flow rate and the programmed flow rate meets an adjustment threshold.

[0137] Clause 11. A computer-implemented method for supplementing an APR, comprising: receiving, at a first electronic device and from a second electronic device remotely connected to the first electronic device, an APR for automatically programming an infusion device according to a predetermined command, the received APR including a programmed fluid type, a programmed disposable item type, and a programmed infusion device identifier; determining, based on the programmed fluid type, the programmed disposable item type, and the programmed infusion device identifier: (i) a recommended alarm threshold for triggering an alarm on the infusion device, or (ii) a recommended flow rate for pumping fluid of the programmed fluid type; modifying the received APR to include (i) the recommended alarm threshold or (ii) the recommended flow rate; and transmitting the modified APR to the infusion device; wherein the infusion device is configured to receive the modified APR and (i) set the alarm to trigger at the recommended alarm threshold, (ii) pump fluid at the recommended flow rate, or (iii) confirm the recommended alarm threshold or the recommended flow rate via a user interface presented on a display associated with the infusion device.

[0138] Clause 12. The computer-implemented method according to Clause 11, wherein the method includes determining a recommended alarm threshold, the recommended alarm threshold including a recommended closure alarm for triggering a closure alarm of an infusion device, and determining the recommended alarm threshold includes: determining a default closure alarm threshold for an infusion device based on a programmed infusion device identifier, wherein the infusion device is configured to trigger a closure alarm when a pressure quantity in a piping system coupled to the infusion device meets the default closure alarm threshold; determining an expected pressure quantity in the piping system during operation of the infusion device based on a programmed fluid type and a programmed disposable item type; determining, based on the default closure alarm threshold and the expected pressure quantity, that the infusion device is likely not correctly triggering a closure alarm; and determining a recommended closure alarm threshold based on the expected pressure quantity and in response to determining that the infusion device is likely not correctly triggering a closure alarm.

[0139] Clause 13. The computer-implemented method according to Clause 11, wherein the method includes determining a recommended alarm threshold, the recommended alarm threshold including a recommended AIL alarm threshold for triggering an air in-line (AIL) alarm for an infusion device, and determining the recommended alarm threshold includes: determining a default AIL alarm threshold for an infusion device based on a programmed infusion device identifier, wherein the infusion device is configured to trigger an AIL alarm when the amount of air in the piping unit coupled to the infusion device meets the default AIL alarm threshold; determining an expected amount of air in the piping unit during operation of the infusion device based on a programmed fluid type and a programmed disposable item type; determining, based on the default AIL alarm threshold and the expected air amount, that the infusion device is likely not correctly triggering the AIL alarm; and determining a recommended AIL alarm threshold based on the expected air amount and in response to determining that the infusion device is likely not correctly triggering the AIL alarm.

[0140] Clause 14. The computer-implemented method according to Clause 11, wherein the method includes determining a recommended flow rate, the received APR further including a programmed flow rate, and determining the recommended flow rate includes: determining the viscosity of a fluid based on a programmed fluid type; determining the characteristics of a disposable item based on a programmed disposable item type, the disposable item characteristics including the inner diameter of the disposable item, the elasticity of the disposable item, or the material of the disposable item; determining a default alarm threshold for triggering an alarm for the infusion device based on a programmed infusion device identifier; determining, based on the programmed flow rate, fluid viscosity, disposable item characteristics, and the default alarm threshold, that pumping fluid at the programmed flow rate is likely to trigger an alarm; and determining a recommended flow rate based on the fluid viscosity, disposable item characteristics, and the default alarm threshold, wherein pumping fluid at the recommended flow rate instead of the programmed flow rate is unlikely to trigger an alarm.

[0141] Clause 15. A computer-implemented method according to any one of Clauses 11 to 14, wherein the received APR further includes a patient identifier, and the method further includes, prior to determining the recommended flow rate: providing the patient identifier to an EMR device; and retrieving an EMR from the EMR device in response to providing the patient identifier to the EMR device, the EMR including patient-specific physiological data; wherein determining the recommended flow rate is further based on the physiological data of the EMR.

[0142] Clause 16. A computer-implemented method according to any one of Clauses 11 to 15, wherein the method includes determining a recommended flow rate, and the method further includes, before modifying the received APR: determining a flow rate limit based on a programmed fluid type, the flow rate limit including an upper and lower limit for pumping fluid of the programmed fluid type; and adjusting the recommended flow rate until it meets the flow rate limit in response to determining that the recommended flow rate does not meet the flow rate limit.

[0143] Clause 17. A computer-implemented method according to any one of Clauses 11 to 16, wherein the infusion device is further configured to administer infusion therapy according to a modified APR, the received APR further including a programmed flow rate and a programmed volume to be infused (VTBI), and the method further comprising, before modifying the received APR: determining a fluid expiration time based on a programmed fluid type; determining a duration of infusion therapy based on the programmed flow rate and the programmed VTBI; and, in response to determining that the fluid expiration time is less than the duration of infusion therapy, determining, based on at least two of the programmed fluid type, fluid expiration time, programmed flow rate, programmed VTBI, and duration of infusion therapy: (i) a recommended flow rate, wherein the recommended flow rate is greater than the programmed flow rate, and administering the infusion therapy at the recommended flow rate instead of the programmed flow rate would result in a fluid expiration time greater than or equal to the duration of the infusion therapy; (ii) an alternative VTBI, wherein the alternative VTBI is less than the programmed VTBI, and administering the infusion therapy using the alternative VTBI instead of the programmed VTBI would result in a fluid expiration time greater than or equal to the duration of the infusion therapy, and the method further includes modifying the received APR to include the alternative VTBI; or (iii) an alternative fluid, wherein the expiration time of the alternative fluid is greater than or equal to the duration of the infusion therapy, and the method further includes modifying the received APR to include the alternative fluid.

[0144] Clause 18. A computer-implemented method according to any one of Clauses 11 to 17, wherein the infusion device is further configured to administer infusion therapy according to a modified APR, the received APR further including a programmed flow rate, and the method further comprising, before modifying the received APR: determining a half-life of a fluid based on a programmed fluid type; determining a flow resolution of the infusion device based on a programmed infusion device identifier, the flow resolution corresponding to a minimum fluid volume that the infusion device can pump; determining the efficacy of the infusion therapy based on the programmed flow rate, the fluid half-life, and the flow resolution of the infusion device; and, in response to determining that the efficacy of the infusion therapy does not meet an efficacy threshold, and based on the programmed flow rate, the fluid half-life, and the flow resolution of the infusion device, determining: (i) a recommended flow rate, wherein administering the infusion therapy at the recommended flow rate instead of the programmed flow rate would result in the efficacy of the infusion therapy meeting the efficacy threshold; or (ii) an alternative infusion device identifier, wherein administering the infusion therapy using an alternative infusion device instead of the infusion device would result in the efficacy of the infusion therapy meeting the efficacy threshold, and the method further comprising modifying the received APR to include the alternative infusion device identifier.

[0145] Clause 19. A computer-implemented method according to any one of Clauses 11 to 18, wherein the infusion device includes an infusion pump, and the method further includes, before transmitting the modified APR to the infusion device: determining a recommended syringe constant based on at least two of a recommended flow rate, a programmed fluid type, a programmed disposable item type, and a programmed infusion device identifier; wherein the infusion device is further configured to convert the recommended flow rate into an operating speed based on the recommended syringe constant, and pumping fluid at the recommended flow rate includes operating the drive head of the infusion pump at the operating speed.

[0146] Clause 20. A non-transitory computer-readable storage medium including instructions that, when executed by a first electronic device, cause the first electronic device to perform operations comprising: receiving from a second electronic device remote from the first electronic device an Automatic Programming Representation (APR) for automatically programming an infusion device according to a predetermined command, the received APR including a programmed fluid type, a programmed disposable item type, and a programmed infusion device identifier; determining, based on the programmed fluid type, the programmed disposable item type, and the programmed infusion device identifier: (i) a recommended alarm threshold for triggering an alarm on the infusion device, or (ii) a recommended flow rate for pumping fluid of the programmed fluid type; modifying the received APR to include (i) the recommended alarm threshold or (ii) the recommended flow rate; and transmitting the modified APR to the infusion device; wherein the infusion device is configured to receive the modified APR and (i) set the alarm to trigger at the recommended alarm threshold, (ii) pump fluid at the recommended flow rate, or (iii) confirm the recommended alarm threshold or the recommended flow rate via a user interface presented on a display associated with the infusion device.

[0147] Further consideration:

[0148] It is understood that the specific order or hierarchy of steps in the process disclosed herein is illustrative of the method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process may be rearranged. Some steps may be performed simultaneously. The appended method claims present the elements of each step in an example order and are not intended to limit one to the specific order or hierarchy presented.

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

[0150] The predicates “configured as,” “operable as,” and “programmed as” do not imply any specific tangible or intangible modification of the subject, but are intended to be used interchangeably. For example, “processor configured as a monitoring and control operation or component” can also mean “processor programmed as a monitoring and control operation” or “processor operable as a monitoring and control operation.” Similarly, “processor configured to execute code” can be interpreted as “processor programmed to execute code” or “operable as execute code.”

[0151] As used herein, the term "automatic" can include actions performed by a computer or machine without user intervention, for example, by an instruction in response to a predicate action by a computer, 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 preferential or superior to other aspects or designs.

[0152] Phrases such as "aspect" do not imply that the aspect is essential to the subject matter or that the aspect applies to all configurations of the subject matter. Disclosures relating to an aspect may apply to all configurations or one or more configurations. An aspect may provide one or more examples. Phrases such as "aspect" may refer to one or more aspects, and vice versa. Phrases such as "implementation" do not imply that such implementation is essential to the subject matter or that such implementation applies to all configurations of the subject matter. Disclosures relating to an implementation may apply to all implementations or one or more implementations. An implementation may provide one or more examples. Phrases such as "implementation" may refer to one or more implementations, and vice versa. Phrases such as "configuration" do not imply that such configuration is essential to the subject matter or that such configuration applies to all configurations of the subject matter. Disclosures relating to a configuration may apply to all configurations or one or more configurations. A configuration may provide one or more examples. Phrases such as "configuration" may refer to one or more configurations, and vice versa.

[0153] As used herein, a “user interface” (also known as an interactive user interface, graphical user interface, or UI) can refer to a web-based interface, including data fields and / or other control elements for receiving input signals or providing electronic information and / or providing information to the user in response to any received input signals. Control elements may include dials, buttons, icons, selectable areas, or other perceptible markings presented via the UI, which initiates data exchange with the device presenting the UI when interacted with (e.g., click, touch, select, etc.). Languages ​​such as Hypertext Markup Language (HTML) and Flash can be utilized. TM Java TM .NET TM The UI can be implemented in whole or in part using technologies such as web services or rich site summaries (RSS). In some implementations, the UI may be included in a separate client (e.g., a fat client) configured to communicate (e.g., send or receive data) according to one or more of the described aspects. Communication may be to or from the medical device or a server with which it communicates.

[0154] As used herein, the terms "determine" or "determine" encompass a wide variety of actions. For example, "determine" can include estimating, calculating, processing, deriving, generating, obtaining, searching (e.g., searching in a table, database, or another data structure), ascertaining, etc., via hardware elements without user intervention. Furthermore, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc., via hardware elements without user intervention. "Determine" can also include parsing, selecting, choosing, building, etc., via hardware elements without user intervention.

[0155] As used herein, the terms “provide” or “supply” encompass a wide variety of actions. For example, “supply” can include storing a value in a location on a storage device for subsequent retrieval, sending a value directly to a recipient via at least one wired or wireless communication medium, sending or storing a reference to a value, etc. “Supply” can also include encoding, decoding, encryption, decryption, acknowledgment, verification, etc., via hardware components.

[0156] As used herein, the term "message" encompasses a variety of formats used for communicating (e.g., sending or receiving) information. A message may include machine-readable aggregates such as XML documents, fixed-field messages, comma-separated messages, JSON, custom protocols, or the like. In some implementations, a message may include signals representing one or more representations of information. When stated in the singular, it is understood that a message may be composed, sent, stored, received, etc., in multiple parts.

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

[0158] As used herein, the terms "equivalent to" or "corresponding to" include structural, functional, quantitative and / or qualitative correlations or relationships between two or more objects, datasets, information, etc., preferably where correspondence or relationship can be used to transform one or more of two or more objects, datasets, information, etc., to appear the same or equal. Correspondence can be evaluated using one or more or combinations of thresholds, value ranges, fuzzy logic, pattern matching, ML evaluation models, etc.

[0159] In any implementation, the generated or detected data may be forwarded to a “remote” device or location, where “remote” means a location or device other than the location or device where the program is executed. For example, a remote location could be another location in the same city (e.g., an office, laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. Accordingly, when one item is indicated as “remote” to another item, it means that the two items may be in the same room but separate, or at least in different rooms or different buildings, and may be at least one mile, ten miles, or at least one hundred miles apart. “Communicating” information refers to the transmission of data representing information as electrical signals through an appropriate communication channel (e.g., a private or public network). “Forwarding” an item means any means of moving an item from one location to another, whether by physically transporting the item or otherwise (where possible), and at least in the case of data, includes the physical transport of the medium carrying the data or enabling the data to communicate. Examples of communication media include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet or information including email transmissions and records on websites, etc.

Claims

1. An infusion system, comprising: Infusion equipment; as well as A first electronic device, the first electronic device being configured to: An automatic programming request (APR) is received from a second electronic device located remote from the first electronic device for automatically programming the infusion device according to a predetermined command. The received APR includes the type of fluid to be programmed, the type of disposable item to be programmed, and the identifier of the infusion device to be programmed. Based on the programmed fluid type, programmed disposable item type, and programmed infusion device identifier, determine: (i) a recommended alarm threshold for triggering an alarm on the infusion device, or (ii) a recommended flow rate for pumping the programmed fluid type; Modify the received APR to include (i) the recommended alarm threshold or (ii) the recommended flow rate; as well as The modified APR is transmitted to the infusion device; The infusion device is configured to receive a modified APR and (i) set the alarm to trigger at the recommended alarm threshold, (ii) pump the fluid at the recommended flow rate, or (iii) confirm the recommended alarm threshold or the recommended flow rate via a user interface presented on a display associated with the infusion device.

2. The infusion system according to claim 1, wherein, The first electronic device is configured to determine the recommended alarm threshold, the recommended alarm threshold including a recommended occlusion alarm for triggering an occlusion alarm of the infusion device, and determining the recommended alarm threshold includes: The default occlusion alarm threshold of the infusion device is determined based on the programmable infusion device identifier, wherein the infusion device is configured to trigger an occlusion alarm when the pressure in the piping system coupled to the infusion device meets the default occlusion alarm threshold. The expected pressure in the piping system during operation of the infusion device is determined based on the programmed fluid type and the programmed disposable item type. Based on the default occlusion alarm threshold and the expected pressure, it is determined that the infusion device most likely did not correctly trigger the occlusion alarm; and Based on the expected pressure and in response to determining that the infusion device is likely not properly triggering the occlusion alarm, the recommended occlusion alarm threshold is determined.

3. The infusion system according to claim 1, wherein, The first electronic device is configured to determine the recommended alarm threshold, the recommended alarm threshold including a recommended AIL alarm threshold for triggering an air in-line (AIL) alarm for the infusion device, and determining the recommended alarm threshold includes: The default AIL alarm threshold for the infusion device is determined based on a programmable infusion device identifier, wherein the infusion device is configured to trigger the AIL alarm when the amount of air in the piping system coupled to the infusion device meets the default AIL alarm threshold; Based on the programmed fluid type and the programmed disposable item type, determine the expected air volume in the piping device during operation of the infusion device; Based on the default AIL alarm threshold and the expected air volume, it is determined that the infusion device most likely did not correctly trigger the AIL alarm; and Based on the expected air volume and in response to determining that the infusion device is likely not correctly triggering the AIL alarm, the recommended AIL alarm threshold is determined.

4. The infusion system according to claim 1, wherein, The first electronic device is configured to determine the recommended flow rate, the received APR further including the programmed flow rate, and determining the recommended flow rate includes: The viscosity of the fluid is determined based on the programmed fluid type; The characteristics of disposable items are determined based on the type of disposable item, including the inner diameter of the disposable item, the elasticity of the disposable item, or the material of the disposable item; A default alarm threshold for triggering an alarm on the infusion device is determined based on a programmable infusion device identifier; Based on the programmed flow rate, fluid viscosity, disposable characteristics, and default alarm threshold, it is determined that pumping the fluid at the programmed flow rate is likely to trigger an alarm; and The recommended flow rate is determined based on the fluid viscosity, the disposable characteristics, and the default alarm threshold, wherein pumping the fluid at the recommended flow rate instead of the programmed flow rate is unlikely to trigger an alarm.

5. The infusion system according to any one of claims 1 to 4, wherein, The received APR further includes a patient identifier, and the first electronic device is further configured to: Provide patient identifiers to electronic health record (EMR) devices; and In response to providing the patient identifier to the EMR device, an EMR is retrieved from the EMR device, the EMR including patient-specific physiological data; The recommended flow rate is further determined based on the physiological data of the EMR.

6. The infusion system according to any one of claims 1 to 5, wherein, The first electronic device is configured to determine the recommended flow rate, and the first electronic device is further configured to: before modifying the received APR: Flow rate limits are determined based on programmed fluid type, the flow rate limits including an upper and lower flow rate limit for the fluid of the programmed fluid type used for pumping; and In response to determining that the recommended flow rate does not meet the flow rate limit, the recommended flow rate is adjusted until it meets the flow rate limit.

7. The infusion system according to any one of claims 1 to 6, wherein, The infusion device is further configured to administer infusion therapy according to a modified APR, the received APR further including a programmed flow rate and a programmed volume to be infused (VTBI), and the first electronic device is further configured to: The expiration time of the fluid is determined based on the programmed fluid type; The duration of the infusion therapy is determined based on programmed flow rate and programmed VTBI; as well as In response to determining that the expiration time of the fluid is less than the duration of the infusion therapy, and based on at least two of the programmed fluid type, fluid expiration time, programmed flow rate, programmed VTBI, and duration of the infusion therapy: (i) the recommended flow rate, wherein the recommended flow rate is greater than the programmed flow rate, and administering the infusion therapy at the recommended flow rate instead of the programmed flow rate would result in the fluid's expiration time being greater than or equal to the duration of the infusion therapy; (ii) An alternative VTBI, wherein the alternative VTBI is smaller than the programmed VTBI, administering the infusion therapy using the alternative VTBI instead of the programmed VTBI would result in the fluid's expiration time being greater than or equal to the duration of the infusion therapy, and the first electronic device is further configured to modify the received APR to include the alternative VTBI; or (iii) An alternative fluid, wherein the expiration time of the alternative fluid is greater than or equal to the duration of the infusion therapy, and the first electronic device is further configured to modify the received APR to include the alternative fluid.

8. The infusion system according to any one of claims 1 to 7, wherein, The infusion device is further configured to administer the infusion therapy according to a modified APR, the received APR further including a programmed flow rate, and the first electronic device is further configured to: The half-life of the fluid is determined based on the programmed fluid type; The flow resolution of the infusion device is determined based on a programmable infusion device identifier, the flow resolution corresponding to the minimum fluid volume that the infusion device can pump; The efficacy of the infusion therapy is determined based on the programmed flow rate, fluid half-life, and flow resolution of the infusion device; as well as In response to determining that the efficacy of the infusion therapy does not meet the efficacy threshold, and based on the programmed flow rate, the fluid half-life, and the flow resolution of the infusion device, the following is determined: (i) the recommended flow rate, wherein administering the infusion therapy at the recommended flow rate instead of the programmed flow rate will result in the efficacy of the infusion therapy meeting the efficacy threshold; or (ii) An identifier for an alternative infusion device, wherein administering the infusion therapy using the alternative infusion device instead of the infusion device would result in the efficacy of the infusion therapy meeting the efficacy threshold, and the first electronic device is further configured to modify the received APR to include the identifier of the alternative infusion device.

9. The infusion system according to any one of claims 1 to 8, wherein, The infusion device includes an injection pump, and the first electronic device is further configured to: Before delivering the modified APR to the infusion device: The recommended syringe constant is determined based on at least two of the recommended flow rate, the programmed fluid type, the programmed disposable item type, and the programmed infusion device identifier; The infusion device is further configured to convert the recommended flow rate into an operating speed based on a recommended syringe constant, and to pump fluid at the recommended flow rate, including a drive head that operates the injection pump at the operating speed.

10. The infusion system according to any one of claims 1 to 9, wherein, The infusion device is further configured to: Before setting alarms, pumping fluid, or confirming recommended alarm thresholds or recommended flow rates, compare (i) the recommended alarm threshold with the default alarm threshold or (ii) the recommended flow rate with the programmed flow rate; as well as In response to the determination that the difference between the recommended alarm threshold and the default alarm threshold does not meet the adjustment threshold, an alarm is set to be triggered at the recommended alarm threshold; In response to determining that the difference between the recommended flow rate and the programmed flow rate does not meet the adjustment threshold, the fluid is pumped at the recommended flow rate; or via the user interface: (i) confirm the recommended alarm threshold in response to determining that the difference between the recommended alarm threshold and the default alarm threshold satisfies an adjustment threshold, or (ii) confirm the recommended flow rate in response to determining that the difference between the recommended flow rate and the programmed flow rate satisfies an adjustment threshold.

11. A computer-implemented method for supplementing APR, comprising: At the first electronic device and from the second electronic device located remotely from the first electronic device, an APR for automatically programming the infusion device according to a predetermined command is received, the received APR including the programmed fluid type, the programmed disposable item type, and the programmed infusion device identifier; Based on the programmed fluid type, programmed disposable item type, and programmed infusion device identifier, determine: (i) a recommended alarm threshold for triggering an alarm on the infusion device, or (ii) a recommended flow rate for pumping the programmed fluid type; Modify the received APR to include (i) the recommended alarm threshold or (ii) the recommended flow rate; as well as The modified APR is transmitted to the infusion device; The infusion device is configured to receive a modified APR and (i) set the alarm to trigger at the recommended alarm threshold, (ii) pump the fluid at the recommended flow rate, or (iii) confirm the recommended alarm threshold or the recommended flow rate via a user interface presented on a display associated with the infusion device.

12. The computer-implemented method according to claim 11, wherein, The method includes determining the recommended alarm threshold, the recommended alarm threshold including a recommended occlusion alarm for triggering an occlusion alarm of the infusion device, and determining the recommended alarm threshold includes: The default occlusion alarm threshold of the infusion device is determined based on the programmable infusion device identifier, wherein the infusion device is configured to trigger an occlusion alarm when the pressure in the piping system coupled to the infusion device meets the default occlusion alarm threshold. The expected pressure in the piping system during operation of the infusion device is determined based on the programmed fluid type and the programmed disposable item type. Based on the default occlusion alarm threshold and the expected pressure, it is determined that the infusion device most likely did not correctly trigger the occlusion alarm; and Based on the expected pressure and in response to determining that the infusion device is likely not properly triggering the occlusion alarm, the recommended occlusion alarm threshold is determined.

13. The computer-implemented method according to claim 11, wherein, The method includes determining the recommended alarm threshold, the recommended alarm threshold including a recommended AIL alarm threshold for triggering an air in-line (AIL) alarm for the infusion device, and determining the recommended alarm threshold includes: The default AIL alarm threshold for the infusion device is determined based on a programmable infusion device identifier, wherein the infusion device is configured to trigger the AIL alarm when the amount of air in the piping system coupled to the infusion device meets the default AIL alarm threshold; Based on the programmed fluid type and the programmed disposable item type, determine the expected air volume in the piping device during operation of the infusion device; Based on the default AIL alarm threshold and the expected air volume, it is determined that the infusion device most likely did not correctly trigger the AIL alarm; and Based on the expected air volume and in response to determining that the infusion device is likely not correctly triggering the AIL alarm, the recommended AIL alarm threshold is determined.

14. The computer-implemented method according to claim 11, wherein, The method includes determining the recommended flow rate, wherein the received APR further includes a programmed flow rate, and determining the recommended flow rate includes: The viscosity of the fluid is determined based on the programmed fluid type; The characteristics of disposable items are determined by programming-based disposable item type determination. These characteristics include the inner diameter of the disposable item, the elasticity of the disposable item, or the material of the disposable item. A default alarm threshold for triggering an alarm on the infusion device is determined based on a programmable infusion device identifier; Based on the programmed flow rate, fluid viscosity, disposable characteristics, and default alarm threshold, it is determined that pumping the fluid at the programmed flow rate is likely to trigger an alarm; and The recommended flow rate is determined based on the fluid viscosity, the disposable characteristics, and the default alarm threshold, wherein pumping the fluid at the recommended flow rate instead of the programmed flow rate is unlikely to trigger an alarm.

15. The computer-implemented method according to any one of claims 11 to 14, wherein, The received APR further includes a patient identifier, and the method further includes, before determining the recommended flow rate: Provide patient identifiers to EMR devices; and In response to providing the patient identifier to the EMR device, an EMR is retrieved from the EMR device, the EMR including patient-specific physiological data; The recommended flow rate is further determined based on the physiological data of the EMR.

16. The computer-implemented method according to any one of claims 11 to 15, wherein, The method includes determining the recommended flow rate, and the method further includes modifying the received APR before: Flow rate limits are determined based on programmed fluid type, the flow rate limits including upper and lower limits for pumping fluid of the programmed fluid type; and In response to determining that the recommended flow rate does not meet the flow rate limit, the recommended flow rate is adjusted until it meets the flow rate limit.

17. The computer-implemented method according to any one of claims 11 to 16, wherein, The infusion device is further configured to administer infusion therapy according to a modified APR, the received APR further including a programmed flow rate and a programmed volume to be infused (VTBI), and the method further includes, before modifying the received APR: The expiration time of the fluid is determined based on the programmed fluid type; The duration of the infusion therapy is determined based on programmed flow rate and programmed VTBI; as well as In response to determining that the expiration time of the fluid is less than the duration of the infusion therapy, and based on at least two of the programmed fluid type, fluid expiration time, programmed flow rate, programmed VTBI, and duration of the infusion therapy: (i) the recommended flow rate, wherein the recommended flow rate is greater than the programmed flow rate, and administering the infusion therapy at the recommended flow rate instead of the programmed flow rate would result in the fluid's expiration time being greater than or equal to the duration of the infusion therapy; (ii) An alternative VTBI, wherein the alternative VTBI is smaller than the programmed VTBI, administering the infusion therapy using the alternative VTBI instead of the programmed VTBI would result in the fluid's expiration time being greater than or equal to the duration of the infusion therapy, and the method further includes modifying the received APR to include the alternative VTBI; or (iii) An alternative fluid, wherein the expiration time of the alternative fluid is greater than or equal to the duration of the infusion therapy, and the method further includes modifying the received APR to include the alternative fluid.

18. The computer-implemented method according to any one of claims 11 to 17, wherein, The infusion device is further configured to administer infusion therapy according to a modified APR, the received APR further including a programmed flow rate, and the method further includes, before modifying the received APR: The half-life of the fluid is determined based on the programmed fluid type; The flow resolution of the infusion device is determined based on a programmable infusion device identifier, the flow resolution corresponding to the minimum fluid volume that the infusion device can pump; The efficacy of the infusion therapy is determined based on the programmed flow rate, fluid half-life, and flow resolution of the infusion device; as well as In response to determining that the efficacy of the infusion therapy does not meet the efficacy threshold, and based on the programmed flow rate, the fluid half-life, and the flow resolution of the infusion device, the following is determined: (i) the recommended flow rate, wherein administering the infusion therapy at the recommended flow rate instead of the programmed flow rate will result in the efficacy of the infusion therapy meeting the efficacy threshold; or (ii) An identifier for an alternative infusion device, wherein administering the infusion therapy using the alternative infusion device instead of the infusion device would result in the efficacy of the infusion therapy meeting the efficacy threshold, and the method further includes modifying the received APR to include the identifier of the alternative infusion device.

19. The computer-implemented method according to any one of claims 11 to 18, wherein, The infusion device includes an injection pump, and the method further includes, before delivering the modified APR to the infusion device: The recommended syringe constant is determined based on at least two of the recommended flow rate, the programmed fluid type, the programmed disposable item type, and the programmed infusion device identifier; The infusion device is further configured to convert the recommended flow rate into an operating speed based on a recommended syringe constant, and to pump fluid at the recommended flow rate, including a drive head that operates the injection pump at the operating speed.

20. A non-transitory computer-readable storage medium including instructions that, when executed by a first electronic device, cause the first electronic device to perform an operation, the operation comprising: A second electronic device, located remote from the first electronic device, receives an APR for automatically programming the infusion device according to a predetermined command. The received APR includes the programmed fluid type, the programmed disposable item type, and the programmed infusion device identifier. Based on the programmed fluid type, programmed disposable item type, and programmed infusion device identifier, determine: (i) a recommended alarm threshold for triggering an alarm on the infusion device, or (ii) a recommended flow rate for pumping the programmed fluid type; Modify the received APR to include (i) the recommended alarm threshold or (ii) the recommended flow rate; as well as The modified APR is transmitted to the infusion device; The infusion device is configured to receive a modified APR and (i) set the alarm to trigger at the recommended alarm threshold, (ii) pump the fluid at the recommended flow rate, or (iii) confirm the recommended alarm threshold or the recommended flow rate via a user interface presented on a display associated with the infusion device.

Images