[go: up one dir, main page]

WO2025053833A1 - Programmation automatique d'un dispositif médical sur la base d'un modèle de programmation obtenu de manière dynamique - Google Patents

Programmation automatique d'un dispositif médical sur la base d'un modèle de programmation obtenu de manière dynamique Download PDF

Info

Publication number
WO2025053833A1
WO2025053833A1 PCT/US2023/031974 US2023031974W WO2025053833A1 WO 2025053833 A1 WO2025053833 A1 WO 2025053833A1 US 2023031974 W US2023031974 W US 2023031974W WO 2025053833 A1 WO2025053833 A1 WO 2025053833A1
Authority
WO
WIPO (PCT)
Prior art keywords
parameter
medical device
template
updated
value
Prior art date
Application number
PCT/US2023/031974
Other languages
English (en)
Inventor
Michael K. WORKMAN
Lisa Diggett
Evan Chen
Claire Ellen KNIGHT
Laura Ann COLLINS
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/031974 priority Critical patent/WO2025053833A1/fr
Publication of WO2025053833A1 publication Critical patent/WO2025053833A1/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
    • 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/40—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 management of medical equipment or devices, e.g. scheduling maintenance or upgrades
    • 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/1407—Infusion of two or more substances
    • 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
    • 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
    • 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/142—Pressure infusion, e.g. using pumps
    • A61M2005/14208—Pressure infusion, e.g. using pumps with a programmable infusion control system, characterised by the infusion program
    • 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
    • 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

