[go: up one dir, main page]

WO2024205577A1 - Systèmes et procédés de guidage de protocole automatisé - Google Patents

Systèmes et procédés de guidage de protocole automatisé Download PDF

Info

Publication number
WO2024205577A1
WO2024205577A1 PCT/US2023/016626 US2023016626W WO2024205577A1 WO 2024205577 A1 WO2024205577 A1 WO 2024205577A1 US 2023016626 W US2023016626 W US 2023016626W WO 2024205577 A1 WO2024205577 A1 WO 2024205577A1
Authority
WO
WIPO (PCT)
Prior art keywords
infusion
papr
test result
therapy
medical test
Prior art date
Application number
PCT/US2023/016626
Other languages
English (en)
Inventor
Lisa Diggett
Michael K. WORKMAN
Claire Ellen KNIGHT
Original Assignee
Carefusion 303, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Carefusion 303, Inc. filed Critical Carefusion 303, Inc.
Priority to PCT/US2023/016626 priority Critical patent/WO2024205577A1/fr
Publication of WO2024205577A1 publication Critical patent/WO2024205577A1/fr

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/168—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body
    • A61M5/16804—Flow controllers
    • A61M5/16827—Flow controllers controlling delivery of multiple fluids, e.g. sequencing, mixing or via separate flow-paths
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
    • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
    • A61M5/168—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body
    • A61M5/172—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body electrical or electronic
    • A61M5/1723—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body electrical or electronic using feedback of body parameters, e.g. blood-sugar, pressure
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/18—General characteristics of the apparatus with alarm
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/50—General characteristics of the apparatus with microprocessors or computers
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/50—General characteristics of the apparatus with microprocessors or computers
    • A61M2205/502—User interfaces, e.g. screens or keyboards
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/58—Means for facilitating use, e.g. by people with impaired vision
    • A61M2205/582—Means for facilitating use, e.g. by people with impaired vision by tactile feedback
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
    • A61M2205/00—General characteristics of the apparatus
    • A61M2205/60—General characteristics of the apparatus with identification means
    • A61M2205/6063—Optical identification systems
    • A61M2205/6072—Bar codes

