Remote scanning and verification of clinical order device configurations

Abstract

A system for scanning and verifying clinical order device configurations is disclosed. A test instance of the infusion device is created based on the request, and an automatic programming command is transmitted to the test instance. The automatic programming command includes verification information for verifying the clinical order data, and a programming response is generated by the test instance based on the automatic programming command, and the programming response is provided for storage in the recording system. In some embodiments, the response includes an image of or a reference to the image of a graphical user interface to be presented by the infusion device configured according to the verification information.

Description

Technical Field

[0001] The present application relates generally to ensuring that an infusion device is properly programmed. Background Art

[0002] Modern infusion devices provide a manual workflow for programming a pump for drug infusion via a user interface. In addition, the infusion device can receive infusion order parameters from a third-party system to configure the device's pump to deliver a specific fluid at a specific rate for a specific patient; the remote programming command is often referred to as an automated programming request (APR). The APR configuration may include pre-populated operating parameter values ​​for presentation via the user interface.

[0003] Pre-population of infusion parameters reduces the number of programming screens, keystrokes, and potential input errors that may be present with manual programming. Generally, there may be no differences in programming screens, prompts, or user interfaces between systems configured for APR and systems not configured for APR, and embodiments of APR do not preclude the clinician from manually programming the pump. However, if any component of the interface system fails, manual programming may be required.

[0004] In some APR-enabled systems, an APR order may be rejected due to a device-to-order deviation that prevents the system from taking automatic action based on the order. For example, an infusion device may be configured not to infuse at a flow rate greater than 999 mL / h. If an APR order includes a rate parameter value of 1000 mL / h, then the order may be rejected because the automatically programmed parameter value does not align with the pump configuration. When the order is rejected, the device must be manually programmed to initiate an infusion. Misalignment errors often go undetected until the pump is programmed in a clinical setting to deliver an infusion to a patient. It is understood that such APR-related errors are not centrally cataloged. Summary of the invention

[0005] The subject technology provides a mechanism and corresponding algorithm for scanning clinical order device configurations and identifying APR misalignment errors in APR orders. Unlike traditional systems and processes, misalignments between pharmacies and other hospital information systems and infusion pumps can be discovered in real time and across multiple devices in a healthcare network and cataloged in a central database. Thus, drug libraries and / or other drug databases can be updated with "good" data according to a centralized schedule, thereby eliminating misaligned data that would otherwise cause the device to be taken out of service for manual correction by a clinician or technician.

[0006] In this regard, the subject technology includes a system for remotely scanning and verifying a clinical order device configuration, including: a processor; and a non-transitory computer-readable medium including instructions that, when executed by the processor, cause the system to: receive a request for a test instance of an infusion device; cause the test instance to be created based on the request; cause an automatic programming command to be transmitted to the identified test instance, the automatic programming command including verification information for verifying clinical order data; based on the automatic programming command transmitted to the test instance, generate a programming response including an image of a graphical user interface or a reference to an image, the graphical user interface to be presented by the infusion device configured according to the verification information; and provide the programming response for storage in a record system. Other aspects include corresponding devices, methods, and computer program products for implementing corresponding systems and features thereof.

[0007] The subject technology also relates to a method for remotely scanning and verifying a clinical order device configuration, comprising: transmitting a request for a test instance of an infusion device to a server; receiving an identifier of the test instance from the server in response to the request; identifying clinical order data associated with a medication; causing an automatic programming command to be transmitted to the test instance based on the identifier to verify the identified clinical order data; receiving a programming response including an image of a graphical user interface or a reference to an image based on the automatic programming command transmitted to the test instance, the graphical user interface to be presented by the infusion device based on the infusion device processing the automatic programming command; identifying errors in the clinical order data based on the programming response; and providing the programming response for storage in a record system. Other aspects include corresponding systems, apparatus, and computer program products for implementing corresponding methods and features thereof.

[0008] It will be appreciated that other configurations of the subject technology will become apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are illustrated and described by way of illustration. As will be appreciated, the subject technology is capable of other and different configurations, and several of its details can be modified in various other aspects, all without departing from the scope of the subject technology. Therefore, the accompanying drawings and detailed description should be considered illustrative in nature rather than as limiting. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] For a better understanding of the various described embodiments, reference should be made to the following description of the embodiments in conjunction with the following drawings. Throughout the drawings and description, like reference numerals refer to corresponding parts.

[0010] Figure 1A An example patient care system including an infusion device is depicted.

[0011] Figure 1B Depicted Figure 1AA closer view of a portion of the patient care system shown in .

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

[0013] Figure 2 Depicted are example systems for reviewing and validating formularies in accordance with aspects of the subject technology.

[0014] Figure 3 An example system for scanning and verifying clinical order device configurations in accordance with aspects of the subject technology is depicted.

[0015] Figure 4 A first example process for establishing a virtual test instance for automatically scanning and validating clinical order device configurations in accordance with aspects of the subject technology is depicted.

[0016] Figure 5A Depicted is an example process for remotely automatically scanning and validating clinical order device configurations in accordance with aspects of the subject technology.

[0017] Figure 5B Depicted is an example process flow for remote automatic scanning and verification of clinical order device configurations in accordance with aspects of the subject technology.

[0018] Fig. 6A , Figure 6B and Figure 6C Depicted are a series of user interfaces in an example infusion programming workflow for automatically programming an infusion device in accordance with various aspects of the subject technology.

[0019] Fig.6D Depicted are example user interfaces in which automated programming requests result in errors in accordance with various aspects of the subject technology.

[0020] Figure 7 Depicted is an example process for remotely automatically scanning and validating clinical order device configurations in accordance with aspects of the subject technology.

[0021] Figure 8 is a conceptual diagram illustrating an example electronic system for automatically scanning and verifying clinical order device configurations in accordance with aspects of the subject technology. DETAILED DESCRIPTION

[0022] Reference will now be made to embodiments, examples of which are shown in the accompanying drawings. In the following description, many specific details are set forth in order to provide an understanding of the various described embodiments. However, it will be apparent to one of ordinary skill in the art that the various described embodiments may be practiced without these specific details. In other instances, well-known methods, processes, components, circuits, and networks are not described in detail in order to avoid unnecessarily obscuring aspects of the embodiments.

[0023] Figure 1A are example patient care systems in accordance with various aspects of the subject technology. Figure 1A The patient care system 1 shown in the figure includes four fluid infusion pumps 16, 18, 20, 22, each of which is operatively engaged with a corresponding fluid application device 2a-d. The fluid supplier 3a-d (which can take various forms, but is shown as a bottle in this case) is inverted and suspended above the pump. The fluid supplier can also take the form of a bag or other type of container. Both the patient care system 1 and the fluid supplier 3a-d are mounted on a roller or rod 4. Specific fluid suppliers and their orientation in the care area (e.g., installation location, installation height, installation type, etc.) can generate one or more interaction records. The interaction record for the device can be generated, for example, in part by detecting a scannable code associated with the device or detecting a physical structure on the device that encodes identification information for the device before use.

[0024] like Figure 1A As shown in the example embodiment of , each applicator 2a-d is connected between a corresponding fluid supplier 3a-d and the same patient so that the patient can receive fluid from all fluid suppliers. The applicator can be actively identified, such as by scanning by a clinician, or passively identified, such as by wireless or optical detection of the applicator.

[0025] In the depicted example, a separate infusion pump 16, 18, 20, 22 is used to infuse each fluid of the fluid supply into the patient. The infusion pump is a flow control device that will act on a corresponding tube or fluid conduit of the fluid administration device to move the fluid from the fluid supply through the conduit to the patient. Because separate 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.

[0026] Typically, medical fluid administration devices have Figure 1A There are many more parts 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 of the illustration.

[0027] Figure 1B According to various aspects of the subject technology Figure 1A A closer view of a portion of the example patient care system shown in . Figure 1B Two of the fluid infusion pumps installed on both sides of the programming module are shown, as well as the display and control keys of each fluid infusion pump, wherein the programming module is capable of programming two infusion pumps. The infusion device 12 includes a door 5a and a handle 5b, which operates to lock the door in a closed position for operation, and unlocks and opens the door to enter the internal pumping and sensing mechanism and load the application device for the pump. When the door 5a is opened, the tube can be connected to the pump 20. When the door 5a is closed, the tube is brought into operative engagement with the pumping mechanism, the upstream and downstream pressure sensors, and other devices of the pump. The display 5c (such as an LED display) is located on the door in a plan view in this embodiment and can be used to visually convey various information related to the pump 20, such as an alarm indication (e.g., an alarm message). The control keys 5e-h exist to be used for programming and control operations of the infusion pump as needed. In some embodiments, the control keys can be presented as interactive elements on the display 5c (e.g., a touch screen display). The infusion device 12 and / or the infusion pump 20 can also include an audio alarm device (not shown) in the form of a speaker.

[0028] 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 of the connected pump and alarm messages. The programming module 14 may also include a speaker to provide audible alarms. In some embodiments, the display 6a may be implemented as a touch screen display. In such an embodiment, the control key 6b may be omitted or reduced in number by providing corresponding interactive elements via a graphical user interface presented by the display 6a. The programming module 14 may include a communication system (not shown), wherein the programming module 14 may use the communication system to communicate with an external device (such as a medical facility server or other computer) and with a portable processor (such as a handheld communication device or a portable computer) or other information devices (such as pumps 20) that a clinician may have for transmitting information and for downloading a drug library to the programming module 16, 18, 20, 22. The communication module may be used to transmit access and interactive information to clinicians who encounter a programming module or a device coupled thereto (e.g., a pump 20 or a barcode scanner). The communication system may include a radio frequency (RF) system, an optical system such as infrared, a BLUETOOTH TMsystem or other wired or wireless systems. The bar code scanner and communication system can alternatively be integrated with the infusion pump 20, such as in the case where the programming module is not used, or in addition to one of the cases where the programming module 14 is used. In addition, the information input device does not need to be hardwired to the medical instrument, and the information can also be transmitted through a wireless connection. In addition, other types of modules can be connected to the pump module or the programming module, such as a syringe pump module, a patient-controlled analgesia module, an end-tidal CO2 monitoring module, an oximeter monitoring module, or the like.

[0029] In some embodiments, pressure measurements from upstream and / or downstream pressure sensors are transmitted to a server or other coordination device, and the methods disclosed herein are implemented on the server or other coordination device. For example, more complex and computationally intensive methods (such as machine learning) can be implemented on a server (or on a PCU with greater memory and / or CPU resources). In some embodiments, machine learning is used to identify an empty condition based on the pressure signal received from the pump.

