Automatically programming a medical device based on a dynamically acquired programming template

Abstract

A system for automatically programming an infusion device based on a dynamically obtained programming template. It discloses that the system obtains a template associated with a type of medical device based on a request to initiate automatic programming of the medical device, and the template includes a plurality of parameters for configuring the medical device. The system determines that a first parameter of the plurality of parameters in the template is a parameter to be updated, and in response to determining that the first parameter is the parameter to be updated, generates an updated value for updating the first parameter in the template. The first parameter is updated with the updated value, and the system automatically causes an automatic programming message to be transmitted to the medical device based on the template, the automatic programming message causing the medical device to be configured in accordance with the template and the parameter including the updated value.

Description

Technical Field

[0001] This application generally relates to ensuring that infusion devices are programmed correctly. Background Technology

[0002] Modern infusion devices can receive infusion order parameters from third-party systems to configure the device's pumps to deliver specific fluids to specific patients at specific rates; remote programming commands are often referred to as automated programming requests (APRs). APRs automatically (and typically remotely) program the infusion device, minimizing manual input and ensuring consistency with the order of medications to be administered, patient data, and general data rules. APR configurations can also include pre-filled operational parameter values ​​for presentation via a user interface. Pre-filling infusion parameters reduces the number of programming screens and buttons, and the potential input errors that can occur with manual programming.

[0003] Systems that enable APR rely on data stored in remote databases and servers. However, this data may not always be up-to-date and / or may be based on outdated data. In some instances, erroneous data can lead to improper programming of infusion devices, which in turn may result in drug overdosing or underdosing. Furthermore, all the data expected to generate an APR may not be available when the APR is requested. Manually typing corrections is time-consuming and can easily lead to further errors. Summary of the Invention

[0004] This subject matter provides a mechanism and corresponding system for automatically updating Automatic Programming Requests (APRs). Unlike traditional systems and processes, this subject matter provides dynamic updates of parameters when generating an APR, thereby ensuring that the latest information required or requested for programming the medical device receiving the APR is available to the medical device.

[0005] In this regard, the subject matter includes a system comprising: one or more computing devices configured to perform operations including: receiving a request to initiate automatic programming of a medical device; obtaining a template specific to the type of the medical device based on the request and the type of the medical device, the template including multiple parameters for configuring 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 multiple parameters in the template is a parameter to be updated; and in response to determining that the first parameter is a parameter to be updated: generating an update value for updating the first parameter in the template; updating the first parameter with the update value; and automatically transmitting an automatic programming message to the medical device based on the template, the automatic programming message causing the medical device to be configured according to the template and the multiple parameters including the first parameter updated with the update value. Other aspects include corresponding devices, methods, and computer program products for implementing the corresponding system and its features.

[0006] This subject matter also relates to a medical device comprising: a display device; and a medical device controller including a processor; wherein the medical device controller is configured to: receive an automated programming template specific to a type of medical device from a server remote from the medical device, and the automated programming template includes multiple parameters for configuring the medical device; determine, before the medical device is configured according to the template, that a first parameter of the multiple parameters in the template is a parameter to be updated; and in response to determining that the first parameter is a parameter to be updated: determine an update value for updating the first parameter in the template; update the first parameter with the update value; and automatically configure the medical device according to the template and the multiple parameters including the first parameter updated with the update value. Other aspects include corresponding systems, processes, methods, and computer program products for implementing corresponding infusion devices and their features.

[0007] This subject matter also relates to a method comprising: receiving a request to initiate automatic programming of a medical device; obtaining a template specific to the type of the medical device based on the request and the type of the medical device, the template including multiple parameters for configuring 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 multiple parameters in the template is a parameter to be updated; and in response to determining that the first parameter is a parameter to be updated, before the medical device is configured using the template: generating an update value for updating the first parameter in the template; updating the first parameter with the update value; and automatically transmitting an automatic programming message to the medical device based on the template, the automatic programming message causing the medical device to be configured according to the template and the multiple parameters including the first parameter updated with the update value. Other aspects include corresponding systems, apparatuses, and computer program products for implementing the corresponding methods and features.

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

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

[0010] Figure 1A An example patient care system including infusion equipment is described.

[0011] Figure 1B Depicting Figure 1A A closer view of a portion of the patient care system shown.

[0012] Figure 1C An example of an institutional patient care system for a healthcare organization is depicted based on aspects of the subject technology.

[0013] Figure 2 An example system for automatically programming medical devices is described based on aspects of the subject technology.

[0014] Figure 3A A first example sequence diagram is depicted for automatically programming medical devices based on dynamically acquired Automatic Programming Request (APR) templates, according to aspects of the subject matter technology.

[0015] Figure 3B An example process is described for automatically programming medical devices using dynamically acquired templates and parameters that are dynamically updated at the server, based on aspects of the subject technology.

[0016] Figure 4A A second example sequence diagram is depicted, illustrating the use of dynamically acquired APR templates for the automatic programming of medical devices based on aspects of the subject matter technology.

[0017] Figure 4B An example process is described for automatically programming a medical device using dynamically acquired templates and dynamically updated parameters at the medical device, based on aspects of the subject technology.

[0018] Figure 4C An example flowchart is depicted for setting refresh timers for APR parameters, based on aspects of the subject technology.

[0019] Figure 5 A third example flowchart is depicted, based on aspects of the subject technology, for automatically programming medical devices using dynamically acquired automated APR templates.

[0020] Figure 6 This is a conceptual diagram illustrating an example electronic system for automatically programming medical devices based on dynamically acquired APR templates, according to aspects of the subject matter technology. Detailed Implementation

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

[0022] Depending on various aspects of the subject matter, the subject matter does not rely on existing immutable data to generate APRs for programming medical devices. Instead, it dynamically updates APR data during generation, while the medical device is being programmed with data associated with the APR, or during runtime after being programmed by the APR. In some implementations, the APR message may include well-defined values ​​or references that can be used by the receiving device to parse the current value of the message in real time. The APR message may also be generated to include reference values ​​to allow downstream devices to obtain missing and / or unavailable information.

[0023] When the APR process is initiated, the system automatically retrieves a template specific to the medical device type, which includes parameters for configuring the operation of the medical device. The system determines that at least one parameter of the template should be updated when configuring the medical device via APR. The system generates an updated value, and the parameters in the APR are updated with this updated value. The APR, along with the updated value, is then sent to the medical device to configure it according to the parameters in the template, including the updated value.

[0024] Figure 1A It is an example patient care system based on various aspects of the subject technology. Figure 1AThe patient care system 12 shown includes four fluid infusion pumps 16, 18, 20, and 22, each of which is operatively engaged with a corresponding fluid application device 2a-d. Fluid dispensers 3a-d (which may take various forms, but are shown as bottles in this case) are inverted and suspended above the pumps. The fluid dispensers may also take the form of bags or other types of containers. Both the patient care system 12 and the fluid dispensers 3a-d are mounted on rollers or rods 4. Specific fluid dispensers and their orientation within the care area (e.g., mounting location, mounting height, mounting type, etc.) can generate one or more interaction records. Interaction records for the devices can be generated, for example, in part by detecting a scannable code associated with the device or by detecting the physical structure on the device that encodes identification information for the device prior to use.

[0025] like Figure 1A As shown in the example implementation, each application device 2a-d is connected between the corresponding fluid supply 3a-d and the same patient, so that the patient can receive fluid from all fluid supplies. The application devices can be actively identified, for example, by scanning by a clinician, or passively identified, for example, by wireless or optical detection of the application devices.

[0026] In the depicted example, individual infusion pumps 16, 18, 20, and 22 are used to infuse each fluid from the fluid supply into the patient. The infusion pump is a flow control device that acts on the corresponding tubing or fluid conduit of the fluid application device to move fluid from the fluid supply through the conduit to the patient. Because individual pumps are used, each pump can be individually set to the pumping or operating parameters required to infuse a specific medical fluid from the corresponding fluid supply into the patient at a specific rate prescribed by the clinician for that fluid.

[0027] Typically, medical fluid application devices have a higher efficiency than... Figure 1A More components are shown. Many have check valves, drip chambers, valved ports, connectors, and other devices well known to those skilled in the art. These other devices are not included in the drawings to maintain clarity.

[0028] Figure 1B It is based on various aspects of the subject technology. Figure 1A A closer view of a portion of the example patient care system shown. Figure 1BTwo fluid infusion pumps are shown mounted on either side of a programming module, along with a display and control keys for each pump, wherein the programming module is capable of programming both infusion pumps. The patient care system 12 (represented as an infusion device) includes a door 5a and a handle 5b, which are operated to lock the door in a closed position for operation, and to unlock and open the door to access the internal pumping and sensing mechanisms and to load the application device onto the pump. When the door 5a is open, tubing can be connected to the pump 20. When the door 5a is closed, the tubing is brought into operative engagement with the pumping mechanism, upstream and downstream pressure sensors, and other equipment of the pump. A display 5c (such as an LED display) is located on the door in this embodiment in a plan view and can be used to visually convey various information related to the pump 20, such as alarm indications (e.g., alarm messages). Control keys 5e-h are present for programming and controlling the operation of the infusion pumps as needed. In some embodiments, the control keys may be presented as interactive elements on the display 5c (e.g., a touchscreen display). The infusion device 12 and / or infusion pump 20 may also include an audio alarm device in the form of a speaker (not shown).

