WO2025136385A1

WO2025136385A1 - Devices, systems, and methods for improving infusion device compliance with medical testing requirements

Info

Publication number: WO2025136385A1
Application number: PCT/US2023/085229
Authority: WO
Inventors: Vinay JANI; Sonia DALAI
Original assignee: CareFusion 303 Inc
Current assignee: CareFusion 303 Inc
Priority date: 2023-12-20
Filing date: 2023-12-20
Publication date: 2025-06-26
Anticipated expiration: 2026-06-20

Abstract

An infusion device includes a fluid pump and a processor. The processor is configured to determine an amount of fluid pumped by the fluid pump or an amount of time the fluid pump has pumped the fluid. The processor is also configured to determine that the amount of fluid satisfies a volume threshold or that the amount of time satisfies a duration threshold. Additionally, the processor is configured to, responsive to determining that the amount of fluid satisfies the volume threshold or that the amount of time satisfies the duration threshold, electronically transmit a request for a medical test and initiate a timer. Further, the processor is configured to determine an adjustment-delay threshold prior to an initiation or a completion of the medical test. Moreover, the processor is configured to reduce an operating speed of the fluid pump when the timer satisfies the adjustment-delay threshold.

Description

DEVICES, SYSTEMS, AND METHODS FOR IMPROVING INFUSION DEVICE COMPLIANCE WITH MEDICAL TESTING REQUIREMENTS

TECHNICAL FIELD

[0001] The present disclosure relates, generally, to infusion devices and, more particularly, to improving infusion device compliance with medical testing requirements.

BACKGROUND

[0002] Many infusion therapies incorporate medical testing to confirm that the patient receiving the therapy is responding properly to it. An infusion therapy involving an anticoagulant, for instance, may require regular testing (e.g., a blood coagulation characterization test) to ensure that the patient is receiving the proper amount of the anticoagulant. The same may be true for other drugs and infusion fluids, such as anesthetics, analgesics, and the like.

[0003] Unfortunately, medical testing requirements are at times overlooked or ignored, especially in busy medical environments. Even when testing requirements are properly upheld, they require additional overhead time that clinicians might otherwise devote to patient care.

SUMMARY