[0030] Figure 1C An example of an institutional patient care system 100 for a healthcare organization in accordance with aspects of the subject technology is depicted. Figure 1C , patient care devices (or generally "medical devices") 12 are connected to the hospital network 10. The term patient care device (or "PCD") can be used interchangeably with the term patient care unit (or "PCU"), either of which can include various auxiliary medical devices, such as infusion pumps, vital signs monitors, medication dispensing equipment (e.g., cabinets, suitcases), medication preparation equipment, automatic dispensing equipment, modules coupled to one of the foregoing (e.g., a syringe pump module configured to be attached to an infusion pump), or other similar equipment. Each element 12 is connected to the internal healthcare network 10 via a transmission channel 31. The transmission channel 31 is any wired or wireless transmission channel, for example, an 802.11 wireless local area network (LAN). In some embodiments, the network 10 also includes computer systems located in various departments throughout the hospital. For example, Figure 1C The network 10 optionally includes computer systems associated with an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers, and / or a medical decision support system. As further described below, the network 10 may include separate sub-networks. In the depicted example, the network 10 includes a device network 41 through which the patient care devices 12 (and other devices) communicate in accordance with normal operation.

[0031] In addition, 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, the functionality and programming of the information system server 30 may be incorporated into another computer if this is 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 and communicating with the information system server 30. The device terminals 32 may include personal computers, personal data assistants, and mobile devices (such as laptops, tablet computers, augmented reality devices, or smartphones) configured with software for communicating with the information system server 30 via the network 10.

[0032] The patient care device 12 includes a system for providing patient care such as described in Eggers et al., which is incorporated herein by reference for this purpose. The patient care device 12 may include or contain a pump, a physiological monitor (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter and other patient monitors), a therapeutic device, and other drug delivery devices that can be used according to the teachings set forth herein. In the depicted example, the patient care device 12 includes a control module 14 connected to one or more functional modules 116, 118, 120, 122, also referred to as an interface unit 14. The interface unit 14 includes a central processing unit (CPU) 50 connected to a memory (e.g., a random access memory (RAM) 58), and one or more interface devices, such as a user interface device 54, a coded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with an additional module or device. The interface unit 14 also (although not necessarily) includes a main non-volatile storage unit 56 (such as a hard disk drive or non-volatile flash memory) for storing software and data, and one or more internal buses 64 for interconnecting the aforementioned elements.

[0033] In various embodiments, the user interface device 54 is a touch screen for displaying information to a user and allowing the user to input information by touching a defined area of ​​the screen. Additionally or in the alternative, the user interface device 54 may include any device 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 bar code reader capable of scanning and interpreting data printed in a bar code format. Additionally or in the alternative, the data input device 60 may be any device for inputting encoded data into a computer, such as a device for reading a magnetic strip, 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, a radio frequency card, a memory stick, a CD, a DVD, or any other analog or digital storage medium. Other examples of the data input device 60 include a voice activation or recognition device or a portable personal data assistant (PDA). 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 14, but it is recognized that the data input device 60 can be integrally located within the pharmacy system 34, or located externally and communicate with the pharmacy system 34 via an RS-232 serial interface or any other suitable communication means. The auxiliary interface 62 can 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) can be used without departing from the subject technology. In addition, the data input device 60 can be a separate functional module, such as modules 16, 18, 20 and 22, and is configured to communicate with the controller 14, or any other system on the network, using appropriate programming and communication protocols.

[0034] The network connection 52 may be a wired or wireless connection, such as via Ethernet, WiFi, BLUETOOTH, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem, or a cable modem. Any direct or indirect network connection may be used, including but not limited to a telephone modem, a MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link, or a WLANS connection or other wireless connection.

[0035] Functional modules 16, 18, 20, 22 are any devices used to provide care to a patient or to monitor the patient's condition. Figure 1CAs shown, at least one of the functional modules 16, 18, 20, 22 can be an infusion pump module, such as an intravenous infusion pump, for delivering drugs or other fluids to a patient. For the purpose of this discussion, the functional module 116 is an infusion pump module. Each of the functional modules 16, 18, 20, 22 can be any patient treatment or monitoring device, including but not limited to an infusion pump, a syringe pump, a PCA pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, an intracranial pressure monitor, etc. The functional modules 18, 20 and / or 22 can be a printer, a scanner, a barcode reader, a near field communication reader, an RFID reader, or any other peripheral input, output, or input / output device.

[0036] Each functional module 16, 18, 20 and / or 22 communicates directly or indirectly with the interface unit 14, which provides overall monitoring and control of the device 12. Figure 1C As shown, or as detailed by Eggers et al., the functional modules 16, 18, 20 and / or 22 can be physically and electronically connected to one or both ends of the interface unit 14 in a serial manner. However, it is recognized that there are other means for connecting the functional modules to the interface unit, which can be used without departing from the subject technology. It will also be appreciated that a device (such as a pump or patient monitoring device) that provides sufficient programmability and connectivity may be able to operate as a stand-alone device and communicate directly with the network without being connected through a separate interface unit or control unit 14. As described above, additional medical devices or peripheral devices can be connected to the patient care device 12 via one or more auxiliary interfaces 62.

[0037] Each functional module 16, 18, 20, 22 may include a module-specific component 76, a microprocessor 70, a volatile memory 72, and a non-volatile memory 74 for storing information. Figure 1C Four functional modules are shown in FIG. 1 , but any number of devices may 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 technology. The module-specific components 76 include any components necessary to operate a particular module, such as a pumping mechanism for an infusion pump module 116.

[0038] Although each functional module may be capable of at least some degree of independent operation, interface unit 14 monitors and controls the overall operation of device 12. For example, as will be described in more detail below, interface unit 14 provides programming instructions to functional modules 16, 18, 20, 22 and monitors the status of each module.

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

[0040] Through existing technology, data traveling to and from various data sources can be converted into network-compatible data, and information movement between medical devices and networks can be achieved in various ways. For example, patient care devices 12 and network 10 can communicate through automatic interaction, manual interaction, or a combination of automatic interaction and manual interaction. Automatic interaction can be continuous or intermittent, and can be achieved through direct network connection 54 (such as Figure 1C ), or by RS232 link, MIB system, RF link (e.g., Bluetooth), IR link, WLANS, digital cable system, telephone modem or other wired or wireless communication means. Manual interaction between the patient care device 12 and the network 10 involves the intermittent or periodic physical transfer of data between systems using, for example, a user interface device 54, a coded data input device 60, a bar code, a computer disk, a portable data assistant, a memory card, or any other medium for storing data. The communication means in various aspects are bidirectional in accessing data from as many points as possible of distributed data sources. Decisions can be made in various places within the network 10. For example, and not by way of limitation, decisions can be made in a HIS server 30, a decision support 48, a remote data server 49, a hospital department or unit station 46, or within the patient care device 12 itself.

[0041] All direct communications with medical devices operating on the network according to the subject technology can be performed through the information system server 30, referred to as the remote data server (RDS). According to aspects of the subject technology, the network interface module incorporated into a medical device (such as, for example, an infusion pump or a vital sign measurement device) ignores all network traffic that does not originate from an authenticated RDS. The primary responsibility of the RDS of the subject technology is to track the location and status of all networked medical devices with a NIM and maintain open communications.

[0042] According to various embodiments, the server 30 includes a prescription set and / or a pharmacy information system. The pharmacy information system can implement a secure doctor's medication order process. A pharmacy website (e.g., provided by the server) can provide the doctor with a list of available drugs from which the doctor can choose. The pharmacy website can include a drug library with a list of available drugs, but can also include and present to the doctor the drug name associated with the recommended dose and dose limit that has been established or adopted by the medical and health facility. In such cases where the doctor only needs to select an item from a computer screen without having to manually type in the drug name and drug administration numbers (such as infusion rate, time, etc.) associated with the administration of the drug, this should produce a more accurate medication process.

[0043] If the clinical order is for the administration of a specific drug regimen, the order will be transmitted to the pharmacy information system 30 of the facility. The pharmacy reviews the order, and once the order is ready, the order can be transmitted to the nurse station for matching with the appropriate patient. A prescription set is a list of approved drugs used in a medical facility (e.g., available for patient ordering). In the prescription set, there may be instructions for use information and / or concentrations and drug ranges approved for the facility. As will be further described, a prescription set may be used to define one or more medical device drug libraries, which may then be provided to infusion pumps within a hospital network. In the library, there is drug information, such as drug name, concentration, diluent volume, strength, minimum or maximum infusion parameters of the drug, and other parameters. The prescription set establishes these parameters via the system 30 together with the parameters for the order outside the prescription set to maintain consistency throughout the healthcare environment and to ensure that the order is understandable and is useful for execution according to expectations of other devices (e.g., infusion pumps) within the system 30.

[0044] Further references Figure 1C , the patient care device 12 is capable of operating in several different modes or personalities, each of which is defined by a configuration database. The configuration database can be a database 56 inside the patient care device, or an external database 37. A particular 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, physiological characteristics, or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., doctor identity) or the location of the patient care device 12 in a hospital or hospital computer network. Patient care information can be input through interface devices 52, 54, 60, or 62, and can originate from anywhere in the network 10, such as, for example, from a pharmacy server, an admission server, a laboratory server, etc.

[0045] The memory 56, 58 of the 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, profiles to be used in a specific practice area such as an ICU, PED, etc. The memory may be an electronically loadable memory such as a non-volatile memory (e.g., an EEPROM). The drug library stored on the pump, which illustratively contains information such as drug names, ranges of delivery parameter values ​​(such as appropriate concentrations, dosage units, and dosage limits), may be used to perform drug calculation-based infusions in a clinical setting.

[0046] The drug library stored in the memory of the pump may include clinical order settings, such as limits set by clinical institutions for each drug in the library (also referred to herein as "guardrails"). Such limits may take the form of maximum and minimum doses for each drug, which may depend on patient factors or other factors associated with the delivery of the drug. For example, the dose limit may vary, depending on the patient's weight or body surface area ("BSA"), depending on the unit or ward (e.g., neonatal care unit (NCU), intensive care unit (ICU), etc.) of the medical institution where the drug is being used, and depending on other factors. If the nurse sets the pump to operate outside the range between the limits of a particular drug, an alarm may be provided. In some cases, the alarm may be overruled, while in other cases it may not be. A medical facility may establish a "soft" limit for each drug, which may be overruled by the nurse, and a "hard" limit, which may not be overruled. In either case of exceeding the limit, a pump data log or other processor communicating with the infusion pump may record each such limit event for subsequent analysis when the attempted setting is higher than the maximum dose or lower than the minimum dose.