Definitions

  • APRs automated programming requests
  • an infusion system includes an infusion control unit configured to receive a protocol-based automated programming request (pAPR).
  • pAPR protocol-based automated programming request
  • the pAPR includes a criterion for a therapy. Additionally, the pAPR instructs the infusion control unit to obtain a medical test result from a first electronic device. The pAPR also instructs the infusion control unit to cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion. In addition to receiving the pAPR, the infusion control unit is also configured to obtain the medical test result from the first electronic device based at least in part on the pAPR.
  • the infusion control unit is further configured to select the primary operation responsive to determining that the medical test result satisfies the criterion or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion. Moreover, the infusion control unit is configured to perform the selected operation based at least in part on the pAPR.
  • a non-transitory, computer- readable medium includes instructions that, when executed by an infusion control unit, cause the infusion control unit to perform various functions.
  • the functions include receiving a pAPR.
  • the pAPR includes a criterion for a therapy.
  • the pAPR instructs the infusion control unit to obtain a medical test result from a first electronic device.
  • the pAPR also instructs the infusion control unit to cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion.
  • the functions also include obtaining the medical test result from the first electronic device based at least in part on the pAPR.
  • the functions further include selecting the primary operation responsive to determining that the medical test result satisfies the criterion or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion.
  • the functions include performing the selected operation based at least in part on the pAPR.
  • a computer-implemented method for handling a pAPR includes receiving a pAPR at an infusion control unit.
  • the pAPR includes a criterion for a therapy.
  • the pAPR instructs the infusion control unit to obtain a medical test result from a first electronic device.
  • the pAPR also instructs the infusion control unit to cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion.
  • the method In addition to receiving the pAPR, the method also includes obtaining, at the infusion control unit, the medical test result from the first electronic device based at least in part on the pAPR. The method further includes selecting, at the infusion control unit, the primary operation responsive to determining that the medical test result satisfies the criterion or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion. Moreover, the method includes performing, at the infusion control unit, the selected operation based at least in part on the pAPR.
  • FIGS. 1A-1B depict an example patient care system that includes infusion pumps mounted to a control unit, according to various aspects of the subject technology.
  • FIG. 2 depicts an example institutional patient care system of a healthcare organization, according to various aspects of the subject technology.
  • FIG. 3 depicts an example system for automatically programming a medical device, according to various aspects of the subject technology.
  • FIGS. 4 A and 4B depict example flow diagrams for automatically programming one or more medical devices, according to various aspects of the subject technology.
  • FIGS. 5A-5C depict example flow diagrams for automatically programming one or more medical devices according to a given medical protocol (e.g., a pAPR), according to various aspects of the subject technology.
  • FIG. 6 depicts an example process for administering a protocol (e.g., a pAPR), according to various aspects of the subject technology.
  • FIG. 7 depicts an example control unit and example screens displayed thereon for administering a protocol, according to various aspects of the subject technology.
  • FIG. 8 is a flow diagram illustrating example screens presented to a clinician regarding patients and corresponding protocols, according to various aspects of the subject technology.
  • FIG. 9 is a conceptual diagram illustrating an example electronic system for automatically programming one or more medical devices to operate according to a given medical protocol, according to various aspects of the subject technology.
  • a protocol-based automated programming request coordinates a medical protocol - improving clinician efficiency and compliance with the requirements of the protocol.
  • protocol-based automated programming request or “pAPR” refers to a data structure that includes the parameters and steps required for administration of a given medical protocol that is not restricted to actions of a single device.
  • a pAPR may include information regarding the infusion of two different drugs from two different infusion pumps, as well as the total volume and flow rates for each of the drugs.
  • the pAPR may also include a step indicating that the patient ought to walk around for a certain amount of time between the two infusions, and that the clinician ought to confirm that the patient’s blood pressure does not exceed a predetermined threshold prior to administration of the second infusion therapy.
  • the pAPR may instruct a blood pressure device to measure the blood pressure of the patient and adjust an infusion pump’s delivery of a drug based on the measured pressure.
  • order may refer to a single infusion delivery (e.g., delivering an amount of a fluid via an infusion pump).
  • therapy may refer to a collection of drugs that can be used for multiple different protocols.
  • a “protocol” can include several different steps, some of which may be performed by an infusion pump whereas other steps may be performed off-pump.
  • pAPRs are defined at a server level.
  • a server may receive an order to execute a protocol (e.g., an open-heart surgery) for a patient.
  • the protocol may include gates, times, drug orders, vital sign readings, patient checks and corresponding confirmations, other electronic medical record (EMR) data, and the like.
  • EMR electronic medical record
  • the server can leverage one or more infusion control units (or patient care units) to present the protocol steps to a clinician. Further, the server can leverage the infusion control unit to track times, alert the clinician of steps, and so on. Additionally, or alternatively, the server can send protocol-related information to a portable electronic device of the clinician.
  • the infusion control unit is configured to administer one or more steps of the protocol.
  • the infusion control unit may also be configured to collect responses or confirmations from the clinician and to provide said responses or confirmations to EMR for documentation.
  • the infusion control unit can collect and/or have emergency or contingencies for the protocol cached, for example, in case the patient enters a danger zone. For instance, if the patient’s heart rate begins to drop below a certain threshold during a particular protocol, the infusion control unit may administer a particular drug to the patient.
  • the infusion control unit may also re-order protocol steps or parameters based on the circumstances (e.g., based on physiological measurements of the patient).
  • an infusion control unit can initiate an infusion and then take additional steps to continue the protocol.
  • the may include a gating item that must be completed before initiating an infusion for the patient.
  • the infusion control unit may, for example, display a reminder of the gating item and query whether the gating item has been completed.
  • Example gating items include obtaining a lab test (e.g., and receiving a particular result), moving the patient (e.g., walking for ten minutes), waiting for an amount of time (e.g., five minutes), checking the patient’s vital signs or hemodynamics, checking the patient’s respiratory status, monitoring the patient’s reaction (e.g., to the first infusion therapy), and querying electronic medical records (EMR) documentation.
  • a lab test e.g., and receiving a particular result
  • moving the patient e.g., walking for ten minutes
  • waiting for an amount of time e.g., five minutes
  • checking the patient’s vital signs or hemodynamics e.g., checking the patient’s respiratory status
  • monitoring the patient’s reaction e.g., to the first infusion therapy
  • EMR electronic medical records
  • the pAPR includes steps that do not directly involve the infusion control unit.
  • the infusion control unit may still be involved, for example, as follows: For gating events, such as those noted above, the infusion control unit may display a prompt or a reminder of the gating event. Additionally, for information needed by the infusion control unit (e.g., lab results, medical test results), the infusion control unit can initiate an application programming interface (API) call to request or otherwise obtain said information. Also, the infusion control unit can initiate a timer - for example, for steps that require something to occur after a predetermined amount of time (e.g., walking a patient for ten minutes prior to an infusion therapy, as discussed above).
  • API application programming interface
  • analytics associated with a pAPR may allow for enforcement of protocol. These can, for example, be implemented as an added layer of guardrails (e.g., in a drug library) to ensure the sequence required by the pAPR is performed within requisite safety parameters. Additionally, or alternatively, the aforesaid analytics may be used to collect data regarding compliance with pAPR steps in order to collect data regarding compliance (e.g., with respect to a particular therapy, a particular clinician, a particular healthcare facility, etc.).
  • An example clinician workflow implementing aspects of the pAPR technology disclosed herein might include: reviewing patient infusion orders at the start of the clinician’s shift, selecting a therapy “profile” for each patient, determining whether the therapy profiles deviate from standard profiles (e.g., to accommodate for patient needs), and sending the respective multi-step infusion therapies and associated pAPRs to the respective infusion control units. For the remainder of the clinician’s shift, all parts of each therapy for each patient would be available to the clinician (e.g., via the clinician’s portable electronic device, via a device terminal, or via the respective infusion control units). Moreover, if any of the infusion control units are interrupted, the clinician can pull up a list of the steps remaining for the respective pAPR and resume therapy accordingly.
  • FIG. 1A depicts an example patient care system 100 that includes infusion pumps 130-133 mounted to a control unit 104, according to various aspects of the subject technology.
  • the patient care system 100 shown in FIG. 1 A includes four infusion pumps ISO- 133, each of which is in operative engagement with a respective administration set 120-123 (e.g., silicon tubing).
  • the administration sets 120-123 connect the infusion pumps 130-133 to fluid supplies 110-113, which are inverted and suspended above the infusion pumps 130-133.
  • the fluid supplies 110-113 are depicted as bottles in FIG. 1A, but they may also take other forms (e.g., bags, other containers). Both the fluid supplies 110-113 and the patient care device 102 are mounted to a roller stand 108.
  • the fluid supplies 110-113, as well as their orientation (e.g., mount location, mount height, mounting type, etc.) within the care area, may generate one or more interaction records.
  • the interaction record for a set 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.
  • 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).
  • 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.
  • FIG. 1 A Typically, medical administration sets have more parts than are shown in FIG. 1 A. Many have check valves, drip chambers, valved ports, connectors, and other devices well known to those skilled in the art. These other devices have not been included in the drawings so as to preserve clarity of illustration.
  • FIG. IB depicts a closer view of a portion of the example patient care system 100 shown in FIG. 1A, according to various aspects of the subject technology.
  • FIG. IB shows the control module 104, with two of the infusion pumps 131-132 mounted at either side of the control unit 104 (also referred to herein as an infusion control unit).
  • the control unit 104 is configured for programming each of the infusion pumps 130-133.
  • FIG. IB also shows the displays and controls of each of the infusion pumps, such as display 124 and controls 126A-D of infusion pump 132.
  • Each of the infusion pumps 130-133 includes a door and a handle.
  • 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.
  • administration set 122 can be connected with the pump 132.
  • the administration set 122 is brought into operating engagement with the pumping mechanism, the upstream and downstream pressure sensors, and/or the other equipment of the infusion pump 132.
  • the display 124 of the infusion pump 132 (e.g., an LED display) is located in plain view on the door 128 in the depicted embodiment and may be used to visually communicate information regarding the infusion pump 132.
  • the display 124 can communicate alert indications (e.g., alarm messages).
  • the control keys 126A-D exist for programming and controlling operations of the infusion pump as desired.
  • 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.
  • the control unit 104 of the patient care device 102 includes a display 114 for visually communicating various information, such as the operating parameters of a connected pump or alert indications and alert messages.
  • the control unit 104 also includes control keys 116A-C for selecting or setting control parameters and/or options for controlling the control module 104 and modules connected thereto (e.g., infusion pumps 130-133).
  • control unit 104 may also include a speaker to provide audible alerts.
  • the display 114 is implemented as a touchscreen display.
  • 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.
  • the control keys 116A-C may select a corresponding option displayed in display 114.
  • the control unit 104 may include a communications system by which the control unit 104 can communicate with external equipment, such as a medical facility server, a handheld communication device, a laptop-type computer, or other information device that a clinician may have to transfer information as well as to download drug libraries to the control unit.
  • external equipment such as a medical facility server, a handheld communication device, a laptop-type computer, or other information device that a clinician may have to transfer information as well as to download drug libraries to the control unit.
  • 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 BLUETOOTHTM system, or other wired or wireless system.
  • RF radio frequency
  • 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.
  • modules may be connected to the infusion pumps 130-133 or to the control unit 104 such as a syringe pump module, patient controlled analgesic module, end-tidal CO2 monitoring module, oximeter monitoring module, or the like.
  • pressure measurements from upstream and/or downstream pressure sensors in the infusion pumps 130-133 are transmitted to a server or other coordination device, and the methods disclosed herein are implemented on the server or other coordination device.
  • a server or other coordination device For example, more sophisticated and computationally intensive approaches like machine-learning can be implemented on the server (or on a PCU with a larger memory and/or CPU resources).
  • machine learning is used to identify empty conditions based on pressure signals received from the pump.
  • FIG. 2 depicts an example institutional patient care system 200 of a healthcare organization, according to various aspects of the subject technology.
  • a patient care device 202 e.g., patient care device 102 of FIGS. 1 A-1B
  • an internal healthcare network 236 The term patient care device, or “PCD,” may be used interchangeably with the term patient care unit, or “PCU,” either of which may include various ancillary medical devices such as an infusion pump (e.g., infusion pumps 130-133 of FIG.
  • an infusion pump e.g., infusion pumps 130-133 of FIG.
  • a vital signs monitor e.g., a medication dispensing device (e.g., cabinet, tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned (e.g., a syringe pump module coupled with an infusion pump), or other similar devices.
  • a medication dispensing device e.g., cabinet, tote
  • a medication preparation device e.g., a medication preparation device
  • an automated dispensing device e.g., a module coupled with one of the aforementioned (e.g., a syringe pump module coupled with an infusion pump), or other similar devices.
  • a module coupled with one of the aforementioned e.g., a syringe pump module coupled with an infusion pump
  • Each element of the patient care device 202 is connected to an internal healthcare network 236 by a transmission channel 234.
  • Transmission channel 234 is any wired or wireless transmission channel, such as an 802.11 wireless
  • the internal healthcare network 236 also includes computer systems located in various departments throughout a hospital.
  • the network 236 optionally includes computer systems associated with an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers, and/or a medical decision support system.
  • the internal healthcare network 236 may include discrete subnetworks.
  • network 10 includes a device network 238 by which the patient care device 202 and other devices communicate in accordance with normal operations.
  • institutional patient care system 200 may incorporate a separate information system server 242 (e.g., a health information system (HIS) server). Moreover, although the information system server 242 is shown as a separate server, the functions and programming of the information system server 242 may be incorporated into another computer. Institutional patient care system 200 may further include a device terminal 240 for connecting and communicating with information system server 242.
  • the device terminal 240 may include personal computers, personal data assistances, and mobile devices such as laptops, tablet computers, augmented reality devices, or smartphones, configured with software for communications with information system server 242 via the internal healthcare network 236.
  • Patient care device 202 comprises a system for providing patient care, and may include or incorporate pumps (e.g., infusion pumps 130-133 of FIG. 1A), physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors), therapy devices, and other drug delivery devices may be utilized according to the teachings set forth herein.
  • pumps e.g., infusion pumps 130-133 of FIG. 1A
  • physiological monitors e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors
  • therapy devices e.g., oximeter, and other drug delivery devices
  • patient care device 202 comprises a control unit 204 (e.g., control unit 104 of FIGS. 1A-1B), also referred to as interface unit 204, connected to one or more functional modules 206-209 (e.g., infusion pumps 130-133 of FIG. 1 A).
  • Control unit 204 includes a central processing unit (CPU) 218 connected to a memory, for example, random access memory (RAM) 222, and one or more interface devices such as user interface device 230, a coded data input device 232, a network connection 220, and an auxiliary interface 226 for communicating with additional modules or devices.
  • CPU central processing unit
  • RAM random access memory
  • 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.
  • main non-volatile storage unit 228, such as a hard disk drive or non-volatile flash memory for storing software data.
  • control unit 204 may include one or more internal buses 224 for interconnecting the aforementioned elements.
  • 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.
  • 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).
  • PDA portable personal data assistant
  • the user interface device 230 and the data input device 232 may be the same device.
  • the data input device 232 is shown in FIG. 2 as being disposed within the control unit 204, it is recognized that the data input device 232 may be external to the control unit 204 (e.g., at the device terminal 240).
  • 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.
  • 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.
  • Network connection 220 may be a wired or wireless connection, such as by Ethernet, WiFi, BLUETOOTH, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem or a cable modem. Any direct or indirect network connection may be used, including, but not limited to a telephone modem, an MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link or a WLANS connection or other wireless connection.
  • the functional modules 206-209 are devices (e.g., infusion pumps 130-133 of FIG. 1A) for providing care to a patient or for monitoring patient conditions. As shown in FIG.
  • 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.
  • 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.
  • the functional modules 206-209 may be a printer, a scanner, a bar code reader, a near-field communication reader, an RFID reader, or any other peripheral input, output or input/output device.
  • 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.
  • 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.
  • 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.
  • 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.
  • NIM network interface module
  • IP Internet Protocol
  • 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.
  • the patient care device 202 and the internal healthcare network 236 may communicate via automated interaction, manual interaction, or a combination of both automated and manual interaction.
  • Automated interaction may be continuous or intermittent and may occur through direct network connection 220, as shown in FIG. 2, or through RS232 links, MIB systems, RF links such as BLUETOOTH, IR links, WLANS, digital cable systems, telephone modems, or other wired or wireless communication means.
  • 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.
  • 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 patient care device 202 is capable of operating in several different modes, or personalities, with each personality defined by a configuration database.
  • the configuration database may be a database 226 internal to the patient care device 202, or an external database 244.
  • a particular configuration database is selected based, at least in part, by patient-specific information such as patient location, age, physical characteristics, or medical characteristics.
  • 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.
  • 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.
  • the memory of the control unit 204 may contain a drug library, an event log, and/or infusion pump configuration settings, such as profiles to be used in particular practice areas (e.g., ICU, PED, etc.).
  • the control unit 204 memory may be electronically loadable memory such as non-volatile memory (e.g., EEPROM).
  • Drug libraries stored on pumps which illustratively contain such information as the drug names, ranges of delivery parameter values such as proper concentrations, dosage units, and dose limits, can be used to perform drug-calculation-based infusions in a clinical setting.
  • 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.
  • BSA body surface area
  • 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.
  • FIG. 3 depicts an example system 300 for automatically programming a medical device, according to various aspects of the subject technology.
  • Interoperability between a hospital electronic medical records (EMR) server e.g., information system server 242 of FIG. 2
  • medical devices e.g., patient care device 102 of FIGS. 1A-B, patient care device 202 of FIG. 2
  • EMR electronic medical records
  • Pre-population of infusion parameters may reduce the number of programming screens and key presses required with manually programming a pump.
  • the implementation of interoperability does not preclude a clinician from manually programming the infusion device. Manual programming may be required in the event of a failure in any component of the interfaced system.
  • features may be described with reference to an EMR server, the features are applicable to provide scan-less auto-programming of medical devices using similar hospital information systems such as pharmacy data management systems (PDMS).
  • PDMS pharmacy data management systems
  • the features may be described using an infusion pump as the example medical device, the features are applicable to provide scan-less auto-programming of other medical devices using barcodes for association such as patient monitors, patient association management systems, or alarms management systems.
  • a clinician may scan a medical item such as an infusate package using a scanner associated with a medical device, such as the infusion device 310.
  • a bar code reader or other data input device is used to scan the coded drug label, the patient’s coded ID band and the caregiver’s ID badge, and optionally supplementary prescription information or medical device configuration instructions (including configuration database ID) printed on the label or an accompanying order.
  • the scanning initiates a process by which information pertaining to the item (e.g., scanned from a code affixed to or transmitted by the item) is automatically sent to the hospital EMR system 302 via a network (e.g., internal healthcare network 236) (see operation 322).
  • the EMR system 302 may confirm the item and generate (see operation 324) and send an automated programming request (APR) to the infusion device 310 to load parameters pertaining to the item.
  • the parameters may be stored in the infusion device 310, but loaded in response to an identifier received from the server. While the examples herein involve an infusion device, any medical device may be configured in the same or similar manner and employ the automated programming error mitigation described herein.
  • a coordination engine 308 coordinates messages sent from the EMR system 302 to the infusion device 310.
  • the EMR system 302 transmits an APR (see operation 326) to the pump coordination engine 308 with a device identifier, also known as a “device ID,” of the infusion device 310 to receive the APR.
  • the pump coordination engine 308 determines whether the infusion device 310 identified by the EMR system 302 is available and, if so, forwards the APR to the infusion device 310 (see operation 328).
  • the infusion device 310 programs itself according to the parameters of the APR.
  • the APR activates a drug library stored on the infusion device 310, and the infusion device 310 is programmed according to parameters stored in the drug library for medication identified in the APR.
  • the infusion device may automatically initiate operation based on the parameters.
  • the infusion device 310 may confirm the automatically entered parameters (see operation 330). The confirmation may include presenting one or more user interface screens including the parameters and values along with a control element (e.g., a button) that, when activated, causes the infusion device to begin operation based on the parameters.
  • the user interface may include additional or alternative control elements to allow a clinician to adjust an automatically entered parameter based on, for example, professional judgement or changes in patient condition.
  • FIGS. 4A and 4B depict example flow diagrams 400 and 450 for automatically programming one or more medical devices, according to various aspects of the subject technology.
  • the various blocks of example flow diagrams 400 and 450 are described herein with reference to FIGS. 1 A-3, as well as the associated components and/or processes described herein.
  • FIG. 4A depicts a first example flow diagram 400 for automatically programming one or more medical devices using an automated programming request (APR), according to various aspects of the subject technology.
  • APR automated programming request
  • an identifier of a patient and/or a medical device e.g., infusion device 310 of FIG. 3
  • an EMR terminal 404 e.g., device terminal 240 of FIG. 2, or EMR terminal 306 of FIG. 3
  • an identifier of the medical device may be scanned from a barcode affixed to the medical device in conjunction with parameters entered into the terminal for selecting and generating an APR (see operation 322 of FIG. 3).
  • Entering the patient or medical device identifier initiates a process whereby information pertaining to the patient and/or the medical device is automatically sent to an EMR server 406 (e.g., information system server 242 of FIG. 2, or EMR system 302 of FIG. 3) of a hospital, and the EMR server 406 performs certain actions pertaining to the patient and/or the medical device and generates and sends an APR to the medical device to configure the medical device.
  • an EMR server 406 e.g., information system server 242 of FIG. 2, or EMR system 302 of FIG.
  • the subject technology provides a mechanism to automatically program a medical device without a scanner or manual translation of identifiers between the medical device and a terminal such as the EMR terminal 404.
  • the scan-less device identification functionality of the subject technology enables a user to explicitly publish a message from a medical device to any data consumer (e.g., the EMR server 406) based on automated device identification propagation.
  • the identifier is automatically sent to the consumer, which then correlates the identifier with other data to generate the APR and send the APR instructions back to the medical device.
  • a hospital system implementing the subject technology may include one or more infusion devices 402 (e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2, or infusion device 310 of FIG. 3).
  • the infusion device(s) 402 may additionally or alternatively include other devices for carrying out a medical protocol, such as a syringe pump, or a smartphone or tablet computer (e.g., for monitoring the medical protocol). These devices may also be referred to as “protocol devices” or “therapy devices.”
  • the hospital system may also include the EMR terminal 404 and the EMR server 406 connected to a connectivity gateway 408.
  • the connectivity gateway 408 is part of or associated with a coordination engine (e.g., pump coordination engine 308 of FIG. 3).
  • the connectivity gateway 408 is a separate system.
  • the connectivity gateway 408 may include one or more computing devices such as servers apart from the EMR server 406.
  • the connectivity gateway 408 may be implemented by or interchangeable with the pump coordination engine 308 of FIG. 3.
  • the EMR server 406 and the connectivity gateway 408 may co-exist as a single server or group of servers.
  • the information system server 242 of FIG. 2 may be representative of the EMR server 406 and/or the connectivity gateway 408.
  • the infusion device(s) 402 includes a user interface element that, when activated, is configured to transmit, via a communication network (e.g., internal healthcare network 236 of FIG. 2), a message indicating that the infusion device is ready to receive automated programming.
  • a communication network e.g., internal healthcare network 236 of FIG. 2
  • the infusion device(s) 402 may display on its display screen (e.g., display 114 of FIG. IB) a virtual button as the interface element.
  • the virtual button may be activated by touch activation in implementations where the display screen is a touch screen, or may be activated by selecting a corresponding control key (e.g., control keys 116A-C of FIG. IB).
  • a clinician interacts with (e.g., authenticates at) the EMR terminal 404 (see operation 410).
  • the EMR terminal 404 may then obtain the clinician’s identification by way of the clinician interaction.
  • the clinician inputs additional identifiers, such as a care area identifier, a patient identifier, a drug identifier, or other identifying information for requesting an APR be sent to the infusion device(s) 402.
  • the identifying information obtained via the terminal 404 is then transmitted to the EMR server 406 as a request to automatically program an infusion device (see operation 411).
  • the request does not include an identification of the infusion device(s) 402 to be programmed. Accordingly, the infusion device to programmed may not yet be known by the system.
  • the interface element is activated and the infusion device(s) 402 or a module connected thereto sends a message to the connectivity gateway 408 indicating that the infusion device(s) 402 is ready to receive automated programming.
  • the message may include, for example, parameters such as an identifier of the infusion device(s) 402 (e.g., a serial number), an identifier of a clinician assigned to the infusion device 402 (e.g., an identifier of a clinician logged into the device), a care area of the device, a patient care unit identifier (e.g., if the device is part of a PCU device), and/or an identifier of a patient associated with the infusion device, and the like.
  • parameters such as an identifier of the infusion device(s) 402 (e.g., a serial number), an identifier of a clinician assigned to the infusion device 402 (e.g., an identifier of a clinician logged into the device), a care area of the device, a patient care unit identifier (e.g., if the device is part of a PCU device), and/or an identifier of a patient associated with the infusion device, and the like.
  • the interface element is activated after a determination is made (e.g., by the infusion device(s) 402, by a hospital information system) that the infusion device(s) 402 is in an operational state to be programmed for performing a therapy (e.g., administration of a medication to a patient).
  • a therapy e.g., administration of a medication to a patient.
  • the interface element is a virtual button displayed on a touchscreen (e.g., display 114 of FIG. IB).
  • the interface element includes a control key (e.g., control keys 116A-C of FIG. IB) associated with the option of sending the message indicating that the device is ready to receive automated programming.
  • each active channel on the infusion device(s) 402 may be associated with a virtual button and/or a control key, and the clinician may select the appropriate interface element to send the message on behalf of the channel.
  • the connectivity gateway 408 informs the EMR server 406 that the infusion device(s) 402 is ready to receive automated programming via messaging (see operation 413).
  • the EMR server 406 based on the request sent by the EMR terminal 404, searches for and identifies all active medical devices that have indicated they are ready to receive automated programming (see operation 414) and returns a list of the active and ready devices to the EMR terminal 404 (see operation 415). The clinician then finds the infusion device(s) 402 within the list and selects the infusion device(s) 402 for automated programming according to the previously entered request.
  • the EMR terminal 404 sends the selected identification of the infusion device(s) 402 to the connectivity gateway 408 (see operation 416), and the connectivity gateway 408 associates the device identifier with the APR and sends the APR to the infusion device(s) 402 (see operation 417).
  • the infusion device(s) 402 will start and begin to infuse a medication according to the programming provided by the APR. After the infusion has begun, the infusion device(s) 402 will send one or more status messages to the EMR server 406.
  • a status message informs the EMR system what was started and includes certain values on which the infusion device(s) 402 is reporting. This information may reflect the APR data and/or may include changes made at the device.
  • the EMR server 406 may wait for the status message and, upon receiving the message, close out the workflow pertaining to the APR.
  • FIG. 4B depicts a second example flow diagram 450 for automatically programming one or more medical devices using an APR, according to various aspects of the subject technology.
  • a request for APR originating at the EMR terminal 404 and the APR is associated with one or more infusion device(s) 402 at the connectivity gateway 408 automatically rather than at the EMR server 406 as shown in FIG. 4 A.
  • the EMR terminal 404 may request auto-programming for a patient or a drug order for a patient, for example, without including a device identifier (see operation 460).
  • the connectivity gateway 408 receives the request from the terminal 206 (see operation 461) in addition to separate indications that one or more infusion devices 402 are ready to receive an APR (see operation 462). In this regard, multiple available devices may be identified (425) by the connectivity gateway for execution of a given protocol.
  • the connectivity gateway 408 Based at least in part on the received request and indication (see operations 461- 462), the connectivity gateway 408 automatically associates the infusion device(s) 402 and the EMR terminal 404 (see operation 463). This allows the previously unassociated APR request from the EMR terminal 404 to be routed to the infusion device(s) 402.
  • the medical device(s) 402 may provide a clinician identifier, a care area identifier, and/or a patient identifier. Similarly, the clinician may enter the same information at the EMR terminal 404. If these data points correspond, then the connectivity gateway 408 may automatically provide the APR without further human interaction.
  • the association may be based on therapies required by a given medical order and/or protocol.
  • a protocol may be identified for a patient, and the system may then determine available medical devices for the protocol based on the patient identifier and/or protocol requirements or other information within the protocol.
  • FIGS. 5A-5C depict example flow diagrams for automatically programming one or more medical devices according to a given medical protocol (e.g., a pAPR), according to various aspects of the subject technology.
  • a given medical protocol e.g., a pAPR
  • FIG. 5 A depicts a first example flow diagram 500 for automatically programming one or more medical devices using a protocolbased APR (pAPR), according to various aspects of the subject technology.
  • pAPR protocolbased APR
  • one or more infusion devices 502 are associated with a patient (see operation 520).
  • the infusion device(s) 502 may be associated with a patient when a clinician enters an identifier of the patient into the infusion device(s) 502.
  • the data pertaining to the association e.g., identifiers of the infusion device(s), the patient care unit, or the patient is sent to the connectivity gateway 508.
  • a clinician interacts with a health information system (HIS) terminal 504 (e.g., an EMR terminal) (see operation 521) and selects a protocol via the HIS terminal 504 (see operation 522).
  • HIS health information system
  • the protocol may be a chemotherapy treatment or a multi-step infusion protocol.
  • the protocol may correspond to a protocol-based automated programming request (pAPR) that includes instructions for instructing infusion device(s) 502 and/or other therapy devices for administering the protocol.
  • pAPR protocol-based automated programming request
  • Interaction with the HIS terminal 504 may occur before or after associating the infusion device(s) 502 with the patient (see operation 520).
  • Selecting the protocol may cause the HIS terminal 504 to send information relevant to the protocol to an HIS server 506 (e.g., an EMR server).
  • HIS server 506 e.g., an EMR server
  • the HIS terminal 504 may send to the HIS server 506 a clinician identifier, a care area identifier, a patient identifier, a protocol identifier, and/or option indicators (e.g., indicating preference with regard to optional aspects of the protocol).
  • the HIS terminal 504 identifies one or more medical devices, such as the infusion device(s) 502 (see operation 523).
  • the HIS terminal 504 may identify the medical device as a device required for performing the protocol. In this manner, the HIS terminal 504 can indicate that the medical device is required for the protocol after the protocol is selected.
  • the HIS terminal 504 may identify devices that are associated with the patient (see operation 520) for which the protocol was selected.
  • the HIS terminal 504 may send the protocol (e.g., a pAPR; see operation 524) to the HIS server 506 for eventual transmission to the medical devices.
  • the HIS terminal 504 sends a patient identifier and/or a device identifier along with the protocol. Either of these identifiers may be used (e.g., by the HIS server 506 or the connectivity gateway 508) to determine which devices ought to receive the protocol.
  • the HIS server 506 may send the protocol along to a connectivity gateway 508 (e.g., connectivity gateway 408 of FIGS. 4A-4B) (see operation 525).
  • the HIS server 506 also sends an identifier of the one or more medical devices to the connectivity gateway 508. Accordingly, the connectivity gateway 508 can then send the protocol to the devices for which the connectivity gateway 508 received identifiers (see operation 526). While FIGS. 5A-5C depict the HIS server 506 and gateway 508 as separate devices, in some implementations, these devices may be incorporated into a single device. In this regard, the HIS server 506 may send the protocol to the devices identified at the HIS terminal 504.
  • FIG. 5B depicts a second example flow diagram 530 for automatically programming one or more medical devices using a pAPR, according to various aspects of the subject technology.
  • one or more infusion device(s) 502 is associated with a patient (see operation 550).
  • the infusion device(s) 502 may be associated with a patient when a clinician enters an identifier of the patient into the infusion device(s) 502.
  • the data pertaining to the association e.g., identifiers of the infusion device(s), the patient care unit, or the patient
  • the connectivity gateway 508 is sent to the connectivity gateway 508.
  • a clinician interacts with an HIS terminal 504 (e.g., an EMR terminal) (see operation 551) and selects a protocol via the HIS terminal 504 (see operation 552).
  • the protocol may be a chemotherapy treatment or a multi- step infusion protocol.
  • the protocol may correspond to a protocol-based automated programming request (pAPR) that includes instructions for instructing infusion device(s) 502 and/or other therapy devices for administering the protocol. Interaction with the HIS terminal 504 may occur before or after associating the infusion device(s) 502.
  • pAPR protocol-based automated programming request
  • Selecting the protocol may cause the HIS terminal 504 to send information relevant to the protocol to the HIS server 506.
  • the HIS terminal 504 may send to the HIS server 506 a clinician identifier, a care area identifier, a patient identifier, a protocol identifier, and/or option indicators (e.g., indicating preference with regard to optional aspects of the protocol).
  • the HIS server 506 identifies steps and device types associated with the protocol identifier (e.g., received from the HIS terminal 504) (see operation 553).
  • a protocol identifier e.g., a pAPR identifier
  • the protocol identifier may also be associated with device types including infusion devices, blood-pressure monitors, and/or smartphones or tablet computers.
  • the HIS server 506 also identifies devices of the device type that are associated with the protocol identifier (see operation 554). Further to the example above, the HIS server 506 may identify infusion devices, blood-pressure monitors, and/or smartphones or tablet computers (e.g., that are available for use, that are suitable for the protocol, that are within a certain distance of the intended treatment location).
  • the HIS server 506 After gathering necessary information (e.g., regarding steps or device types), the HIS server 506 sends a pAPR to the connectivity gateway 508 (see operation 555). Sending the pAPR to the connectivity gateway 508 may include sending a device identifier. For example, the HIS server 506 may send device identifiers for devices required or suggested for use in executing the pAPR. From there, the connectivity gateway 508 then sends the pAPR to the infusion device(s) 502 and/or other therapy devices (e.g., devices identified in operation 555) (see operation 556).
  • the connectivity gateway 508 sends the pAPR to the infusion device(s) 502 and/or other therapy devices (e.g., devices identified in operation 555) (see operation 556).
  • the HIS server 506 sends the pAPR directly to the infusion device(s) 502 and/or other therapy devices (e.g., rather than sending the pAPR to the connectivity gateway 508 and the connectivity gateway 508 sending the pAPR to the infusion device(s) 502).
  • FIG. 5C depicts a third example flow diagram 560 for automatically programming one or more medical devices using a pAPR, according to various aspects of the subject technology.
  • a device may not be associated with a patient or protocol at the same time as others.
  • a first protocol device 510 e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2, or infusion device 310 of FIG. 3 reports a protocol event to a protocol gateway 514 (e.g., connectivity gateway 408 or connectivity gateway 508) (see operation 580).
  • a protocol gateway 514 e.g., connectivity gateway 408 or connectivity gateway 508
  • Reporting the protocol event may include sending to the protocol gateway 514 a protocol identifier, a device identifier, a patient identifier, and/or information regarding the protocol event.
  • the first protocol device 510 may report the completion of an event (e.g., an infusion therapy) that is part of a protocol (e.g., a chemotherapy treatment).
  • the flow diagram 560 also depicts the protocol gateway 514 reporting the protocol event to an HIS server 506 (see operation 581). For example, after the protocol gateway 514 receives information from the first protocol device 510 regarding the completion of the protocol event, the protocol gateway 514 may report the protocol event’s completion to the HIS server 506. In this manner, the first protocol device 514 administering a protocol (e.g., as instructed by a pAPR) can stay in sync with other devices involved in administering the protocol, such as a second protocol device 512. [00111] After receiving the report of the protocol event from the protocol gateway 514, the HIS server 506 identifies one or more other devices associated with the patient identifier (see operation 582).
  • the HIS server 506 may identify each device associated with the given patient identifier (e.g., in conjunction with the provided protocol identifier, or other provided identifiers) to determine devices associated with the protocol for which an event was reported by the first protocol device 510. In the depicted flow diagram 560, the HIS server 506 identifies the second protocol device 512 as being associated with the protocol event reported by the first protocol device 510.
  • the HIS server 506 then sends a pAPR (e.g., corresponding to the aforementioned protocol) to the protocol gateway 514 (see operation 583).
  • Sending the pAPR to the protocol gateway 514 may include sending a device identifier.
  • the device identifier may indicate a device to which the pAPR or information regarding the pAPR ought to be sent, such as the first protocol device 510.
  • the protocol gateway 514 After receiving the pAPR from the HIS server 506, the protocol gateway 514 then sends the pAPR to the first protocol device 510 (e.g., identified by device identifiers sent from the HIS server 506 to the protocol gateway 514) (see operation 584).
  • the second protocol device 512 then associates with the patient identifier (see operation 585).
  • the second protocol device 512 may associate with the patient identifier after transmission of the pAPR from the protocol gateway 514.
  • the second protocol device 512 may associate with the patient identifier when a clinician enters the patient identifier into the second protocol device 512 or scans a barcode associated with the patient identifier at the second protocol device 512.
  • a clinician may enter a patient identifier into the second protocol device 512 to check whether there any active protocols (e.g., pAPRs) for the patient associated with the patient identifier (e.g., prior to the second protocol device 512 receiving the pAPR).
  • associating with the patient identifier includes sending information from the second protocol device 512 to the protocol gateway 514 (e.g., an indication that the second protocol device 512 is administering a protocol to the patient associated with the patient identifier).
  • the protocol gateway 514 after receiving the information from the second protocol device 512, the protocol gateway 514 identifies protocols (e.g., active protocols, pending protocols, complete protocols) associated with the patient identifier (see operation 586). Then, in some implementations, the protocol gateway 514 sends one or more of the identified protocols (e.g., pAPRs) to the second protocol device 512 (see operation 587).
  • protocols e.g., active protocols, pending protocols, complete protocols
  • the protocol gateway 514 sends one or more of the identified protocols (e.g., pAPRs) to the second protocol device 512 (see operation 587).
  • a clinician can use the second protocol device 512 to locate protocols associated with a patient by entering the patient’s identifier into the second protocol device 512 - thus providing alternative or additional means whereby the second protocol device 512 may receive pAPRs associated with a given patient identifier (e.g., as compared with operations 580-584).
  • a clinician may want to check for ongoing protocols (e.g., corresponding to ongoing procedures, therapies, and the like) for a given patient prior to beginning a new protocol with the patient.
  • ongoing protocols e.g., corresponding to ongoing procedures, therapies, and the like
  • completed protocols e.g., corresponding to ongoing procedures, therapies, and the like
  • a detailed treatment history e.g., which procedures, therapies, and the like the patient has completed.
  • the pAPR received by the second protocol device 512 may automatically configure the second protocol device 512 to carry out one or more steps of the protocol.
  • FIG. 6 depicts an example process 600 for administering a protocol (e.g., a pAPR), according to various aspects of the subject technology.
  • a protocol e.g., a pAPR
  • the various blocks of example process 600 are described herein with reference to FIGS. 1 A-5C, as well as the components and/or processes described herein.
  • the one or more of the blocks of process 600 may be implemented, for example, by one or more computing devices (e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2, or infusion device 310 of FIG. 3).
  • one or more of the blocks may be implemented based on one or more machine learning algorithms. In some implementations, one or more of the blocks may be implemented apart from other blocks, and by one or more different processors or devices. Further for explanatory purposes, the blocks of example process 600 are described as occurring in serial, or linearly. However, multiple blocks of example process 600 may occur in parallel. In addition, the blocks of example process 600 need not be performed in the order shown and/or one or more of the blocks of example process 600 need not be performed.
  • the example process 600 includes receiving (602) a protocol -based automated programming request (pAPR) that includes instructions and a criterion (e.g., a predetermined criterion).
  • a protocol -based automated programming request e.g., a predetermined criterion
  • the pAPR may be received at an infusion control unit (e.g., control unit 104 of FIGS. 1A-1B, control unit 204 of FIG. 2).
  • the instructions included in the pAPR instruct the infusion control unit to obtain a medical test result from a first electronic device (e.g., information system server 242 of FIG. 2, EMR server 406 of FIGS. 4A-4B, HIS server 506 of FIGS. 5A-5C).
  • a first electronic device e.g., information system server 242 of FIG. 2, EMR server 406 of FIGS. 4A-4B, HIS server 506 of FIGS. 5A-5C.
  • the instructions further instruct the infusion control unit to cause a first therapy device (e.g., infusion pumps 130-133 of FIG. 1, functional modules 206-209 of FIG. 2, first and/or second protocol devices 510/512 of FIG. 5C) to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion
  • a first therapy device e.g., infusion pumps 130-133 of FIG. 1, functional modules 206-209 of FIG. 2, first and/or second protocol devices 510/512 of FIG. 5C
  • the process 600 also includes obtaining (604) a medical test result from the first electronic device (e.g., based on the pAPR).
  • the medical test result is not obtainable from the first electronic device.
  • the medical test result may be stored on a server external to a main hospital server (e.g., on an HIS server of another medical care facility).
  • the process 600 may include determining that the medical test result can be obtained from a second electronic device (e.g., on the HIS server of the other medical care facility) (e.g., based on the pAPR).
  • the process 600 may further include obtaining the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device.
  • the process 600 includes determining (606) whether the medical test result satisfies (e.g., exceeds) the criterion included in the pAPR.
  • the medical test result may include a heart rate, a blood sugar level, a blood pressure level, a weight, or another physiological metric of a patient.
  • the process 600 includes selecting a primary operation. Moreover, responsive to determining (606) that the medical test result does not satisfy the criterion, the process 600 includes selecting a secondary operation. After selecting the primary or secondary operation, the process 600 includes performing (612) the selected operation (e.g., based on the pAPR).
  • the first therapy device may include a first infusion pump.
  • the primary operation may include activating the first infusion pump to administer a primary amount of a primary intravenous (IV) fluid.
  • the secondary operation involves administering a different amount of the primary IV fluid, such that the secondary operation includes activating the first infusion pump to administer a secondary amount of the primary IV fluid.
  • the secondary operation involves administering a different IV fluid, such that the secondary operation includes activating an infusion pump (e.g., the first infusion pump, a second infusion pump) to administer to administer an amount (e.g., the primary amount, the secondary amount) of a secondary IV fluid.
  • an infusion pump e.g., the first infusion pump, a second infusion pump
  • the amount or type of the IV fluid administered is selected or determined based on the medical test result.
  • the medical test result may indicate that the patient should receive an amount of the primary IV fluid (e.g., an analgesic) less than the primary amount (e.g., based on the patient’s weight, blood pressure, etc.).
  • the medical test result may indicate that the patient should not receive the primary IV fluid and should instead receive the secondary IV fluid (e.g., based on an allergy of the patient to the primary IV fluid).
  • the pAPR may require completion of an action prior to advancing the protocol.
  • the pAPR may require that the patient take a ten minute walk in between a first and second infusion therapy.
  • the process 600 may include displaying a prompt inquiring whether the action (e.g., the ten minute walk) has been completed.
  • the medical test result may include the response received to the prompt. If the response indicates that the patient has walked for ten minutes, then the primary operation (e.g., activating an infusion device to administer the second infusion therapy) will be selected.
  • the second operation e.g., displaying a reminder of to walk the patient for ten minutes
  • the second operation may include continuing to display the reminder until the infusion control unit receives an indication of completion of the action.
  • the process 600 may include performing the primary operation.
  • the secondary operation can act as an intermediary operation, performed prior to the primary operation in certain circumstances.
  • the process 600 includes providing a list of workflow protocols for display on a display device (e.g., display 114 of FIG. IB, user interface device 230 of FIG. 2, a smartphone or tablet computer) associated with the infusion control unit.
  • the process 600 may further include receiving a patient identifier and a selected workflow protocol from the list. Additionally, the process 600 may include identifying, based on the received patient identifier, the first therapy device and one or more second therapy devices.
  • the process 600 includes sending the pAPR to the first therapy device and the one or more second therapy devices responsive to identifying the first therapy device and the one or more second therapy devices based on the received patient identifier, wherein the pAPR provides the selected workflow protocol to the first therapy device and the one or more second therapy devices.
  • the process 600 includes providing a list of patients (e.g., screen 810 of FIG. 8) for display on a display device associated with the infusion control unit.
  • the process 600 may also include receiving a selected patient from the list. Additionally, the process can include determining that the pAPR is associated with the selected patient. Further, the process 600 may include activating, before the pAPR is received, a first graphically displayed control for display of a current status of the pAPR for the patient.
  • the process 600 includes receive two or more selected patients from the aforementioned list of patients. Further, the process 600 may include providing, for each respective patient of the two or more selected patients, a second graphically displayed control for activating the pAPR for the respective patient, wherein selection of the second graphically displayed control initiates a display of a protocol definition interface for configuring one or more parameters of the pAPR including setting the criterion for the therapy.
  • the process 600 may also include performing operations at a server (e.g., information system server 242 of FIG. 2, EMR system 302 of FIG. 3, EMR server 406 of FIGS. 4A-4B, or HIS server 506 of FIGS. 5A-5C).
  • a server e.g., information system server 242 of FIG. 2, EMR system 302 of FIG. 3, EMR server 406 of FIGS. 4A-4B, or HIS server 506 of FIGS. 5A-5C.
  • the process 600 may include identifying a second therapy device (e.g., infusion pumps 130-133 of FIG. 1, functional modules 206-209 of FIG. 2, first and/or second protocol devices 510/512 of FIG. 5C) being newly associated with a patient identifier.
  • the process 600 may also include determining, responsive to the identification, that the pAPR is active and in a current state on the first therapy device for the patient identifier.
  • the process 600 may include sending, responsive to the determination, the pAPR and an indication of the current state to the second therapy device. Moreover, the process 600 may include causing the second therapy device to perform a tertiary operation associated with the therapy and the current state. In some implementations, the second therapy device is configured to display an indication of the pAPR and the current state after receiving the pAPR, as depicted in screen 702 of FIG. 7.
  • the above-described example process 600, as well as related features and applications, may also be implemented as software processes that are specified as a set of specific instructions recorded on a computer readable storage medium (also referred to as computer readable medium), and may be executed automatically (e.g., without user intervention).
  • processing unit(s) When these specific instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions.
  • processing unit(s) e.g., one or more processors, cores of processors, or other processing units
  • Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc.
  • the computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.
  • the term “software” is meant to include, where appropriate, firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some implementations, multiple software aspects of the subject disclosure can be implemented as sub-parts of a larger program while remaining distinct software aspects of the subject disclosure. In some implementations, multiple software aspects can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software aspect described here is within the scope of the subject disclosure. In some implementations, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.
  • a computer program (also known as a program, software, software application, script, or code) can be written in a programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in one or more forms, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment.
  • a computer program may, but need not, correspond to a file in a file system.
  • a program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
  • a computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
  • FIG. 7 depicts an example control unit (e.g., control unit 104 of FIGS. 1A-1B, control unit 204 of FIG. 2) and example screens 702, 704, 706, and 708 displayed thereon for administering a protocol (e.g., a pAPR), according to various aspects of the subject technology.
  • a protocol e.g., a pAPR
  • a clinician can use a control unit to access protocols (e.g., pending pAPRs) for a given user.
  • the clinician is prompted to enter a patient identifier.
  • the clinician can enter the patient identifier manually (e.g., using buttons or touch inputs).
  • the clinician can enter the patient identifier by scanning a barcode associated with the patient identifier.
  • the server may determine that a medical protocol is associated with the patient and/or medical device.
  • the device indicates that the medical protocol (e.g., a pAPR) is pending.
  • the protocol may be pending for a patient identifier entered at screen 702. In this manner, the device can warn the clinician of pending or ongoing protocols for a patient prior to the clinician beginning a new protocol for the patient.
  • steps of the protocol are displayed, with the protocol including multiple infusions and a test (e.g., a biometric test).
  • the screen 706 also includes progress information regarding the steps. For example, the screen 706 can indicate which of the steps are completed, which are ongoing (e.g., 50% complete, 75% complete), and which are yet to begin.
  • a control element such as a softkey or graphical user interface icon may be activated. When the control element is interacted with, the device may use pAPR information to configure one or more parameters for administration of the selected step.
  • screen 708 detailed information regarding one of the steps is displayed (e.g., an infusion), with information regarding a volume to be infused (VTBI) and the corresponding flow rate.
  • the screen 708 may regard one of the multiple infusion steps displayed in screen 706. If the step was previously initiated, the screen 708 may provide a status of the step. If the step was not under execution by another device, the screen 708 may allow for review of automatic configuration parameters to be executed by the device.
  • FIG. 8 is a flow diagram illustrating example screens 810 and 812 presented to a clinician (e.g., via a control unit or an EMR terminal) regarding patients and corresponding protocols, according to various aspects of the subject technology.
  • a clinician logs into a system (e.g., via device terminal 240 of FIG. 2, EMR terminal 404 of FIGS. 4A-B, or HIS terminal 504 of FIGS. 5A-5B) at step 802
  • the system shows a list of patients (e.g., patients to which the clinician is assigned) in step 804.
  • the system may present a first screen 810 to the clinician (e.g., via a tablet computer or a smartphone) that includes the names of the patients in a list (e.g., ordered by priority).
  • the system can also present a second screen 812 that introduces additional information regarding the patients.
  • the information may indicate whether a patient has an ongoing protocol, whether the protocol requires immediate or urgent attention, whether the protocol is complete or nearing completion, and so on.
  • This information is suggested in the second screen 812 by the check mark (e.g., indicating completion) and the exclamation point (e.g., indicating urgency).
  • the second screen 812 also includes addition signs for each of the patients, suggesting that the clinician can add a new protocol or add a new step to an ongoing protocol for the respective patient.
  • Presentation of the second screen 812 may occur, for example, after the device at which the screen is displayed receives one or more protocols (e.g., pAPRs) for the respective patients. This is indicated by step 806, which relates to receiving the protocols. Additionally, step 808 describes adjusting the screen content to include the indicators regarding the received protocols - thus switching from displaying the first screen 810 to displaying the second screen 812.
  • protocols e.g., pAPRs
  • FIG. 9 is a conceptual diagram illustrating an example electronic system 900 for automatically programming one or more medical devices to operate according to a given medical protocol, according to various aspects of the subject technology.
  • Electronic system 900 may be a computing device for execution of software associated with one or more portions or steps of the processes outlined in FIGS. 4A-6. Additionally, electronic system 900 may be a computing device including components provided by FIGS.
  • electronic system 900 may be a specifically configured personal computer or a mobile device such as a smartphone, tablet computer, laptop, PDA, an augmented reality device, a wearable such as a watch or band or glasses, or combination thereof, or other touch screen or television with one or more processors embedded therein or coupled thereto, or similar computer-related electronic device having network connectivity.
  • a mobile device such as a smartphone, tablet computer, laptop, PDA, an augmented reality device, a wearable such as a watch or band or glasses, or combination thereof, or other touch screen or television with one or more processors embedded therein or coupled thereto, or similar computer-related electronic device having network connectivity.
  • the electronic system 900 may include various types of computer readable media and interfaces for various other types of computer readable media.
  • the electronic system 900 includes a bus 908, one or more processing unit(s) 912, a system memory 904, a read-only memory (ROM) 910, a permanent storage device 902, an input device interface 914, an output device interface 906, and one or more network interfaces 916.
  • the electronic system 900 may include or be integrated with other computing devices or circuitry specifically configured for operation of the various components and methods previously described.
  • the bus 908 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 900. For instance, bus 908 communicatively connects processing unit(s) 912 with the ROM 910, the system memory 904, and the permanent storage device 902.
  • the processing unit(s) 912 retrieves instructions to execute and data to process, in order to execute the processes of the subject disclosure.
  • the processing unit(s) 912 can be a single processor or a multi-core processor in different implementations.
  • the ROM 910 stores static data and instructions that are needed by processing unit(s) 912 and other modules of the electronic system.
  • Permanent storage device 902 is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when electronic system 900 is off. Some implementations of the subject disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as permanent storage device 902.
  • system memory 904 is a read-and-write memory device. However, unlike storage device 902, system memory 904 is a volatile read-and-write memory (e.g., randomaccess memory). System memory 904 stores some of the instructions and data that the processor needs at runtime. In some implementations, the processes of the subject disclosure are stored in system memory 904, permanent storage device 902, and/or ROM 910. From these various memory units, the processing unit(s) 912 retrieves instructions to execute and data to process in order to execute the processes of some implementations.
  • the bus 908 connects to input and output device interfaces 914 and 906.
  • Input device interface 914 enables the user to communicate information and select commands to the electronic system 900.
  • Input devices used with input device interface 914 include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”).
  • Output device interfaces 906 enables, for example, display of images generated by the electronic system 900.
  • Output devices used with output device interface 906 include, for example, printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices such as a touchscreen that functions as both input and output devices.
  • CTR cathode ray tubes
  • LCD liquid crystal displays
  • the bus 908 also couples the electronic system 900 to a network through the network interfaces 916.
  • the network interfaces 916 may include, for example, a wireless access point (e.g., a Bluetooth or WiFi access point) or radio circuitry for connecting to a wireless access point.
  • the network interfaces 916 may also include hardware (e.g., Ethernet hardware or a network interface module) for connecting the computer to a part of a network of computers such as a local area network (“LAN”), a wide area network (“WAN”), wireless LAN, or an Intranet, or a network of networks, such as the Internet.
  • LAN local area network
  • WAN wide area network
  • wireless LAN wireless local area network
  • Intranet or a network of networks, such as the Internet.
  • Any or all components of the electronic system 900 can be specially configured to be used in conjunction with the subject disclosure.
  • 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).
  • 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.
  • CD-ROM compact discs
  • CD-R recordable compact discs
  • 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.
  • ASICs application specific integrated circuits
  • FPGAs field- programmable gate arrays
  • 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.
  • display or displaying means displaying on an electronic device.
  • 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.
  • 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.
  • a display device e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
  • keyboard and a pointing device e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well.
  • 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.
  • a computer can interact with a user by sending documents to and receiving documents from a device that is used by the
  • 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).
  • 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.
  • 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).
  • 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
  • An infusion system comprising: a first therapy device; and an infusion control unit configured to: receive a protocol-based automated programming request (pAPR) that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause the first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtain the medical test result from the first electronic device based at least in part on the pAPR; select the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and perform the selected operation based at least in part on the pAPR.
  • pAPR protocol-based automated programming request
  • Clause 4 The infusion system of clause 3, further comprising the second therapy device, wherein the second therapy device is configured to display an indication of the pAPR and the current state after receiving the pAPR.
  • Clause 5 The infusion system of any one of clauses 1 through 4, wherein the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary intravenous (IV) fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.
  • the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary intravenous (IV) fluid
  • performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.
  • Clause 6 The infusion system of any one of clauses 1 through 5, further comprising a second infusion pump wherein the secondary operation comprises activating the second infusion pump to provide a secondary IV fluid different from the primary IV fluid.
  • Clause 7 The infusion system of any one of clauses 5 or 6, wherein the secondary amount or the secondary IV fluid is selected based on the medical test result obtained from the first electronic device.
  • Clause 8 The infusion system of any one of clauses 1 through 7, further comprising a display device, wherein performing the secondary operation comprises displaying a notice requiring completion of an action, receiving an indication that the action was completed, and performing the primary operation responsive to receiving the indication.
  • Clause 9 The infusion system of any one of clauses 1 through 8, wherein the infusion control unit is further configured to: provide a list of workflow protocols for display on a display device associated with the infusion control unit; receive a patient identifier and a selected workflow protocol from the list; identify, based on the received patient identifier, the first therapy device and one or more second therapy devices; and send the pAPR to the first therapy device and the one or more second therapy devices responsive to identifying the first therapy device and the one or more second therapy devices based on the received patient identifier, wherein the pAPR provides the selected workflow protocol to the first therapy device and the one or more second therapy devices.
  • the infusion control unit is further configured to: receive two or more selected patients from the list; and provide, for each respective patient of the two or more selected patients, a second graphically displayed control for activating the pAPR for the respective patient, wherein selection of the second graphically displayed control initiates a display of a protocol definition interface for configuring one or more parameters of the pAPR including setting the criterion for the therapy.
  • a non-transitory, computer-readable medium comprising instructions that, when executed by an infusion control unit, cause the infusion control unit to: receive a pAPR that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtain the medical test result from the first electronic device based at least in part on the pAPR; select the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and perform the selected operation based at least in part on the pAPR.
  • the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary IV fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.
  • Clause 15 The non-transitory, computer-readable medium of any one of clauses 12 through 14, wherein the secondary operation comprises activating a second infusion pump to provide a secondary IV fluid different from the primary IV fluid.
  • Clause 16 The non-transitory, computer-readable medium of any one of clauses 14 or 15, wherein the secondary amount or the secondary IV fluid is selected based on the medical test result obtained from the first electronic device.
  • Clause 17 The non-transitory, computer-readable medium of any one of clauses 12 through 17, further comprising a display device, wherein performing the secondary operation comprises displaying a notice requiring completion of an action, receiving an indication that the action was completed, and performing the primary operation responsive to receiving the indication.
  • a computer-implemented method for handling a pAPR comprising: receiving, at an infusion control unit, a pAPR that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtaining, at the infusion control unit, the medical test result from the first electronic device based at least in part on the pAPR; selecting, at the infusion control unit, the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and performing, at the infusion control unit, the selected operation based at least in part on the
  • Clause 19 The computer-implemented method of clause 18, further comprising: determining, at the infusion control unit, that the medical test result cannot be obtained from the first electronic device; determining, at the infusion control unit, that the medical test result can be obtained from a second electronic device different from the first electronic device based at least in part on the pAPR; and obtaining, at the infusion control unit, the medical test result from the second electronic device responsive to determining that the medical test result cannot be obtained from the first electronic device and can be obtained from the second electronic device.
  • Clause 20 The computer-implemented method of any one of clauses 18 or 19, wherein the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary IV fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.
  • a phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology.
  • a disclosure relating to an aspect may apply to all configurations, or one or more configurations.
  • An aspect may provide one or more examples.
  • a phrase such as an aspect may refer to one or more aspects and vice versa.
  • a phrase such as an “implementation” does not imply that such implementation is essential to the subject technology or that such implementation applies to all configurations of the subject technology.
  • a disclosure relating to an implementation may apply to all implementations, or one or more implementations.
  • An implementation may provide one or more examples.
  • a phrase such as an “implementation” may refer to one or more implementations and vice versa.
  • a “user interface” (also referred to as an interactive user interface, a graphical user interface, or a UI) may refer to a network-based interface including data fields or other control elements for receiving input signals or providing electronic information or for providing information to the user in response to any received input signals.
  • Control elements may include dials, buttons, icons, selectable areas, or other perceivable indicia presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiates an exchange of data for the device presenting the UI.
  • a UI may be implemented in whole or in part using technologies such as hyper-text mark-up language (HTML), FLASHTM, JAVATM, .NETTM, C, C++, web services, or rich site summary (RSS).
  • HTTP hyper-text mark-up language
  • FLASHTM FLASHTM
  • JAVATM JAVATM
  • .NETTM C, C++
  • web services or rich site summary (RSS).
  • 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.
  • 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.
  • 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.
  • the terms “provide” or “providing” encompass a wide variety of actions.
  • “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.
  • a message encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information.
  • a message may include a machine-readable aggregation of information such as an XML document, fixed field message, comma separated message, JSON, a custom mode, or the like.
  • a message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.
  • correspond encompasses a structural, functional, quantitative and/or qualitative correlation or relationship between two or more objects, data sets, information and/or the like, preferably where the correspondence or relationship may be used to translate one or more of the two or more objects, data sets, information and/or the like so to appear to be the same or equal. Correspondence may be assessed using one or more of a threshold, a value range, fu5y logic, pattern matching, a machine learning assessment model, or combinations thereof.
  • 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.
  • 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.
  • office, lab, etc. e.g., office, lab, etc.
  • 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).
  • 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.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Medical Informatics (AREA)
  • Epidemiology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Hematology (AREA)
  • Vascular Medicine (AREA)
  • Anesthesiology (AREA)
  • Veterinary Medicine (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Animal Behavior & Ethology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Diabetes (AREA)
  • Chemical & Material Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Medicinal Chemistry (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)

Abstract

L'invention concerne un système de perfusion comprenant un premier dispositif de thérapie et une unité de commande de perfusion. L'unité de commande de perfusion est configurée pour recevoir une demande de programmation automatisée basée sur un protocole (pAPR). La pAPR ordonne également à l'unité de commande de perfusion d'amener le premier dispositif de thérapie à effectuer une opération primaire associée à la thérapie si un résultat de test médical satisfait un critère ou d'amener le premier dispositif de thérapie à effectuer une opération secondaire associée à la thérapie si le résultat de test médical ne satisfait pas le critère. L'unité de commande de perfusion est également configurée pour obtenir le résultat de test médical à partir du premier dispositif électronique sur la base de la pAPR. De plus, l'unité de commande de perfusion est configurée pour sélectionner l'opération primaire en réponse à la détermination du fait que le résultat de test médical satisfait le critère, ou autrement sélectionner l'opération secondaire. En outre, l'unité de commande de perfusion est configurée pour effectuer l'opération sélectionnée sur la base de la pAPR.
PCT/US2023/016626 2023-03-28 2023-03-28 Systèmes et procédés de guidage de protocole automatisé WO2024205577A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2023/016626 WO2024205577A1 (fr) 2023-03-28 2023-03-28 Systèmes et procédés de guidage de protocole automatisé

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2023/016626 WO2024205577A1 (fr) 2023-03-28 2023-03-28 Systèmes et procédés de guidage de protocole automatisé

Publications (1)

Publication Number Publication Date
WO2024205577A1 true WO2024205577A1 (fr) 2024-10-03

Family

ID=86142720

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/016626 WO2024205577A1 (fr) 2023-03-28 2023-03-28 Systèmes et procédés de guidage de protocole automatisé

Country Status (1)

Country Link
WO (1) WO2024205577A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180147347A1 (en) * 2015-06-04 2018-05-31 Smiths Medical Asd, Inc. Procedure-based programming for infusion pumps
WO2023044127A1 (fr) * 2021-09-20 2023-03-23 Carefusion 303, Inc. Sélection automatique d'un contenant de perfusion jetable

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180147347A1 (en) * 2015-06-04 2018-05-31 Smiths Medical Asd, Inc. Procedure-based programming for infusion pumps
WO2023044127A1 (fr) * 2021-09-20 2023-03-23 Carefusion 303, Inc. Sélection automatique d'un contenant de perfusion jetable

Similar Documents

Publication Publication Date Title
US20240087731A1 (en) Context-aware healthcare notification system
US20220223249A1 (en) System and method for reduced infusion administration line error
US20220193336A1 (en) Synchronization of patient association data across a healthcare organization network
US20230187063A1 (en) System and method for asynchronous communication of infusion information and obtaining remote assistance for an ongoing infusion
KR20230147154A (ko) 상호 운용 가능한 펌프용 스마트 바코드 id
WO2023044127A1 (fr) Sélection automatique d'un contenant de perfusion jetable
WO2024205577A1 (fr) Systèmes et procédés de guidage de protocole automatisé
US20240374811A1 (en) Infusion device automated programming mitigation
WO2024107180A1 (fr) Programmation automatisée sans balayage de dispositifs de perfusion
US20230321342A1 (en) Device, method, and system for accurate delivery of flush infusion
WO2025063952A1 (fr) Dispositifs, systèmes et procédés de complémentation de demandes de programmation automatisées
WO2024086250A1 (fr) Dispositifs, systèmes et procédés de validation de demandes de programmation automatisées
WO2025053833A1 (fr) Programmation automatique d'un dispositif médical sur la base d'un modèle de programmation obtenu de manière dynamique
WO2024091255A1 (fr) Dispositif et procédé de commande de perfusion modulaire
WO2024107179A1 (fr) Système d'identification d'actifs automatisé
WO2023219607A1 (fr) Balayage et validation à distance de configurations de dispositif d'ordonnance clinique
WO2024232873A1 (fr) Dispositif, système et procédé de prédiction d'alarme de perfusion à venir et de notification de celle-ci à un clinicien
WO2024177635A1 (fr) Pompe à seringue avec détection de centrage de force
WO2024242677A1 (fr) Dispositif, système et procédé pour la détermination et l'augmentation d'un engagement de praticien par rapport à des dispositifs de perfusion
WO2023015005A1 (fr) Système et procédé de détection et de commande d'un état vide de pompe à seringue
EP4094270A1 (fr) Conversion automatisée de pharmacothèques

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23719151

Country of ref document: EP

Kind code of ref document: A1