[0004] The present disclosure provides devices, systems, and methods that address some of the aforenoted problems, as well as other problems associated with medical testing and infusion devices. These devices, systems, and methods involve automatically adjusting (e.g., slowing) an infusion therapy based on the status of a medical test associated with the infusion therapy. The subject technology can be employed in manufacturing to evaluate the performance of infusion devices configured for automatic adjustment, as described herein. For example, a manufacturer can confirm that the infusion devices it manufactures properly respond to inputs regarding simulated infusion therapies and medical test requirements. In this manner, manufacturers can ensure the infusion devices comply with regulatory requirements and thereby improve the safety and efficacy of the infusion devices. Additionally, the subject technology can be used in healthcare to ensure that infusion devices comply with medical testing requirements. Example implementations of the advancements discussed herein include the following: [0005] An infusion device includes a fluid pump and a processor. The processor is configured to cause the fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion. The processor is also configured to determine (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion. Additionally, the processor is configured to determine (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold. Further, the processor is configured to, responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmit a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiate a timer. Moreover, the processor is configured to determine an adjustment-delay threshold prior to an initiation or a completion of the medical test. Furthermore, the processor is configured to reduce the operating speed of the fluid pump when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated or completed.

[0006] A computer-implemented method for improving infusion device compliance with medical testing requirements includes causing a fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion. The method also includes determining (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion. Additionally, the method includes determining (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold. Further, the method includes, responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmitting a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiating a timer. Moreover, the method includes determining an adjustment-delay threshold prior to an initiation or a completion of the medical test. Furthermore, the method includes reducing an operating speed of the fluid pump when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated or completed.

[0007] A non-transitory, computer-readable storage medium comprising instructions that, when executed by an electronic device, cause the electronic device to cause a fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion. The instructions also cause the electronic device to determine (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion. Additionally, the instructions cause the electronic device to determine (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold. Further, the instructions cause the electronic device to, responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmit a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiate a timer. Moreover, the instructions cause the electronic device to determine an adjustment-delay threshold prior to an initiation or a completion of the medical test. Furthermore, the instructions cause the electronic device to reduce an operating speed of the fluid pump when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated or completed.

[0008] Although the present disclosure describes the subject technology in the context of syringe pumps, much of the subject technology is nonetheless applicable to other types of infusion pumps. It is understood that other configurations of the subject technology will become readily apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0011] FIG. 2 depicts an example institutional patient care system of a healthcare organization, according to various aspects of the subject technology. [0012] FIG. 3 depicts an example sequence diagram for automatically ordering a medical test and adjusting an infusion device based on initiation or completion of the medical test, according to various aspects of the subject technology.

[0013] FIGS. 4A and 4B depict an example control unit displaying example notices regarding medical test requirements and recommendations, according to various aspects of the subject technology.

[0014] FIG. 5 depicts an example process for improving infusion device compliance with medical testing requirements, according to various aspects of the subject technology.

[0015] FIG. 6 is a conceptual diagram illustrating an example electronic system for improving infusion device compliance with medical testing requirements, according to various aspects of the subject technology.

DETAILED DESCRIPTION

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

[0017] The following figures illustrate exemplary devices, systems, and methods, which can be used to improve infusion device compliance with medical testing requirements or recommendations. The innovations discussed herein can be employed in manufacturing and testing of infusion devices to ensure that the infusion devices properly enforce, or at least encourage compliance with, medical testing requirements or recommendations. Additionally, the present disclosure can also be used in clinical settings, for example, in automatically ordering medical tests and ensuring that said medical tests are initiated and/or completed in compliance with testing requirements or recommendations.

[0018] As discussed in more detail herein, a medical test can be automatically requested (e.g., ordered by the infusion pump) after an infusion therapy has continued for a predetermined amount of time or after a predetermined amount of fluid has been delivered during the infusion therapy. If the medical test is not initiated or completed within a predetermined amount of time, then the infusion device performing the infusion therapy can be automatically adjusted, for example, to reduce the flow rate of the device (e.g., by reducing an operating speed).

[0019] According to various implementations, an adjustment to the infusion device is made to ensure that the infusion therapy does not overstep predetermined infusion requirements. For example, an infusion therapy involving an anticoagulant (e.g., heparin) may require regular (e.g., semi-hourly) blood coagulation characterization tests (e.g., partial thromboplastin time (PTT) tests) to confirm that the patient receiving the infusion therapy should continue to receive the anticoagulant. Thus, a blood coagulation characterization test can be automatically requested after the infusion therapy has continued for a predetermined amount of time or a predetermined amount of the anticoagulant has been provided to the patient. If the test is not initiated or completed within a predetermined amount of time after the test is requested, then the operating speed of the infusion device may be slowed (e.g., stopped) to reduce a flow rate of the anticoagulant and thereby avoid over-infusing the anticoagulant.

[0020] The disclosed features may be applicable in situations that require medical technologists to notify clinicians of situations where tests are not possible or are delayed for reasons such as diagnostic machine failure or reagent replacement. For example, an infusion therapy requiring an anticoagulant (e.g., heparin) may require regular (e.g., semi-hourly) coagulation blood panels (e.g., partial thromboplastin time (PTT) or prothrombin time (PT)) for dose modification when necessary. A blood coagulation panel can be automatically requested after continuation of infusion therapy for a predetermined amount of time or anticoagulant. However, if a diagnostic machine is in a failure state, the infusion device can receive a signal from the machine and directly notify a clinician or care provider or results are delayed or unable to be delivered. Furthermore, in these situations, treatment can be adjusted or stopped automatically by the infusion device or based on clinical judgment, the latter requiring user interaction.

[0021] The disclosed features may be applicable to allow for treatments that require diagnostic tests (e.g., troponin, complete blood panel (CBC)) to be manipulated (increased, decreased, or stop) even when diagnostic tests have not been completed. In these situations, the features describe allow for notification (e.g., warning) that necessary tests have yet to be performed and an automatic lock on the infusion device for treatment manipulation in relevant situations.

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

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

[0024] As shown in FIG. 1A, each administration set 120-123 is connected between a respective fluid supply 110-113 and a patient 106 so that the patient 106 may receive the fluids in any or all the fluid supplies 110-113. Each of the administration sets 120-123 may be identified either actively (e.g., by clinician scanning) or passively (e.g., by wireless or optical detection). Typically, medical administration sets have more parts than are shown in FIG. 1 A. Many have check valves, drip chambers, valved ports, connectors, and other devices well known to those skilled in the art. These other devices are not included in the drawings to preserve clarity of illustration.

[0025] In the depicted example, a separate infusion pump 130-133 is used to infuse each of the respective fluids of the fluid supplies 110-113 into the patient 106. The infusion pumps 130-133 are flow control devices that will act on the respective tube or fluid conduit of the respective administration set 120-123 to move fluid from the fluid supply 110-113, through the conduit, and to the patient. Because individual infusion pumps 130-133 are used, each of the infusion pumps 130-133 may be individually set to the pumping or operating parameters required for infusing the particular medical fluid from the respective fluid supply 110-113 into the patient at the particular rate prescribed for that fluid by the clinician. [0026] FIG. IB depicts a portion of the patient care device 102 shown in FIG. 1A. The illustrated patient care device 102 includes the control unit 104, along with two of the infusion pumps 131 and 132 mounted at either side of the control unit 104. In some implementations, the control unit 104 is configured for programming each of the infusion pumps 130-133 (see FIG. 1A). FIG. IB also shows the displays and controls of the infusion pumps 131 and 132, such as the display 124 and the controls 126 of the infusion pump 132.

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

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

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

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

[0031] The control unit 104 may also include a communications system by which the control unit 104 can communicate with external equipment, such as a medical facility server, a handheld communication device, a laptop-type computer, or other information device that a clinician may have to transfer information or to download drug libraries to the control unit 104.

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

[0033] FIG. 2 depicts an example institutional patient care system 200 of a healthcare organization, according to various aspects of the subject technology. In FIG. 2, a patient care device 202 (e.g., patient care device 102 of FIGS. 1A and IB) is connected to an internal healthcare network 236. The term patient care device (“PCD”) may be used interchangeably with the term patient care unit (“PCU”), either of which may include various ancillary medical devices, such as an infusion pump (e.g., infusion pumps 130-133 of FIG. 1A), a vital signs monitor, a medication dispensing device (e.g., cabinet, tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned (e.g., a syringe pump module coupled with an infusion pump), and the like. Each element of the patient care device 202 is connected to an internal healthcare network 236 by 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 a hospital or healthcare center. For example, the internal healthcare network 236 optionally includes computer systems associated with an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers, and/or a medical decision support system. As described further below, the internal healthcare network 236 may include discrete subnetworks. In the depicted example, the internal healthcare network 236 includes a device network 238 by which the patient care device 202 and other devices can communicate in accordance with normal operations.

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

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

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

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

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

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

[0041] Network connection 220 may be a wired or wireless connection, such as by Ethernet, Wi-Fi, BLUETOOTH, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem or a cable modem. Any direct or indirect network connection may be used, including, but not limited to a telephone modem, an MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link or a WLANS connection or other wireless connection. [0042] The functional modules 206-209 are devices (e.g., infusion pumps 130-133 of FIG. 1 A) for providing care to a patient or for monitoring patient conditions. As shown in FIG. 2, at least one of functional modules 206-209 may be an infusion pump module such as an intravenous infusion pump for delivering medication or other fluid to a patient. For the purposes of this discussion, functional module 206 is an infusion pump module. Each of functional modules 206-209 may be any patient treatment or monitoring device including, but not limited to, an infusion pump, a syringe pump, a PCA pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, an intracranial pressure monitor, or the like. Additionally, the functional modules 206-209 may include a printer, a scanner, a bar code reader, a near-field communication reader, an RFID reader, or any other peripheral input, output or input/output device.

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

[0044] Each of the functional modules 206-209 may include a microprocessor 216, a volatile memory 214, a nonvolatile memory 212, and module-specific components 210. It should be noted that while four functional modules are shown in FIG. 2, any number of devices may be connected directly or indirectly to the control unit 204. The number and type of functional modules described herein are intended to be illustrative, and they in no way limit the scope of the subject technology. The module-specific components 210 include any components necessary for operation of a particular module, such as a pumping mechanism for the functional module 206. [0045] While each of the functional modules 206-209 may be capable of a least some level of independent operation, the control unit 204 monitors and controls overall operation of the patient care device 202. For example, as will be described in more detail below, the control unit 204 provides programming instructions to the functional modules 206-209 and monitors the status of each of the functional modules 206-209.

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

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

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

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

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

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

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

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

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

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

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

[0058] In the case of a syringe pump, the electronically loaded drug library may include a list of names of syringe manufacturers identifying syringes that can be used in the drug infusion pump, and the drug infusion pump offers the user the list of names of syringe manufacturers from which to make a selection when the electronically loaded drug library is in the pump. The loaded drug library may include a list of syringe sizes identifying syringes that can be used in the drug infusion pump, and the drug infusion pump offers the user the list of syringe sizes from which to make a selection when the electronically loaded drug library is in said pump. In the case of a peristaltic pump, the electronically loaded drug library may include a list of infusion set manufacturers. A loaded drug library may include a set of features, each of which is either be toggled on or off, and the pump offers the user only the features from among the set of features that are toggled on when the electronically loaded drug library is in said pump.

[0059] FIG. 3 depicts an example sequence diagram 300 for automatically ordering a medical test (e.g., a diagnostic test) and adjusting an infusion device based on initiation or completion of the medical test, according to various aspects of the subject technology. The adjustment may include slowing or stopping an infusion therapy performed by the infusion device to improve compliance with medical test requirements that, for example, mandate a medical test when infusing particular fluids. For explanatory purposes, the various interactions of sequence diagram 300 are described with reference to the components and/or processes described above in FIGS. 1 A through 2.

[0060] A system implementing the subject technology may include an infusion device 302 (e.g., patient care device 102 of FIGS. 1A and IB, or patient care device 202 of FIG. 2), a clinician device 304 (e.g., device terminal 240 of FIG. 2, a computer, or a smart device), and an EMR server 306 (e.g., information system server 242 of FIG. 2). The system can also include other devices discussed herein, such as those described with respect to the institutional patient care system 200 of FIG. 2.

[0061] In the depicted example sequence diagram 300, the infusion device 302 determines (e.g., detects) a current volume provided (e.g., an amount of fluid provided since the therapy started) during an infusion therapy or a current duration of the infusion therapy (310) (e.g., an amount of time since the therapy started). On determining that the volume satisfies a threshold amount or that the duration satisfies a threshold duration (311), the infusion device 302 automatically (e.g., without further user interaction or initiation) notifies a clinician of a medical test requirement or recommendation (e.g., for a diagnostic test) for the infusion therapy (312A). The notice to the clinician can be provided, for example, via a display of the infusion device 302 (see, e.g., FIGS. 4A and 4B). Or, as another example, the notice can be provided via the clinician device 304 (e.g., a smartphone or tablet notification).

[0062] The medical test requirement or recommendation may be preprogrammed into a drug library used by the infusion device (e.g., in coordination with a drug manufacturer or drug guidelines of a healthcare institution or hospital at which the infusion therapy is administered). When required, in some implementations, the reason for the requirement may be provided to the user of the infusion device. For example, the infusion device may notify the clinician that the healthcare institution requires a PTT test after administering heparin for two hours (see, e.g., notice 402 of FIG. 4A). As another example, the infusion device may notify the clinician that the fluid manufacturer recommends a PTT test after administering 100 milliliters of heparin (see, e.g., notice 404 of FIG. 4B).

[0063] Alternatively, or additionally, the infusion device 302 can, based on predetermined programming (e.g., information stored in a drug library), automatically order the required or recommended medical test from the EMR server 306 (312B) after determining that the volume satisfies the threshold volume or that the duration exceeds the threshold duration. For example, the infusion device may electronically transmit to the EMR server 306 a type of the medical test (e.g., a PTT test, a blood sugar test) and an identifier of the recipient of the infusion therapy (e.g., patient 106 of FIG. 1A).

[0064] The infusion device provides a fluid at a first predetermined operating speed while waiting to receive an indication that the medical test was initiated. In this regard, a processor of the infusion device may monitor a communication connection (e.g., network connection 220 of FIG. 2) for a signal (e.g., from clinician device 304 or EMR server 306) indicating that the medical test was initiated (or, in some implementations, completed). If the medical test is not initiated or completed within a predetermined amount of time (or after a predetermined amount of fluid is pumped), then the infusion device 302 may be configured to reduce the rate of the infusion therapy, for example, by decreasing the operating speed of a fluid pump of the infusion device 302. In some implementations, the predetermined amount of time is equal to a difference between the time at which the medical test is requested and the medical test is required or recommended. For example, if a medical test is required at two hours into an infusion therapy and the medical test is requested at one hour into the infusion therapy, then the predetermined amount of time may be an hour. In this manner, the infusion device 302 can slow the infusion therapy when the clinician fails to timely meet the medical test requirement or recommendation.

[0065] The infusion device 302 may receive confirmation that the medical test was completed or initiated, for instance, from the clinician (e.g., via a user interface of the infusion device 302), from the clinician device 304 (314 A), or from a query of a medical database such as the EMR server 306 (314B). After receiving the confirmation, the infusion device may then resume pumping the fluid at a programmed flow rate (315). In some implementations, the infusion device 302 may notify a user of the received confirmation (e.g., via a display of the infusion device 302). Moreover, in some implementations, the infusion therapy is associated with multiple medical test requirements, in which case the sequence diagram 300 outlined herein may repeat itself.

[0066] FIGS. 4A and 4B depict an example control unit 104 displaying example notices 402 and 404 regarding medical test requirements and recommendations, according to various aspects of the subject technology. As described above, a medical test can be automatically requested after an infusion therapy has continued for a predetermined amount of time or after a predetermined amount of fluid has been delivered during the infusion therapy. Requesting the medical test can include displaying a notice (e.g., notices 402 and 404) regarding the medical test via a display 114 of the control unit 104.

[0067] The first example notice 402 may provide an indication of a medical test requirement for completion of a PTT test after infusing heparin for 2 hours. The control unit 104 may display the first notice 402, for example, after determining that the amount of time the fluid pump (e.g., infusion pumps 130-133 of FIG. 1A or functional modules 206-209 of FIG. 2) has pumped heparin exceeds a time threshold (e.g., 1.5, 1.9, or 2.0 hours). The notice 402 indicates that the control unit 104 will pause the infusion 30 minutes after displaying the notice 402 if a PTT test is not completed before then. A user of the control unit 104 can confirm completion of the PTT test by selecting a confirmation button 406 on the display 114. Additionally, in some implementations, the control unit 104 can confirm completion of the PTT test based on an electronic medical record (EMR) of the patient receiving the infusion therapy.

[0068] The second example notice 404 may provide an indication of a medical test requirement for initiation of a PTT test after infusing 100 milliliters of heparin. The control unit 104 displays the second notice 404, for example, after determining that the amount of heparin the fluid pump has pumped exceeds a volume threshold (e.g., 80, 90, or 100 milliliters). The notice 404 indicates that the control unit 104 will slow the infusion after pumping another 20 milliliters if a PTT test is not initiated before then. A user of the control unit 104 can confirm initiation of the PTT test by selecting a confirmation button 408 on the display 114. Additionally, the control unit 104 can confirm initiation of the PTT test based on the aforenoted EMR.

[0069] The example notices 402 and 404 may both indicate that a respective infusion therapy will be paused or slowed if a PTT test is not completed or initiated within a certain amount of time. However, the control unit 104 can also display notices after stopping or slowing the fluid pump (or otherwise adjusting the infusion device). For example, another notice might indicate that the infusion has already been stopped or slowed and that the flow rate of the fluid pump will be increased (e.g., to a programmed flow rate) only after the requested medical test is completed, initiated, or ordered.

[0070] Furthermore, each of the example notices 402 and 404 may suggest a delay between presentation of the respective notice and adjustment of the infusion (pausing in notice 402 and slowing in notice 404). As used herein, “adjustment-delay threshold” is used to refer to this delay. In some implementations, the adjustment-delay threshold is an amount of time, such as the “thirty minutes” of notice 402. In some implementations, the adjustment-delay threshold is an amount of fluid, such as the “20 mL” of notice 404. Further, in some implementations, the notice is displayed an amount of time prior to a time at which a medical test is required or recommended, where the amount of time is equal to the adjustment-delay threshold (or an amount of time needed to pump an amount of fluid equal to the adjustment-delay threshold). For example, if a particular medical test is required two hours into an infusion therapy, then the notice might be displayed thirty minutes prior to the two hour mark with an adjustmentdelay threshold of thirty minutes (see, e.g., notice 402).

[0071] FIG. 5 depicts an example process 500 for improving infusion device compliance with medical testing requirements, according to various aspects of the subject technology. For explanatory purposes, the present disclosure describes the blocks of example process 500 with reference to FIGS. 1-4, including the components and/or processes described therein. One or more of the blocks of process 500 may be implemented by one or more of the computing devices described herein, such as the patient care device 102 of FIGS. 1A and IB, the control unit 104 of FIGS. 1 A, IB, and 3, the patient care device 202 of FIG. 2, the infusion device 302, the clinician device 304, or the EMR server 306 of FIG. 3.

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

[0073] In the depicted example, a processor of an electronic device (e.g., patient care device 102 of FIGS. 1 A and IB, patient care device 202 of FIG. 2, infusion device 302 of FIG. 3, or control unit 104 of FIGS. 4A and 4B) causes a fluid pump (e.g., infusion pumps 130- 133 of FIG. 1 A or functional modules 206-209 of FIG. 2) to pump a fluid at an operating speed that corresponds to a programmed flow rate for a current infusion (502). While the fluid pump pumps the fluid, the processor determines (i) an amount of fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion (504). The processor then determines whether (i) the amount of fluid satisfies a volume threshold or (ii) the amount of time satisfies a duration threshold (506).

[0074] The volume and duration thresholds may correspond to medical test recommendations or requirements for infusion of the aforenoted fluid. For example, for some fluids (e.g., anticoagulants), medical testing is recommended (e.g., by the fluid manufacturer or the healthcare institution at which the fluid is administered) or even required (e.g., PTT testing) after providing a certain amount (e.g., 50 milliliters) of the fluid or after providing the fluid for a certain amount of time. Accordingly, if a medical test ought to be ordered based on a requirement or recommendation, for example, after providing 100 milliliters of the fluid, then 100 milliliters, or a volume less than 100 milliliters (e.g., 80 or 90 milliliters), may be used as the volume threshold. Likewise, if a medical test should be ordered, for instance, after providing the fluid for 2 hours, then the duration threshold may be 2 hours or less (e.g., 1.5 hours).

[0075] Either of the two thresholds can be determined by a user. For example, prior to the processor initiating an infusion therapy, the processor may receive the volume threshold or the duration threshold from a user input (e.g., via user interface device 230 of FIG. 2). However, in some implementations, at least one of the thresholds is determined by the processor (e.g., based on a type of the fluid) or retrieved by the processor from a lookup table (e.g., indexed by the fluid type).

[0076] After the processor determines that the amount of fluid satisfies the volume threshold or that the amount of time satisfies the duration threshold (506), the processor electronically transmits a request (508) to a server for a medical test (e.g., a diagnostic test request) pertaining to a target (e.g., patient 106 of FIG. 1 A) of the current infusion and initiates a timer (510). As an example, the request may be sent responsive to determining that the amount of fluid satisfies the volume threshold or that the amount of time satisfies the duration threshold. . The timer may be initiated, for example, concurrently with sending the request, after sending the request, or responsive to receiving acknowledgment from the server that the request was received or that the test was initiated.

[0077] In some implementations, transmitting the medical test request includes transmitting an order for the medical test to a server (e.g., EMR server 306 of FIG. 3), where the order includes, for example, a type of the medical test and an identifier of the target of the current infusion. In some implementations, transmitting the medical test request includes transmitting the medical test request to a display device associated with the processor (e.g., display 114 of FIGS. IB and 3 or a display of device terminal 240 of FIG. 2), where the display device is configured to display a notification of the medical test request. Moreover, in some implementations, the processor does not initiate the timer (510) until after determining that the medical test request was successfully received, for example, by the EMR server.

[0078] Additionally, the processor may determine an adjustment-delay threshold. Determining the adjustment-delay threshold (512) may involve retrieving the adjustment-delay threshold from a lookup table or calculating the adjustment-delay threshold, for example, based on operational parameters of the infusion therapy. The adjustment-delay threshold can be, for example, a programmed amount of time (or, in some implementations, a programmed amount of fluid) that provides a delay between transmission of the medical test request and a time at which an adjustment to the infusion device (e.g., a reduction in the fluid pump operating speed) will be made absent confirmation that the test was initiated or completed. In some implementations, the programmed amount of time of the adjustment-delay threshold is increased or decreased based on an importance of the medical test (e.g., whether the medical test is required or is simply recommended). For example, if the importance of the medical test is high (e.g., necessary for continuation of infusion therapy), then the adjustment-delay threshold may be short (e.g., five minutes). In this manner, the operating speed reduction can be expedited by shortening the adjustment-delay threshold, thereby avoiding pumping too much of the fluid without initiation or completion of the requested medical test.

[0079] After initiating the timer (510), the processor determines whether the timer satisfies (e.g., meets or exceeds) the adjustment-delay threshold (514). In some implementations, if the processor determines that the timer satisfies the adjustment-delay threshold (e.g., prior to determining that the test was initiated or completed, or that the threshold was not cancelled or extended for some other reason), the processor reduces the operating speed of the fluid pump (516). Reducing the operating speed of the fluid pump can include reducing the operating speed by a particular percentage (e.g., 25%) or by a fixed amount (e.g., 5 milliliters). Additionally, reducing the operating speed can include stopping the fluid pump entirely.

[0080] According to various implementations, the processor determines whether the medical test was initiated (or, in some implementations, ordered or completed) prior to the timer satisfying the adjustment-delay threshold. For example, the processor may actively monitor a server (e.g., the EMR server 306 of FIG. 6) or query a medical database associated with the server to determine a status of the medical test (e.g., ordered, initiated, completed). In some implementations, the processor will assume that the medical test was not initiated (or ordered or completed) unless the processor receives a confirmation to that effect, for example, from the medical database or from a user input (see, e.g., steps 314A and 314B of FIG. 3, or confirmation buttons 406 and 408 of FIGS. 4A and 4B).

[0081] If the medical test request is handled (e.g., medical test is initiated or completed) prior to the timer satisfying the adjustment-delay threshold, then the timer can be canceled so that the infusion device is not adjusted (e.g., not reducing the operating speed of the fluid pump). Likewise, in some implementations, if the medical test request is handled after the timer satisfies the adjustment-delay threshold and the infusion device has already been adjusted, then the infusion device can be un-adjusted (e.g., returned to its prior, pre-adjustment operation state). For example, this may include increasing the operating speed of the fluid pump to a preadjustment operating speed. The infusion device adjustment may help to ensure compliance with medical test recommendations or requirements. Thus, once a medical test recommendation or requirement is met, there may be no need to adjust the infusion device or continue with the adjustment thereto.

[0082] In some implementations, after transmitting the medical test request, the processor may determine that the medical test was initiated based on (i) a received confirmation of initiation (e.g., confirmation button 408 of FIG. 4B) or (ii) a query of a medical database (e.g., an EMR server that includes an EMR pertaining to the target of the current infusion). If the processor determines that the medical test was initiated, the processor can then (i) cancel the timer if the timer has not yet satisfied the adjustment-delay threshold or (ii) increase the operating speed of the fluid pump if the timer has already satisfied the adjustment-delay threshold (e.g., assuming the infusion pump was also adjusted responsive to the timer satisfying the adjustment-delay threshold). Increasing the operating speed of the fluid pump may include, for instance, increasing the operating speed to the operating speed that corresponds to the programmed flow rate for the current infusion.

[0083] Furthermore, in some implementations, after determining that the medical test was initiated, the processor may determine an order-completion threshold that defines a time at which the medical test needs to be completed in order to comply with a testing requirement or recommendation (e.g., a mandatory requirement) and then set a new timer. Since the adjustment-delay threshold was not satisfied, the order-completion threshold may be seen as extending the period of the adjustment-delay threshold to ensure that the medical test was not only initiated (as determined by the first timer not satisfying the adjustment-delay threshold) but also completed in accordance with medical testing requirements. The processor may then adjust the infusion pump (e.g., by reducing the operating speed thereof) if the new timer satisfies the order-completion threshold before completion of the medical test. The processor may then determine whether the medical test was completed based on (i) a received confirmation of completion (e.g., confirmation button 406 of FIG. 4 A) or (ii) another query of the aforenoted medical database. If the processor determines that the medical test was completed, then the processor can (i) cancel the timer before the timer satisfies the ordercompletion threshold or (ii) increase the operating speed of the fluid pump after the timer satisfies the order-completion threshold (or otherwise un-adjust the infusion device).

[0084] In some implementations, the adjustment-delay threshold is used to define a time by which the medical test must be completed (rather than initiated). For example, some medical testing requirements may mandate only a completion time (and not an initiation time). Accordingly, in some implementations, after transmitting the medical test request, the processor may determine that the medical test was completed based on (i) a received confirmation of completion (see, e.g., confirmation button 406 of FIG. 4A) or (ii) a query of a medical database (e.g., EMR server 306 of FIG. 3). If the processor determines that the medical test was completed, the processor can also (i) cancel the timer if the timer has not yet satisfied the adjustment-delay threshold or (ii) increase the operating speed of the fluid pump if the timer has already satisfied the adjustment-delay threshold (e.g., assuming the infusion pump was also adjusted responsive to the timer satisfying the adjustment-delay threshold). Increasing the operating speed of the fluid pump may include, for instance, increasing the operating speed to the operating speed that corresponds to the programmed flow rate for the current infusion.

[0085] The processor can also be configured to respond to a determination that a medical test device responsive for performing the medical test is offline, inoperative, or otherwise unavailable. In some implementations, after transmitting the medical test request, the processor receives an indication from an EMR server that a medical-test device (e.g., a coagulation analyzer, a blood-glucose meter) configured to perform the medical test is unavailable (e.g., offline, inoperative, or performing another medical test). Responsive to receiving the indication, the processor then displays a notice via a display device associated with the infusion device, where the notice indicates that the medical-test device is unavailable.

[0086] Additionally, in some implementations, after transmitting the medical test request, the processor receives an infusion cancelation request, and, responsive to receiving the infusion cancelation request, (i) stops the fluid pump, (ii) cancels the timer, and/or (iii) transmits a message to cause cancelation of the medical test. A medical test may no longer be necessary, for example, if the medical test was ordered based on a recommendation or requirement for a canceled infusion therapy. Accordingly, in this manner, the processor can preserve testing resources and avoid continuation of unnecessary medical tests.

[0087] Moreover, in some implementations, responsive to determining that the timer satisfies the adjustment-delay threshold, the processor displays a notice via a display device associated with the infusion device, where the notice indicates that the medical test is required for the fluid pump to continue pumping the fluid (e.g., at the programmed flow rate).

[0088] Furthermore, as noted above, the volume and duration thresholds can be determined by the processor based on various parameters related to the infusion therapy. In some implementations, prior to determining that the amount of fluid satisfies the volume threshold or that the amount of time satisfies the duration threshold, the processor receives a type of the fluid and, based on the fluid type, determines the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or determines the duration threshold prior to determining that the amount of time satisfies the duration threshold.

[0089] Relatedly, in some implementations, the processor receives an identifier of the target of the current infusion (e.g., the patient) and retrieves an EMR from an EMR server (e.g., EMR server 306 of FIG. 3) using the target identifier. Then, based on physiological data from the EMR (e.g., associated with the target of the current infusion), the processor determines the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or determines the duration threshold prior to determining that the amount of time satisfies the duration threshold.

[0090] FIG. 6 is a conceptual diagram illustrating an example electronic system 600 for improving infusion device compliance with medical testing requirements, according to various aspects of the subject technology. The electronic system 600 may be implemented by a computing device for execution of software associated with portions or steps of process 500 of FIG. 5, or components and methods provided by FIGS. 1-4. In this regard, the electronic system 600 may include the patient care device 102 of FIGS. 1A and IB, the patient care device 202 of FIG. 2, the infusion device 302 of FIG. 3, or the control unit 104 of FIGS. 4A and 4B.

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

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

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

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

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

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

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

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

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

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

[0101] As used in this specification and any claims of this application, the terms “computer,” “server,” “processor,” and “memory” all refer to electronic or other technological devices specifically configured with one or more of the features described above. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer-readable medium” and “computer-readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals. [0102] To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well. For example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, tactile feedback), and input from the user can be received in forms such as acoustic, speech, gesture, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user (e.g., by sending web pages to a web browser on a user’s client device in response to requests received from the web browser).

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

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

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

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

[0107] Illustration of Subject Technology as Clauses:

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

[0109] Clause 1. An infusion device comprising: a fluid pump; and a processor configured to: cause the fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion; determine (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion; determine (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold; responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmit a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiate a timer; determine an adjustment-delay threshold prior to an initiation or a completion of the medical test; and reduce the operating speed of the fluid pump when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated or completed. [0110] Clause 2. The infusion device of Clause 1, wherein the processor is further configured to (i) reduce the operating speed of the fluid pump if and when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated, and, (ii) after transmitting the medical test request: determine that the medical test was initiated based on (i) a received confirmation of initiation or (ii) a query of a medical database; and responsive to determining that the medical test was initiated, (i) cancel the timer if the timer has not yet satisfied the adjustment-delay threshold or (ii) increase the operating speed of the fluid pump if the timer has already satisfied the adjustment-delay threshold.

[OHl] Clause 3. The infusion device of Clause 2, wherein the processor is further configured to (i) reduce the operating speed of the fluid pump if and when a new timer satisfies an order-completion threshold prior to determining that the medical test was completed, and, (ii) after determining that the medical test was initiated: initiate the new timer; determine an order-completion threshold, wherein the order-completion threshold defines a time at which the medical test needs to be completed in order to comply with a mandatory medical testing requirement; determine that the medical test was completed based on (i) a received confirmation of completion or (ii) another query of the medical database; and responsive to determining that the medical test was completed, (i) cancel the new timer if the new timer has not yet satisfied the order-completion threshold or (ii) increase the operating speed of the fluid pump if the new timer has already satisfied the order-completion threshold.

[0112] Clause 4. The infusion device of any one of Clauses 1 through 3, wherein the processor is further configured to, after transmitting the medical test request: receive an indication from an electronic medical record (EMR) server that a medical-test device configured to perform the medical test is inoperative; and responsive to receiving the indication, display a notice via a display device associated with the infusion device, the notice indicating that the medical-test device is inoperative.

[0113] Clause 5. The infusion device of any one of Clauses 1 through 4, wherein the processor is further configured to, after transmitting the medical test request: receive an infusion cancelation request; and responsive to receiving the infusion cancelation request, (i) stop the fluid pump, (ii) cancel the timer, and (iii) transmit a message to cause cancelation of the medical test. [0114] Clause 6. The infusion device of any one of Clauses 1 through 5, wherein transmitting the medical test request comprises transmitting an order for the medical test to an electronic medical record (EMR) server, the order comprising a type of the medical test and an identifier of the target of the current infusion.

[0115] Clause 7. The infusion device of any one of Clauses 1 through 6, wherein reducing the operating speed comprises stopping the fluid pump, and the processor is further configured to, responsive to determining that the timer satisfies the adjustment-delay threshold, display a notice via a display device associated with the infusion device, the notice indicating that the medical test is required for the fluid pump to continue pumping the fluid.

[0116] Clause 8. The infusion device of any one of Clauses 1 through 7, wherein the processor is further configured to: receive a type of the fluid; and determine, based on the type of the fluid, (i) the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or (ii) the duration threshold prior to determining that the amount of fluid satisfies the duration threshold.

[0117] Clause 9. The infusion device of any one of Clauses 1 through 8, wherein the processor is further configured to: receive an identifier of the target of the current infusion; retrieve an electronic medical record (EMR) based on the target identifier and from an EMR server, the EMR comprising physiological data associated with the target of the current infusion; and determine, based on the physiological data, (i) the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or (ii) the duration threshold prior to determining that the amount of time satisfies the duration threshold.

[0118] Clause 10. The infusion device of any one of Clauses 1 through 9, wherein the fluid comprises an anticoagulant, the medical test comprises a PTT test or a PT test, and the processor is further configured to, after transmitting the medical test request: determine that the medical test was completed based on (i) a received confirmation of completion or (ii) an EMR pertaining to the target of the current infusion; responsive to determining that the medical test was completed, retrieve a result of the medical test from an EMR server; determine that the medical test result satisfies a safety threshold for administration of the anticoagulant; and responsive to determining that the medical test result satisfies the safety threshold, increase the operating speed of the fluid pump. [0119] Clause 11. A computer-implemented method for improving infusion device compliance with medical testing requirements, comprising: causing a fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion; determining (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion; determining (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold; responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmitting a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiating a timer; determining an adjustment-delay threshold prior to an initiation or a completion of the medical test; and reducing the operating speed of the fluid pump when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated or completed.

[0120] Clause 12. The computer-implemented method of Clause 11, further comprising

(i) reducing the operating speed of the fluid pump if and when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated, and,

(ii) after transmitting the medical test request: determining that the medical test was initiated based on (i) a received confirmation of initiation or (ii) a query of a medical database; and responsive to determining that the medical test was initiated, (i) canceling the timer if the timer has not yet satisfied the adjustment-delay threshold or (ii) increasing the operating speed of the fluid pump if the timer has already satisfied the adjustment-delay threshold.

[0121] Clause 13. The computer-implemented method of Clause 12, further comprising (i) reducing the operating speed of the fluid pump if and when a new timer satisfies an ordercompletion threshold prior to determining that the medical test was completed, and, (ii) after determining that the medical test was initiated: initiating the new timer; determining the ordercompletion threshold, wherein the order-completion threshold defines a time at which the medical test needs to be completed in order to comply with a mandatory medical testing requirement; determining that the medical test was completed based on (i) a received confirmation of completion or (ii) another query of the medical database; and responsive to determining that the medical test was completed, (i) canceling the new timer if the new timer has not yet the order-completion threshold or (ii) increasing the operating speed of the fluid pump if the new timer has already satisfied the order-completion threshold. [0122] Clause 14. The computer-implemented method of any one of Clauses 11 through

13, further comprising, after transmitting the medical test request: receiving an indication from an electronic medical record (EMR) server that a medical-test device configured to perform the medical test is inoperative; and responsive to receiving the indication, displaying a notice via a display device associated with the infusion device, the notice indicating that the medical-test device is inoperative.

[0123] Clause 15. The computer-implemented method of any one of Clauses 11 through

14, further comprising, after transmitting the medical test request: receiving an infusion cancelation request; and responsive to receiving the infusion cancelation request, (i) stopping the fluid pump, (ii) canceling the timer, and (iii) transmitting a message to cause cancelation of the medical test.

[0124] Clause 16. The computer-implemented method of any one of Clauses 11 through

15, wherein transmitting the medical test request comprises transmitting an order for the medical test to an electronic medical record (EMR) server, the order comprising a type of the medical test and an identifier of the target of the current infusion.

[0125] Clause 17. The computer-implemented method of any one of Clauses 11 through

16, wherein reducing the operating speed comprises stopping the fluid pump, and the method further comprises, responsive to determining that the timer satisfies the adjustment-delay threshold, displaying a notice via a display device associated with the infusion device, the notice indicating that the medical test is required for the fluid pump to continue pumping the fluid.

[0126] Clause 18. The computer-implemented method of any one of Clauses 11 through

17, further comprising: receiving a type of the fluid; and determining, based on the type of the fluid, (i) the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or (ii) the duration threshold prior to determining that the amount of fluid satisfies the duration threshold.

[0127] Clause 19. The computer-implemented method of any one of Clauses 11 through

18, further comprising: receiving an identifier of the target of the current infusion; retrieving an electronic medical record (EMR) based on the target identifier and from an EMR server, the EMR comprising physiological data associated with the target of the current infusion; and determining, based on the physiological data, (i) the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or (ii) the duration threshold prior to determining that the amount of time satisfies the duration threshold.

[0128] Clause 20. A non-transitory, computer-readable storage medium comprising instructions that, when executed by an electronic device, cause the electronic device to: cause a fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion; determine (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion; determine (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold; responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmit a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiate a timer; determine an adjustmentdelay threshold prior to an initiation or a completion of the medical test; and reduce an operating speed of the fluid pump when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated or completed.

[0129] Further Consideration:

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

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

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

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

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

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

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

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

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

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

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

Claims

What is claimed is:

1. An infusion device comprising: a fluid pump; and a processor configured to: cause the fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion; determine (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion; determine (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold; responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmit a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiate a timer; determine an adjustment-delay threshold prior to an initiation or a completion of the medical test; and reduce the operating speed of the fluid pump when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated or completed.

2. The infusion device of Claim 1, wherein the processor is further configured to (i) reduce the operating speed of the fluid pump if and when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated, and, (ii) after transmitting the medical test request: determine that the medical test was initiated based on (i) a received confirmation of initiation or (ii) a query of a medical database; and responsive to determining that the medical test was initiated, (i) cancel the timer if the timer has not yet satisfied the adjustment-delay threshold or (ii) increase the operating speed of the fluid pump if the timer has already satisfied the adjustment-delay threshold.

3. The infusion device of Claim 2, wherein the processor is further configured to (i) reduce the operating speed of the fluid pump if and when a new timer satisfies an order-completion threshold prior to determining that the medical test was completed, and, (ii) after determining that the medical test was initiated: initiate the new timer; determine the order-completion threshold, wherein the order-completion threshold defines a time at which the medical test needs to be completed in order to comply with a mandatory medical testing requirement; determine that the medical test was completed based on (i) a received confirmation of completion or (ii) another query of the medical database; and responsive to determining that the medical test was completed, (i) cancel the new timer if the new timer has not yet satisfied the order-completion threshold or (ii) increase the operating speed of the fluid pump if the new timer has already satisfied the order-completion threshold.

4. The infusion device of Claim 1, wherein the processor is further configured to, after transmitting the medical test request: receive an indication from an electronic medical record (EMR) server that a medicaltest device configured to perform the medical test is inoperative; and responsive to receiving the indication, display a notice via a display device associated with the infusion device, the notice indicating that the medical-test device is inoperative.

5. The infusion device of Claim 1, wherein the processor is further configured to, after transmitting the medical test request: receive an infusion cancelation request; and responsive to receiving the infusion cancelation request, (i) stop the fluid pump, (ii) cancel the timer, and (iii) transmit a message to cause cancelation of the medical test.

6. The infusion device of Claim 1, wherein transmitting the medical test request comprises transmitting an order for the medical test to an electronic medical record (EMR) server, the order comprising a type of the medical test and an identifier of the target of the current infusion.

7. The infusion device of Claim 1, wherein reducing the operating speed comprises stopping the fluid pump, and the processor is further configured to, responsive to determining that the timer satisfies the adjustment-delay threshold, display a notice via a display device associated with the infusion device, the notice indicating that the medical test is required for the fluid pump to continue pumping the fluid.

8. The infusion device of Claim 1, wherein the processor is further configured to: receive a type of the fluid; and determine, based on the type of the fluid, (i) the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or (ii) the duration threshold prior to determining that the amount of fluid satisfies the duration threshold.

9. The infusion device of Claim 1, wherein the processor is further configured to: receive an identifier of the target of the current infusion; retrieve an electronic medical record (EMR) based on the target identifier and from an EMR server, the EMR comprising physiological data associated with the target of the current infusion; and determine, based on the physiological data, (i) the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or (ii) the duration threshold prior to determining that the amount of time satisfies the duration threshold.

10. The infusion device of Claim 1, wherein the fluid comprises an anticoagulant, the medical test comprises a partial thromboplastin time (PTT) test or a prothrombin time (PT) test, and the processor is further configured to, after transmitting the medical test request: determine that the medical test was completed based on (i) a received confirmation of completion or (ii) an EMR pertaining to the target of the current infusion; responsive to determining that the medical test was completed, retrieve a result of the medical test from an EMR server; determine that the medical test result satisfies a safety threshold for administration of the anticoagulant; and responsive to determining that the medical test result satisfies the safety threshold, increase the operating speed of the fluid pump.

11. A computer-implemented method for improving infusion device compliance with medical testing requirements, comprising: causing a fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion; determining (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion; determining (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold; responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmitting a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiating a timer; determining an adjustment-delay threshold prior to an initiation or a completion of the medical test; and reducing the operating speed of the fluid pump when the timer satisfies the adjustmentdelay threshold prior to determining that the medical test was initiated or completed.

12. The computer-implemented method of Claim 11, further comprising (i) reducing the operating speed of the fluid pump if and when the timer satisfies the adjustment-delay threshold prior to determining that the medical test was initiated, and, (ii) after transmitting the medical test request: determining that the medical test was initiated based on (i) a received confirmation of initiation or (ii) a query of a medical database; and responsive to determining that the medical test was initiated, (i) canceling the timer if the timer has not yet satisfied the adjustment-delay threshold or (ii) increasing the operating speed of the fluid pump if the timer has already satisfied the adjustment-delay threshold.

13. The computer-implemented method of Claim 12, further comprising (i) reducing the operating speed of the fluid pump if and when a new timer satisfies an order-completion threshold prior to determining that the medical test was completed, and, (ii) after determining that the medical test was initiated: initiating the new timer; determining the order-completion threshold, wherein the order completion threshold defines a time at which the medical test needs to be completed in order to comply with a mandatory medical testing requirement; determining that the medical test was completed based on (i) a received confirmation of completion or (ii) another query of the medical database; and responsive to determining that the medical test was completed, (i) canceling the new timer if the new timer has not yet satisfied the order-completion threshold or (ii) increasing the operating speed of the fluid pump if the new timer has already satisfied the order-completion threshold.

14. The computer-implemented method of Claim 11, further comprising, after transmitting the medical test request: receiving an indication from an electronic medical record (EMR) server that a medicaltest device configured to perform the medical test is inoperative; and responsive to receiving the indication, displaying a notice via a display device associated with the infusion device, the notice indicating that the medical-test device is inoperative.

15. The computer-implemented method of Claim 11 , further comprising, after transmitting the medical test request: receiving an infusion cancelation request; and responsive to receiving the infusion cancelation request, (i) stopping the fluid pump, (ii) canceling the timer, and (iii) transmitting a message to cause cancelation of the medical test.

16. The computer-implemented method of Claim 11, wherein transmitting the medical test request comprises transmitting an order for the medical test to an electronic medical record (EMR) server, the order comprising a type of the medical test and an identifier of the target of the current infusion.

17. The computer-implemented method of Claim 11, wherein reducing the operating speed comprises stopping the fluid pump, and the method further comprises, responsive to determining that the timer satisfies the adjustment-delay threshold, displaying a notice via a display device associated with the infusion device, the notice indicating that the medical test is required for the fluid pump to continue pumping the fluid.

18. The computer-implemented method of Claim 11, further comprising: receiving a type of the fluid; and determining, based on the type of the fluid, (i) the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or (ii) the duration threshold prior to determining that the amount of fluid satisfies the duration threshold.

19. The computer-implemented method of Claim 11, further comprising: receiving an identifier of the target of the current infusion; retrieving an electronic medical record (EMR) based on the target identifier and from an EMR server, the EMR comprising physiological data associated with the target of the current infusion; and determining, based on the physiological data, (i) the volume threshold prior to determining that the amount of fluid satisfies the volume threshold or (ii) the duration threshold prior to determining that the amount of time satisfies the duration threshold.

20. A non-transitory, computer-readable storage medium comprising instructions that, when executed by an electronic device, cause the electronic device to: cause a fluid pump to pump a fluid at an operating speed corresponding to a programmed flow rate for a current infusion; determine (i) an amount of the fluid pumped by the fluid pump during the current infusion or (ii) an amount of time the fluid pump has pumped the fluid during the current infusion; determine (i) that the amount of fluid satisfies a volume threshold or (ii) that the amount of time satisfies a duration threshold; responsive to determining (i) that the amount of fluid satisfies the volume threshold or (ii) that the amount of time satisfies the duration threshold, (i) electronically transmit a request for a medical test to a server, the medical test pertaining to a target of the current infusion, and (ii) initiate a timer; determine an adjustment-delay threshold prior to an initiation or a completion of the medical test; and reduce an operating speed of the fluid pump when the timer satisfies the adjustmentdelay threshold prior to determining that the medical test was initiated or completed.