[0047] The pump also includes a display for displaying a user interface, including a control panel through which a user can program the programmable controller, and a display screen for displaying drug entries from a drug library. Each of the associated drug delivery parameter sets includes information selected from a group 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 that specify units that can be used to express drug delivery information, and the drug infusion pump provides the available mode option list 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 syringe manufacturers' names that identify syringes that can be used in the drug infusion pump, and the drug infusion pump provides the list of syringe manufacturers' names 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 that identify syringes that can be used in the drug infusion pump, and the drug infusion pump provides the 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 switched on or switched off, and the pump provides the user with only features from the set of features that are switched on when the electronically loaded drug library is in the pump.

[0048] Figure 2 An example system 200 for reviewing and validating a prescription set according to aspects of the subject technology is depicted. Interoperability between a hospital's electronic medical record (EMR) 202 and a medical device, such as an infusion device 12, enables pre-population of infusion parameters. Pre-population of infusion parameters can reduce the number of programming screens and keystrokes required for manual programming of a pump. Implementation of interoperability does not preclude a clinician from manually programming an infusion device. Manual programming may be required in the event of a failure of any component of the interface system.

[0049] The formulary 204 determines which medications can be dispensed within the hospital network. A hospital committee may be formed to determine how the medications within the formulary will be applied to the patient care devices 12. Configuration definitions are agreed upon (e.g., by hospital department such as ICU, NICU, pediatrics, oncology, surgery, etc.), and medications and typical infusion protocols are established in a medical device drug library ("drug library"). In addition, all external restrictions, or guardrail conditions, are defined in the drug library. When all definitions are complete, the configuration including the drug library may be released (2.1). The pumps at the facility are then updated by passing the configuration database to some or all of its pumps.

[0050] In the clinical field, clinicians can use a scanner associated with a medical device (such as an infusion device 12) to scan medical items, such as infusion packaging. For example, a barcode reader (or other data input device) is used to scan coded drug labels, patient coded ID bands and caregiver ID badges, as well as optionally supplemental prescription information or medical device configuration instructions (including configuration database ID) printed on the label or accompanying order. The reader / scanner does not need to be integrated with the medical device. The scanner can be part of a separate device connected to the same network 40 as the infusion device 12 and configured with software to play a role in the overall workflow involving the infusion device 12, such as a medical record terminal 206 (e.g., part of one or more computing devices). The scan initiates a process by which information related to the item (e.g., scanned from a code attached to or transmitted by the item) is automatically sent (2.2) to the hospital's EMR 202 (e.g., at a centralized server 30) via the network 40. The EMR 202 performs certain actions related to the item and generates (2.3) an automatic programming request (APR) and sends it to the medical device 12 to load parameters related to the item. The parameters may be stored in the medical device 12, but are loaded in response to the identifier received from the server. Although the examples herein relate to infusion devices, any medical device may be configured in the same or similar manner and employ the automatic programming error mitigation described herein.

[0051] In the depicted embodiment, the coordination engine 208 coordinates messages sent from the EMR 202 to the infusion device 12. In the depicted embodiment, the EMR 202 transmits an APR with a device identifier (ID) of the infusion device for receiving the APR to the pump coordination engine 206 (2.4). The coordination engine then determines whether the infusion device 12 identified by the EMR is available and, if available, forwards the APR to the device 12 (2.5). When the infusion device 12 receives the APR, the infusion device 12 determines whether the APR and the contents are compliant. The compliance determination can be based on whether the data fields included in the APR are consistent with the drug library loaded in the infusion device. For example, the APR can include or omit fields that can prevent the device 12 from parsing or automatically programming itself using the information included in the APR alone. In addition, or in an alternative, the compliance determination can be based on the value included in the data field of the APR. For example, if the specified value for the parameter is outside the configuration range of the infusion device, the value can be determined to be non-compliant. If the APR is determined to be out of compliance, the request may be denied and / or an error may be caused at the device 12. Such an error is indicated or referred to as a misalignment error.

[0052] The foregoing process can be used outside of a clinical setting to verify whether a drug or its parameters stored in a pharmacy information system (e.g., in an EMR 202 and / or a prescription set 204) is not aligned with a drug library deployed on site. However, verification using this process requires a physical infusion device and is typically performed on site. Moreover, if a site or care area has multiple pump configurations (e.g., multiple drug library configurations), the verification test may also require the use of a different physical infusion device in each configuration, with the results manually verified at each device. However, a prescription set may include thousands of drug entries, and incomplete verification of the entries may leave critical but infrequently used drugs or device configurations untested. In addition, automation of the verification process may only be able to determine whether a test APR message is accepted by the device, not how the device actually behaves and / or responds to the message.

[0053] Figure 3 An example system 300 for scanning and verifying a clinical order device configuration according to aspects of the subject technology is depicted. In the depicted example, the device configuration, including the drug library, can be scanned and verified by an automated process controlled at the EMR system 202 or via the coordination engine 208. In this regard, the number of test instances, including medical devices, device types, care areas, modules, and drug types for each test instance can all be determined by an automated script. The process can be controlled by or at the EMR system or formulary (e.g., at the server 30) or by a terminal 32 associated with the system.

[0054] In the depicted system, a message requesting a test instance of an infusion device may first be transmitted to the coordination server 208 (3.1). As described herein, a test instance includes a physical or virtual (described below) medical device, such as an infusion device 12. In the depicted example, the coordination server 208 creates a test instance by locating and / or identifying an existing test instance or activating or virtually creating a test instance (3.2). The coordination server then responds to the message request with the test instance. Next, a clinical order setting is determined for each test. The clinical order setting may include runtime parameters, including one or more of the following: for example, a pump model (e.g., an identifier of a module of the pump to be tested), a pump type (e.g., a peristaltic pump or a syringe pump), a number of modules, a firmware version, a drug library, a care area, a language, whether encryption should be used, and a storage location (e.g., ftp or IP address, email, etc.). The clinical order setting may further include runtime parameters specific to the drug library on the test instance, including a drug library version, a care area, a module configuration (e.g., which channel to use on the pump, which may further specify the type of pump to be used based on the channel), etc. These parameters may be entered by the user at test time, or may be provided in a script that is executed for a particular execution cycle.Once a test instance is identified and prepared, and a clinical order setup is determined, the EMR system 202 may transmit an APR to the test instance for each of one or more test configurations.

[0055] In some implementations, the coordination server 208 can determine a test instance for the EMR 202. For example, the coordination server 208 can receive a request to create a test instance from the EMR, and then identify the test instance based on being included in the request (e.g., from a pool of test instances). In some implementations, the coordination server can query a queue data store for idle infusion devices corresponding to the identified infusion device type, and the identified idle infusion devices are returned as test instances. Once identified, the coordination engine 208 can transmit a response identifying the test instance to the EMR.

[0056] The function of the APR process can be similar to that of Figure 2 As described above, but in an automated manner. For example, a patient order may be automatically generated (e.g., by a script) including a patient identifier, a drug identifier, and other information related to the clinical order (3.3). EMR system 202 may further generate a simulated scan event (3.4), such as scanning a drug barcode or QR code at medical record terminal 206 (see Figure 2). The simulated scan event also provides a patient identifier, a drug identifier, and order information. According to various embodiments, the main script can generate a scan event, which is then used to query an order database for patient orders. Patient orders can be predetermined or based on actual data.

[0057] The EMR system 202 then generates an APR based on each scan event and the corresponding order (3.5). The APR may include, for example, a drug identifier and a request to load parameters for a drug corresponding to the drug identifier. In this regard, the APR may instruct the infusion device to load parameters from a library of available drugs stored on the infusion device. According to various embodiments, the APR may include a concentration for the drug.

[0058] The EMR system 202 transmits the APR to the infusion device test instance (3.6). In some embodiments, such as Figure 3 As depicted in , the APR is proxied by the coordination server 204, which receives the APR along with a device identifier for the test instance and then transmits the APR with an identifier representing the ERM system 202 to the test instance (3.7).

[0059] The test instance (e.g., infusion device 12) receives and processes the APR. The infusion device 12 (and / or processor or system) determines whether the information in the request matches known parameters for a corresponding match in a drug library, and / or whether the APR includes any deviations from information stored on the device (e.g., in a drug library). For example, if the APR includes a certain drug concentration, the infusion device can check the drug library to determine whether the received drug concentration is within the allowed range for the drug identified by the APR. In some embodiments, if the drug is not found in the current drug library, the pump is configured to search other drug libraries stored in the pump's memory for the drug. The pump can search based on the name of the drug or based on certain parameters provided in the APR.

[0060] When the APR is processed by the infusion device, the infusion device generates a behavioral response (3.8), which may include identifying any deviations between the information provided by the APR and the information stored in the device. In some embodiments, the test instance identifies a deviation of the received automatic programming data relative to the stored programming data. The deviation may arise from a drug identified in the APR not being identified in the currently active first drug library stored in the memory of the test instance. In some embodiments, the deviation may include a concentration of the received drug being outside of an allowed concentration range stored in the drug library for the drug.

[0061] In some embodiments, the deviation may arise based on a test instance determining that parameters for a drug to be loaded are stored in a deactivated second drug library that is stored in a memory of the infusion pump. In some embodiments, the system may determine that the second drug library is for a different care area than the care area currently activated for the infusion device. In some embodiments, the deviation may include receiving an APR for changing an infusion parameter of a drug while an infusion is being administered to a patient but determining that the infusion is not being administered to a patient when receiving the automatic programming data.

[0062] In some embodiments, the test instance includes a first pump channel and a second pump channel (e.g., corresponding to a plurality of infusion modules 18, 20). The system can identify the first pump channel for receiving the automatic programming data and determine that the parameters to be loaded are more aligned with the second pump channel than with the first pump channel. In some embodiments, the deviation can include that the automatic programming data is for a drug to be administered after a first drug is administered to a patient, but the first drug is not currently being administered.