[0029] The programming module 14 of the infusion device 12 includes a display 6a for visually conveying various information, such as operating parameters and alarm indications and messages of the connected pump, and control keys 6b and 6c for selecting and / or setting control parameters and / or options for controlling the infusion device 12 and the connected modules. The programming module 14 may also include a speaker to provide audible alarms. In some embodiments, the display 6a may be implemented as a touchscreen display. In such embodiments, the control keys 6b may be omitted or reduced in number by means of corresponding interactive elements provided via a graphical user interface presented through the display 6a. In some embodiments, each control key 6b (or 6c) can select a corresponding option displayed on the display 6b.

[0030] Programming module 14 may include a communication system (not shown) that allows it to communicate with external devices (such as a medical facility server or other computer) and with portable processors (such as handheld communication devices or portable computers) or other information devices (such as pump 20) that a clinician may have for transmitting information and downloading a drug catalog to programming modules 16, 18, 20, 22. The communication module can be used to transmit access and interaction information to a clinician who encounters the programming module or a device coupled thereto (e.g., pump 20 or barcode scanner). The communication system may include one or more of a radio frequency (RF) system, an optical system such as infrared, a BLUETOOTH™ system, or other wired or wireless systems. The barcode scanner and communication system may alternatively be integrated with infusion pump 20, such as without the programming module, or in addition to using programming module 14. Furthermore, the information input device does not need to be hardwired to the medical device; information can also be transmitted wirelessly. In addition, other types of modules can be connected to pump modules or programming modules, such as syringe pump modules, patient-controlled analgesia modules, end-tidal CO2 monitoring modules, pulse oximeter monitoring modules, or the like.

[0031] Figure 1C An example of an institutional patient care system 100 of a healthcare organization, based on aspects of the subject matter technology, is depicted. Figure 1C In this system, infusion device 12 (or generally, "medical device") is connected to hospital network 10. The term "patient care device" (or "PCD") may be used interchangeably with the term "patient care unit" (or "PCU"), either of which may include various assistive medical devices such as infusion pumps, vital sign monitors, medication dispensing devices (e.g., cabinets, cases), medication preparation devices, automated dispensing devices, modules coupled to one of the foregoing (e.g., injection pump modules configured to be attached to infusion pumps), or other similar devices. Each element of infusion device 12 is connected to the internal healthcare network 10 via transmission channel 31. Transmission channel 31 is any wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN). In some embodiments, network 10 also includes computer systems located in various departments throughout the hospital. For example, Figure 1C Network 10 may optionally include computer systems associated with admissions, billing, biomedical engineering, clinical laboratories, central supply, one or more unit station computers, and / or medical decision support systems. As further described below, network 10 may include discrete subnetworks. In the depicted example, network 10 includes a device network 41 through which patient care devices 12 (and other devices) communicate in accordance with normal operation.

[0032] Additionally, the institutional patient care system 100 may include a separate information system server 30. Furthermore, although the information system server 30 is shown as a separate server, its functionality and programming can be integrated into another computer if desired by the engineers designing the institutional information system. The institutional patient care system 100 may also include one or more device terminals 32 for connecting to and communicating with the information system server 30. Device terminals 32 may include personal computers, personal data assistants, and mobile devices (such as laptops, tablets, augmented reality devices, or smartphones) configured with software for communicating with the information system server 30 via the network 10.