Definitions

  • This application relates generally to ensuring that an infusion device is properly programmed.
  • Modem infusion devices may receive infusion order parameters from a third-party system to configure the device’s pump to deliver a specific fluid, at specific rates, for a specific patient; a remote programming command often referred to as an automated programming request (APR).
  • APR automated programming request
  • the APR automatically (and often remotely) programs the infusion device, thereby minimizing manual entry as well as ensuring conformity with an order for the medication to be administered, the patient’s data, and universal data rules.
  • the APR configuration may also include pre-populating operating parameter values for presentment via the user interface. Pre-population of infusion parameters reduces the number of programming screens, key presses, and potential input errors that may exist with manual programming.
  • APR enabled systems rely on data stored in remote databases and servers. This data, however, may not always be up-to-date and/or may be based on expired data. Incorrect data can, in some instances, lead to improperly programmed infusion devices which can, in turn, lead to an overinfusion or under infusion of a medication. Moreover, all the data desired to generate an APR may not be available at the time the APR is requested. Manually keying in corrections take time and may be prone to further errors.
  • the subject technology provides a mechanism and corresponding system for automatically updating automated programming requests (APRs). Unlike legacy systems and processes, the subject technology provides for dynamic updating of parameters while generating an APR, thus ensuring that the latest information required or requested to program a medical device receiving the APR is made available to the medical device.
  • APRs automated programming requests
  • the subject technology includes a system comprising: one or more computing devices configured to perform operations comprising: receiving a request to initiate automated programming of a medical device; obtaining, based on the request and a type of the medical device, a template specific to the type of the medical device and comprising a plurality of parameters for configuring of the medical device; determining, after obtaining the template and before the medical device is configured according to the template, that a first parameter of the plurality of parameters in the template is a parameter to be updated; and responsive to determining that the first parameter is a parameter to be updated: generating an updated value to update the first parameter in the template; updating the first parameter with the updated value; and automatically causing an automated programming message to be transmitted to the medical device based on the template, the automated programming message causing the medical device to be configured according to template and the plurality of parameters including the first parameter updated with the updated value.
  • Other aspects include corresponding devices, methods, and computer program products for implementation of the corresponding system and its features.
  • the subject technology also relates to a medical device, comprising: a display device; and a medical device controller comprising a processor; wherein the medical device controller is configured to: receive, from a server remote from the medical device, an automated programming template specific to a type of the medical device and comprising a plurality of parameters for configuring of the medical device; determine, before the medical device is configured according to the template, that a first parameter of the plurality of parameters in the template is a parameter to be updated; and responsive to determining that the first parameter is a parameter to be updated: determine an updated value for updating the first parameter in the template; update the first parameter with the updated value; and automatically configure the medical device according to template and the plurality of parameters including the first parameter updated with the updated value.
  • Other aspects include corresponding systems, processes, methods, and computer program products for implementation of the corresponding infusion device and its features.
  • the subject technology also relates to a method, comprising: receiving a request to initiate automated programming of a medical device; obtaining, based on the request and a type of the medical device, a template specific to the type of the medical device and comprising a plurality of parameters for configuring of the medical device; determining, after obtaining the template and before the medical device is configured according to the template, that a first parameter of the plurality of parameters in the template is a parameter to be updated; and responsive to determining that the first parameter is a parameter to be updated, before the medical device is configured using the template: generating an updated value to update the first parameter in the template; updating the first parameter with the updated value; and automatically causing an automated programming message to be transmitted to the medical device based on the template, the automated programming message causing the medical device to be configured according to template and the plurality of parameters including the first parameter updated with the updated value.
  • Other aspects include corresponding systems, apparatus, and computer program products for implementation of the corresponding method and its features.
  • FIG. 1 A depicts an example patient care system that includes an infusion device.
  • FIG. IB depicts a closer view of a portion of the patient care system shown in FIG.
  • FIG. 1C depicts an example of an institutional patient care system of a healthcare organization, according to aspects of the subject technology.
  • FIG. 2 depicts an example system for automatically programming a medical device, according to aspects of the subject technology.
  • FIG. 3A depicts a first example sequence diagram for automatically programming a medical device based on a dynamically obtained automated programming request (APR) template, according to aspects of the subject technology.
  • FIG. 3B depicts an example process for automatically programming a medical device using a dynamically obtained template and parameters dynamically updated at server, according to aspects of the subject technology.
  • APR automated programming request
  • FIG. 4A depicts a second example sequence diagram for automatically programming a medical device based on a dynamically obtained APR template, according to aspects of the subject technology.
  • FIG. 4B depicts an example process for automatically programming a medical device using a dynamically obtained template and parameters dynamically updated at the medical device, according to aspects of the subject technology.
  • FIG. 4C depicts an example flow diagram for setting a refresh timer for a parameter of an APR, according to aspects of the subject technology.
  • FIG. 5 depicts a third example flow diagram for automatically programming a medical device based on a dynamically obtained automated APR template, according to aspects of the subject technology.
  • FIG. 6 is a conceptual diagram illustrating an example electronic system for automatically programming a medical device based on a dynamically obtained APR template, according to aspects of the subject technology.
  • an APR message may include well defined values or references that can be used by the receiving device to resolve a current value for the message, in real time.
  • the APR message may also be generated to include a referenced value to allow downstream devices to obtain the missing and/or unavailable information.
  • the system automatically obtains a template specific to the type of the medical device and that includes parameters for configuring operation of the medical device.
  • the system determines that at least one of the parameters of the template should be updated when the medical device is configured by the APR.
  • An updated value is generated by the system and the parameters of the APR updated with the updated value.
  • the APR is caused to be sent to the medical device, with the updated value, to configure the medical device according to the parameters of the template, including the updated value.
  • FIG. 1A is an example patient care system, according to various aspects of the subject technology.
  • the patient care system 12 shown in FIG. 1 A includes four fluid infusion pumps 16, 18, 20, 22, each of which is in operative engagement with a respective fluid administration set 2a-d.
  • Fluid supplies 3a-d which may take various forms but in this case are shown as bottles, are inverted and suspended above the pumps. Fluid supplies may also take the form of bags or other types of containers.
  • Both the patient care system 12 and the fluid supplies 3a-d are mounted to a roller stand or pole 4.
  • the specific fluid supplies as well as their orientation (e.g., mount location, mount height, mounting type, etc.) within the care area may generate one or more interaction records.
  • the interaction record for a set for example may be generated in part by detecting a scannable code associated with the set or detecting a physical structure on the set that encodes identifying information for the set prior to use.
  • each administration set 2a-d is connected between a respective fluid supply 3a-d and the same patient so that the patient may receive the fluids in all the fluid supplies.
  • the administration set may be identified either actively by, for example, scanning by a clinician or passively by, for example, wireless or optical detection of the administration set.
  • a separate infusion pump 16, 18, 20, 22 is used to infuse each of the fluids of the fluid supplies into the patient.
  • the infusion pumps are flow control devices that will act on the respective tube or fluid conduit of the fluid administration set to move the fluid from the fluid supply through the conduit to the patient. Because individual pumps are used, each may be individually set to the pumping or operating parameters required for infusing the particular medical fluid from the respective fluid supply into the patient at the particular rate prescribed for that fluid by the clinician.
  • FIG. 1 A Typically, medical fluid 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 is a closer view of a portion of the example patient care system shown in FIG. 1A, according to various aspects of the subject technology.
  • FIG. IB shows two of the fluid infusion pumps mounted at either side of a programming module, and the displays and control keys of each, with the programming module being capable of programming both infusion pumps.
  • the patient care system 12 represented as an infusion device — includes a door 5a and a handle 5b that operates to lock the door in a closed position for operation and to unlock and open the door for access to the internal pumping and sensing mechanisms and to load administration sets for the pump. When the door 5a is open, the tube can be connected with the pump 20.
  • a display 5c such as an LED display, is located in plain view on the door in this embodiment and may be used to visually communicate various information relevant to the pump 20, such as alert indications (e.g., alarm messages).
  • Control keys 5e-h exist for programming and controlling operations of the infusion pump as desired. In some implementations, the control keys may be presented as interactive elements on the display 5c (e.g., touchscreen display).
  • the infusion device 12 and/or infusion pump 20 may also include audio alert equipment in the form of a speaker (not shown).
  • the programming module 14 of the infusion device 12 includes a display 6a for visually communicating various information, such as the operating parameters of a connected pump and alert indications and alert messages, and control keys 6b and 6c for selecting and/or setting control parameters and/or options for controlling the infusion device 12 and connected modules.
  • the programming module 14 may also include a speaker to provide audible alerts.
  • the display 6a may be implemented as a touchscreen display.
  • the control keys 6b may be omitted or reduced in number by providing corresponding interactive elements via a graphical user interface presented via the display 6a.
  • each control key 6b (or 6c) may select a corresponding option displayed in display 6b.
  • the programming module 14 may include a communications system (not shown) with which the programming module 14 may communicate with external equipment such as a medical facility server or other computer and with a portable processor, such as a handheld communication device or a laptop-type of computer, or other information device that a clinician may have to transfer information as well as to download drug libraries to a programming module 16, 18, 20, 22 (such as pump 20).
  • the communication module may be used to transfer access and interaction information for clinicians encountering the programming module or device coupled therewith (e.g., pump 20 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 pump 20, such as in cases where a programming module is not used, or in addition to one with the programming module 14. Further, information input devices need not be hard-wired to medical instruments, information may be transferred through a wireless connection as well. Additionally, other types of modules may be connected to the pump modules or to the programming module such as a syringe pump module, patient controlled analgesic module, End Tidal CO2 monitoring module, oximeter monitoring module, or the like.
  • FIG. 1C depicts an example of an institutional patient care system 100 of a healthcare organization, according to aspects of the subject technology.
  • an infusion device 12 (or “medical device” generally) is connected to a hospital network 10.
  • patient care device or “PCD” may be used interchangeably with the term patient care unit (or “PCU”), either which may include various ancillary medical devices such as an infusion pump, a vital signs monitor, a medication dispensing device (e.g., cabinet, tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned (e.g., a syringe pump module configured to attach to an infusion pump), or other similar devices.
  • ancillary medical devices such as an infusion pump, a vital signs monitor, a medication dispensing device (e.g., cabinet, tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned (e.g., a syringe
  • Transmission channel 31 is any wired or wireless transmission channel, for example an 802.11 wireless local area network (LAN).
  • network 10 also includes computer systems located in various departments throughout a hospital.
  • network 10 of FIG. 1C 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.
  • network 10 may include discrete subnetworks.
  • network 10 includes a device network 41 by which patient care devices 12 (and other devices) communicate in accordance with normal operations.
  • institutional patient care system 100 may incorporate a separate information system server 30.
  • information system server 30 is shown as a separate server, the functions and programming of the information system server 30 may be incorporated into another computer, if such is desired by engineers designing the institution's information system.
  • Institutional patient care system 100 may further include one or multiple device terminals 32 for connecting and communicating with information system server 30.
  • Device terminals 32 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 30 via network 10.
  • Patient care device 12 comprises a system for providing patient care, such as that described in Eggers et al., which is incorporated herein by reference for that purpose.
  • Patient care device 12 may include or incorporate pumps, 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.
  • patient care device 12 comprises a control module 14, also referred to as interface unit 14, connected to one or more functional modules 116, 118, 120, 122.
  • Interface unit 14 includes a central processing unit (CPU) 50 connected to a memory, for example, random access memory (RAM) 58, and one or more interface devices such as user interface device 54 (e.g., FIG. IB (6a)), a coded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices.
  • Interface unit 14 also, although not necessarily, includes a main non-volatile storage unit 56, such as a hard disk drive or non-volatile flash memory, for storing software and data and one or more internal buses 64 for interconnecting the aforementioned elements.
  • main non-volatile storage unit 56 such as a hard disk drive or non-volatile flash memory
  • user interface device 54 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 54 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 60 may be a bar code reader capable of scanning and interpreting data printed in bar coded format.
  • data input device 60 can be any device for entering coded data into a computer, such as a device(s) for reading a magnetic strips, radio-frequency identification (RFID) devices whereby digital data encoded in RFID tags or smart labels (defined below) are captured by the reader 60 via radio waves, PCMCIA smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog or digital storage media.
  • RFID radio-frequency identification
  • Other examples of data input device 60 include a voice activation or recognition device or a portable personal data assistant (PDA).
  • PDA portable personal data assistant
  • user interface device 54 and data input device 60 may be the same device.
  • data input device 60 may be integral within pharmacy system 34 or located externally and communicating with pharmacy system 34 through an RS- 232 serial interface or any other appropriate communication means.
  • Auxiliary interface 62 may be an RS-232 communications interface, however any other means for communicating with a peripheral device such as a printer, patient monitor, infusion pump or other medical device may be used without departing from the subject technology.
  • data input device 60 may be a separate functional module, such as modules 16, 18, 20 and 22, and configured to communicate with controller 14, or any other system on the network, using suitable programming and communication protocols.
  • Network connection 52 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.
  • ISDN integrated services digital network
  • DSL digital subscriber line
  • 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.
  • Functional modules 16, 18, 20, 22 are any devices for providing care to a patient or for monitoring patient condition. As shown in FIG. 1C, at least one of functional modules 16, 18, 20, 22 may be an infusion pump module such as an intravenous infusion pump for delivering medication or other fluid to a patient. For the purposes of this discussion, functional module 116 is an infusion pump module. Each of functional modules 16, 18, 20, 22 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. Functional module 16, 18, 20 and/or 22 may be a printer, scanner, bar code reader, near-field communication reader, RFID reader, or any other peripheral input, output or input/output device.
  • Each functional module 16, 18, 20 and/or 22 communicates directly or indirectly with interface unit 14, with interface unit 14 providing overall monitoring and control of device 12.
  • Functional modules 16, 18, 20 and/or 22 may be connected physically and electronically in serial fashion to one or both ends of interface unit 14 as shown in FIG. 1C, or as detailed in Eggers et al.
  • devices such as pumps or patient monitoring devices that provide sufficient programmability and connectivity may be capable of operating as standalone devices and may communicate directly with the network without connected through a separate interface unit or control unit 14.
  • additional medical devices or peripheral devices may be connected to patient care device 12 through one or more auxiliary interfaces 62.
  • Each functional module 16, 18, 20, 22 may include module-specific components 76, a microprocessor 70, a volatile memory 72 and a nonvolatile memory 74 for storing information. It should be noted that while four functional modules are shown in FIG. 1C, any number of devices may be connected directly or indirectly to central controller 14. The number and type of functional modules described herein are intended to be illustrative, and in no way limit the scope of the subject technology.
  • Module-specific components 76 include any components necessary for operation of a particular module, such as a pumping mechanism for infusion pump module 116.
  • each functional module may be capable of a least some level of independent operation
  • interface unit 14 monitors and controls overall operation of device 12.
  • interface unit 14 provides programming instructions to the functional modules 16, 18, 20, 22 and monitors the status of each module.
  • NIM network interface module
  • Medical devices incorporating aspects of the subject technology may be equipped with a network interface module (NIM), allowing the medical device to participate as a node in a network. While for purposes of clarity the subject technology will be described as operating in an Ethernet network environment using the Internet Protocol (IP), it is understood that concepts of the subject technology are equally applicable in other network environments, and such environments are intended to be within the scope of the subject technology.
  • 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.
  • patient care device 12 and network 10 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 52 (as shown in FIG. 1C), 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 patient care device 12 and network 40 involves physically transferring, intermittently or periodically, data between systems using, for example, user interface device 54, coded data input device 60, 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 network 40. For example, and not by way of limitation, decisions can be made in health information system (HIS) server 30, hospital department or unit stations 32, or within patient care device 12 itself.
  • HIS health information system
  • RDS remote data server
  • network interface modules incorporated into medical devices such as, for example, infusion pumps or vital signs measurement devices, ignore all network traffic that does not originate from an authenticated RDS.
  • the primary responsibilities of the RDS of the subject technology are to track the location and status of all networked medical devices that have NIMs and maintain open communication.
  • server 30 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 server
  • the pharmacy website may contain a drug library having the list of available drugs but may also contain and present to the physician the drug names associated with recommended dosages and dose limits that have been established or adopted by the healthcare facility.
  • the physician need only select items from the computer screen rather than having to manually type in drug names and drug administration numbers (such as infusion rates, times, etc.) associated with administration of the medication, a more accurate medication process should result.
  • a clinical order is for administration of a particular medication regimen
  • the order will be transmitted to the facility's pharmacy information system (e.g., part of server 30).
  • the pharmacy reviews the order, and once the order has been prepared, the order may be transmitted to the nurse station for matching with the appropriate patient.
  • Formulary is an approved list of drugs for use (e.g., available to order for a patient) within a medical facility. Within a formulary, there may be indication for use information and/or concentrations and drug ranges approved for the facility. As will be described further, a formulary may be used to define one or more medical device drug libraries, which may then be provided to infusion pumps within a hospital network.
  • medication information such as drug names, concentration, diluent volume, strength, minimum or maximum infusion parameters for a drug, and other parameters.
  • the establishment of these parameters, along with parameters for off- formulary orders, via the system 30 is useful for maintaining consistency across the healthcare environment and ensuring an order is intelligible and executed according to expectations by other devices within the system 30 (e.g., an infusion pump).
  • patient care device 12 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 56 internal to patient care device, or an external database 37.
  • 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 a patient care device’s 12 location in the hospital or hospital computer network.
  • Patient care information may be entered through interface device 52, 54, 60 or 62, and may originate from anywhere in network 10, such as, for example, from a pharmacy server, admissions server, laboratory server, and the like.
  • a memory 56, 58 of the interface unit 14 may contain a drug library or libraries, an event log or logs, and pump configuration settings, such as, but not limited to, profiles to be used in particular practice areas such as ICU, PED, etc.
  • the 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 depending on other factors. An alarm may be provided if the nurse sets the pump to operate outside the range between the limits for a particular drug.
  • BSA body surface area
  • the alarm may be overridden and in other cases it may not.
  • the medical facility may establish “soft” limits for each drug, which may be overridden by the nurse, and “hard” limits which may not.
  • a pump data log or other processor in communication with the infusion pump may record each such limit event for later analysis where the attempted setting is higher than the maximum or lower than the minimum dosage.
  • the pump also includes a display for displaying a user interface, including a control panel through which the user can program the programmable controller and a display screen for displaying drug entries from the drug library.
  • Each of the associated sets of drug delivery parameters includes information selected from a group of parameters including drug concentration, drug delivery rate, drug dose, and bolus size.
  • the electronically loaded drug library contains a list of available mode options specifying the units available for expressing drug delivery information, and the drug infusion pump offers the user the list of available mode options from which to make a selection when the electronically loaded drug library is in the pump.
  • the electronically loaded drug library may include a list of names of syringe manufacturers identifying syringes that can be used in the drug infusion pump, and the drug infusion pump offers the user the list of names of syringe manufacturers from which to make a selection when the electronically loaded drug library is in the pump.
  • the loaded drug library may include a list of syringe sizes identifying syringes that can be used in the drug infusion pump, and the drug infusion pump offers the user the list of syringe sizes from which to make a selection when the electronically loaded drug library is in said pump.
  • the electronically loaded drug library may include a list of infusion set manufacturers.
  • a loaded drug library may include a set of features, each of which is either be toggled on or off, and the pump offers the user only the features from among the set of features that are toggled on when the electronically loaded drug library is in said pump.
  • FIG. 2 depicts an example system 200 for automatically programming a medical device, according to aspects of the subject technology.
  • Interoperability between a hospital’s electronic medical records (EMR) system 202 and medical devices such as infusion device 12 enable pre-population of infusion parameters. Pre-population of infusion parameters may reduce the number of programming screens and key presses required with manual programming of 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.
  • EMR electronic medical records
  • features may be described with reference to an EMR, the features are applicable to provide auto-programming of medical devices using similar hospital information systems such as pharmacy data management systems (PDMSs) or other patient data management systems.
  • PDMSs pharmacy data management systems
  • the features may be described using an infusion device as the example patient care devices 12, the features are applicable to provide autoprogramming of other medical devices using barcodes for association such as patient monitors, patient association management systems, ventilators, or alarms management systems.
  • a formulary 204 determines which medications can be dispensed within a hospital network.
  • a hospital committee may be formed to determine how medications within that formulary would be applied to the patient care devices 12.
  • Configuration definitions e.g., by hospital unit such as ICU, NICU, Pediatrics, Oncology, Surgery, etc.
  • drug library a medical device drug library
  • limitation, or guard rail conditions are defined in the drug library.
  • a configuration can be released including the drug library.
  • Pumps at the institution are then updated by transferring the configuration databases into some or all of their pumps.
  • Corresponding updates to the formulary may be shared with other hospital systems such as the pharmacy ordering system or electronic medical records system which may be use formulary information to generate a patient order to deliver a particular drug to a particular patient (e.g., FIG. 2 at 2.1).
  • a clinician may scan a medical item such as an infusate package using a scanner associated with a medical device such as an infusion device 12.
  • a bar code reader or other data input device
  • the reader/scanner is not required to be integrated with a medical device.
  • the scanner may be part of a separate device such as a medical records terminal 206 (e.g., part of one or more computing devices) connected to the same network 40 as the infusion device 12 and configured with software to function in an overall workflow involving the infusion device 12.
  • 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 (e.g., FIG. 2 at 2.2) to the hospital’s EMR 202 (e.g., at a centralized server 30) via a network 40.
  • the EMR system 202 may confirm the item and generate (e.g., FIG. 2 at 2.3) and send an automated programming request (APR) to the medical device 12 to load parameters pertaining to the item.
  • the parameters may be stored in the medical device 12, 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 208 coordinates messages sent from the EMR system 202 to the infusion device 12.
  • the EMR system 202 transmits an APR (or request therefor) (e.g., FIG. 2 at 2.4) to the pump coordination engine 208 with a device identifier (ID) of the infusion device to receive the APR.
  • the coordination engine 208 determines whether the infusion device 12 identified by the EMR system 202 is available and, if so, provides (e.g., forward or generate and transmit) the APR to the device 12 (e.g., FIG. 2 at 2.5).
  • the infusion device 12 programs itself according to the parameters of the APR.
  • the APR activates a drug library stored on the device, and the infusion device 12 is programmed according to parameters stored in the drug library for the medication identified in the APR.
  • the infusion device 12 may automatically initiate operation based on the parameters.
  • the infusion device 12 may confirm the automatically entered parameters (e.g., FIG 2 at 2.6). 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 12 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.
  • FIG. 3A depicts a first example sequence diagram 300 for automatically programming a medical device based on a dynamically obtained automated programming request (APR) template, according to aspects of the subject technology.
  • APR automated programming request
  • an identifier of a medical device 12 may be scanned at an EMR terminal 206 and a process initiated by which information pertaining to the medical device is automatically sent to the hospital’s EMR server 202.
  • the EMR server 202 performs certain actions pertaining to the medical device and causes transmission of an automated programming request (APR) to the medical device 12 to configure the device 12.
  • APR automated programming request
  • an identifier of the medical device 12 is scanned from a barcode affixed to the device in conjunction with parameters entered into the terminal for selecting and generating the APR.
  • a hospital system implementing the subject technology may include one or more infusion devices 12, an EMR terminal 206, and an EMR server 202 (including, e.g., one or more patient PDMSs) connected to a connectivity gateway 302.
  • the connectivity gateway 302 includes or is part of or associated with the coordination engine 208.
  • the connectivity gateway 302 is a separate system.
  • the gateway 302 may include one or more computing devices such a server or servers apart from the EMR server 202.
  • the gateway 302 may be implemented by or interchangeable with the coordination engine 208 of FIG. 2.
  • the EMR server 202 and the connectivity gateway 302 may co-exist as a single server or a group of servers.
  • Server 30 of FIG. 1C may be representative of an EMR server 202 and/or a connectivity gateway 302.
  • a clinician interacts with and authenticates to the EMR terminal 206.
  • the EMR terminal 206 may obtain the clinicians identification by way of the authentication process, and the clinician may enter the care area, patient identifier, drug identifier, device/pump/module identifier, order identifier, and/or other identifying information for requesting an APR be sent to an infusion device 12.
  • the identifying information obtained via the EMR terminal 206 is transmitted to the EMR server 202 as a request to automatically program the infusion device (304).
  • the EMR 202 transmits a request message to the connectivity gateway 302 (306) with some or all of the information obtained via the terminal 206.
  • the EMR server 202 may send a request message that includes a device identifier (ID) of the infusion device to receive the APR (in addition to one or more of the identifiers received at 304).
  • ID device identifier
  • the connectivity gateway 302 then obtains an APR template for programming the medical device (308).
  • the obtained template is specific to the type of the medical device.
  • the server 302 may perform a lookup of the medical device type based on the device identifier received with the request (e.g., in a database).
  • the device identifier includes the type of medical device for which the APR is to be sent.
  • the APR template may be associated with the device identifier and obtained by a lookup based on the identifier.
  • the APR template is obtained (e.g., retrieved from a database) based on the order identifier, or based on the order identifier in combination with the medical device or type identifier.
  • Each APR template includes a plurality of predetermined parameters used to program the corresponding medical device.
  • an APR template comprises a predetermined organization of parameter placeholders for parameter values that the corresponding medical device uses to operate.
  • An APR template for the purpose of this disclosure, includes an organized group or structure of informational elements used to program a medical device.
  • the informational elements may include parameters and/or parameter placeholders (e.g., into which parameter values may be inserted after designation/generation of the placeholder).
  • the terms parameter and parameter placeholder may be used synonymously.
  • the APR template may include default values for one or more (or all) of the parameters.
  • the system proceeds to identify the parameters within the APR (e.g., by electronically parsing or scanning the APR template) and then retrieves the parameter values to populate the template with the retrieved values.
  • Parameter values may be stored for various medical devices, with each value selected for typical operation.
  • the parameters are provided from a drug library, as previously described.
  • the drug libraries for each medical device type may be stored on EMR server 202 and queried by the system upon receiving a request for a template.
  • the template is obtained based on the medical device type and provides which parameters should be used, and one or more (or all of) the parameter values are obtained based on the order identifier and/or patient identifier.
  • the connectivity gateway 302 having obtained the template, looks up the variable values for one or more (or all) of the parameters identified in the template by providing the order identifier to the EMR server 310.
  • the parameters may be retrieved from a single database 37 or multiple databases 37 and/or external systems.
  • the APR template may identify from which source to retrieve each parameter. Accordingly, the APR may be generated from multiple sources based on the APR template.
  • the parameters are then merged with the obtained APR template to generate an APR for the medical device (312).
  • the merge may include substituting values in the APR template with obtained, order-specific, values.
  • the coordination engine 302 forwards the APR to the device 12 (e.g., FIG. 2 at 2.5) (314).
  • the infusion device 12 programs itself according to the parameters of the APR (316).
  • the APR activates a drug library stored on the device, and the infusion device is programmed according to parameters stored in the drug library for the medication identified in the APR.
  • the drug library is identified based on information (e.g., medication identifier) within the APR.
  • some parameters and/or parameter values are provided by the APR, while some parameters and/or parameter values are provided by the drug library.
  • the infusion device may automatically initiate operation based on the parameters.
  • the infusion device may confirm the automatically entered parameters (e.g., FIG 2 at 2.6).
  • 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.
  • the infusion device After the APR has been accepted and processed by the infusion device without failure, the infusion device begins to infuse a medication according to the programming provided by the APR. After the infusion has begun, the infusion device may send one or more status messages to the EMR system 202. A status message informs the EMR system what was started and includes certain values on which the infusion device is reporting. This information may reflect the APR data and/or may include changes made at the device. The EMR system may wait for the status message and, upon receiving the message, closes out the workflow pertaining to the APR.
  • FIG. 3B depicts an example process 320 for automatically programming a medical device using a dynamically obtained template and parameters dynamically updated at server, according to aspects of the subject technology.
  • process 320 is a streamlined variation of process 320.
  • the one or more of the blocks of process 320 may be implemented, for example, by one or more computing devices including, for example, EMR server 202 and/or connectivity gateway 302. In some implementations, one or more of the blocks may be implemented based on one or more machine learning algorithms.
  • a server receives a request to automatically program a medical device (322), as described previously. A template is then retrieved for the APR based on the request (324).
  • the system determines whether the APR template includes a substation variable (326); i.e., the system determines whether a parameter of a plurality of parameters in the template is a parameter to be updated. If the parameter is a parameter to be updated then a variable value for updating the parameter is obtained (328).
  • the template may indicate from which source (e.g., database 37, network service, etc) the parameter is to be updated. In this regard, multiple parameters may be updated from multiple different sources.
  • the parameter value may be obtained at a predetermined time, for example, before the medical device is configured according to the template, or at a predetermined time afterward.
  • a substitution variable is retrieved from a network source (e.g., a server or database).
  • a network source e.g., a server or database.
  • the parameter value is obtained by a server.
  • the parameter value may be obtained by the medical device that received the APR.
  • template parameter is updated with the obtained parameter value and the APR message (to be sent to the medical device) is generated based on the template and the updated value (330).
  • the APR is sent to the medical device to program the medical device (332) (e.g., as described in FIG. 2 at 2.5). If the template does not include a parameter flagged for updating then the APR message is generated (330) as described in FIG.
  • FIG. 4A depicts a second example sequence diagram 350 for automatically programming a medical device based on a dynamically obtained automated programming request (APR) template, according to aspects of the subject technology.
  • APR automated programming request
  • the parameter(s) of the template to be updated/substitute are updated/ substituted by the medical device 12 (instead of at a server as in, for example, FIG.
  • the APR request is made and provided to the server(s) in a similar manner as in FIG. 3A (304, 306), and a server (e.g., the connectivity gateway 302) obtains an APR template (308).
  • the server 302 forwards the APR to the medical device 12 (314).
  • the medical device looks up one or more parameters identified for substitution (340).
  • the parameters of the APR including the parameters identified for substitution, may be populated and/or updated from on a drug library stored on the medical device, or may be obtained from a remote server.
  • the medical device 12 looks up the variable values for each parameter identified for substitution by providing the order identifier to the EMR server 310.
  • the identified parameters are obtained during the programming process, after the AR is retrieved.
  • the updated parameters e.g., including substituted values
  • the depicted sequence concludes when the medical device 12 completes programming according to the parameters of the APR (316).
  • a parameter provided in the APR and/or APR template may include a function call.
  • the server (or the medical device) upon receiving the APR template may insert a function call into a parameter placeholder.
  • the function may perform a calculation based on one or more retrieved values.
  • the function call may then be used at runtime to obtain a parameter value, for example, based on a condition (e.g., a runtime condition at the medical device).
  • the function call is executed, which may initiate an evaluation of the condition.
  • the parameter may then be updated to a first value when the condition is satisfied or a second value when the condition is not satisfied.
  • the condition may include selecting a parameter based on another value or determination.
  • the value of the parameter may depend on what care area the medical device is located or associated with.
  • evaluation of the condition may include evaluation of the care area. If the care area is identified to be a first care area, then the parameter may be set to a first value, and when the care area is identified to be a second care area then the parameter may be set to a second value. In some implementations, if the care area is identified to be a third care area, then the parameter may be set to a third value and so on.
  • FIG. 4B depicts an example process 380 for automatically programming a medical device using a dynamically obtained template and parameters dynamically updated at the medical device, according to aspects of the subject technology.
  • the various blocks of example process 380 are described herein with reference to FIGS. 1A-C, 2, 3 A, 3B, and 4A and the associated components and/or processes described herein.
  • the one or more of the blocks of process 380 may be implemented, for example, by one or more computing devices including, for example, EMR server 202 and/or connectivity gateway 302. In some implementations, one or more of the blocks may be implemented based on one or more machine learning algorithms.
  • 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, to the extent that the blocks of example process 380 are described as occurring in serial, or linearly, in some implementations, multiple blocks of example process 380 may occur in parallel. In addition, the blocks of example process 380 need not be performed in the order shown and/or one or more of the blocks of example process 380 need not be performed.
  • a medical device 12 receives an automated programming request (APR) (382) from a server, as previously described.
  • the APR may be based on a dynamically obtained template, as previously described.
  • One or more parameters is flagged (e.g., identified) for updating by the medical device, either upon being received (e.g., when parsed by the medical device) or when the medical device is configured according to the APR, or at a predetermined period of time after the medical device is programmed or an infusion is initiated.
  • the medical device 12 proceeds to obtain an updated parameter value for each of the flagged parameters (386).
  • the medical device may retrieve a substitution variable value from another computing device (e.g., a remote server or database) for each of the flagged parameters.
  • another computing device e.g., a remote server or database
  • multiple parameters may each be updated from a different source.
  • the configuration of the medical device 12 may be completed, as previously described (388).
  • FIG. 4C depicts an example flow diagram for setting a refresh timer for a parameter of an automated programming request (APR), according to various aspects of the subject technology.
  • APR automated programming request
  • the various blocks of example process 400 are described herein with reference to FIGS. 1A-C, 2, 3A, 3B, 4A and 4B and the associated components and/or processes described herein.
  • process 400 is a streamlined variation of process 400.
  • the one or more of the blocks of process 400 may be implemented, for example, by one or more computing devices including, for example, EMR server 202 and/or connectivity gateway 302. In some implementations, one or more of the blocks may be implemented based on one or more machine learning algorithms.
  • 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, to the extent that the blocks of example process 400 are described as occurring in serial, or linearly, in some implementations, multiple blocks of example process 400 may occur in parallel. In addition, the blocks of example process 400 need not be performed in the order shown and/or one or more of the blocks of example process 400 need not be performed.
  • an automated programming request is received at a medical device such as, in this example, an infusion device.
  • a medical device such as, in this example, an infusion device.
  • an infusion is initiated according to the APR (402).
  • the parameters of the APR in the subject technology, an APR generated according to a dynamically obtained template — are used to program an infusion.
  • an APR of the subject technology may include a parameter (or variable) flagged for substitution.
  • the medical device 12 determines whether the APR includes such a parameter (404). If not, then the infusion begins. In some implementations, the determination may occur periodically. For example, when the infusion has not yet completed (418), the medical device may periodically determine whether a substitution parameter has been inserted into the programming of the medical device, or into the APR from which the medical device is programmed. In some implementations, a new APR may be obtained or updated from the server during the infusion. In some implementations, a clinician may flag a parameter for substitution via the control panel of the device.
  • the medical device 12 may attempt to obtain a new parameter.
  • Multiple substitution parameters identified by the template may be sourced from multiple sources.
  • the population and/or updating of parameters may occur at the server, but one or more parameters may be further updated at the medical device.
  • the parameter is updated with a new value and the infusion begins.
  • the medical device may receive the APR and identify a parameter within the APR (or template) that is flagged to be refreshed after the medical device is configured, or at a predetermined time in the future.
  • the parameter is set with a first value and flagged to be updated to a second value after a predetermined period of time.
  • the medical device may set a refresh timer after the medical devicel2 is configured according to the template and first parameter (406). Accordingly, the medical device may periodically determine whether timer has expired (408) while operating as intended (e.g., continuing to infuse a medication).
  • the refresh timer expiration may be specified by a clinician when initiating the infusion (e.g., via a user interface) or may be automatically set based on information available to the infusion device 12 such as care area, drug to be administered, or parameter to be retrieved.
  • the medical device 12 may determine a new value to update the first parameter ( 10) and then proceed to update the first parameter based on the new value (414).
  • the medical device 12 may first determine whether the new value varies from or otherwise fails to correspond with the current parameter before performing an update (412).
  • the medical device 12 may prompt the user/clinician to confirm the updated parameter value before updating the current parameter with the updated parameter value ( 16).
  • FIG. 5 depicts a third example flow diagram for automatically programming a medical device based on a dynamically obtained automated APR template, according to aspects of the subject technology.
  • process 500 is a streamlined variation of process 500.
  • the one or more of the blocks of process 500 may be implemented, for example, by one or more computing devices including, for example, EMR server 202 and/or connectivity gateway 302. In some implementations, one or more of the blocks may be implemented based on one or more machine learning algorithms.
  • 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, to the extent that the blocks of example process 500 are described as occurring in serial, or linearly, in some implementations, multiple blocks of example process 500 may occur in parallel. In addition, the blocks of example process 500 need not be performed in the order shown and/or one or more of the blocks of example process 500 need not be performed.
  • a request to initiate an automated programming of a medical device 12 is received (502).
  • the medical device 12 may be an infusion pump or pump controller configured to administer a medication to a patient by way of an infusion set (e.g., intravenous tube and catheter).
  • the request may be received from a computer terminal associated with the medical device, as described with regard to FIG. 2.
  • a template corresponding to the type of the medical device is obtained (504).
  • An APR template for the purpose of this disclosure, includes an organized group or structure of informational elements used to program a medical device.
  • One or more (or all) of the elements may include one or more parameters associated with an infusion (e.g., flow rate, VTBI (volume-to-be-infused), guardrails, etc.).
  • One or more (or all) of the elements may include a parameter placeholder for a parameter to be populated at a different time and/or from another system.
  • the obtained template includes parameters for configuring the medical device 12, for example, according to an order (previously entered into the corresponding healthcare information system by a clinician).
  • the template will be specific to the type of the medical device.
  • the received request may include data sufficient for the system to identify the medical device and/or its type. Such data may include, for example, an identifier for an order, patient, clinician, medical device, medical device type, and/or medication.
  • the system determines, from the template, that a first parameter of the parameters associated with the template is a parameter to be updated (506).
  • the parameter may flagged within the template by meta data or other indication that is identified by the system during a scan or parsing of the template.
  • the meta data or other indication may further identify when the parameter should be updated.
  • the parameter may be flagged for update when the medical device is configured, or may be flagged for a future update. In either case, the parameter may be initially set to a default value prior to the update, and the default value may be used to initially program the medical device (e.g., to start an infusion).
  • the system determines that the first parameter is a parameter to be updated (and/or at the time indicated for the update)
  • the system then proceeds to update the first parameter (508).
  • the updated parameter value may be generated (e.g., a value calculated based on a formula, obtained by function call, or retrieved) and then substituted into the template.
  • updating the parameter includes setting a new value of the parameter.
  • updating the parameter may include substituting an existing parameter value, or replacing a parameter, with an entirely different parameter. An example of the latter may include substituting SP02 parameter for an ETCO2 parameter.
  • updating the parameter may include generating a function call and inserting the function call into a parameter placeholder so that, when the parameter is used (e.g., to program the medical device or in an implementation in which the template is used to generate and APR), the function call is executed and the updated value is retrieved from a remote location identified by the function call.
  • a numeric parameter value may be replaced with a function call for retrieving a new parameter value when the function call is executed.
  • the updated parameter(s) may include a function call.
  • the function call may obtain a new parameter based on a condition. For example, when the parameter is going to be used at runtime (e.g., by the medical device), the function call is executed by the software used to obtain the parameter from the APR and/or template.
  • the system e.g., the medical device or server directed by the function call
  • the first parameter indicated to be updated is then updated with the new parameter, as previously described.
  • the condition is transmitted by the medical device when the server is called by the function call; e.g., the function call itself includes the condition as a parameter.
  • the server may then retrieve the new parameter based on the condition and cause the first parameter (subject of the function call) to be updated with the new parameter (e.g., by way of returning the new parameter to the function call).
  • a care area may be determined, and whether the condition is satisfied may be based on the determined care area.
  • the care area may be sent (by the medical device) as part of the function call to the server, and the server may perform a lookup based on the care area to determine the new parameter for updating the first parameter.
  • the value may be a network service for providing order specific information.
  • the APR template may include the information needed to access the network service such as authorization token, order identifier, or other parameter that can be used by the service to retrieve the expected information.
  • the authorization token may only be valid when presented with the order identifier. This can prevent unauthorized access to hospital or patient information.
  • the server may lookup the care area itself based on information received from the medical device (e.g., device identifier).
  • the updated parameter may be determined by a trained (machine-learning) model.
  • the system may collect parameter data associated with a medication across a patient population, a clinician population, and/or a medical device population. An identifier for the medication may be sent with the request to initiate automated programming of the medical device.
  • the system may also receive a characteristic of the patient, of the clinician associated with the patient, and/or of the medical device. The characteristics may be sent with the APR or retrieved based on the information in the APR (e.g., from the EMR server). The characteristic(s) may then be input into the trained model which, based on its training and machine learning, determines the updated parameter.
  • the updated parameter (e.g., parameter value) includes a most recent clinical guidance for the patient, medical device, and/or medication.
  • the system may retrieve (e.g., from a server 202/302) a most recent clinical guidance based on information in the request.
  • the clinical guidance may be based on a care area of the medical device, which may be determined according to any of the previously described methods.
  • the guidance may be based on seniority of history of clinician, or care area (e.g., to warn clinicians in certain care area of an issue related to the medication or medical device).
  • a function call may be used, as previously described to fetch the most recent clinical guidance at the time of programming the medical device.
  • the depicted process continues after the template is updated by automatically causing an automated programming message to be transmitted to the medical device based on the template (510).
  • the populated template is sent as the APR.
  • an APR is generated based on the template (e.g., at the server or by the medical device after the template is received by the medical device). Accordingly, the APR causes the medical device to be configured according to the template and the plurality of parameters including the first parameter updated with the updated parameter value.
  • the system may determine that a parameter of the APR or template (e.g., the first parameter) should be refreshed after the medical device is configured according to the template. Accordingly, the parameter to be refreshed is flagged.
  • the medical device (or system by way of meta data) may set a refresh timer when the device is configured according to the APR.
  • the refresh timer may be set and/or started after the medical device is configured according to the template or, for example, when an infusion programmed by the APR is started.
  • the medical device may automatically determine a new parameter to update the first parameter and update the first parameter of the medical device based on the new parameter.
  • the APR is periodically updated at the server based on the template, and the flagged parameter is refreshed prior to the updated APR is sent to the medical device based on the refresh timer schedule.
  • 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 any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, 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. 6 is a conceptual diagram illustrating an example electronic system 600 for automatically programming a medical device based on a dynamically obtained APR template, according to aspects of the subject technology.
  • Electronic system 600 may be a computing device for execution of software associated with one or more portions or steps of processes 300, 350, 400, and 500 or components and methods provided by FIGS. 1-5, including but not limited to computing hardware within server 30, terminal 32, 206, or patient care device 12, and/or any computing devices or associated terminals disclosed herein.
  • Electronic system 600 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.
  • Electronic system 600 may include various types of computer readable media and interfaces for various other types of computer readable media.
  • electronic system 600 includes a bus 608, processing unit(s) 612, a system memory 604, a readonly memory (ROM) 610, a permanent storage device 602, an input device interface 614, an output device interface 606, and one or more network interfaces 616.
  • ROM readonly memory
  • electronic system 600 may include or be integrated with other computing devices or circuitry specifically configured for operation of the various components and methods previously described.
  • Bus 608 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 600. For instance, bus 608 communicatively connects processing unit(s) 612 with ROM 610, system memory 604, and permanent storage device 602. [0097] From these various memory units, processing unit(s) 612 retrieves instructions to execute and data to process, in order to execute the processes of the subject disclosure.
  • the processing unit(s) can be a single processor or a multi-core processor in different implementations.
  • ROM 610 stores static data and instructions that are needed by processing unit(s) 612 and other modules of the electronic system.
  • Permanent storage device 602 is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when electronic system 600 is off.
  • Some implementations of the subject disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as permanent storage device 602.
  • system memory 604 is a read-and-write memory device. However, unlike storage device 602, system memory 604 is a volatile read-and-write memory, such as, random access memory. System memory 604 stores some of the instructions and data that the processor needs at runtime. In some implementations, the processes of the subject disclosure are stored in system memory 604, permanent storage device 602, and/or ROM 610. From these various memory units, processing unit(s) 612 retrieves instructions to execute and data to process in order to execute the processes of some implementations.
  • Bus 408 also connects to input and output device interfaces 614 and 606.
  • Input device interface 614 enables the user to communicate information and select commands to the electronic system.
  • Input devices used with input device interface 614 include, e.g., alphanumeric keyboards and pointing devices (also called “cursor control devices”).
  • Output device interfaces 606 enables, e.g., the display of images generated by the electronic system 600.
  • Output devices used with output device interface 606 include, e.g., 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
  • bus 608 also couples electronic system 600 to a network (not shown) through network interfaces 616.
  • Network interfaces 616 may include, e.g., a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point.
  • Network interfaces 616 may also include hardware (e.g., Ethernet hardware or 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 electronic system 600 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, any 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.
  • 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; e.g., feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • a computer can interact with a user by sending documents to and receiving documents from a device
  • Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a 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 any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an internetwork (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).
  • LAN local area network
  • WAN wide area network
  • Internet internetwork
  • peer-to-peer networks e.g
  • the computing system can include 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
  • a system comprising: one or more computing devices configured to perform operations comprising: receiving a request to initiate automated programming of a medical device; obtaining, based on the request and a type of the medical device, a template specific to the type of the medical device and comprising a plurality of parameters for configuring of the medical device; determining, after obtaining the template and before the medical device is configured according to the template, that a first parameter of the plurality of parameters in the template is a parameter to be updated; and responsive to determining that the first parameter is a parameter to be updated: generating an updated value to update the first parameter in the template; updating the first parameter with the updated value; and automatically causing an automated programming message to be transmitted to the medical device based on the template, the automated programming message causing the medical device to be configured according to template and the plurality of parameters including the first parameter updated with the updated value.
  • Clause 2 The system of Clause 1, wherein the operations further comprise, after determining that the first parameter is a parameter to be updated and before the medical device is configured using the template: determining that a flagged parameter of the plurality of parameters is flagged to be refreshed after the medical device is configured according to the template; setting a refresh timer; and on expiration of the refresh timer, after the medical device is configured according to the template, (1) determining a new parameter value for updating the flagged parameter and (2) updating the a current value of the flagged parameter based on the new parameter value so that the medical device uses the new parameter value instead of the current value of the flagged parameter.
  • Clause 3 The system of Clause 1 or Clause 2, wherein the template includes a function call for obtaining values of the first parameter, and wherein updating the first parameter comprises: executing the function call; and receiving, based on the function call, the updated value for the first parameter.
  • Clause 4 The system of Clause 3, wherein the function call obtains a new parameter based on a condition, and wherein the operations further comprise, before the medical device is configured: receiving an indication that the function call was initiated; responsive to the indication: determining whether the condition is satisfied; setting the new parameter to a first value when the condition is satisfied and setting the new parameter to a second value different than the first value when the condition is not satisfied; and causing the first parameter to be updated with the new parameter.
  • Clause 5. The system of Clause 4, wherein the operations further comprise: receiving the condition and the indication from the medical device over a network; and providing the new parameter value to the medical device to cause the first parameter to be updated with the new parameter.
  • Clause 6 The system of Clause 4, wherein the operations further comprise: determining a care area of the medical device; and wherein determining whether the condition is satisfied is based on the care area.
  • Clause 7 The system of any one of Clauses 1-6, wherein the request and the plurality of parameters are for configuring the medical device to provide a medication, wherein the operations further comprise: collecting parameter data associated with the medication across a patient population, a clinician population, and a medical device population; identifying the medication based on the request; receiving a characteristic of a patient associated with the medical device, of a clinician associated with the patient, or of the medical device; and determining the updated value based on inputting the characteristic into a machine-learning model trained with the parameter data.
  • Clause 8 The system of any one of Clauses 1-7, wherein the operations further comprise: updating a second parameter of the plurality of parameters in the template to include a function call for obtaining clinical information associated with a medication provided by the medical device; receiving, from the medical device when the automated programming message causes the medical device to be configured, a request for the clinical information and a request for a characteristic of a patient, of a clinician associated with the patient, or of the medical device; and provide, to the medical device, the clinical information updated based on the request and the characteristic.
  • a medical device comprising: a display device; and a medical device controller comprising a processor; wherein the medical device controller is configured to: receive, from a server remote from the medical device, an automated programming template specific to a type of the medical device and comprising a plurality of parameters for configuring of the medical device; determine, before the medical device is configured according to the template, that a first parameter of the plurality of parameters in the template is a parameter to be updated; and responsive to determining that the first parameter is a parameter to be updated: determine an updated value for updating the first parameter in the template; update the first parameter with the updated value; and automatically configure the medical device according to template and the plurality of parameters including the first parameter updated with the updated value.
  • Clause 10 The medical device of Clause 9, wherein the medical device controller is further configured to, after determining that the first parameter is a parameter to be updated and before the medical device is configured using the template: determine that a flagged parameter of the plurality of parameters is flagged to be refreshed after the medical device is configured according to the template; set a refresh timer; and on expiration of the refresh timer, after the medical device is configured according to the template, (1) determine a new parameter value for updating the flagged parameter and (2) update the a current value of the flagged parameter based on the new parameter value so that the medical device uses the new parameter value instead of the current value of the flagged parameter.
  • Clause 11 The medical device of Clause 9 or Clause 10, wherein the first parameter comprises a function call, and wherein the medical device controller is further configured to: determine the updated value comprises executing the function call to retrieve the updated value; and update the first parameter comprises replacing the first parameter with the updated value.
  • Clause 12 The medical device of Clause 11, wherein the function call obtains the updated value based on a condition, wherein the medical device controller is further configured to, before the medical device is configured: determine whether the condition is satisfied; and set the updated value to a first parameter value when the condition is satisfied and set the updated value to a second parameter value different than the first parameter value when the condition is not satisfied.
  • Clause 13 The medical device of any one of Clauses 9-12, wherein the plurality of parameters are for configuring the medical device to provide a medication, wherein the medical device controller is further configured to: collect parameter data associated with the medication across at least one of a patient population, a clinician population, and a medical device population; identify the medication; receive a characteristic of a patient associated with the medical device, clinician associated with the patient, or the medical device; and determine the updated value based on inputting the characteristic into a machine-learning model trained with the parameter data. [0126] Clause 14.
  • a second parameter of the plurality of parameters in the template comprises a function call for obtaining clinical information associated with a medication provided by the medical device; executing the function call to obtain the clinical information; receiving the clinical information from a remote computing device; and display the clinical information on the display device.
  • a method comprising: receiving a request to initiate automated programming of a medical device; obtaining, based on the request and a type of the medical device, a template specific to the type of the medical device and comprising a plurality of parameters for configuring of the medical device; determining, after obtaining the template and before the medical device is configured according to the template, that a first parameter of the plurality of parameters in the template is a parameter to be updated; and responsive to determining that the first parameter is a parameter to be updated, before the medical device is configured using the template: generating an updated value to update the first parameter in the template; updating the first parameter with the updated value; and automatically causing an automated programming message to be transmitted to the medical device based on the template, the automated programming message causing the medical device to be configured according to template and the plurality of parameters including the first parameter updated with the updated value.
  • Clause 16 The method of Clause 15, wherein the method further comprises, after determining that the first parameter is a parameter to be updated and before the medical device is configured using the template: determining that the first parameter is flagged to be refreshed after the medical device is configured according to the template and the first parameter; setting a refresh timer after the medical device is configured according to the template and the first parameter; and on expiration of the refresh timer, (1) determining a new parameter value for updating the flagged parameter and (2) updating the a current value of the flagged parameter based on the new parameter value so that the medical device uses the new parameter value instead of the current value of the flagged parameter.
  • Clause 17 The method of Clause 15 or Clause 16, wherein the updated value comprises a function call and updating the first parameter comprises inserting the function call into the template for the first parameter, wherein the function call obtains a new parameter based on a condition, and wherein the method further comprises, before the medical device is configured: receiving an indication that the function call was initiated; responsive to the indication: determining whether the condition is satisfied; setting the new parameter to a first value when the condition is satisfied and setting the new parameter to a second value different than the first value when the condition is not satisfied; and causing the first parameter to be updated with the new parameter.
  • Clause 18 The method of Clause 17, wherein the method further comprises: receiving the condition and the indication from the medical device over a network; and providing the new parameter to the medical device to cause the first parameter to be updated with the new parameter.
  • Clause 19 The method of any one of Clauses 15-18, wherein the request and the plurality of parameters are for configuring the medical device to provide a medication, wherein the method further comprises: collecting parameter data associated with the medication across a patient population, a clinician population, and a medical device population; identifying the medication based on the request; receiving a characteristic of a patient associated with the medical device, of a clinician associated with the patient, or of the medical device; and determining the updated value based on inputting the characteristic into a machine-learning model trained with the parameter data.
  • Clause 20 The method of any one of Clauses 15-19, wherein the method further comprises: updating a second parameter of the plurality of parameters in the template to include a function call for obtaining clinical information associated with a medication provided by the medical device; receiving, from the medical device when the automated programming message causes the medical device to be configured, a request for the clinical information and a request for a characteristic of a patient, of a clinician associated with the patient, or of the medical device; and provide, to the medical device, the clinical information updated based on the request and the characteristic.
  • Clause 21 A non-transitory computer readable medium comprising instructions that, when executed by a computing system, cause the computing system to perform a method according to any one of Clauses 15 through 20.
  • Pronouns in the masculine include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the invention described herein.
  • a processor configured to monitor and control an operation or a component may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation.
  • a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code.
  • the term automatic may include performance by a computer or machine without user intervention; for example, by instructions responsive to a predicate action by the computer or machine or other initiation mechanism.
  • the word “example” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “example” is not necessarily to be construed as preferred or advantageous over other aspects or designs.
  • 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 “embodiment” does not imply that such embodiment is essential to the subject technology or that such embodiment applies to all configurations of the subject technology.
  • a disclosure relating to an embodiment may apply to all embodiments, or one or more embodiments.
  • An embodiment may provide one or more examples.
  • a phrase such as an “embodiment” may refer to one or more embodiments and vice versa.
  • a phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology.
  • a disclosure relating to a configuration may apply to all configurations, or one or more configurations.
  • a configuration may provide one or more examples.
  • a phrase such as a “configuration” may refer to one or more configurations and vice versa.
  • a “user interface” (also referred to as an interactive user interface, a graphical user interface or a UI) may refer to a network based interface including data fields and/or other control elements for receiving input signals or providing electronic information and/or for providing information to the user in response to any received input signals.
  • Control elements may include dials, buttons, icons, selectable areas, or other perceivable indicia presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiates an exchange of data for the device presenting the UI.
  • a UI may be implemented in whole or in part using technologies such as hyper-text mark-up language (HTML), 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 protocol, or the like.
  • a message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.
  • a “selective” process may include determining one option from multiple options.
  • a “selective” process may include one or more of: dynamically determined inputs, preconfigured inputs, or user-initiated inputs for making the determination.
  • an n-input switch may be included to provide selective functionality where n is the number of inputs used to make the selection.
  • the terms “correspond” or “corresponding” when used to describe a relationship between two or more elements encompasses a structural, functional, quantitative and/or qualitative correlation or relationship between two or more objects, data sets, information and/or the like, preferably where the correspondence or relationship may be used to translate one or more of the two or more objects, data sets, information and/or the like so to appear to be the same or equal.
  • Correspondence may be assessed using one or more of a threshold, a value range, fuzzy logic, pattern matching, a machine learning assessment model, or combinations thereof.
  • 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)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Hematology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Anesthesiology (AREA)
  • Veterinary Medicine (AREA)
  • Vascular Medicine (AREA)
  • Epidemiology (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)

Abstract

Système de programmation automatique d'un dispositif de perfusion sur la base d'un modèle de programmation obtenu de manière dynamique. Le système divulgué obtient, sur la base d'une demande d'initiation de programmation automatisée d'un dispositif médical, un modèle associé au type du dispositif médical et comprenant une pluralité de paramètres pour configurer le dispositif médical. Le système détermine qu'un premier paramètre de la pluralité de paramètres dans le modèle est un paramètre à mettre à jour, et en réponse à la détermination que le premier paramètre est un paramètre à mettre à jour, génère une valeur mise à jour pour mettre à jour le premier paramètre dans le modèle. Le premier paramètre est mis à jour avec la valeur mise à jour et le système amène automatiquement un message de programmation automatisé à être transmis au dispositif médical sur la base du modèle, le message de programmation automatisé amenant le dispositif médical à être configuré selon un modèle et des paramètres comprenant la valeur mise à jour.
PCT/US2023/031974 2023-09-05 2023-09-05 Programmation automatique d'un dispositif médical sur la base d'un modèle de programmation obtenu de manière dynamique WO2025053833A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2023/031974 WO2025053833A1 (fr) 2023-09-05 2023-09-05 Programmation automatique d'un dispositif médical sur la base d'un modèle de programmation obtenu de manière dynamique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2023/031974 WO2025053833A1 (fr) 2023-09-05 2023-09-05 Programmation automatique d'un dispositif médical sur la base d'un modèle de programmation obtenu de manière dynamique

Publications (1)

Publication Number Publication Date
WO2025053833A1 true WO2025053833A1 (fr) 2025-03-13

Family

ID=88207560

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/031974 WO2025053833A1 (fr) 2023-09-05 2023-09-05 Programmation automatique d'un dispositif médical sur la base d'un modèle de programmation obtenu de manière dynamique

Country Status (1)

Country Link
WO (1) WO2025053833A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070233520A1 (en) * 2006-03-28 2007-10-04 Hospira, Inc. Medication administration and management system and method
CN108022639A (zh) * 2016-11-01 2018-05-11 深圳市理邦精密仪器股份有限公司 对医疗设备进行管理的装置及方法、医疗设备的管理系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070233520A1 (en) * 2006-03-28 2007-10-04 Hospira, Inc. Medication administration and management system and method
CN108022639A (zh) * 2016-11-01 2018-05-11 深圳市理邦精密仪器股份有限公司 对医疗设备进行管理的装置及方法、医疗设备的管理系统

Similar Documents

Publication Publication Date Title
US20220223249A1 (en) System and method for reduced infusion administration line error
US20220193336A1 (en) Synchronization of patient association data across a healthcare organization network
US20250095841A1 (en) Auto-programming request rejection reduction
CN114375208A (zh) 用于医疗设备的双模式地理围栏
WO2023044127A1 (fr) Sélection automatique d'un contenant de perfusion jetable
WO2025053833A1 (fr) Programmation automatique d'un dispositif médical sur la base d'un modèle de programmation obtenu de manière dynamique
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
AU2021209836B2 (en) Automated conversion of drug libraries
WO2024205577A1 (fr) Systèmes et procédés de guidage de protocole automatisé
WO2024091255A1 (fr) Dispositif et procédé de commande de perfusion modulaire
WO2024086250A1 (fr) Dispositifs, systèmes et procédés de validation de demandes de programmation automatisées
EP4497140A1 (fr) Balayage et validation à distance de configurations de dispositif d'ordonnance clinique
WO2024107179A1 (fr) Système d'identification d'actifs automatisé
WO2024177635A1 (fr) Pompe à seringue avec détection de centrage de force
WO2024232873A1 (fr) Dispositif, système et procédé de prédiction d'alarme de perfusion à venir et de notification de celle-ci à un clinicien
WO2024118080A1 (fr) Compensation basée sur un modèle pour une précision de distribution de pompe à perfusion améliorée
CN116648755A (zh) 跨医疗卫生组织网络的患者关联数据的同步