[0063] If no misalignment error is generated (e.g., the parameters are accepted and consistent with the drug library on the device), the infusion device can send (e.g., via the coordination engine) a confirmation that the APR message was accepted and processed (e.g., understood) to the EMR system 202. If a parameter (such as concentration or other parameter) is outside an allowed range (e.g., a clinically defined dosage error reduction range), the system can return a misalignment error.

[0064] According to various embodiments, the response (3.8) from the test instance to the APR may include, in addition to the confirmation information, information related to the results of the internal processing of the APR by the test instance. The response may be in the form of one or more messages, including a transaction identifier (corresponding to the identifier received by the test instance), a message type (e.g., a confirmation message or an error message), a device identifier for the test instance, a timestamp associated with the receipt and processing of the APR, and a message payload. In some embodiments, the APR response may include a test response flag (e.g., a field identifying that the response is a test rather than a real patient order; a field identifying that the EMR does not take formal action on the response). Optionally, the echo test data submitted when the test instance was created may be included. Such data allows the test system to include its own metadata to facilitate automatic review of the response. The echo test data may be returned as specified. In some embodiments, the echo test data may include some replacement fields (e.g., device ID, timestamp, etc.) to allow custom field formatting of the echo response.

[0065] In some embodiments, the test instance may include screen capture data, e.g., in the form of images indicating each step associated with programming the test instance based on the received APR. In an infusion device that is not configured to be fully automatic, such screen captures may be obtained as the clinician steps through the steps of the manual programming process, e.g., by clicking on the next step on each screen. Some infusion devices may operate in a fully automatic test mode, wherein the test instance will simulate clicking "next" until the "start" option is provided, and each screen is captured and encoded (e.g., as a binary image) and attached to the APR message response sent to the EMR system 202. In some embodiments, the APR response may include a user interface step-through, which may be stored by the EMR system 202 (e.g., in the database 37) and recalled for review when diagnosing the cause of the misalignment error. As will be further described, the test instance may (in addition or in the alternative) be run in a "virtual mode" by which all processing is performed by software in a simulated environment.

[0066] The programmed responses received from the infusion device are stored in a database associated with the recording system 37. In this regard, the recording system (or a user having access to the recording system) can access the data as needed to verify pump behavior (3.9).

[0067] Figure 4 A first example process 400 for establishing a virtual test instance for automatically scanning and verifying a clinical order device configuration is depicted in accordance with aspects of the subject technology. Figure 1A , Figure 1B , Figure 1C and Figure 2 As well as the associated components and / or processes described herein describe the various blocks of the example process 400. One or more of the blocks of the process 400 may be implemented, for example, by one or more computing devices, including, for example, a server 30 and / or a medical device 12. In some embodiments, one or more of the blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more of the blocks may be separated from other blocks and implemented by one or more different processors or devices. In addition, for the purpose of explanation, to the extent that the blocks of the example process 400 are described as occurring serially or linearly, in some embodiments, multiple blocks of the example process 400 may occur in parallel. In addition, the blocks of the example process 400 do not need to be executed in the order shown and / or one or more of the blocks of the example process 400 do not need to be executed.

[0068] In the depicted example, a request for a test pump instance is received by a server (402). In some embodiments, the server may include one or more components of a pharmacy information system, including an EMR system 202 and / or a prescription set 204. In some embodiments, the server includes a coordination engine 208. In the depicted example, a server (e.g., a coordination engine 208) receives the request and first determines whether a physical infusion device 12 is available (404). For example, the server may maintain or access a queue data store for infusion devices within a hospital network. The data store may be continuously updated to identify which of the infusion devices is currently active (e.g., registered on the network and able to receive communications). In this regard, the server 208 may query a queue data store for idle infusion devices corresponding to the infusion device identified in the request (e.g., including a pump model, module, firmware version, drug library, care area, etc.).

[0069] When an idle pump is available (e.g., not in use with a patient), the server can determine whether the pump includes a configuration that matches the requested data (406). If the pump is available and configured according to the requested infusion device, then the pump is reserved for the immediate scanning and verification procedure. In this regard, the server can lock the pump for use by the server, preventing it from being used with a patient in a clinical setting until the scanning and verification process is complete. The server can then transmit a response identifying the physical pump to the requester (e.g., the requesting server) (408).

[0070] If no physical pump is found to be idle or otherwise available, or if no available pump is found to be compatible with the identified data, then the coordination server 208 may create a virtual instance of the pump (410). In this regard, the coordination engine 208 may include a software development sandbox in which virtual instances of infusion devices may be modeled and interacted with as if they were real physical devices. The virtual instances may be able to execute the same or similar software utilized by the corresponding physical device (e.g., in the contained virtual environment) and generate a graphical image of its physical user interface as if the user were viewing the physical device, including programming readouts and operating parameter values. For the software utilized by the infusion device to provide a graphical display of their entire user interface, each display may be captured and returned to the call server as part of the response.

[0071] The virtual instance can extend (e.g., via a sandbox) a virtual communication interface for communicating with a remote system using a message protocol similar to or the same as the physical infusion device it models. In this way, the virtual instance is able to receive and process the APR and receive and process automatic programming commands from the server in the same manner as the physical infusion device. The APR can be sent by the EMR system 202 to the virtual instance (e.g., via the coordination server 208) and instruct the virtual instance on the infusion of the drug.

[0072] Regarding the identification of the virtual instance, the server (e.g., the coordination engine 208) transmits a response identifying the test virtual instance to the pharmacy information system (e.g., the EMR system 202) (412). The server (e.g., the coordination engine 208) can create multiple instances, each with different clinical data settings and configurations. For example, the script can identify multiple infusion devices, which can then be identified in the physical environment or created virtually, as previously described.

[0073] Figure 5A A first example process 500 for remotely automatically scanning and verifying a clinical order device configuration in accordance with aspects of the subject technology is depicted. Figure 1A , Figure 1B , Figure 1C , Figure 2 , Figure 3 and Figure 4 As well as the associated components and / or processes described herein to describe the various blocks of the example process 500. One or more of the blocks of the process 500 may be implemented, for example, by one or more computing devices, including, for example, a server 30 and / or a medical device 12. In some embodiments, one or more of the blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more of the blocks may be separated from other blocks and implemented by one or more different processors or devices. Further for the purpose of explanation, to the extent that the blocks of the example process 500 are described as occurring serially or linearly, in some embodiments, multiple blocks of the example process 500 may occur in parallel. In addition, the blocks of the example process 500 do not need to be executed in the order shown, and / or one or more of the blocks in the example process 500 do not need to be executed.

[0074] As previously described, a request for a test instance of an infusion device is received, and the test instance is created and identified based on the request. The server then sends or causes an automatic programming request (APR) to be transmitted to the identified test instance, including verification information for verifying the clinical order data. The depicted example describes how the test instance processes the request.

[0075] In the depicted example, the APR is received at the test instance (502). Where a physical test instance (e.g., an idle infusion device) is connected to the hospital network 10, the APR is received over the network using the network communication interface 52 of the device. Where the test instance is a virtual instance, the virtual instance extends the virtual communication interface for communicating with the server using the same message protocol as the physical infusion device. In this regard, automatic programming commands are received and processed in a normal manner to instruct the test instance.

[0076] The test instance receives and begins processing the APR. In this regard, the test instance (and / or processor or system) determines whether the APR and its contents are compliant (504). The compliance determination can be based on data fields included in the APR (e.g., in the verification information). For example, the test instance determines whether the information in the APR corresponds to a drug library loaded into the memory of the test instance, and / or whether the information is consistent with the information in the drug library or whether an acceptable match is found, or whether there is any deviation between the information stored on the device (e.g., in the drug library) and the information provided in the APR. For example, the APR can include or omit fields that can prevent the pump from parsing or automatically programming the pump using an order alone. If the expected field is omitted, the APR may be determined to be non-compliant. Compliance determination can be based on values ​​included in the data fields of the APR. For example, if the specified value for a parameter is outside the configuration range of the infusion pump, the value can be determined to be non-compliant. If the APR includes a certain drug concentration, the infusion device can check the drug library to determine whether the received drug concentration is within the allowed range of the drug identified by the APR. In some embodiments, if the drug is not found in the current drug library, the pump is configured to search other drug libraries stored in the pump's memory for the drug. The pump may search based on the name of the drug or based on certain parameters provided in the APR. Determining whether the request is compliant may also include determining whether it complies with a protocol understandable by the test instance.

[0077] If the information of the APR (such as, for example, drug concentration or other parameters) is outside the allowed range (e.g., clinically defined limits / reference values), or the APR itself is defective (e.g., missing fields), or the requested drug library is not available, or the APR is otherwise non-compliant, the system can generate an error message (506) indicating a misalignment between the APR and the information stored in the test instance (e.g., within the drug library). A misalignment error may also be returned if a parameter (such as concentration or other parameter) is outside the allowed range (e.g., clinically defined dose error reduction range). The error message can then be transmitted to the server 30 (508) or can be queued for transmission with other messages.

[0078] If the APR is (at least initially) understood, the test instance may (optionally) send a confirmation back to the server (510) indicating that the APR is compliant and that the APR will be processed by the test instance. In response to or after determining that the APR is compliant, the test instance may then continue to configure itself based on the information received in the APR (512). In this regard, the APR may identify the drug, and the test instance may determine that the drug library loaded into the test instance includes the drug. The test instance may then set operating parameters of the test instance based on the parameters in the drug library corresponding to the drug. In this regard, the test instance (whether physical or virtual) configures itself to deliver the drug to the patient using parameters associated with (or indexed by) the information identified in the APR.

[0079] If no errors were generated (e.g., the parameters were accepted and consistent with the drug library on the device), the test instance generates a response for transmission to the originating request service (e.g., the EMR system 202 or the formulary 204). As part of the response, the test instance can generate one or more images (e.g., screenshots) of a graphical user interface that will be presented by the infusion device configured according to the automatic programming command (514). As previously described, the APR response can include a user interface step-through, represented by a series of images illustrating what the user interface of the physical infusion device will display during the acceptance and configuration of the parameters loaded in response to the APR. In this regard, any errors that are apparent through the user interface can be captured and transmitted in the response for subsequent evaluation of any misalignment errors.