[0033] Patient care device 12 includes systems for providing patient care, such as those described in Eggers et al., which are incorporated herein by reference for this purpose. Patient care device 12 may include or contain pumps, physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors), treatment devices, and other medication delivery devices that may be used in accordance with the teachings set forth herein. In the depicted example, patient care device 12 includes 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 (e.g., random access memory (RAM) 58), and one or more interface devices, such as user interface device 54 (e.g., ...). Figure 1B (6a) ), encoded data input device 60, network connection 52, and auxiliary interface 62 for communicating with additional modules or devices. Interface unit 14 also (though 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 components.

[0034] In various embodiments, the user interface device 54 is a touchscreen used to display information to a user and allow the user to input information by touching a defined area of ​​the screen. Additionally or alternatively, the user interface device 54 may include any means for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen. The data input device 60 may be a barcode reader capable of scanning and interpreting data printed in barcode format. Additionally or alternatively, the data input device 60 may be any device for inputting encoded data into a computer, such as a device for reading magnetic stripes, a radio frequency identification (RFID) device, whereby digital data encoded in an RFID tag or smart tag (defined below) is captured by the reader 60 via radio waves, a PCMCIA smart card, an RFID card, a memory stick, a CD, DVD, or any other analog or digital storage medium. Other examples of the data input device 60 include voice-activated or recognition devices or portable personal data assistants (PDAs). Depending on the type of interface device used, the user interface device 54 and the data input device 60 may be the same device. Although the data input device 60 is... Figure 1C The data input device 60 is shown as being housed within interface unit 14; however, it is understood that the data input device 60 may be integrated within pharmacy system 34 or located externally and communicate with pharmacy system 34 via an RS-232 serial interface or any other suitable communication device. Auxiliary interface 62 may be an RS-232 communication interface; however, any other means for communicating with peripheral devices (such as printers, patient monitors, infusion pumps, or other medical devices) may be used without departing from the subject matter. Alternatively, the 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.

[0035] Network connection 52 can be a wired or wireless connection, such as via Ethernet, WiFi, BLUETOOTH, Integrated Services Digital Network (ISDN) connection, Digital Subscriber Line (DSL) modem, or cable modem. Any direct or indirect network connection can be used, including but not limited to telephone modems, MIB systems, RS232 interfaces, auxiliary interfaces, optical links, infrared links, radio frequency links, microwave links, or WLAN connections or other wireless connections.

[0036] Functional modules 16, 18, 20, and 22 are any devices used to provide care to patients or to monitor patient conditions. For example... Figure 1CAs shown, at least one of functional modules 16, 18, 20, and 22 can be an infusion pump module for delivering medications or other fluids to a patient, such as an intravenous infusion pump. For the purposes of this discussion, functional module 116 is an infusion pump module. Each of functional modules 16, 18, 20, and 22 can be any patient treatment or monitoring device, including but not limited to infusion pumps, syringe pumps, PCA pumps, epidural pumps, enteral pumps, blood pressure monitors, pulse oximeters, EKG monitors, EEG monitors, heart rate monitors, intracranial pressure monitors, etc. Functional modules 16, 18, 20, and / or 22 can be printers, scanners, barcode readers, near-field communication readers, RFID readers, or any other peripheral input, output, or input / output device.

[0037] Each functional module 16, 18, 20 and / or 22 communicates directly or indirectly with interface unit 14, which provides overall monitoring and control of device 12. For example... Figure 1C As shown, or as detailed by Eggers et al., functional modules 16, 18, 20, and / or 22 can be physically and electronically connected serially to one or both ends of interface unit 14. However, it is recognized that other means exist for connecting functional modules to the interface unit, which can be used without departing from the subject matter. It will also be appreciated that devices providing sufficient programmability and connectivity (such as pumps or patient monitoring devices) can operate as standalone devices and communicate directly with the network without connection via a separate interface unit or control unit 14. As described above, additional medical devices or peripheral devices can be connected to patient care device 12 via one or more auxiliary interfaces 62.

[0038] Each functional module 16, 18, 20, 22 may include a module-specific component 76, a microprocessor 70, volatile memory 72, and non-volatile memory 74 for storing information. It should be noted that, although... Figure 1C Four functional modules are shown, but any number of devices can be connected directly or indirectly to the 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 matter. Module-specific components 76 include any components necessary for operating a particular module, such as the pumping mechanism for the infusion pump module 116.

[0039] Although each functional module may be able to operate independently to some extent, the interface unit 14 monitors and controls the overall operation of the device 12. For example, as will be described in more detail below, the interface unit 14 provides programming instructions to functional modules 16, 18, 20, and 22 and monitors the status of each module.

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

[0041] Existing technologies allow data traveling to and from various data sources to be converted into network-compatible data, and information movement between medical devices and networks can be achieved in various ways. For example, patient care device 12 and network 10 can communicate via automatic interaction, manual interaction, or a combination of automatic and manual interaction. Automatic interaction can be continuous or intermittent and can be achieved via a direct network connection 52 (e.g., ...). Figure 1C (As shown), or via RS232 links, MIB systems, RF links (e.g., 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 the intermittent or periodic physical transfer of data between systems using, for example, user interface device 54, coded data input device 60, barcodes, computer disks, portable data assistants, memory cards, or any other media used for data storage. The communication devices in each aspect are bidirectional in terms of accessing data from as many points as possible from distributed data sources. Decisions can be made in various locations within network 40. For example, and not limitingly, decisions can be made in the Health Information System (HIS) server 30, hospital departments or unit stations 32, or within the patient care device 12 itself.

[0042] All direct communication with medical devices operating on a network according to the present invention can be performed through an information system server 30 (referred to as a Remote Data Server (RDS)). According to aspects of the present invention, the network interface module incorporated into the medical device (such as an infusion pump or vital sign measuring device) ignores all network traffic not originating from the certified RDS. The primary responsibility of the RDS in this invention is to track the location and status of all networked medical devices with NIM and to maintain open communication.

[0043] According to various implementations, server 30 includes a prescription set and / or a pharmacy information system. The pharmacy information system enables a secure physician medication ordering process. A pharmacy website (e.g., provided by the server) can provide physicians with a list of available medications from which they can choose. The pharmacy website may contain a drug library with a list of available medications, but it may also contain and present to physicians medication names associated with recommended dosages and dosage limits already established or adopted by healthcare facilities. In cases where physicians only need to select items from a computer screen instead of manually typing in the medication name and dosage figures (such as infusion rate, time, etc.) associated with medication administration, this should result in a more accurate medication process.

[0044] If a clinical order pertains to the administration of a specific medication regimen, the order is transmitted to the facility's pharmacy information system (e.g., part of server 30). The pharmacy reviews the order, and once it is ready, it can be transmitted to the nursing station for matching with the appropriate patient. A prescription set is a list of approved medications used within a healthcare facility (e.g., available for patient ordering). Within the prescription set, there may be instructions regarding usage information and / or approved concentrations and ranges of medications for use in the facility. As will be further described, prescription sets may be used to define one or more medical device drug libraries, which can then be made available to infusion pumps within the hospital network. Within the library, there is drug information such as drug name, concentration, diluent volume, strength, minimum or maximum infusion parameters, and other parameters. Establishing these parameters via system 30, along with parameters for orders outside the prescription set, is useful for maintaining consistency across the healthcare environment and ensuring that orders are understandable and executed as expected by other devices (e.g., infusion pumps) within system 30.

[0045] Further reference Figure 1C The patient care device 12 can operate in several different modes or personalities, each defined by a configuration database. The configuration database can be an internal database 56 of the patient care device or an external database 37. A specific configuration database is selected based at least in part on patient-specific information such as patient location, age, physical characteristics, or medical characteristics. Medical characteristics include, but are not limited to, patient diagnosis, treatment prescriptions, medical history, medical records, patient care provider identity, physical characteristics, or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., physician identity) or the location of the patient care device 12 within the hospital or hospital computer network. Patient care information can be entered via interface devices 52, 54, 60, or 62 and can originate from anywhere within network 10, such as, for example, from a pharmacy server, admission server, laboratory server, etc.

[0046] The memories 56, 58 of interface unit 14 may contain one or more drug libraries, one or more event logs, and pump configuration settings, such as, but not limited to, configuration files to be used in specific practice areas such as ICUs, PEDs, etc. The memories may be electronically loadable memories such as non-volatile memory (e.g., EEPROM). Drug libraries stored on the pump (which, exemplarily, contain information such as drug names and ranges of delivery parameter values ​​(e.g., appropriate concentrations, dose units, and dose limits)) can be used to perform drug-based infusions in a clinical setting.

[0047] The drug library stored in the pump's memory can include clinical order settings, such as limits (also referred to herein as "guardrails") set by the clinical facility for each drug in the library. These limits can take the form of maximum and minimum doses for each drug, and can be dependent on patient factors or other factors associated with drug delivery. For example, dose limits can vary depending on the patient's weight or body surface area ("BSA"), the unit or ward of the healthcare facility using the drug (e.g., neonatal intensive care unit, intensive care unit, etc.), and other factors. An alert can be provided if a nurse sets the pump to operate outside the range of limits for a particular drug. In some cases, the alert may be denied, while in others it may not. Healthcare facilities can establish "soft" limits for each drug, which can be denied by a nurse, and "hard" limits, which may not be denied. In either case of exceeding a limit, the pump data log or other processor communicating with the infusion pump can record each such limit event for subsequent analysis in cases where the attempted setting is above the maximum dose or below the minimum dose.

[0048] The pump also includes a display for showing the 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 drug delivery parameter sets includes information selected from a set of parameters including drug concentration, drug delivery rate, drug dosage, and bolus size. The electronically loaded drug library contains a list of available mode options specifying units that can be used to express drug delivery information, and the drug infusion pump provides this list of available mode options to the user, from which the user makes a selection when the electronically loaded drug library is in the pump. In the case of a syringe pump, the electronically loaded drug library may include a list of names identifying syringe manufacturers that can be used in the drug infusion pump, and the drug infusion pump provides this list of syringe manufacturers to the user, from which the user makes 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 provides this list of syringe sizes to the user, from which the user makes a selection when the electronically loaded drug library is in the pump. In the case of a peristaltic pump, the electronically loaded drug library may include a list of infusion device manufacturers. The loaded drug library may include a set of features, each of which is toggled on or off, and the pump only provides the user with features from the set of features that are toggled on when the electronically loaded drug library is in the pump.

[0049] Figure 2 An example system 200 for automatically programming medical devices is depicted, based on aspects of the subject matter technology. Interoperability between a hospital's electronic medical record (EMR) system 202 and medical devices (such as infusion devices 12) enables the pre-filling of infusion parameters. Pre-filling of infusion parameters can reduce the number of programming screens and buttons required for manual programming of the pump. The implementation of interoperability does not preclude clinicians from manually programming the infusion device. Manual programming may be necessary in the event of a failure of any component of the interface system.

[0050] While the features may be described with reference to the EMR, these features are applicable to providing automated programming of medical devices using similar hospital information systems, such as a pharmacy data management system (PDMS) or other patient data management systems. Furthermore, while the features may be described using an infusion device as an example patient care device 12, these features are applicable to providing automated programming of other medical devices associated with barcodes, such as patient monitors, patient association management systems, ventilators, or alarm management systems.

[0051] Prescription set 204 determines which medications can be dispensed within the hospital network. A hospital committee may be formed to determine how the medications in this prescription set will be used on patient care devices 12. Configuration definitions (e.g., by hospital department such as ICU, NICU, pediatrics, oncology, surgery, etc.) are agreed upon, and medications and typical infusion protocols are established in the medical device drug library (“Drug Library”). Additionally, restrictions or guardrail conditions are defined in the Drug Library. Once the definitions are complete, the configuration including the Drug Library can be released. The pumps at the facility are then updated by transferring the configuration database to some or all of their pumps. Corresponding updates to the prescription set can be shared with other hospital systems (such as pharmacy ordering systems or electronic medical record systems) that can use the prescription set information to generate patient orders to deliver specific medications to specific patients (e.g., Figure 2 (At 2.1).

[0052] In the clinical field, clinicians can use scanners associated with medical devices, such as infusion devices 12, to scan medical items, such as infusion packaging. For example, barcode readers (or other data input devices) are used to scan coded medication labels, patient ID strips, and caregiver ID badges, as well as optional supplementary prescription information or medical device configuration instructions (including configuration database IDs) printed on labels or accompanying orders. The reader / scanner does not need to be integrated with the medical device. The scanner may be part of a separate device connected to the same network 40 as infusion device 12 and configured with software to function in the overall workflow involving infusion device 12, such as medical record terminal 206 (e.g., part of one or more computing devices). A scan initiates a process in which information relating to the item (e.g., scanned from a code affixed to or delivered by the item) is automatically transmitted via network 40 (e.g., ...). Figure 2 At location 2.2, the EMR system 202 connects to the hospital (e.g., at centralized server 30). This EMR system 202 can verify the item and generate (e.g., ...) Figure 2 At section 2.3, an Automatic Programming Request (APR) is sent to medical device 12 to load parameters related to the item. These parameters may be stored in medical device 12, but are loaded in response to an identifier received from the server. While the examples in this document pertain to infusion devices, any medical device can be configured in the same or similar manner and employ the automatic programming error mitigation described herein.

[0053] In the depicted embodiment, the coordination engine 208 coordinates messages sent from the EMR system 202 to the infusion device 12. In the depicted embodiment, the EMR system 202 transmits to the pump coordination engine 208 an APR (or a request thereof) containing the device identifier (ID) of the infusion device receiving the APR (e.g., ...). Figure 2(At 2.4). Then, the coordination engine 208 determines whether the infusion device 12 identified by the EMR system 202 is available, and if available, provides (e.g., forwards or generates and transmits) the APR to device 12 (e.g., Figure 2 At 2.5). When the infusion device 12 receives an APR, it programs itself according to the parameters of the APR. In some embodiments, the APR activates a drug library stored on the device, and the infusion device 12 programs itself according to parameters stored in the drug library for the drug identified in the APR. In some embodiments, after successful programming, the infusion device 12 may automatically initiate operation based on the parameters. In some embodiments, the infusion device 12 may confirm the automatically entered parameters (e.g., Figure 2 (At 2.6). This confirmation may include presenting one or more user interface screens (including parameters and values, and control elements (e.g., buttons)) that, when activated, cause the infusion device 12 to begin operation based on the parameters. The user interface may include additional or alternative control elements to allow clinicians to adjust the automatically entered parameters based on, for example, professional judgment or changes in the patient's condition.

[0054] Figure 3A A first example sequence diagram 300 depicts an automated programming medical device based on a dynamically acquired Automated Programming Request (APR) template, according to aspects of the subject matter technology. For illustrative purposes, reference is made to... Figure 1A , Figure 1B , Figure 1C and Figure 2 The components and / or processes described in the sequence diagram 300 are used to describe the various interactions between the components.

[0055] As previously described, the identifier of medical device 12 can be scanned at EMR terminal 206 to initiate a process through which information related to the medical device is automatically sent to the hospital's EMR server 202. EMR server 202 performs certain actions related to the medical device and transmits an Automatic Programming Request (APR) to medical device 12 to configure it. In some embodiments, the identifier of medical device 12 is scanned from a barcode affixed to the device, and the APR is selected and generated in conjunction with parameters input to the terminal.

[0056] Using an infusion device as an example, a hospital system implementing the subject matter technology may include one or more infusion devices 12, an EMR terminal 206, and an EMR server 202 (including, for example, one or more patient PDMSs) connected to a connectivity gateway 302. In some embodiments, the connectivity gateway 302 includes, is part of, or is associated with a coordination engine 208. In some embodiments, the connectivity gateway 302 is a separate system. In some embodiments, the gateway 302 may include one or more computing devices, such as one or more servers other than the EMR server 202. In some embodiments, the gateway 302 may be... Figure 2 The coordination engine 208 is implemented or interchangeable with it. In some implementations, the EMR server 202 and the connection gateway 302 can coexist as a single server or a group of servers. Figure 1C Server 30 can represent EMR server 202 and / or connection gateway 302.

[0057] exist Figure 3A In the depicted example, a clinician interacts with and authenticates with the EMR terminal 206. About Figure 2 The EMR terminal 206 can obtain the identity of the clinician through an authentication process, and the clinician can enter the nursing area, patient identifier, drug identifier, device / pump / module identifier, order identifier and / or other identification information to request that an APR be sent to the infusion device 12. The identification information obtained by the EMR terminal 206 is transmitted to the EMR server 202 (304) as a request to the automated programming infusion device.

[0058] EMR 202 transmits a request message (306) to connection gateway 302 containing some or all of the information obtained via terminal 206. For example, EMR server 202 may send a request message including (in addition to one or more identifiers received at 304) the device identifier (ID) of the infusion device for receiving APR.

[0059] Then, the connection gateway 302 obtains the APR template to program the medical device (308). In some implementations, the obtained template is specific to the type of medical device. For example, the server 302 may perform a lookup for the medical device type based on a device identifier received with the request (e.g., in a database). In some implementations, the device identifier includes the type of medical device to which the APR is to be sent. In some implementations, the APR template may be associated with a device identifier and obtained via an identifier-based lookup. In some implementations, the APR template is obtained based on an order identifier or a combination of an order identifier and a medical device or type identifier (e.g., retrieved from a database).

[0060] Each APR template includes a plurality of predetermined parameters for programming a corresponding medical device. In some embodiments, the APR template includes a predetermined organization of parameter placeholders for parameter values ​​used by the corresponding medical device to operate. For the purposes of this disclosure, the APR template includes an organized group or structure of information elements for programming the medical device. Information elements may include parameters and / or parameter placeholders (e.g., parameter values ​​may be inserted therein after the placeholders are specified / generated). For the purposes of this disclosure, in some embodiments, the terms parameter and parameter placeholder may be used synonymously.

[0061] In some implementations, the APR template may include default values ​​for one or more (or all) parameters. According to various implementations, when an APR template is obtained, the system continues to identify parameters within the APR (e.g., by electronic parsing or scanning the APR template) and then retrieves parameter values ​​to populate the template using the retrieved values. Parameter values ​​may be stored for various medical devices, and each value is selected for typical operation. In some implementations, as previously described, parameters are provided from a drug database. The drug database for each medical device type may be stored on EMR server 202 and queried by the system upon receiving a request for a template. In some implementations, the template is obtained based on the medical device type and provides which parameters should be used, while one or more parameter values ​​are obtained based on an order identifier and / or patient identifier.

[0062] In the depicted example, the connection gateway 302, having already acquired the template, locates the variable values ​​(310) of one or more (or all) parameters identified in the template by providing an order identifier to the EMR server. Parameters can be retrieved from a single database 37 or multiple databases 37 and / or external systems. In some implementations, the APR template can identify from which source each parameter was retrieved. Therefore, the APR can be generated from multiple sources based on the APR template. The parameters are then merged with the acquired APR template to generate the APR for the medical device (312). In some implementations, merging may include replacing values ​​in the APR template with acquired, order-specific values.

[0063] Coordination engine 302 forwards the APR to device 12 (e.g., Figure 2(at 2.5) (314). When the infusion device 12 receives the APR, the infusion device 12 programs itself according to the parameters of the APR (316). In some embodiments, the APR activates a drug library stored on the device, and the infusion device programs itself according to parameters stored in the drug library for the drug identified in the APR. In some embodiments, the drug library is identified based on information within the APR (e.g., drug identifiers). In some embodiments, some parameters and / or parameter values ​​are provided by the APR, while some parameters and / or parameter values ​​are provided by the drug library.

[0064] In some implementations, the infusion device can automatically initiate operation based on parameters after successful programming. As previously mentioned, the infusion device can confirm the automatically entered parameters (e.g., Figure 2 (See section 2.6). This confirmation may include presenting one or more user interface screens (including parameters and values, and control elements (e.g., buttons)) that, when activated, cause the infusion device to begin operation based on the parameters. The user interface may include additional or alternative control elements to allow clinicians to adjust automatically entered parameters based on, for example, professional judgment or changes in the patient's condition.

[0065] After the APR has been accepted and processed without failure by the infusion device, the infusion device begins infusing the drug according to the programming provided by the APR. Once infusion has begun, the infusion device may send one or more status messages to the EMR system 202. The status messages inform the EMR system what has been initiated and include certain values ​​being reported by the infusion device. This information may reflect APR data and / or may include changes made at the device. The EMR system may wait for status messages and, upon receiving a message, close the workflow associated with the APR.

[0066] Figure 3B An example process 320 is described, based on aspects of the subject matter technology, for automatically programming medical devices using dynamically acquired templates and parameters dynamically updated at the server. For illustrative purposes, this document refers to... Figure 1A -Figure C, Figure 2 and Figure 3AThe various blocks of example process 320 are described herein with reference to the associated components and / or processes. According to various embodiments, process 320 is a simplified variant of process 320. One or more 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 embodiments, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be implemented separately from other blocks and may be implemented by one or more different processors or devices. Furthermore, for illustrative purposes, to the extent that the blocks of example process 320 are described as occurring serially or linearly, in some embodiments, multiple blocks of example process 320 may occur in parallel. Additionally, the blocks of example process 320 need not be executed in the order shown and / or one or more blocks in example process 320 need not be executed.

[0067] According to various implementations, a server (e.g., an EMR and / or a connection gateway server) receives a request for automatic programming of a medical device (322), as previously described. A template for the APR is then retrieved based on the request (324). The system determines whether the APR template includes a replacement variable (326); that is, the system determines whether a parameter among multiple parameters in the template is a parameter to be updated. If the parameter is a parameter to be updated, a variable value for updating the parameter is obtained (328). According to various implementations, the template may indicate from which source (e.g., a database 37, a network service, etc.) the parameter will be updated. In this respect, multiple parameters can be updated from multiple different sources. As will be further described below, parameter values ​​can be obtained at a predetermined time, for example, before the medical device is configured according to the template, or at a predetermined time after configuration. According to various implementations, replacement variables are retrieved from a network source (e.g., a server or a database). In the depicted example, the parameter value is obtained by the server. In some examples, the parameter value may be obtained by the medical device receiving the APR.

[0068] In the depicted example, the template parameters are updated with the acquired parameter values, and an APR message (330) is generated (to be sent to the medical device) based on the template and the updated values. The APR is sent to the medical device to program the medical device (332) (e.g., as in...). Figure 2 (As described in section 2.5). If the template does not include parameters marked as pending updates, then as... Figure 2 The APR message is generated (330), and the APR message is sent to the medical device to program the medical device (332).

[0069] Figure 4AA second example sequence diagram 350 depicts an automated programming medical device based on a dynamically acquired Automated Programming Request (APR) template, according to aspects of the subject matter technology. For illustrative purposes, reference is made herein to... Figure 1A , Figure 1B , Figure 1C , Figure 2 as well as Figure 3A and Figure 3B The components and / or processes described in the sequence diagram 300 are used to describe the various interactions between the components.

[0070] In the depicted example, the parameters(s) to be updated / replaced in the template are determined by medical device 12 (rather than in, for example) Figure 3A (Update / replace at the server in the middle). In this regard, APR requests to be updated / replaced with... Figure 3A The APR is initiated and provided to the server (304, 306) in a similar manner, and the server (e.g., connection gateway 302) obtains the APR template (308). The server 302 forwards the APR to the medical device 12 (314). After the medical device receives the APR, it looks up one or more parameters identified as replacements (340). The parameters of the APR (including those identified as replacements) can be filled in and / or updated from a drug library stored on the medical device, or can be obtained from a remote server. In the depicted example, the medical device 12 looks up the variable values ​​for each parameter identified as a replacement by providing an order identifier to the EMR server (310). According to various embodiments, the identified parameters are obtained during programming, after the AR is retrieved. In some embodiments, the updated parameters (e.g., including replacement values) can be merged with the obtained APR template at the medical device to generate an APR for the medical device. The depicted sequence ends when the medical device 12 completes programming based on the parameters of the APR (316).

[0071] In some implementations, parameters provided in the APR and / or APR template may include function calls. For example, when a server (or medical device) receives an APR template, it may insert a function call into parameter placeholders. For example, the function may perform calculations based on one or more retrieved values. The function call can then be used at runtime to obtain parameter values, for example, based on conditions (e.g., runtime conditions at the medical device). In some implementations, executing the function call when the parameter is to be used may initiate an evaluation of the conditions. The parameter may then be updated to a first value if the conditions are met, or to a second value if the conditions are not met. According to various implementations, the conditions may include selecting the parameter based on another value or determination. For example, the value of the parameter may depend on which care area the medical device is located in or associated with. In this regard, the evaluation of the conditions may include an evaluation of the care area. If the care area is identified as a first care area, the parameter may be set to a first value, and when the care area is identified as a second care area, the parameter may be set to a second value. In some implementations, if the care area is identified as a third care area, the parameter may be set to a third value, and so on.

[0072] Figure 4B An example process 380 is described, based on aspects of the subject matter technology, for automatically programming a medical device using dynamically acquired templates and dynamically updated parameters at the medical device. For illustrative purposes, this document refers to... Figures 1A-1C , Figure 2 , Figure 3A , Figure 3B and Figure 4A The various blocks of example process 380 are described herein with reference to the associated components and / or processes. One or more 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 embodiments, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be separate from other blocks and may be implemented by one or more different processors or devices. Further for illustrative purposes, to the extent that the blocks of example process 380 are described as occurring serially or linearly, in some embodiments, multiple blocks of example process 380 may occur in parallel. Furthermore, the blocks of example process 380 do not need to be executed in the order shown, and / or one or more blocks of example process 380 do not need to be executed.

[0073] In the depicted example, as previously described, medical device 12 receives an Automatic Programming Request (APR) from a server (382). As previously described, the APR may be based on a dynamically acquired template. One or more parameters are tagged (e.g., identified) for updating by the medical device upon receipt (e.g., when parsed by the medical device), or when the medical device is configured according to the APR, or within a predetermined time period after programming the medical device or initiating an infusion. At appropriate times, medical device 12 continues to acquire updated parameter values ​​for each tagged parameter (386). For example, the medical device may retrieve replacement variable values ​​for each tagged parameter from another computing device (e.g., a remote server or database). As previously described, multiple parameters may be updated from different sources. After the parameters are determined, the configuration of medical device 12 can be completed as previously described (388).

[0074] Figure 4C A sample flowchart illustrating the setting of a refresh timer for parameters in an Automatic Programming Request (APR) is provided, based on various aspects of the subject matter technology. For illustrative purposes, this document references... Figures 1A-1C , Figure 2 , Figure 3A , Figure 3B , Figure 4A and Figure 4B The various blocks of example process 400 are described herein with reference to the associated components and / or processes. According to various embodiments, process 400 is a simplified variant of process 400. One or more 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 embodiments, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be separate from other blocks and may be implemented by one or more different processors or devices. Further for illustrative purposes, to the extent that the blocks of example process 400 are described as occurring serially or linearly, in some embodiments, multiple blocks of example process 400 may occur in parallel. Furthermore, the blocks of example process 400 do not need to be executed in the order shown, and / or one or more blocks of example process 400 do not need to be executed.

[0075] According to various implementations, an Automatic Programming Request (APR) is received at a medical device (such as an infusion device in this example). In the depicted example, infusion is initiated (402) according to the APR. Upon initiation, parameters of the APR (in the subject matter art, the APR is generated based on a dynamically acquired template) are used to program the infusion.

[0076] As previously described, the APR of the subject technology may include parameters (or variables) marked as replacements. In the depicted example, medical device 12 determines whether the APR includes such parameters (404). If not, infusion begins. In some embodiments, this determination may occur periodically. For example, while the infusion has not yet been completed (418), the medical device may periodically determine whether a replacement parameter has been inserted into the programming of the medical device, or whether it has been inserted into the APR that programs the medical device. In some embodiments, a new APR may be obtained from a server or updated during infusion. In some embodiments, a clinician may mark parameters as replacements via the device's control panel.

[0077] When the APR includes replacement parameters, medical device 12 can attempt to acquire the new parameters. Multiple replacement parameters identified by the template can originate from multiple sources. In some implementations, parameter input and / or updating can occur at the server, but one or more parameters can be further updated at the medical device. According to various implementations, the parameter is updated with the new value and infusion begins.

[0078] In some implementations, the medical device can receive an APR (Application Processing Representation) and identify parameters in the APR (or template) that are marked as to be refreshed after the medical device is configured or at a predetermined future time. In the depicted example, the parameter is set with a first value and marked as to be updated to a second value after a predetermined time period. In this regard, the medical device can set a refresh timer (406) after the medical device 12 is configured according to the template and the first parameter. Thus, the medical device can periodically determine whether the timer has expired (408) as it is operating as expected (e.g., continuing medication infusion). The refresh timer expiration can be specified by the clinician when the infusion is initiated (e.g., via a user interface) or can be set automatically based on information available to the infusion device 12 (such as the care area, the medication to be administered, or the parameter to be retrieved). When the refresh timer expires, the medical device 12 can determine a new value to update the first parameter (410) and then continue updating the first parameter based on the new value (414). In some implementations, the medical device 12 can first determine whether the new value is different from the current parameter or otherwise does not correspond to the current value before performing the update (412). In some implementations, the medical device 12 may prompt the user / clinician to confirm the updated parameter value (416) before updating the current parameter with the updated parameter value.

[0079] Figure 5 A third example flowchart is depicted, based on aspects of the subject matter technology, for the automated programming of medical devices using dynamically acquired automated APR templates. For illustrative purposes, this paper refers to... Figures 1A-1C , Figure 2 , Figure 3A-B, and Figure 4A Figure C and the associated components and / or processes described herein illustrate the various blocks of example process 500. According to various embodiments, process 500 is a simplified variant of process 500. One or more 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 embodiments, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be separate from other blocks and may be implemented by one or more different processors or devices. Further for illustrative purposes, to the extent that the blocks of example process 500 are described as occurring serially or linearly, in some embodiments, multiple blocks of example process 500 may occur in parallel. Furthermore, the blocks of example process 500 do not need to be executed in the order shown, and / or one or more blocks of example process 500 do not need to be executed.

[0080] In the depicted example, a request to initiate the automatic programming of medical device 12 is received (502). As previously described, medical device 12 may be an infusion pump or pump controller configured to administer medication to a patient via an infusion device (e.g., an intravenous tubing and catheter). This request may be received from a computer terminal associated with the medical device, such as regarding... Figure 2 As stated above.

[0081] Based on (or in response to) this request, a template corresponding to the type of medical device is obtained (504). For the purposes of this disclosure, the APR template includes an organized group or structure of information elements for programming the medical device. One or more elements of the element may include one or more parameters associated with infusion (e.g., flow rate, VTBI (volume to be infused), guardrail, etc.). One or more elements of the element may include parameter placeholders for parameters to be filled in at different times and / or from another system. The obtained template includes parameters for configuring the medical device 12 (e.g., based on an order (previously entered by a clinician into the corresponding healthcare information system). In some embodiments, the template will be specific to the type of medical device. In this regard, the received request may include data sufficient to enable the system to identify the medical device and / or its type. For example, such data may include identifiers of the order, patient, clinician, medical device, medical device type, and / or medication.

[0082] The system (e.g., server 202 / 302) determines from the template that the first parameter among the parameters associated with the template is the parameter to be updated (506). According to various implementations, the parameter may be marked within the template by metadata or other indications identified by the system during template scanning or parsing. The metadata or other indications may further identify when the parameter should be updated. For example, the parameter may be marked as updating when configuring a medical device, or it may be marked as updating in the future. In either case, the parameter may be initially set to a default value before updating, and the default value may be used for initial programming of the medical device (e.g., for initiating an infusion).

[0083] When the system determines that the first parameter is the parameter to be updated (and / or is at the indicated time for updating), the system then proceeds to update the first parameter (508). In this regard, an updated parameter value (e.g., a value calculated based on a formula, a value obtained through a function call, or a retrieved value) can be generated and then replaced in the template. According to various implementations, updating a parameter includes setting a new value for that parameter. In some implementations, updating a parameter may include replacing an existing parameter value or replacing the parameter with a completely different parameter. An example of the latter may include replacing the ETCO2 parameter with the SP02 parameter.

[0084] In some implementations, updating parameters may include generating a function call and inserting the function call into parameter placeholders, such that when the parameter is used (e.g., in implementations used to program a medical device or to generate an APR using a template), the function call is executed and an updated value is retrieved from a remote location identified by the function call. In some implementations, numeric parameter values ​​may be replaced with function calls for retrieving new parameter values ​​when the function call is executed.

[0085] While the example depicted includes a single parameter being updated, it is understood that any number of parameters (e.g., two, three, four, etc.) can be identified by the system as pending updates and subsequently updated. As previously stated, the parameters to be updated (one or more) may include function calls. In this regard, function calls may retrieve new parameters based on conditions. For example, when a parameter will be used at runtime (e.g., by a medical device), the function call is executed by software used to retrieve the parameter from an APR and / or template. The system (e.g., the medical device or server to which the function call is directed) determines whether the conditions are met and sets the new parameter based on circumstances closely related to those conditions. For example, the system may set the new parameter to a first value when the conditions are met and to a second value different from the first value when the conditions are not met. Then, as previously stated, the first parameter indicated as pending updates is updated with the new parameter.

[0086] In some implementations, when the server is invoked by a function call, the conditions are transmitted by the medical device; for example, the function call itself includes the conditions as parameters. The server can then retrieve new parameters based on these conditions and update the first parameter (the object of the function call) with the new parameters (e.g., by returning the new parameters to the function call). In one example, a care area can be determined, and whether a condition is met can be based on the determined care area. In one example, the care area can be sent to the server as part of a function call (by the medical device), and the server can perform a lookup based on the care area to determine new parameters for updating the first parameter. For example, this value could be a web service used to provide order-specific information. The APR template can include information required to access the web service, such as an authorization token, an order identifier, or other parameters that the service can use to retrieve the expected information. In some instances, the authorization token can be valid only when it appears with the order identifier. This can prevent unauthorized access to hospital or patient information. In another example, the server can look up the care area itself based on information received from the medical device (e.g., a device identifier).

[0087] In some implementations, the updated parameters can be determined by a trained (machine learning) model. Therefore, the system can collect drug-related parameter data across patient groups, clinician groups, and / or medical device groups. The drug's identifier can be sent along with a request to initiate automated programming of the medical device. The system can also receive characteristics of the patient, the patient's associated clinician, and / or the medical device. These characteristics can be sent with an APR or retrieved based on information in the APR (e.g., from an EMR server). One or more of these characteristics can then be fed into a trained model that determines the updated parameters based on its training and machine learning.

[0088] In some implementations, the updated parameters (e.g., parameter values) include the latest clinical guidelines for the patient, medical device, and / or medication. The system can retrieve the latest clinical guidelines based on information in the request (e.g., from server 202 / 302). In some implementations, the clinical guidelines can be based on the care area of ​​the medical device, which can be determined according to any of the methods described previously. In some implementations, the guidelines can be based on the clinician's past qualifications or care area (e.g., to alert clinicians in a specific care area to issues related to the medication or medical device). In one example, a function call as described above can be used to retrieve the latest clinical guidelines when programming the medical device.

[0089] The described process continues after the template update by automatically transmitting an automated programming message (APR) to the medical device (510) based on the template. In some embodiments, the filled template is sent as an APR. In some embodiments, the APR is generated based on the template (e.g., generated at a server or generated by the medical device after receiving the template). Thus, the APR enables the medical device to be configured according to the template and multiple parameters, including a first parameter updated with the updated parameter value.

[0090] As previously described, the system can determine that after the medical device is configured according to a template, the APR or parameters of the template (e.g., the first parameter) should be refreshed. Therefore, the parameter to be refreshed is marked. When the device is configured according to the APR, the medical device (or the system via metadata) can set a refresh timer. The refresh timer can 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 begins. When the refresh timer expires, the medical device can automatically determine new parameters to update the first parameter and update the first parameter of the medical device based on the new parameters. In some implementations, the APR is periodically updated at the server based on the template, and the marked parameter is refreshed before the updated APR is sent to the medical device according to the refresh timer schedule.

[0091] Many of the example processes 400, 500, and 700 described above, along with their related features and applications, can also be implemented as software processes. These software processes are specified as a set of instructions recorded on a computer-readable storage medium (also known as a computer-readable medium) and can be executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, or other processing units), they cause the processing unit to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard disk drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or via wired connections.

[0092] The term "software" is intended to include, where appropriate, firmware residing in read-only memory or an application stored in magnetic storage, which can be read into memory for processor processing. Furthermore, in some embodiments, the multiple software aspects disclosed herein may be implemented as sub-parts of a larger program while maintaining the distinct software aspects disclosed herein. In some embodiments, the multiple software aspects may also be implemented as separate programs. Finally, any combination of separate programs that collectively implement the software aspects described herein is within the scope of this disclosure. In some embodiments, a software program, when installed for operation on one or more electronic systems, defines one or more specific machine implementations of the operations performed and executed by the software program.

[0093] Computer programs (also referred to as programs, software, software applications, scripts, or code) can be written in any programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, objects, or other units suitable for use in a computing environment. A computer program may, but does not necessarily, correspond to a file in a file system. A program may be stored as a portion of a file containing 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 coordinating files (e.g., a file storing one or more modules, subroutines, or code sections). A computer program can be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected by a communication network.

[0094] Figure 6 This is a conceptual diagram illustrating an example electronic system 600 for automatically programming a medical device based on dynamically acquired APR templates, according to aspects of the subject matter technology. The electronic system 600 may be for performing one or more parts or steps of processes 300, 350, 400, and 500, or as shown in Figure 1- Figure 5 The computing devices associated with the provided components and methods include, but are not limited to, the 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 specially configured personal computer or mobile device, such as a smartphone, tablet, laptop, PDA, augmented reality device, wearable device (such as a watch or strap or glasses), or a combination thereof, or other touchscreen or television having one or more processors embedded therein or coupled thereto, or similar computer-related electronic devices with network connectivity.

[0095] Electronic system 600 may include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, electronic system 600 includes a bus 608, one or more processing units 612, system memory 604, read-only memory (ROM) 610, permanent storage device 602, input device interface 614, output device interface 606, and one or more network interfaces 616. In some embodiments, electronic system 600 may include or be integrated with other computing devices or circuitry, specifically configured to operate the various components and methods described above.

[0096] Bus 608 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 600. For example, bus 608 communicatively connects one or more processing units 612 to ROM 610, system memory 604, and permanent storage device 602.

[0097] From these various memory units, one or more processing units 612 retrieve instructions to be executed and data to be processed in order to perform the processes disclosed in this subject matter. In different embodiments, the one or more processing units may be single-processor or multi-core processors.

[0098] ROM 610 stores static data and instructions required by processing unit 612 (or other modules of the electronic system). On the other hand, permanent storage device 602 is a read-write memory device. This device is a non-volatile memory cell that stores instructions and data even when the electronic system 600 is off. Some embodiments disclosed in this subject matter use mass storage devices (such as magnetic disks or optical disks and their corresponding disk drives) as permanent storage device 602.

[0099] Other embodiments use removable storage devices (such as floppy disks, flash drives, and their corresponding disk drives) as permanent storage device 602. Like permanent storage device 602, system memory 604 is a read-write memory device. However, unlike storage device 602, system memory 604 is volatile read-write memory, such as random access memory. System memory 604 stores some instructions and data required by the processor during operation. In some embodiments, the processes disclosed in this subject matter are stored in system memory 604, permanent storage device 602, and / or ROM 610. From these various memory units, processing unit 612 retrieves instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0100] Bus 408 is also connected 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, for example, alphanumeric keypads and pointing devices (also referred to as "cursor control devices"). Output device interface 606 enables, for example, the display of images generated by electronic system 600. Output devices used with output device interface 606 include, for example, printers and display devices such as cathode ray tube (CRT) or liquid crystal display (LCD). Some implementations include devices such as touchscreens, which function as both input and output devices.

[0101] In addition, such as Figure 6 As shown, bus 608 also couples electronic system 600 to a network (not shown) via network interface 616. Network interface 616 may include, for example, a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. Network interface 616 may also include hardware (e.g., Ethernet hardware or network interface module) for connecting the computer to a part of or more of a computer network (such as the Internet), such as a local area network (“LAN”), wide area network (“WAN”), wireless LAN, or intranet). Any or all components of electronic system 800 may be specifically configured for use in conjunction with the disclosure of this subject matter.

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

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

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

[0105] As used in the specification and any claims of this application, the terms "computer," "server," "processor," and "memory" refer to electronic or other technical devices. These terms do not include people or groups of people. For the purposes of this specification, the terms "displayed" or "being displayed" mean displayed on an electronic device. As used in the specification and any claims of this application, the terms "computer-readable medium" and "computer-readable media" are entirely limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, or any other transient signals.

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

[0107] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes backend components, such as a data server, or middleware components, such as an application server, or frontend components, such as a client computer with a graphical user interface or a web browser through which a user can interact with embodiments of the subject matter described in this specification, or any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication (e.g., a communication network) of any form or medium. Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

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

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

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

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

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

[0113] Clause 1. A system comprising: one or more computing devices configured to perform operations including: receiving a request to initiate automatic programming of a medical device; obtaining a template specific to the medical device type based on the request and the type of the medical device, the template including multiple parameters for configuring 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 multiple parameters in the template is a parameter to be updated; and in response to determining that the first parameter is a parameter to be updated: generating an update value for updating the first parameter in the template; updating the first parameter with the update value; and automatically transmitting an automatic programming message to the medical device based on the template, the automatic programming message causing the medical device to be configured according to the template and the multiple parameters including the first parameter updated with the update value.

[0114] Clause 2. The system according to Clause 1, wherein the operation further includes, 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 marker parameter of a plurality of parameters is marked as to be refreshed after the medical device is configured according to the template; setting a refresh timer; and when the refresh timer expires, after the medical device is configured according to the template, (1) determining a new parameter value for updating the marker parameter, and (2) updating the current value of the marker parameter based on the new parameter value so that the medical device uses the new parameter value instead of the current value of the marker parameter.

[0115] Clause 3. The system according to Clause 1 or Clause 2, wherein the template includes a function call for obtaining a value of a first parameter, and wherein updating the first parameter includes: executing the function call; and receiving an updated value for the first parameter based on the function call.

[0116] Clause 4. The system according to Clause 3, wherein the function call obtains a new parameter based on a condition, and wherein the operation further includes, before the medical device is configured: receiving an indication that the function call is initiated; in response to the indication: determining whether the condition is met; if the condition is met, setting the new parameter to a first value, and if the condition is not met, setting the new parameter to a second value different from the first value; and updating the first parameter with the new parameter.

[0117] Clause 5. The system according to Clause 4, wherein the operation further includes: receiving conditions and instructions from the medical device via a network; and providing new parameter values ​​to the medical device so that the first parameter is updated with the new parameters.

[0118] Clause 6. The system according to Clause 4, wherein the operation further includes: determining the care area of ​​the medical device; and wherein the determination of whether the condition is met is based on the care area.

[0119] Clause 7. A system according to any one of Clauses 1-6, wherein a request and multiple parameters are used to configure a medical device to deliver a drug, wherein the operation further includes: collecting drug-related parameter data across patient groups, clinician groups, and medical device groups; identifying the drug based on the request; receiving features of the patient associated with the medical device, the clinician associated with the patient, or the medical device; and determining updated values ​​based on inputting the features into a machine learning model trained with the parameter data.

[0120] Clause 8. A system according to any one of Clauses 1-7, wherein the operation further includes: updating a second parameter of a plurality of parameters in a template to include a function call for obtaining clinical information associated with a drug provided by a medical device; receiving requests for clinical information and requests for features of the patient, the clinician associated with the patient, or the medical device when an automated programming message configures the medical device; and providing the medical device with clinical information updated based on the requests and features.

[0121] Clause 9. A medical device comprising: a display device; and a medical device controller including a processor; wherein the medical device controller is configured to: receive an automated programming template specific to a type of medical device from a server remote from the medical device, and the automated programming template includes a plurality of parameters for configuring 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 in response to determining that the first parameter is a parameter to be updated: determine an update value for updating the first parameter in the template; update the first parameter with the update value; and automatically configure the medical device according to the template and the plurality of parameters including the first parameter updated with the update value.

[0122] Clause 10. The medical device according to 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 a template: determine that a flag parameter of a plurality of parameters is flagged as to be refreshed after the medical device is configured according to the template; set a refresh timer; and when the refresh timer expires, after the medical device is configured according to the template: (1) determine a new parameter value for updating the flag parameter, and (2) update the current value of the flag parameter based on the new parameter value so that the medical device uses the new parameter value instead of the current value of the flag parameter.

[0123] Clause 11. A medical device according to Clause 9 or Clause 10, wherein the first parameter includes a function call, and wherein the medical device controller is further configured to: determine the update value including executing the function call to retrieve the update value; and update the first parameter including replacing the first parameter with the update value.

[0124] Clause 12. The medical device according to Clause 11, wherein the function call is based on a condition to obtain an update value, wherein the medical device controller is further configured to, before the medical device is configured: determine whether the condition is met; and if the condition is met, set the update value to a first parameter value, and if the condition is not met, set the update value to a second parameter value different from the first parameter value.

[0125] Clause 13. A medical device as described in any one of Clauses 9-12, wherein multiple parameters are used to configure the medical device to deliver a drug, wherein the medical device controller is further configured to: collect drug-related parameter data across at least one of a patient population, a clinician population, and a medical device population; identify the drug; receive features of the patient associated with the medical device, the clinician associated with the patient, or the medical device; and determine updated values ​​based on inputting the features into a machine learning model trained with the parameter data.

[0126] Clause 14. A medical device according to any one of Clauses 9-13, wherein the medical device controller is further configured to: wherein a second parameter of the plurality of parameters in the template includes a function call for obtaining clinical information associated with a drug provided by the medical device; executing the function call to obtain the clinical information; receiving the clinical information from a remote computing device; and displaying the clinical information on a display device.

[0127] Clause 15. A method comprising: receiving a request to initiate automatic programming of a medical device; obtaining a template specific to the type of the medical device based on the request and the type of the medical device, the template including multiple parameters for configuring 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 multiple parameters in the template is a parameter to be updated; and in response to determining that the first parameter is a parameter to be updated, before the medical device is configured using the template: generating an update value for updating the first parameter in the template; updating the first parameter with the update value; and automatically transmitting an automatic programming message to the medical device based on the template, the automatic programming message causing the medical device to be configured according to the template and the multiple parameters including the first parameter updated with the update value.

[0128] Clause 16. The method according to 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 a template: determining that the first parameter is marked as 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 when the refresh timer expires, (1) determining a new parameter value for updating the marked parameter, and (2) updating the current value of the marked parameter based on the new parameter value so that the medical device uses the new parameter value instead of the current value of the marked parameter.

[0129] Clause 17. The method according to Clause 15 or Clause 16, wherein updating the value includes a function call, and updating the first parameter includes inserting the function call into a template for the first parameter, wherein the function call obtains the new parameter based on a condition, and wherein the method further includes, before the medical device is configured: receiving an indication that the function call is initiated; in response to the indication: determining whether a condition is met; if the condition is met, setting the new parameter to a first value, and if the condition is not met, setting the new parameter to a second value different from the first value; and updating the first parameter with the new parameter.

[0130] Clause 18. The method according to Clause 17, wherein the method further comprises: receiving conditions and instructions from a medical device via a network; and providing new parameters to the medical device to update the first parameter with the new parameters.

[0131] Clause 19. The method according to any one of Clauses 15-18, wherein a request and multiple parameters are used to configure a medical device to deliver a drug, wherein the method further comprises: collecting drug-associated parameter data across patient populations, clinician populations, and medical device populations; identifying the drug based on the request; receiving features of the patient associated with the medical device, the clinician associated with the patient, or the medical device; and determining updated values ​​based on inputting the features into a machine learning model trained with the parameter data.

[0132] Clause 20. The method according to any one of Clauses 15-19, wherein the method further comprises: updating a second parameter of a plurality of parameters in a template to include a function call for obtaining clinical information associated with a drug provided by a medical device; receiving from the medical device requests for clinical information and requests for features of the patient, the clinician associated with the patient, or the medical device when an automated programming message configures the medical device; and providing the medical device with clinical information updated based on the requests and features.

[0133] Clause 21. A non-transitory computer-readable medium comprising instructions that, when executed by a computing system, cause the computing system to perform the methods described in any one of Clauses 15 to 20.

[0134] Further consideration:

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

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

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

[0138] As used herein, the term "automatic" can include actions performed by a computer or machine without user intervention; for example, by instructions issued by a computer, machine, or other initiation mechanism in response to a predicate action. The word "example" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as an "example" is not necessarily to be construed as preferential or superior to other aspects or designs.

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

[0140] As used herein, a “user interface” (also referred to as an interactive user interface, graphical user interface, or UI) can mean a web-based interface including data fields and / or other control elements for receiving input signals or providing electronic information and / or for providing information to a user in response to any received input signals. Control elements may include dial pads, buttons, icons, selectable areas, or other perceptible markings presented via the UI that, when interacted with (e.g., click, touch, select, etc.), initiate data exchange between the device presenting the UI. The UI may be implemented, in whole or in part, using technologies such as Hypertext Markup Language (HTML), Flash™, Java™, .NET™, C, C++, web services, or Rich Site Summary (RSS). In some embodiments, the UI may be included in a separate client (e.g., a thick client, a fat client) configured to communicate (e.g., send or receive data) according to one or more of the described aspects. Communication may arrive at or originate from a medical device or server with which it communicates.

[0141] As used herein, the term "determine" or "confirm" encompasses a wide variety of actions. For example, "determine" can include calculating, processing, deducing, generating, retrieving, searching (e.g., looking in a table, database, or other data structure), confirming, etc., via hardware components without user intervention. Furthermore, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc., via hardware components without user intervention. "Determine" can also include parsing, selecting, choosing, building, etc., via hardware components without user intervention.

[0142] As used herein, the term “provide” or “provide” encompasses a wide variety of actions. For example, “providing” can include storing a value at a location on a storage device for later retrieval, transmitting a value directly to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, etc. “Providing” can also include encoding, decoding, encrypting, decrypting, verifying, authenticating, etc., via hardware components.

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

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

[0145] As described herein, the term "correspondence" or "correspondence" encompasses, when used to describe a relationship between two or more elements, a structural, functional, quantitative, and / or qualitative association or relationship between two or more objects, datasets, information, and / or the like. Preferably, a correspondence or relationship can be used to translate one or more of the two or more objects, datasets, information, and / or the like so that they appear identical or equal. Correspondence can be evaluated using one or more of thresholds, value ranges, fuzzy logic, pattern matching, machine learning evaluation models, or combinations thereof.

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

Claims

1. A system comprising: One or more computing devices, the one or more computing devices being configured to perform operations including the following: Receive a request to initiate the automatic programming of medical equipment; Based on the request and the type of the medical device, a template specific to the type of the medical device is obtained, and the template includes multiple parameters for configuring the medical device; After obtaining the template and before the medical device is configured according to the template, it is determined that the first parameter of the plurality of parameters in the template is the parameter to be updated; and In response to determining that the first parameter is the parameter to be updated: Generate an updated value for updating the first parameter in the template; Update the first parameter with the updated value; and Based on the template, an automatic programming message is automatically transmitted to the medical device, which configures the medical device according to the template and the plurality of parameters including the first parameter updated with the updated value.

2. The system according to claim 1, wherein, The operation further includes, after determining that the first parameter is a parameter to be updated, and before the medical device is configured using the template: The marker parameter of the plurality of parameters is marked as to be refreshed after the medical device is configured according to the template; Set a refresh timer; and When the refresh timer expires, after the medical device is configured according to the template, (1) a new parameter value for updating the marker parameter is determined, and (2) the current value of the marker parameter is updated based on the new parameter value, so that the medical device uses the new parameter value instead of the current value of the marker parameter.

3. The system according to claim 1 or claim 2, wherein, The template includes a function call for obtaining the value of the first parameter, and wherein updating the first parameter includes: Execute the function call; and Based on the function call, the updated value for the first parameter is received.

4. The system according to claim 3, wherein, The function call retrieves new parameter values ​​based on conditions, and the operation further includes, prior to the configuration of the medical device: Receive an indication that the function call has been initiated; In response to the instruction: Determine whether the conditions are met; When the condition is met, the new parameter value is set to a first value; and when the condition is not met, the new parameter value is set to a second value different from the first value; and The first parameter is updated with the new parameter value.

5. The system according to claim 4, wherein, The operation also includes: Receive the conditions and instructions from the medical device via a network; and The new parameter value is provided to the medical device so that the first parameter is updated with the new parameter value.

6. The system according to claim 4, wherein, The operation also includes: Determine the care area of ​​the medical device; and The determination of whether the condition is met is based on the nursing area.

7. The system according to any one of claims 1-6, wherein, The request and the plurality of parameters are used to configure the medical device to deliver medication, wherein the operation further includes: Collect parameter data related to the drug across patient groups, clinician groups, and medical device groups; Identify the drug based on the request; Receive features of the patient associated with the medical device, the clinician associated with the patient, or the medical device; and The updated value is determined by inputting the features into a machine learning model trained with the parameter data.

8. The system according to any one of claims 1-7, wherein, The operation also includes: Update the second parameter of the plurality of parameters in the template to include a function call for obtaining clinical information associated with the drug provided by the medical device; When the automatic programming message configures the medical device, requests for clinical information and requests for features of the patient, the clinician associated with the patient, or the medical device are received from the medical device. The medical device is provided with the clinical information updated based on the request and the features.

9. A medical device, the medical device comprising: Display devices; and A medical device controller, the medical device controller including a processor; The medical device controller is configured as follows: Receives an automated programming template specific to the type of the medical device from a server located remotely from the medical device, and the automated programming template includes multiple parameters for configuring the medical device; Before the medical device is configured according to the template, it is determined that the first parameter of the plurality of parameters in the template is the parameter to be updated; and In response to determining that the first parameter is the parameter to be updated: Determine the update value for updating the first parameter in the template; Update the first parameter with the updated value; and The medical device is automatically configured based on a template and the plurality of parameters, including the first parameter updated with the updated value.

10. The medical device according to claim 9, wherein, The medical device controller is also configured to, after determining that the first parameter is a parameter to be updated, and before the medical device is configured using the template: The marker parameter of the plurality of parameters is marked as to be refreshed after the medical device is configured according to the template; Set a refresh timer; and When the refresh timer expires, after the medical device has been configured according to the template: (1) Determine a new parameter value for updating the marker parameter, and (2) Update the current value of the marker parameter based on the new parameter value, such that the medical device uses the new parameter value instead of the current value of the marker parameter.

11. The medical device according to claim 9 or claim 10, wherein, The first parameter includes a function call, and the medical device controller is further configured to: Determining the updated value includes executing the function call to retrieve the updated value; and Updating the first parameter includes replacing the first parameter with the updated value.

12. The medical device according to claim 11, wherein, The function call retrieves 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 conditions are met; as well as When the condition is met, the updated value is set to a first parameter value; when the condition is not met, the updated value is set to a second parameter value that is different from the first parameter value.

13. The medical device according to any one of claims 9-12, wherein, The plurality of parameters are used to configure the medical device to deliver medication, wherein the medical device controller is further configured to: Collect parameter data related to the drug from at least one of the patient population, clinician population, and medical device population; Identify the drug; Receive features of the patient associated with the medical device, the clinician associated with the patient, or the medical device; as well as The updated value is determined by inputting the features into a machine learning model trained with the parameter data.

14. The medical device according to any one of claims 9-13, wherein, The medical device controller is also configured to: The second parameter of the plurality of parameters in the template includes a function call for obtaining clinical information associated with the drug provided by the medical device; Execute the function call to obtain the clinical information; Receive the clinical information from a remote computing device; and The clinical information is displayed on the display device.

15. A method, the method comprising: Receive a request to initiate the automatic programming of medical equipment; Based on the request and the type of the medical device, a template specific to the type of the medical device is obtained, and the template includes multiple parameters for configuring the medical device; After obtaining the template and before the medical device is configured according to the template, it is determined that the first parameter of the plurality of parameters in the template is the parameter to be updated; and In response to determining that the first parameter is a parameter to be updated, before the medical device is configured using the template: Generate an updated value for updating the first parameter in the template; Update the first parameter with the updated value; and Based on the template, an automatic programming message is automatically transmitted to the medical device, which configures the medical device according to the template and the plurality of parameters including the first parameter updated with the updated value.

16. The method according to claim 15, wherein, The method further includes, after determining that the first parameter is a parameter to be updated, and before the medical device is configured using the template: It is determined that the first parameter is marked as pending refresh after the medical device is configured according to the template and the first parameter; After the medical device is configured according to the template and the first parameter, a refresh timer is set; as well as When the refresh timer expires, (1) a new parameter value for updating the marker parameter is determined, and (2) the current value of the marker parameter is updated based on the new parameter value, so that the medical device uses the new parameter value instead of the current value of the marker parameter.

17. The method according to claim 15 or claim 16, wherein, The updated value includes a function call, and updating the first parameter includes inserting the function call into the template for the first parameter, wherein the function call retrieves the new parameter based on conditions, and wherein the method further includes, before the medical device is configured: Receive an indication that the function call has been initiated; In response to the instruction: Determine whether the conditions are met; When the condition is met, the new parameter is set to a first value; and when the condition is not met, the new parameter is set to a second value different from the first value. The first parameter is updated with the new parameter.

18. The method according to claim 17, wherein, The method further includes: Receive the conditions and instructions from the medical device via a network; and The new parameters are provided to the medical device so that the first parameters are updated with the new parameters.

19. The method according to any one of claims 15-18, wherein, The request and the plurality of parameters are used to configure the medical device to deliver medication, wherein the method further includes: Collect parameter data related to the drug across patient groups, clinician groups, and medical device groups; Identify the drug based on the request; Receive features of the patient associated with the medical device, the clinician associated with the patient, or the medical device; and The updated value is determined by inputting the features into a machine learning model trained with the parameter data.

20. The method according to any one of claims 15-19, wherein, The method further includes: Update the second parameter of the plurality of parameters in the template to include a function call for obtaining clinical information associated with the drug provided by the medical device; When the automatic programming message configures the medical device, requests for clinical information and requests for features of the patient, the clinician associated with the patient, or the medical device are received from the medical device. The medical device is provided with the clinical information updated based on the request and the features.

Images