[0080] The test instance, the server hosting the test instance, or the server responsible for communicating with the test instance (e.g., the coordination engine 208) generates a response message (516) including one or more images. In addition to any images, as previously described, the response to the APR from the test instance may also include information related to the results of the internal processing of the APR by the test instance in addition to the confirmation information. The response can be in the form of one or more messages, including a transaction identifier (corresponding to an identifier received by the test instance), a message type (e.g., a confirmation message or an error message), a device identifier for the test instance, a timestamp associated with the receipt and processing of the APR, and a message payload (which may include an image in binary form). Once the response is generated, the response can be transmitted back to the requestor (508).

[0081] After the response to the APR is generated and transmitted, the test instance, or the server responsible for its creation or identification (e.g., an EMR server or a coordination engine server), determines whether the test instance should be deactivated; for example, decomposed, deleted, terminated, discarded, and / or removed from memory (518). In some embodiments, the test instance or the server responsible for causing the creation of the test instance waits until it specifically receives an instruction to deactivate the test instance. In some embodiments, multiple APRs are intended for a single test instance, and the test instance or server may wait until all APRs are received and processed before deactivating the test instance. In some embodiments, the server responsible for causing the creation or initiation of the test instance may provide an indication to the test instance indicating how many APRs to send, or that there will be multiple APRs (or a single APR) before the test instance should be deactivated. In addition, or in an alternative, each APR may indicate its sequence number relative to other APRs specified for the test instance. When the last sequence number is reached, the test instance may be deactivated (520). If the APR (or the first instruction) indicates that more APRs are expected, then the test instance may wait to receive the next APR (502).

[0082] Figure 5B An example process flow 501 for remote automatic scanning and verification of clinical order device configurations according to aspects of the subject technology is depicted. For purposes of explanation, reference is made herein to Figure 5A And further reference Figure 1A , Figure 1B , Figure 1C , Figure 2 , Figure 3 and Figure 4 The various blocks of the example process flow 501 are described with reference to the associated components and / or processes described herein.

[0083] As previously described, a request for a test instance of an infusion device is received, and a test instance is created and identified based on the request. The server then sends an automatic programming request (APR) to be transmitted to the identified test instance or causes the automatic programming request (APR) to be sent. According to various embodiments, the APR may include information for programming the infusion device according to a patient order. In this regard, the order may include or be associated with an identifier and / or name for the drug, the volume to be infused, the amount or concentration of the drug, the dosage unit, the diluent volume, and other parameters. According to various embodiments, some or all of this information is provided as verification information for verifying clinical order data.

[0084] As previously described, the APR is received at the test instance and preliminary processing (504) is performed by the test instance to determine whether the APR and the contents of the APR are compliant. Compliance determination can be based on the format of the APR, the data fields included in the APR, and / or the parameters provided within the (one or more) APR message. For example, the APR may not be compliant because it contains or omits a field that may prevent the test instance from parsing or automatically programming the test instance using the APR or the order identified by the APR. In another example, if the specified value for the parameter is outside the configuration range of the (simulated) infusion pump, the value can be determined to be non-compliant. If it is not compliant with the protocol, then the request may be rejected, in part because the test instance cannot process the request. If the APR is compliant with an understandable protocol, then the APR can then be accepted, and a confirmation (510) can be sent from the test instance to the EMR system 202 (e.g., via the coordination server 208) indicating that the APR is being processed.

[0085] If the APR is (at least initially) understood, the test instance may (optionally) send a confirmation back to the server (510) indicating that the APR is compliant and that the APR will be processed by the test instance. The confirmation message may indicate whether the message is well formatted (e.g., all fields are present, valid, etc.), and / or whether the request parameters and / or restrictions are accepted. The confirmation message may include information within a drug library corresponding to the APR or a (simulated) pump provided with information of the APR. For example, the confirmation may provide an alias for a drug identified in the APR or an order identified by the APR. Some example message fields and values ​​that may be included in the confirmation are further described in Table 1.

[0086]

[0087] Table 1

[0088] Upon receiving the confirmation message(s), the EMR system may then store (511) the data in the database 37. In this manner, all data used for the test may be collected by the database for later retrieval and analysis to determine the degree of misalignment between the EMR and / or formulary system and the drug library deployed in the hospital organization (e.g., as simulated by the test instance). In some embodiments, the confirmation message(s) may not include data that may be stored, or the message(s) may not be sent or stored at all. In such embodiments, the test instance may begin the main process (512, 514), such as with respect to Figure 5A As described above, this information may be returned using data returned in an APR response message (516a), such as regarding Figure 5AThe returned data may include, for example, user interface screenshots and workflow fields and values ​​that will be presented by the actual infusion device during automatic programming based on the received APR. The data returned in the APR response message and the captured screenshots may then be stored (517a) in the database 37 for further analysis. Some example message fields and values ​​that may be included in the APR response message 516 are further described in Table 2.

[0089] Infusion Device(s) Workflow Message a. Infusion appears as expected b. APR error message c. Pump status d. Restriction of illegal behavior i.Disposable products 1. The volume to be infused (VTBI) exceeds the available volume 2. Rate exceeds disposable type ii.Guardrail 1. Soft 2. Hard e.Clinical consultation f. Drug contraindications i. Based on laboratory values ii. Allergy test iii. Drug-drug interactions g. Treatment options h. Other notifications i. Program rate change i. Page-to-page conversion workflow i. Loading / unloading containers j. Any additional fields that need to be filled in

[0090] Table 2

[0091] The data fields and values ​​returned using the APR response can be based on calculations performed by the simulated infusion device (e.g., by the test instance). Such calculations can be performed without human involvement. Certain values ​​can be calculated based on the values ​​sent in the APR. For example, BSA (body surface area) can be calculated based on the weight provided in the APR, or BSA can be calculated based on the weight of the patient found based on the patient identifier included in the APR. The test instance simulation can automatically accept all available user acceptance options, as if the user reviewed the data provided by the APR and / or the calculation based on the APR at the device, and accepted the programming (e.g., no changes). In some embodiments, the calculations performed by the test instance may result in the termination of the programming, and the test instance will report the cause of the failure and include a copy of all information that caused the failure in the APR response message (516). For example, VTBI can be calculated based on the provided concentration and the patient's weight, and VTBI can exceed the available volume. Therefore, the test instance can terminate the infusion and report errors and calculated parameters, as previously and further described below. The APR response message (516) can also indicate precision misalignment. For example, the message may indicate that the analog infusion device accepts one decimal point precision when four decimal points are provided (or vice versa), or accepts a subset of the string (e.g., 16 of the 18 characters of the patient identifier). It is noted that some or all of these calculations may be performed during preliminary processing (504) and the misalignment reported in the confirmation message (510) (including, for example, a captured screenshot corresponding to the calculated data).

[0092] After the APR has been accepted and processed by the infusion device without error (512, 514), the infusion device will start and begin infusing the medication according to the programming provided by the APR. After the infusion has begun, the infusion device will send one or more status messages to the EMR system 202. The status message informs the EMR system what has been initiated and includes certain values ​​that the infusion device is reporting. This information may reflect the APR data and / or may include changes made at the device. The EMR system may wait for the status message and close the workflow associated with the APR upon receipt of the message.

[0093] According to various aspects of the subject technology, as the test instance simulates a real-time infusion device, the test instance will simulate the start of an infusion (512) and then provide one or more status messages back to the EMR system 202 (516b). When the simulation begins, the test instance will perform further calculations based on data that has been provided by the APR or information obtained by the test instance based on the APR (e.g., based on patient or order information, or information from a drug library). The EMR system can monitor the test instance to close the APR simulation test.

[0094] Upon receiving the status message(s), the EMR system may store (517b) the data therein along with previously received data in the database 37 for further analysis. Some example message fields and values ​​that may be included in one or more status messages provided by a test instance are further described in Table 3.

[0095] Infusion status message(s) a. Value alignment i. Flow rate ii. Volume to be infused iii. Dosage iv. Volume accumulation over time b. Value check i. Order ID ii. Patient Information 1. ID or Identifier 2.Weight 3.BSA iii. Clinician ID iv. Infusion information 1. Alias ​​or drug identifier 2. Drug quantity 3. Diluent volume 4. Dosage Unit c. Expected start and finish events relative to time d. Cancel programming

[0096] Table 3

[0097] Each message received from (or sent to) the test instance may include a unique identifier, such as provided by the original APR. In this regard, all stored data along with the APR may be stored in a database for collective retrieval. After storing the status message data, the EMR may close the current APR test. If there are more data groups identified for testing (and / or APRs), the EMR system may repeat (525) for each data group to be tested. Figure 5B In this regard, multiple APRs may be initiated by a script to test a drug library in a formulary against a drug library deployed in the field, or to test whether a drug library is suitable for being deployed in the field so that its data fields conform to expected data fields based on known formulary information.

[0098] The administrator can then query (524) the test data (e.g., from the terminal 32) to obtain the test results. The EMR system 202 maintains a log file for each test in the database 37, indexed by the unique identifier previously described. When a query is received, all data for the identifier can be accumulated (526) and processed to determine the misalignment for the particular test, and it is returned (528) to the user. In some cases, the misalignment may have been identified by the test instance and included in the data returned to the EMR system. In some cases, the misalignment is identified by comparing the data returned from the test instance (e.g., from a confirmation, APR response message, and / or status message) with the data or formula information in the EMR system. As previously described, a screenshot (e.g., an image) of the (simulated) physical infusion device interface is captured and stored with the data and provided to the user to accurately depict how the infusion device reacts to the misalignment.

[0099] Fig. 6A , Figure 6B and Figure 6C Depicted are a series of user interfaces 602, 604, 606 in an example infusion programming workflow for automatically programming an infusion device in accordance with various aspects of the subject technology. The depicted screens 600 may be displayed on a display 6a of a control unit 14. The depicted example screens are displayed to facilitate selection of parameters that are automatically populated in response to an automatic programming request (APR).

[0100] When an APR is received that is processed by the infusion device, and no misalignment errors are received, the infusion device will display (e.g., on display 6a) a series of programming confirmation displays in a predetermined workflow. In this way, the clinician can simply review the parameters filled into the specified fields by way of the APR, rather than having to manually enter the parameters. For example, the APR can cause the drug library on the device to load the drug amount, diluent volume, and dosage unit from the drug library stored on the device. In some cases, where the APR includes patient information (e.g., a patient identifier), patient parameters (such as patient weight) may also be loaded and displayed. As depicted, there may be multiple screens of confirmation.

[0101] According to various embodiments, a graphical user interface screen may be captured for each step of a procedure associated with the APR. When a physical device is used as a test instance and / or manual confirmation is required, the test instance may capture each screen as it is confirmed by the clinician. In an automated embodiment, the test instance may simulate clicking “Next” (e.g., Fig. 6A ) until a "Start" option is provided (e.g. Figure 6B ). The test instance can then simulate the start of the infusion and the final image (e.g. Figure 6C) may be captured. The captured image may then be attached to the APR response and returned to the requesting system as previously described.

[0102] Fig.6D An example user interface 608 is depicted in which an automatic programming request results in an error in accordance with various aspects of the subject technology. If the APR is well formed, an acknowledgement can be sent to the requesting system to indicate that the message has been understood. However, as described in this example, the data included in the APR may violate agency rules. In such cases, the test instance can capture an image of the user interface displaying the error and include the image in the response sent to the requesting system (e.g., at the end of the image). In some cases, a screen may be approved (e.g., Fig. 6A ), but subsequent steps may include a violation value. In this case, the image(s) of the UI before the error can be included in the response transmitted by the test instance. The system can simulate acceptance of the error so that all screens are captured to complete APR programming.

[0103] According to various embodiments, as previously described, multiple APRs may be initiated by a script. The requesting system (e.g., the coordination engine 208) may maintain and provide log files for displaying results from one or more test instances. Each log file may include a list of all APRs transmitted, which are further identified as passed or failed. Each log file may be provided to a client device as a user interface of the results (e.g., a web page formatted in HTML), and one or more hyperlinks are included with each entry, which provide further information about the entry when selected. For example, a user may be able to view the user interface, select a hyperlink corresponding to an image associated with a corresponding APR, and step through the images. In this way, a user can view images generated in response to each corresponding APR for each corresponding test instance.

[0104] The user interface may be categorizable to display a list of all APR faults, or a list of faults by category (e.g., pump model, type, drug library version, nursing area, etc.). The user may then select which entry to further review, and obtain visual data of the infusion device during the processing of the APR, thereby visually identifying the fault as needed. In some embodiments, the system may provide one or more hyperlinks connected to entries in the drug library for correction. For example, the drug library may be stored in a central database 37 and downloaded or deployed to a physical device as needed. A clinician (e.g., working from a terminal 32) may select a hyperlink corresponding to a fault, and select a corresponding hyperlink to access an editable input field to view and / or modify the corresponding value(s) in the database. The drug library associated with the entry may then be updated and specified (e.g., by a user) for deployment to a corresponding device employing the library via a network 10 at a predetermined time.

[0105] Figure 7 An example process 700 for remotely automatically scanning and verifying a clinical order device configuration in accordance with aspects of the subject technology is depicted. For purposes of explanation, reference is made herein to Figure 1A , Figure 1B , Figure 1C ,and Figure 2 6 and the associated components and / or processes described herein to describe the various blocks of the example process 700. One or more of the blocks of process 700 may be implemented, for example, by one or more computing devices, including, for example, a server 30 and / or a medical device 12. In some embodiments, one or more of the blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more of the blocks may be separated from other blocks and may be implemented by one or more different processors or devices. Further for the purpose of explanation, to the extent that the blocks of the example process 700 are described as occurring serially or linearly, in some embodiments, multiple blocks of the example process 700 may occur in parallel. In addition, the blocks of the example process 700 do not need to be executed in the order shown, and / or one or more of the blocks of the example process 700 do not need to be executed.

[0106] In the depicted example, a request for a test instance of an infusion device is received (702). The request for the test instance can originate from a pharmacy information system to determine whether drug information stored in a formulary is consistent with drug information stored in one or more drug libraries configured to be used by infusion devices in a hospital network (e.g., in drug libraries currently deployed or designated to be deployed to infusion devices). The pharmacy information system can include a record system such as a formulary 204 and / or an EMR system 202. The request can be initiated by a user, or by an automated script. For example, a script can be created and executed to obtain an infusion device of a known type that is capable of storing a drug library designated for verification.

[0107] Further references Figure 7 , the requested test instance is caused to be created and identified based on the request (704). According to some embodiments, the request includes test instance identification information for identifying and creating the test instance within the physical operating environment. The server (e.g., server 30 including coordination engine 208) that receives the identification information creates and / or maintains a pathway for communicating with the test instance. For example, the server may query a queue data store (e.g., in database 37) for idle infusion devices corresponding to the infusion device identified in the request (e.g., identified by type, model, capability, etc.). If an idle infusion device matching the description is identified within the hospital network, the device may be reserved for verifying the prescription set information via one or more APR commands sent from the pharmacy information system to the test instance. In this regard, the identified idle device may be locked for use as a test instance, preventing the patient from using it until it is released after the procedure.

[0108] In some embodiments, the pharmacy information system uses the infusion device to confirm the availability of the infusion device. For example, the server can discover the device in the queue data store and then use the identifier of the device to query the device location on the network 10 and confirm that the device is still idle. Once the idle device is confirmed, the server can create an interface for communicating with the infusion device and provide the identifier of the test instance to the pharmacy information system. In this regard, the server can extend the virtual interface for the device so that the request server within the pharmacy information system can communicate with the device, including sending an APR to the device and receiving a response.

[0109] If the device is not available, e.g., the device is not idle in the queue data store or its availability cannot be confirmed, the server may cause a virtual instance of the infusion device to be instantiated as a test instance based at least in part on the request. In some embodiments, the virtual instance will be created without first determining whether an idle physical device exists. In some embodiments, the server may generate multiple virtual instances, and the queue data store may be used to identify an idle virtual instance. The virtual instance may be locked until it is released after the process to prevent other servers from using it.

[0110] Each virtual instance can extend a virtual communication interface for communicating with a remote system using the message protocol of the infusion device, and for receiving and processing automatic programming commands (APRs) that indicate the configuration of the infusion device regarding the infusion of a drug (e.g., according to a drug library stored on the device). In other words, the virtual instance can include software that behaves like a physical infusion device. In some embodiments, the virtual instance can execute the same software that is executed in the corresponding physical device. The pharmacy information system, either alone or via a coordination engine, can communicate with the virtual instance using the virtual communication instance as if it were communicating with a real physical device of the same designation (e.g., infusion device type, model, version, etc.).

[0111] After the test instance is confirmed as available or virtually generated, an automatic programming command (or APR) is transmitted to the identified test instance (706). In some embodiments, the APR is transmitted by the recording system. The APR can be received by the coordination engine 208 before it is transmitted to the identified test instance, and the coordination engine 208 can coordinate the communication between the recording system and the test instance.

[0112] The automatic programming command may include verification information for verifying the clinical order data. The clinical order data may correspond to data stored in the prescription set 204 and / or in the drug library configured for the requested infusion device. The purpose of providing the verification information to the test instance is to determine whether the data in the prescription set and the drug library are aligned with each other. In this regard, the verification information may directly correspond to the information in the prescription set and may be sent to the test instance for the purpose of verifying the clinical order data stored in the drug library.

[0113] In some embodiments, the verification information can identify specific drug library information stored in a drug library configured for deployment by an infusion device. For example, the drug library can be stored in a database 37 and periodically deployed to an infusion device. The verification information can include and / or identify information in a prescription set 204, which is also expected in a corresponding drug library. Once received by the test instance, the APR (and the verification information) causes the test instance to be configured with the identified drug library information from the drug library deployed to the test instance. If the verification information sent using the APR matches the drug library information, the configuration will pass. Otherwise, as previously described, the configuration may result in misalignment errors.

[0114] Based on the automatic programming command transmitted to the test instance, a programming response is generated (708). The programming response includes information about how the test instance reacted or performed based on the APR. As previously described, the programming response can include an image or reference to an image of a graphical user interface that would be presented by the infusion device configured according to the automatic programming command. According to various embodiments, the programming response identifies one or more deviations between the verification information (e.g., based on the formulary information) and the drug library information.

[0115] In some embodiments, the test instance can receive the programming response and generate a graphical user interface image based on the infusion device software running on the test instance. In this regard, the test instance cannot control how the APR is processed. In the case of a virtual instance, the APR is processed as if it were sent to a physical device executing the same software. Therefore, in some embodiments, the test instance or the coordination server can receive the image and use optical character recognition to extract text from the image, and then compare the extracted text with the expected test for the clinical order associated with the APR. Based on this comparison, misalignment errors can be identified and the programming response can be updated with the misalignment error together with the identification of the field associated with the error. In some embodiments, the image can be compared with a reference image associated with the clinical order, and the comparison can determine whether the image corresponds to the reference image. As previously described, the programming response can be updated to include a detailed demonstration (walk-through) of multiple screens, recreating the infusion device user interface, as it would appear if the user viewed the response at the device when the APR was received.

[0116] After the programmed response is generated, the programmed response is provided to the recording system for storage (710). The response can be provided to the EMR system 202 by the coordination engine 208. In embodiments where the coordination engine is omitted, the response can be provided directly to the EMR system 202. In some embodiments, the response can be stored separately from any images provided with the response. In this regard, the response can include a reference (e.g., a hyperlink) to each image. The response can be stored in a first database and the images can be stored in a second database. When the record is retrieved from the first database and displayed for review, the user can use the hyperlink to extract the image from the second database.

[0117] Many of the above-described example processes 400, 500, and 700 and related features and applications may also be implemented as a software process, which is specified as a set of instructions recorded on a computer-readable storage medium (also referred to as a computer-readable medium) and can be automatically executed (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, cores of processors, or other processing units), they cause the processing units 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 drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or via wired connections.

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

[0119] A computer program (also referred to as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or portions of code). A computer program may be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0120] Figure 8 1-1 is a conceptual diagram illustrating an example electronic system 800 for automatically scanning and verifying clinical order device configurations according to aspects of the subject technology. The electronic system 800 may be a system for performing one or more portions or steps of processes 400, 500, and 700 or by FIG. Figure 7 The components and methods associated with the provided computing devices include, but are not limited to, computing hardware within the server 30, terminal 32, or patient care device 12 and / or any computing device or associated terminal disclosed herein. In this regard, the electronic system 800 can be a personal computer or a mobile device such as a smartphone, tablet computer, laptop computer, PDA, augmented reality device, wearable device (such as a watch or band or glasses), or a combination thereof, or other touch screen or television having one or more processors embedded therein or coupled thereto, or any other class of computer-related electronic devices having network connectivity.

[0121] The electronic system 800 may include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, the electronic system 800 includes a bus 808, (one or more) processing units 812, a system memory 804, a read-only memory (ROM) 810, a permanent storage device 802, an input device interface 814, an output device interface 806, and one or more network interfaces 816. In some embodiments, the electronic system 800 may include or be integrated with other computing devices or circuits for operating the various components and methods described previously.

[0122] Bus 808 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 800. For example, bus 808 communicatively connects processing unit(s) 812 with ROM 810, system memory 804, and permanent storage device 802.

[0123] From these various memory units, processing unit(s) 812 retrieve instructions to execute and data to process in order to perform the processes of the subject disclosure. In various implementations, the processing unit(s) may be a single processor or a multi-core processor.

[0124] ROM 810 stores static data and instructions required by (one or more) processing units 812 and other modules of the electronic system. On the other hand, permanent storage device 802 is a read-write memory device. Such a device is a non-volatile memory unit that stores instructions and data even when the electronic system 800 is turned off. Some embodiments of the subject disclosure use a mass storage device (such as a magnetic disk or optical disk and its corresponding disk drive) as permanent storage device 802.

[0125] Other embodiments use removable storage devices (such as floppy disks, flash drives and their corresponding disk drives) as permanent storage devices 802. Like permanent storage devices 802, system memory 804 is a read-write memory device. However, unlike storage devices 802, system memory 804 is a volatile read-write memory, such as random access memory. System memory 804 stores some instructions and data that the processor needs at run time. In some embodiments, the processes disclosed in the subject matter are stored in system memory 804, permanent storage devices 802, and / or ROM 810. From these various memory units, (one or more) processing units 812 retrieve instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0126] The bus 408 is also connected to input and output device interfaces 814 and 806. The input device interface 814 enables a user to communicate information and select commands to the electronic system. Input devices used with the input device interface 814 include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 806 enables, for example, the display of images generated by the electronic system 800. Output devices used with the output device interface 806 include, for example, a printer and a display device, such as a cathode ray tube (CRT) or a liquid crystal display (LCD). Some embodiments include devices such as a touch screen that function as both an input and an output device.

[0127] In addition, if Figure 8As shown, bus 808 also couples electronic system 800 to a network (not shown) via network interface 816. Network interface 816 may include, for example, a wireless access point (e.g., Bluetooth or WiFi) or a radio circuit for connecting to a wireless access point. Network interface 816 may also include hardware (e.g., Ethernet hardware) for connecting a computer to a network (such as the Internet) that is part of a computer network (such as a local area network ("LAN"), a wide area network ("WAN"), a wireless LAN, or an intranet) or a plurality of networks. Any or all components of electronic system 800 may be used in conjunction with the subject disclosure.

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

[0129] Some embodiments include electronic components such as microprocessors, storage, and memory that store computer program instructions in machine-readable or computer-readable media (also referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, compact disk-read only (CD-ROM), compact disk-recordable (CD-R), compact disk-rewritable (CD-RW), read-only digital versatile disks (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 drives, read-only and recordable A disk, an ultra-density optical disk, any other optical or magnetic medium, and a floppy disk. A 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 produced by a compiler), and files including higher-level code that is executed by a computer, electronic component, or microprocessor using an interpreter.

[0130] Although the above discussion refers primarily 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 circuits themselves.

[0131] 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 purpose of this specification, the terms display or displaying means displaying 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, and any other transient signals.

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

[0133] Embodiments of the subject matter described in this specification may be implemented in a computing system that includes a back-end component, such as a data server, or includes a middleware component, such as an application server, or includes a front-end component, such as a client computer with a graphical user interface or a web browser, through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., adhoc peer-to-peer networks).

[0134] A computing system may include a client and a server. The client and the server are usually remote from each other and may interact via a communication network. The relationship between the client and the server is due to the 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., an HTML page) to a client device (e.g., to display data to a user interacting with the client device and to receive user input from a user interacting with the client device). Data generated at the client device (e.g., the result of the user interaction) may be received from the client device at the server.

[0135] Those skilled in the art will appreciate that various illustrative blocks, modules, elements, assemblies, methods and algorithms described herein can be implemented as electronic hardware, computer software or a combination of the two. In order to illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, assemblies, methods and algorithms are generally described above with regard to their functions. Whether this function is implemented as hardware or software depends on specific applications and the design constraints imposed on the overall system. For each specific application, the described function can be implemented in different ways. Various components and blocks can be arranged differently (for example, arranged in different orders, or partitioned in different ways), and all can not deviate from the scope of subject technology.

[0136] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an example method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps can be performed simultaneously. The accompanying method claims present elements of the various steps in an example order and are not meant to be limited to the specific order or hierarchy presented.

[0137] The subject technology as a description of the terms:

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

[0139] Clause 1. A system for remotely scanning and verifying a clinical order device configuration, comprising: a processor; and a non-transitory computer-readable medium comprising instructions that, when executed by the processor, cause the system to: receive a request for a test instance of an infusion device; cause the test instance to be created based on the request; cause an automatic programming command to be transmitted to the identified test instance, the automatic programming command including verification information for verifying clinical order data; based on the automatic programming command transmitted to the test instance, generate a programming response including an image of a graphical user interface or a reference to the image, the graphical user interface to be presented by the infusion device configured according to the verification information; and provide the programming response for storage in a record system.

[0140] Clause 2. The system of claim 1, wherein the automatic programming commands are received from the system of record before being transmitted to the identified test case.

[0141] Clause 3. The infusion device of claim 1 or claim 2, wherein the instructions further cause the system to: transmit an identifier of the test instance to a recording system.

[0142] Clause 4. The system of any one of claims 1 to 3, wherein causing the test instance to be created and identified comprises the system being caused to: identify an infusion device in a physical operating environment; confirm availability of the infusion device; and create an interface for communicating with the infusion device, wherein the automatic programming command is transmitted to the infusion device via the interface.

[0143] Clause 5. The system of claim 4, wherein the system being caused to identify the infusion device in the physical operating environment comprises the system being caused to query a queue data store for idle infusion devices corresponding to the infusion device.

[0144] Clause 6. The system of any one of claims 1 to 3, wherein causing the test instance to be created comprises the system being caused to: query a queue data store for idle infusion devices corresponding to the infusion device; determine that the idle infusion device is unavailable; and instantiate a virtual infusion device as the test instance based at least in part on the request.

[0145] Clause 7. The system of any one of claims 1 to 6, wherein the verification information identifies drug library information stored in a drug library, the drug library configured for deployment by the infusion device; and wherein the instructions cause the automatic programming command to be transmitted to the identified test instance comprises: the automatic programming command causes the test instance to be configured by the identified drug library information deployed from the drug library to the test instance.

[0146] Clause 8. The system of claim 7, wherein causing the test instance to be created and identified comprises the system being caused to: generate a virtual instance of the infusion device, the virtual instance extending a virtual communication interface for communicating with a remote system using a message protocol of the infusion device and for receiving and processing automatic programming commands, wherein the test instance includes the virtual instance, and wherein the automatic programming commands are transmitted to the virtual instance via the virtual communication interface.

[0147] Clause 9. The system of claim 6 or claim 8, wherein generating the programming response comprises: receiving the programming response from the virtual instance; and formatting the programming response for the system of record.

[0148] Clause 10. The system of any one of claims 1 to 9, wherein generating the programming response further comprises: extracting text from the image using optical character recognition; and comparing the extracted text to expected text for a clinical order associated with the automated programming command, wherein formatting the programming response comprises updating the programming response to include a result of the comparison.

[0149] Clause 11. The system of any one of claims 1 to 10, wherein the programmed response identifies one or more deviations between data stored in the pharmacy system and programmed data stored in the drug library used by the test instance.

[0150] Clause 12. A method for remotely scanning and verifying a clinical order device configuration, comprising: transmitting a request for a test instance of an infusion device to a server; receiving an identifier of the test instance from the server in response to the request; identifying clinical order data associated with a medication; causing an automatic programming command to be transmitted to the test instance based on the identifier to verify the identified clinical order data; receiving a programming response including an image of, or a reference to an image of, a graphical user interface to be presented by the infusion device based on processing of the automatic programming command by the infusion device based on the programming response; identifying an error in the clinical order data based on the programming response; and providing the programming response for storage in a system of record.

[0151] Clause 13. The method of claim 12, further comprising: performing image analysis of the image; and identifying errors in the clinical order data based on the image analysis of the image.

[0152] Clause 14. The method of claim 12 or claim 13, further comprising: identifying an infusion device in the physical operating environment; confirming availability of the infusion device; and creating an interface for communicating with the infusion device, wherein the automatic programming command is transmitted to the infusion device via the interface.

[0153] Clause 15. The method of any one of claims 12 to 14, wherein identifying the infusion device comprises querying a queue data store for idle infusion devices corresponding to the infusion device.

[0154] Clause 16. The method of claim 12, further comprising: querying a queue data store for idle infusion devices corresponding to the infusion device; determining that the idle infusion device is unavailable; and instantiating a virtual infusion device as a test instance based at least in part on the request.

[0155] Clause 17. A method according to any one of claims 12 to 116, wherein the automatic programming command includes verification information identifying drug library information stored in a drug library, the drug library being configured for deployment by the infusion device, the method further comprising: the automatic programming command causing the test instance to be configured by the identified drug library information deployed from the drug library to the test instance.

[0156] Clause 18. The method of any one of claims 12, 13, or 17, further comprising: generating a virtual instance of the infusion device, the virtual instance extending a virtual communication interface for communicating with a remote system using a message protocol of the infusion device and for receiving and processing automatic programming commands, wherein the test instance includes the virtual instance, and wherein the automatic programming commands are transmitted to the virtual instance via the virtual communication interface.

[0157] Clause 19. The method of claim 18, wherein generating the programming response comprises: receiving the programming response from the virtual instance; and formatting the programming response for the system of record.

[0158] Clause 20. The method of any one of claims 12 to 19, further comprising: extracting text from the image using optical character recognition; and comparing the extracted text to expected text for a clinical order associated with the automated programming request, wherein formatting the programming response comprises updating the programming response to include a result of the comparison.

[0159] Clause 21. A non-transitory computer readable medium comprising instructions which, when executed by a processor, cause an infusion device to implement the method of any one of claims 12 to 20.

[0160] Further considerations:

[0161] It is understood that the specific order or hierarchy of steps in the disclosed process is an illustration of an example method. Based on design preferences, it is understood that the specific order or hierarchy of steps in the process can be rearranged. Some steps can be performed simultaneously. The accompanying method claims present elements of the various steps in an example order and are not meant to be limited to the specific order or hierarchy presented.

[0162] The preceding description is provided to enable any person skilled in the art to practice the various aspects described herein. The preceding description provides various examples of the subject technology, and the subject technology 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 to be given the full scope consistent with the language claims, wherein unless specifically so stated, referring to an element in the singular is not intended to mean "one and only one", but "one or more". Unless otherwise specifically stated, the term "some" refers to one or more. Male pronouns (e.g., his) include female and neutral genders (e.g., her and its), and vice versa. Titles and subtitles, if any, are used only for convenience and do not limit the invention described herein.

[0163] The predicates "configured to", "operable to", and "programmed to" do not imply any particular tangible or intangible modification of the subject, but are intended to be used interchangeably. For example, a processor being configured to monitor and control an operation or component may also mean that the processor is programmed to monitor and control the operation or that the processor is operable to monitor and control the operation. Similarly, a processor being configured to execute code may be interpreted as the processor being programmed to execute code or being operable to execute code.

[0164] The term automatically, as used herein, may include being performed by a computer or machine without user intervention; for example, by being responsive to instructions of a predicate action by a computer or machine or other initiating mechanism. The word "exemplary" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0165] Phrases such as "aspects" do not mean that the aspect is essential to the subject technology, or that the aspect applies to all configurations of the subject technology. The disclosure related to the aspect can apply to all configurations, or one or more configurations. An aspect can provide one or more examples. Phrases such as aspects can refer to one or more aspects, and vice versa. Phrases such as "embodiments" do not mean that such embodiments are essential to the subject technology, or that such embodiments are applicable to all configurations of the subject technology. The disclosure related to the embodiment can apply to all embodiments, or one or more embodiments. An embodiment can provide one or more examples. Phrases such as "embodiments" can refer to one or more embodiments, and vice versa. Phrases such as "configurations" do not mean that such configurations are essential to the subject technology, or that such configurations are applicable to all configurations of the subject technology. The disclosure related to the configuration can apply to all configurations, or one or more configurations. A configuration can provide one or more examples. Phrases such as "configurations" can refer to one or more configurations, and vice versa.

[0166] As used herein, a "user interface" (also referred to as an interactive user interface, graphical user interface, or UI) may refer to a web-based interface that includes 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 dials, buttons, icons, selectable areas, or other perceptible indicia presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiate data exchange with the device presenting the UI. The UI may use technologies such as Hypertext Markup Language (HTML), FLASH, or other web-based technologies. TM , JAVA TM , .NET TM , C, C++, web services, or rich site summary (RSS)). In some embodiments, the UI can be included in a stand-alone client (e.g., thick client, fat client) configured to communicate (e.g., send or receive data) according to one or more aspects described. Communications can be to or from a medical device or server communicating with it.

[0167] As used herein, the term "determine" or "determine" covers a wide variety of actions. For example, "determine" may include accounting, calculating, processing, deriving, generating, acquiring, searching (e.g., searching in a table, a database, or another data structure), confirming, etc. via a hardware element without user intervention. In addition, "determine" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. via a hardware element without user intervention. "Determine" may include parsing, selecting, selecting, establishing, etc. via a hardware element without user intervention.

[0168] As used herein, the term "providing" or "providing" encompasses a wide variety of actions. For example, "providing" may include storing a value at a location on a storage device for subsequent retrieval, sending a value directly to a recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, etc. "Providing" may also include encoding, decoding, encrypting, decrypting, verifying, validating, etc. via a hardware element.

[0169] As used herein, the term "message" encompasses a variety of formats for communicating (e.g., sending or receiving) information. A message may include a machine-readable aggregation of information, such as an XML document, a fixed field message, a comma-delimited message, JSON, a custom protocol, etc. In some embodiments, a message may include a signal for transmitting one or more representations of information. Although described in the singular, it will be understood that a message may be composed, sent, stored, received, etc., in multiple parts.

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

[0171] As used herein, the term "correspondence" or "correspondence" encompasses a structural, functional, quantitative and / or qualitative association or relationship between two or more objects, data sets, information and / or the like, preferably, wherein the correspondence or relationship can be used to translate one or more of the two or more objects, data sets, information and / or the like to appear the same or equal. Correspondence can be assessed using one or more of a threshold, a range of values, fuzzy logic, pattern matching, a machine learning assessment model, or a combination thereof.

[0172] In any embodiment, the data generated or detected can be forwarded to a "remote" device or location, where "remote" refers to a location or device other than the location or device where the program is executed. For example, the remote location can be another location in the same city (e.g., an office, a laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. Therefore, when an item is indicated as being "remote" from another item, it means that the two items can be in the same room, but can be separated, or at least in different rooms or different buildings, and can be at least one mile, ten miles, or at least one hundred miles apart. "Transmitting" information means transmitting data representing the 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 the next, whether by physically transporting the item or otherwise (where possible), at least in the case of data, including physically transporting a medium that carries 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 for remotely scanning and verifying a clinical order device configuration, comprising: processor; and A non-transitory computer-readable medium comprising instructions that, when executed by the processor, cause the system to: receiving a request for a test instance of an infusion device; causing creation of a test instance based on the request; causing an automatic programming command to be transmitted to the identified test instance, the automatic programming command including verification information for verifying the clinical order data; generating, based on the automatic programming command transmitted to the test instance, a programming response including an image of, or a reference to, a graphical user interface to be presented by the infusion device configured according to the verification information; as well as The programmed response is provided for storage in a recording system.

2. The system according to claim 1, wherein: The automatic programming commands are received from the recording system before being transmitted to the identified test case.

3. An infusion device according to claim 1 or claim 2, wherein: The instructions also cause the system to: An identifier of the test instance is transmitted to the recording system.

4. The system according to any one of claims 1 to 3, wherein: Causing the test instance to be created and identified includes causing the system to: identifying the infusion device in a physical operating environment; confirming the availability of said infusion equipment; and creating an interface for communicating with the infusion device, Wherein, the automatic programming command is transmitted to the infusion device via the interface.

5. The system according to claim 4, wherein: The system being caused to identify the infusion device in a physical operating environment includes the system being caused to: A queue data store is queried for idle infusion devices corresponding to the infusion device.

6. The system according to any one of claims 1 to 3, wherein: Causing the test instance to be created includes causing the system to: querying a queue data storage of idle infusion devices corresponding to the infusion device; Determining that an idle infusion device is unavailable; and A virtual infusion device is instantiated as a test instance based at least in part on the request.

7. The system according to any one of claims 1 to 6, in, The verification information identifies drug library information stored in a drug library, the drug library being configured for deployment by the infusion device; and The instructions causing the automatic programming command to be transmitted to the identified test instance include: the automatic programming command causing the test instance to be configured by the identified drug library information deployed from the drug library to the test instance.

8. The system according to claim 7, wherein: Causing the test instance to be created and identified includes causing the system to: generating a virtual instance of the infusion device, the virtual instance extending a virtual communication interface for communicating with a remote system using a message protocol of the infusion device and for receiving and processing the automatic programming command, Wherein the test instance includes the virtual instance, and wherein the automatic programming command is transmitted to the virtual instance via the virtual communication interface.

9. A system according to claim 6 or claim 8, wherein: Generating the programmed response includes: receiving the programmed response from the virtual instance; and The programmed response is formatted for the recording system.

10. The system according to any one of claims 1 to 9, wherein: Generating the programmed response further comprises: extracting text from the image using optical character recognition; and comparing the extracted text to expected text for a clinical order associated with the automated programming command, Wherein formatting the programming response includes updating the programming response to include a result of the comparing.

11. The system according to any one of claims 1 to 10, wherein: The programmed response identifies one or more deviations between data stored in the pharmacy system and programmed data stored in the drug library used by the test instance.

12. A method for remotely scanning and verifying a clinical order device configuration, comprising: transmitting a request for a test instance of an infusion device to a server; receiving an identifier of the test instance from the server in response to the request; Identify clinical order data associated with a medication; causing automatic programming commands to be transmitted to the test instance based on the identifier to verify the identified clinical order data; receiving, based on the automatic programming command transmitted to the test instance, a programming response including an image of, or a reference to, a graphical user interface to be presented by the infusion device based on processing of the automatic programming command by the infusion device; identifying an error in the clinical order data based on the programmed response; as well as The programmed response is provided for storage in a recording system.

13. The method according to claim 12, further comprising: performing image analysis on the image; as well as The error in the clinical order data is identified based on image analysis of the image.

14. The method according to claim 12 or claim 13, further comprising: identifying the infusion device in a physical operating environment; confirming the availability of said infusion equipment; as well as creating an interface for communicating with the infusion device, Wherein, the automatic programming command is transmitted to the infusion device via the interface.

15. The method according to any one of claims 12 to 14, wherein: Identifying the infusion device comprises: A queue data store is queried for idle infusion devices corresponding to the infusion device.

16. The method according to claim 12, further comprising: querying a queue data storage of idle infusion devices corresponding to the infusion device; Determine that idle infusion equipment is unavailable; as well as A virtual infusion device is instantiated as the test instance based at least in part on the request.

17. The method according to any one of claims 12 to 116, wherein: The automatic programming command includes authentication information identifying drug library information stored in a drug library, the drug library being configured for deployment by the infusion device, the method further comprising: The automatic programming commands cause the test instance to be configured with the identified drug library information deployed from a drug library to the test instance.

18. The method according to any one of claims 12, 13 or 17, further comprising: generating a virtual instance of the infusion device, the virtual instance extending a virtual communication interface for communicating with a remote system using a message protocol of the infusion device and for receiving and processing the automatic programming command, Wherein the test instance includes the virtual instance, and wherein the automatic programming command is transmitted to the virtual instance via the virtual communication interface.

19. The method according to claim 18, wherein: Generating the programmed response includes: receiving the programmed response from the virtual instance; and The programmed response is formatted for the recording system.

20. The method according to any one of claims 12 to 19, further comprising: extracting text from the image using optical character recognition; as well as comparing the extracted text to expected text for a clinical order associated with the automated programming request, Wherein formatting the programming response includes updating the programming response to include a result of the comparing.

21. A non-transitory computer readable medium comprising instructions which, when executed by a processor, cause an infusion device to implement the method of any one of claims 12 to 20.

Images