Remote scanning and validation of clinical order device configurations

Abstract

A system for scanning and validating clinical order device configurations is disclosed. A test instance of an infusion device is created based on a request and an auto-program command is communicated to the test instance. The auto-program command includes validation information for validating clinical order data, and a program response is generated by the test instance based on the auto-program command, and the program response is provided for storage in a records system. In some embodiments, the response includes an image of or reference to an image of a graphical user interface that would be presented by an infusion device configured according to the validation information.

Description

TECHNICAL FIELD

[0001] The present application generally relates to ensuring that infusion devices are programmed correctly. BACKGROUND

[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 pump of the device to deliver a particular fluid at a particular rate for a particular patient; the remote programming command is commonly referred to as an automated programming request (APR). The APR configuration can include pre-populated operational 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 can exist with manual programming. Typically, there is no difference in the programming screens, prompts, or user interfaces between systems configured for APRs and systems not configured for APRs, and the implementation of APRs does not preclude a clinician from manually programming the pump. However, manual programming is required if any component of the interfacing system fails.

[0004] In some APR-enabled systems, an APR order can be rejected due to a device-to-order deviation that prevents the system from taking an automatic action based on the order. For example, an infusion device can be configured to not 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 can be rejected because the automatically programmed parameter value does not align with the pump configuration. When an order is rejected, the device must be manually programmed to initiate the infusion. The misalignment error is often not discovered until the pump is programmed in a clinical setting to deliver an infusion to a patient. Such APR-related errors are not, to the knowledge of the inventors, centrally cataloged. SUMMARY

[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 conventional systems and processes, misalignments between pharmacy 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. As a result, the drug library and / or other medication databases can be updated with“good” data according to a centralized schedule, eliminating misalignment data that would otherwise cause devices 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 validating 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 a test instance to be created based on the request; cause an auto-programming command to be transmitted to the identified test instance, the auto-programming command comprising validation information for validating clinical order data; generate a programming response comprising an image of a graphical user interface or a reference to an image that would be presented by the infusion device configured according to the validation information based on the auto-programming command transmitted to the test instance; and provide the programming response for storage in a records 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 validating 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 auto-programming command to be transmitted to the test instance based on the identifier to validate the identified clinical order data; receiving a programming response comprising an image of a graphical user interface or a reference to an image that would be presented by the infusion device based on the infusion device processing the auto-programming command based on the auto-programming command transmitted to the test instance; identifying an error in the clinical order data based on the programming response; and providing the programming response for storage in a records system. Other aspects include corresponding systems, apparatuses, and computer program products for implementing corresponding methods and features thereof.

[0008] It is understood that other configurations of the subject technology will become readily apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive. BRIEF DESCRIPTION OF DRAWINGS

[0009] For a better understanding of the various described implementations, reference should be made to the Description of the Embodiments below in conjunction with the following drawings. In the drawings and description below, like numerals are used to refer to like parts throughout several figures.

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

[0011] Figure 1B An example patient care system including an infusion device is depicted. Figure 1AA closer view of a portion of the patient care system shown in FIG. 1.

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

[0013] Figure 2 An example system for reviewing and validating a set of prescriptions is depicted in accordance with aspects of the subject technology.

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

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

[0016] Figure 5A An example process for remotely automatically scanning and validating a clinical order device configuration is depicted in accordance with aspects of the subject technology.

[0017] Figure 5B An example process flow for remotely automatically scanning and validating a clinical order device configuration is depicted in accordance with aspects of the subject technology.

[0018] Figure 6A 、 Figure 6B and Figure 6C A series of user interfaces in an example infusion programming workflow for automatically programming an infusion device is depicted in accordance with aspects of the subject technology.

[0019] Figure 6D An example user interface in which an automatic programming request results in an error is depicted in accordance with aspects of the subject technology.

[0020] Figure 7 An example process for remotely automatically scanning and validating a clinical order device configuration is depicted in accordance with aspects of the subject technology.

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

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

[0023] Figure 1A is an example patient care system in accordance with various aspects of the subject technology. Figure 1A The patient care system 1 shown in FIG. 1 includes four fluid infusion pumps 16, 18, 20, 22, each of which is in operative engagement with a respective fluid administration set 2a-d. Fluid supplies 3a-d, which can take various forms but are shown in this case as bottles, are inverted and hung above the pumps. The fluid supplies can also take the form of bags or other types of containers. Both the patient care system 1 and the fluid supplies 3a-d are mounted to a roller or bar 4. The particular fluid supplies, as well as their orientation within the care area (e.g., mounting location, mounting height, mounting type, etc.) can generate one or more interaction records. Interaction records for the sets, for example, can be generated in part by detecting a scannable code associated with the set or detecting a physical structure on the set that encodes identification information for the set prior to use.

[0024] As shown in the example implementation of FIG. 1, each administration set 2a-d is connected between a respective fluid supply 3a-d and the same patient so that the patient can receive fluids from all of the fluid supplies. The administration sets can be actively identified by, for example, being scanned by a clinician, or passively identified by, for example, wireless or optical detection of the administration sets. Figure 1A

[0025] In the depicted example, separate infusion pumps 16, 18, 20, 22 are used to infuse each of the fluid supplies into the patient. The infusion pumps are flow control devices that will act on the respective tubes or fluid conduits of the fluid administration sets to move the fluids from the fluid supplies through the conduits to the patient. Because separate pumps are used, each pump can be individually set to the pumping or operating parameters required to infuse the particular medical fluid from the respective fluid supply into the patient at the particular rate prescribed for that fluid by the clinician.

[0026] Generally, medical fluid administration sets have more components than Figure 1A are shown. Many have check valves, drip chambers, valved ports, connectors, and other devices well known to those skilled in the art. These other devices have not been included in the figures in order to preserve the clarity of the illustrations. ​

[0027] Figure 1B is shown in FIG. 1 in accordance with various aspects of the subject technology. Figure 1A A closer view of a portion of the example patient care system shown in FIG. 1. Figure 1B Two of the fluid infusion pumps mounted on either side of a programming module that is capable of programming both infusion pumps are shown, as well as the display and control keys of each fluid infusion pump. The infusion device 12 includes a door 5a and handle 5b that operate to lock the door in the closed position for operation, and to unlock and open the door for access to the internal pumping and sensing mechanisms and to load the pump with an administration set. When the door 5a is open, tubing can be connected to the pump 20. When the door 5a is closed, the tubing is brought into operative engagement with the pumping mechanism, upstream and downstream pressure sensors, and other devices of the pump. A display 5c, such as an LED display, is located on the door in the plan view in this embodiment and can be used to visually communicate various information related to the pump 20, such as alarm indications (e.g., alarm messages). Control keys 5e-h are present for programming and control operation of the infusion pump as needed. In some implementations, the control keys can be presented as interactive elements on the display 5c, such as a touch screen display. The infusion device 12 and / or infusion pump 20 can also include an audio alarm device in the form of a speaker (not shown).

[0028] The programming module 14 of the infusion device 12 includes a display 6a for visually communicating various information, such as operating parameters and alarm indications and alarm messages of the connected pump. The programming module 14 can also include a speaker to provide audible alarms. In some implementations, the display 6a can be implemented as a touch screen display. In such implementations, the control keys 6b can be omitted or reduced in number by virtue of providing corresponding interactive elements via a graphical user interface presented through the display 6a. The programming module 14 can include a communication system (not shown) that the programming module 14 can use to communicate with external devices, such as a medical facility server or other computer, as well as with portable processors, such as a hand-held communication device or a portable computer, or other information devices, such as the pump 20, that a clinician can possess for communicating information and for downloading drug libraries to the programming module 16, 18, 20, 22. The communication module can be used to communicate access and interaction information to a clinician encountering or coupling with a device of the programming module, e.g., the pump 20 or a bar code scanner. The communication system can include a radio frequency (RF) system, an optical system such as infrared, a BLUETOOTH TMOne or more of the systems or other wired or wireless systems. The bar code scanner and communication system can alternatively be integrally included with the infusion pump 20, such as without the use of a programming module, or in addition to one use of the programming module 14. Additionally, the information input device need not be hardwired to the medical instrument, information can also be transferred through a wireless connection. Further, other types of modules can be connected to the pump module or programming module, such as a syringe pump module, a patient controlled analgesia module, an end-tidal C02monitoring module, a pulse 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 coordinating device, and the methods disclosed herein are implemented on the server or other coordinating device. For example, more complex and computationally intensive methods, such as machine learning, can be implemented on a server (or PCU with greater memory and / or CPU resources). In some embodiments, machine learning is used to identify empty conditions based on pressure signals received from the pump.

[0030] Figure 1C An example of a healthcare organization's institutional patient care system 100 is depicted in accordance with aspects of the subject technology. In Figure 1C The patient care devices (or generally "medical devices") 12 are connected to a 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 ancillary medical devices such as infusion pumps, vital signs monitors, medication dispensing devices (e.g., cabinets, carts), medication preparation devices, automated dispensing devices, modules coupled with one of the foregoing (e.g., a syringe pump module configured to attach to an infusion pump), or other similar devices. Each element 12 is connected to the internal healthcare network 10 by 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 implementations, the network 10 also includes computer systems located in various departments throughout the hospital. For example, Figure 1C The network 10 can optionally include computer systems associated with the admissions department, billing department, biomedical engineering department, clinical laboratory, central supply department, one or more unit station computers, and / or a medical decision support system. As described further below, the network 10 can include discrete 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 operations.

[0031] In addition, the institutional patient care system 100 can 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 can be incorporated into another computer if the engineers designing the institutional information system so desire. The institutional patient care system 100 can also include one or more device terminals 32 for connecting and communicating with the information system server 30. The device terminals 32 can include personal computers, personal data assistants, and mobile devices (such as laptops, tablets, augmented reality devices, or smartphones) configured with software for communicating with the information system server 30 via the network 10.

[0032] The patient care device 12 includes a system for providing patient care such as that described in Eggers et al., which is incorporated herein by reference for that purpose. The patient care device 12 can include or incorporate pumps, physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors), therapy devices, and other drug delivery devices that can be used in accordance with the teachings set forth herein. In the depicted example, the patient care device 12 includes a control module 14, also referred to as an interface unit 14, that is connected to one or more functional modules 116, 118, 120, 122. The interface unit 14 includes a central processing unit (CPU) 50 connected to a memory (e.g., random access memory (RAM) 58), as well as one or more interface devices, such as a user interface device 54, a coded data input device 60, a network connection 52, and a secondary interface 62 for communicating with additional modules or devices. The interface unit 14 also (although not necessarily) includes a primary non-volatile storage unit 56 (such as a hard 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 touchscreen for displaying information to a user and allowing the user to input information by touching a defined area of ​​the screen. Additionally or alternatively, the user interface device 54 may include any means for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen. The data input device 60 may be a barcode reader capable of scanning and interpreting data printed in barcode format. Additionally or alternatively, the data input device 60 may be any device for inputting encoded data into a computer, such as a device for reading magnetic stripes, a radio frequency identification (RFID) device, whereby digital data encoded in an RFID tag or smart tag (defined below) is captured by the reader 60 via radio waves, a PCMCIA smart card, an RFID card, a memory stick, a CD, DVD, or any other analog or digital storage medium. Other examples of the data input device 60 include voice-activated or recognition devices or portable personal data assistants (PDAs). Depending on the type of interface device used, the user interface device 54 and the data input device 60 may be the same device. Although the data input device 60 is... Figure 1C The data input device 60 is shown as being housed within interface unit 14; however, it is understood that the data input device 60 may be integrated within pharmacy system 34 or located externally and communicate with pharmacy system 34 via an RS-232 serial interface or any other suitable communication device. Auxiliary interface 62 may be an RS-232 communication interface; however, any other means for communicating with peripheral devices (such as printers, patient monitors, infusion pumps, or other medical devices) may be used without departing from the subject matter. Alternatively, the data input device 60 may be a separate functional module, such as modules 16, 18, 20, and 22, and configured to communicate with controller 14 or any other system on the network using suitable programming and communication protocols.

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

[0035] Functional modules 16, 18, 20, and 22 are any devices used to provide care to patients or to monitor patient conditions. For example... Figure 1CAs shown, at least one of the functional modules 16, 18, 20, 22 can be an infusion pump module for delivering medication or other fluids to a patient, such as an intravenous infusion pump. For purposes 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 bar code reader, a near field communication reader, an RFID reader, or any other peripheral input, output, or input / output device.

[0036] Each of the functional modules 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. As Figure 1C As shown, or as detailed by Eggers et al., the functional modules 16, 18, 20, and / or 22 can be connected physically and electronically in series to one or both ends of the interface unit 14. However, it is recognized that other means for connecting functional modules with an interface unit exist, and these can be used without departing from the subject technology. It will also be recognized that a device providing sufficient programmability and connectivity, such as a pump or patient monitoring device, can be capable of operating as a stand-alone device and can communicate directly with a network without being connected through a separate interface unit or control unit 14. As noted above, additional medical devices or peripheral devices can be connected to the patient care device 12 through one or more auxiliary interfaces 62.

[0037] Each of the functional modules 16, 18, 20, 22 can include module-specific components 76, a microprocessor 70, volatile memory 72, and non-volatile memory 74 for storing information. It should be noted that while Figure 1C While four functional modules are shown in FIG. 1, any number of devices can be connected directly or indirectly to the central controller 14. The number and type of functional modules described herein are intended to be illustrative and in no way limit the scope of the subject technology. The module-specific components 76 include any components necessary for the operation of the particular module, such as a pumping mechanism for the infusion pump module 116.

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

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

[0040] Existing technologies allow data traveling to and from various data sources to be converted into network-compatible data, and information movement between medical devices and networks can be achieved in various ways. For example, patient care device 12 and network 10 can communicate via automatic interaction, manual interaction, or a combination of automatic and manual interaction. Automatic interaction can be continuous or intermittent and can be achieved via a direct network connection 54 (e.g., ...). Figure 1C (As shown), or via RS232 links, MIB systems, RF links (e.g., Bluetooth), IR links, WLANs, digital cable systems, telephone modems, or other wired or wireless communication means. Manual interaction between patient care device 12 and network 10 involves the intermittent or periodic physical transfer of data between systems using, for example, user interface device 54, coded data input device 60, barcodes, computer disks, portable data assistants, memory cards, or any other media used for data storage. The communication devices in each aspect are bidirectional in terms of accessing data from as many points as possible from distributed data sources. Decisions can be made in various locations within network 10. For example, and not limited to, decisions can be made in HIS server 30, decision support 48, remote data server 49, hospital department or unit station 46, or within patient care device 12 itself.

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

[0042] According to various embodiments, the server 30 includes a formulary and / or a pharmacy information system. The pharmacy information system can implement a secure physician medication ordering process. A pharmacy website (e.g., provided by the server) can provide physicians with a list of available medications from which the physician can choose. The pharmacy website can contain a medication library with a list of available medications, but can also contain and present to the physician medication names associated with recommended dosages and dosage limits that have been established or adopted by the healthcare facility. In such cases where the physician only needs to select items from a computer screen without having to manually enter medication names and medication administration numbers (such as infusion rates, times, etc.) associated with administration of the medication, this should result in a more accurate medication process.

[0043] If the clinical order is for administration of a particular medication regimen, the order is communicated to the pharmacy information system 30 of the facility. The pharmacy reviews the order, and once the order has been prepared, the order can be communicated to a nurses' station for matching with the appropriate patient. The formulary is a list of approved medications for use within the healthcare facility (e.g., available for patient ordering). Within the formulary, there can be indications for ranges of concentrations and medications approved for use at the facility and / or information for use. As will be further described, the formulary can be used to define one or more medical device medication libraries, which can then be provided to infusion pumps within the hospital network. Within the library, there is medication information such as medication name, concentration, diluent volume, strength, minimum or maximum infusion parameters for the medication, and other parameters. The formulary establishes these parameters via the system 30 along with parameters for orders outside of the formulary are useful to maintain consistency throughout the healthcare environment and to ensure that orders are understandable and performed according to expectations by other devices (e.g., infusion pumps) within the system 30.

[0044] With further reference to 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 internal to the patient care device or an external database 37. The particular configuration database is selected based at least in part on patient-specific information such as patient location, age, physical or medical characteristics. Medical characteristics include, but are not limited to, patient diagnosis, treatment prescription, medical history, medical record, patient care provider identity, physiological or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., physician identity) or the location of the patient care device 12 in the hospital or hospital computer network. Patient care information can be entered through an interface device 52, 54, 60 or 62 and can originate from anywhere in the network 10 such as, for example, from a pharmacy server, an admissions server, a laboratory server, etc.

[0045] The memory 56, 58 of the interface unit 14 can contain one or more drug libraries, one or more event logs, and pump configuration settings, such as but not limited to configuration files to be used in particular practice areas such as ICUs, PEDs, and the like. The memory can be an electronically loadable memory such as a non-volatile memory (e.g., EEPROM). The drug libraries stored on the pump, which illustratively contain information such as drug name, range of delivery parameter values such as appropriate concentration, dosage units, and dosage limits, can be used to perform drug calculation-based infusions in a clinical setting.

[0046] The drug libraries stored within the memory of the pump can include clinical order settings such as limits (also referred to herein as "guardrails") set by the clinical institution for each drug of the library. Such limits can take the form of maximum and minimum doses for each drug, which can depend on patient factors or other factors associated with delivery of the drug. For example, the dosage limits can vary depending on the patient's weight or body surface area ("BSA"), depending on the unit or ward of the medical institution in which the drug is being used (e.g., neonatal care unit (NCU), intensive care unit (ICU), and the like), and depending on other factors. If a nurse sets the pump to operate outside the range between the limits for a particular drug, an alarm can be provided. In some cases, the alarm can be overridden, while in other cases it can not. The medical facility can establish "soft" limits for each drug, which can be overridden by the nurse, and "hard" limits, which can not be overridden. In either case of exceeding a limit, the pump data log or other processor in communication with the infusion pump can record each such limit event for subsequent analysis in the event that the attempted setting is above the maximum dose or below 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 the drug library. Each of the associated set of drug delivery parameters includes information selected from a group of parameters including drug concentration, drug delivery rate, drug dose, and bolus size. The electronically loaded drug library contains a list of available mode options specifying units in which drug delivery information can be expressed, and the drug infusion pump provides the list of available mode options to the user from which the user makes a selection when the electronically loaded drug library is in the pump. In the case of a syringe pump, the electronically loaded drug library can include a list of syringe manufacturers identifying syringes that can be used in the drug infusion pump, and the drug infusion pump provides the list of syringe manufacturers to the user from which the user makes a selection when the electronically loaded drug library is in the pump. The loaded drug library can include a list of syringe sizes identifying 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 can include a list of infusion set manufacturers. The loaded drug library can include a set of features, each of which is toggled on or toggled off, and the pump provides only features from the set of features that are toggled on to the user when the electronically loaded drug library is in the pump.

[0048] Figure 2 An example system 200 for reviewing and validating a set of prescriptions is depicted in accordance with aspects of the subject technology. Interoperability between an electronic medical record (EMR) 202 of a hospital and medical devices, such as 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 the pump. Implementation of interoperability does not preclude manual programming of the infusion device by a clinician. Manual programming can be required in the event of a failure of any component of the interface system.

[0049] A set of prescriptions 204 determines which drugs can be dispensed within a hospital network. A hospital committee can be formed to determine how the drugs within the set of prescriptions will be applied to patient care devices 12. Configuration definitions (e.g., by hospital department such as ICU, NICU, Pediatrics, Oncology, Surgery, etc.) are agreed upon and drug and typical infusion protocols are established in a medical device drug library (“drug library”). In addition, all external limits, or fence conditions, are defined in the drug library. When all definitions are complete, the configuration including the drug library (2.1) can be released. Pumps at the facility are then updated by passing the configuration database to some or all of the pumps.

[0050] In the clinical domain, a clinician can use a scanner associated with a medical device, such as infusion device 12, to scan medical items, such as infusion packaging. For example, a bar code reader (or other data input device) is used to scan coded medication 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 labels or accompanying orders. The reader / scanner need not be integrated with the medical device. The scanner can be part of a separate device, such as medical records terminal 206 (e.g., part of one or more computing devices), connected to the same network 40 as infusion device 12 and configured with software to function in the overall workflow involving infusion device 12. Scanning initiates a process by which information related to the item (e.g., scanned from a code affixed to or communicated by the item) is automatically sent (2.2) via network 40 to the hospital’s EMR 202 (e.g., at centralized server 30). The EMR 202 performs certain actions related to the item and generates (2.3) and sends an automatic programming request (APR) to infusion device 12 to load parameters related to the item. The parameters can be stored in infusion device 12, but loaded in response to an identifier received from the server. While examples herein involve infusion devices, any medical device can be configured and employ the automatic programming error mitigation described herein in the same or similar manner.

[0051] In the depicted implementation, coordination engine 208 coordinates messages sent from EMR 202 to infusion device 12. In the depicted implementation, EMR 202 communicates an APR to pump coordination engine 206 with a device identifier (ID) of the infusion device to receive the APR (2.4). The coordination engine then determines whether the infusion device 12 identified by the EMR is available and, if so, forwards the APR to the device 12 (2.5). When infusion device 12 receives the APR, infusion device 12 determines whether the APR and contents are compliant. This compliance determination can be based on whether data fields included in the APR are consistent with a library of medications loaded in the infusion device. For example, the APR can include or omit fields that can prevent device 12 from resolving or automatically programming itself using information included in the APR alone. Additionally, or in the alternative, the compliance determination can be based on values included within data fields of the APR. For example, if a specified value for a parameter is outside of a configuration range of the infusion device, the value can be determined to be non-compliant. If the APR is determined to be non-compliant, the request can be rejected and / or cause an error at device 12. Such an error is indicative of or referred to as a misalignment error.

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

[0053] Figure 3 An example system 300 for scanning and verifying clinical order device configurations according to aspects of the subject technology is depicted. In the depicted example, device configurations including drug libraries 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 prescription set (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 can 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 one (3.2). The coordination server then responds to the message request with the test instance. Next, a clinical order setup is determined for each test. The clinical order setup can include runtime parameters including one or more of, for example, a pump model (e.g., an identifier of a module of a pump to use for the test), 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., an ftp or IP address, an email, etc.). The clinical order setup can 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 can further specify the type of pump to use according to the channel), etc. These parameters can be input by a user at the time of the test, or can be provided in a script executed for the particular execution cycle. Once the test instance is identified and ready, and the clinical order setup is determined, the EMR system 202 can transmit an APR to the test instance for each of the one or more test configurations.

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

[0056] The functions of the APR process can be similar to that described with respect to Figure 2 described, but in an automated manner. For example, a patient order can 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). The EMR system 202 can further generate a simulated scan event (3.4), such as scanning a drug barcode or QR code at the medical record terminal 206 (see Figure 2The simulated scan events also provide patient identifiers, drug identifiers, and order information. Depending on the implementation, the main script can generate scan events, which are then used to query an order database for patient orders. Patient orders can be pre-ordered or based on actual data.

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

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

[0059] A test instance (e.g., infusion device 12) receives and processes an APR. Infusion device 12 (and / or a processor or system) determines whether the information in the request matches known parameters used 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 may check the drug library to determine whether the received drug concentration is within the permissible 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 that drug. The pump may search based on the drug's name 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 discrepancies between the information provided by the APR and the information stored in the device. In some embodiments, the test instance identifies the discrepancy between the received automated programming data and the stored programming data. This discrepancy may stem from the fact that a drug identified in the APR is not identified in a currently active first drug library stored in the test instance's memory. In some embodiments, this discrepancy may include the concentration of the received drug being outside the permissible concentration range stored in a drug library for that drug.

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

[0062] In some embodiments, the test instance includes a first pump channel and a second pump channel (e.g., corresponding to the multiple infusion modules 18, 20). The system can identify the first pump channel for receiving the auto-program data and determine that the parameters to be loaded are more aligned with the second pump channel than the first pump channel. In some embodiments, the deviation can include the auto-program data being 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 arises (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) an APR message to the EMR system 202 confirming that the APR message was accepted and processed (e.g., understood). If the parameters (such as concentration or other parameters) are outside of an allowed range (e.g., a clinically defined dose error reduction range), the system can return a misalignment error.

[0064] According to various embodiments, the response from the test instance to the APR (3.8) can include, in addition to the attestation information, information related to the results of the internal processing of the APR by the test instance. The response can 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 can include a test response flag (e.g., a field identifying that the response is a test and not a real patient order; a field identifying that the EMR is not to take formal action on the response). Optionally, the echo test data submitted at the time the test instance was created can be included. Such data allows the test system to include its own metadata to facilitate automated review of the response. The echo test data can be returned as specified. In some embodiments, the echo test data can include some replacement fields (e.g., device ID, timestamp, etc.) to allow custom field formatting of the echo response.

[0065] In some implementations, the test instance can 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 infusion devices that are not configured to be fully automated, such screen captures can be obtained as the clinician progresses through the steps of the manual programming process, e.g., by clicking next on each screen. Some infusion devices can operate in a fully automated test mode, in which the test instance will simulate clicking “next” until the “start” option is provided, each screen is captured and encoded (e.g., as a binary image) and appended to the APR message response sent to the EMR system 202. In some implementations, the APR response can include a user interface walkthrough, which can be stored by the EMR system 202 (e.g., in the database 37) and recalled for review in diagnosing the cause of a misalignment error. As will be further described, the test instance can (additionally or in the alternative) be run in a “virtual mode,” by which all processing is performed by software in a simulated environment.

[0066] The programming response received from the infusion device is stored in the database 37 associated with the record system. In this regard, the record system (or a user accessing the record 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 clinical order device configurations is depicted in accordance with aspects of the subject technology. For purposes of explanation, various blocks of the example process 400 are described herein with reference to Figure 1A 、 Figure 1B 、 Figure 1C and Figure 2 and the associated components and / or processes described herein. One or more of the blocks of the process 400 can be implemented, for example, by one or more computing devices including, for example, the server 30 and / or the medical device 12. In some implementations, one or more of the blocks can be implemented based on one or more machine learning algorithms. In some implementations, one or more of the blocks can be implemented separately from the other blocks, and by one or more different processors or devices. Additionally, to the extent the blocks of the example process 400 are described as occurring serially, or linearly, in some implementations, multiple blocks of the example process 400 can occur in parallel. Moreover, the blocks of the example process 400 need not be performed in the order shown and / or one or more of the blocks of the example process 400 need not be performed.

[0068] In the depicted example, a request for a test pump instance is received by a server (402). In some implementations, the server can comprise one or more components of a pharmacy information system, including the EMR system 202 and / or the prescription set 204. In some implementations, the server comprises the coordination engine 208. In the depicted example, the server (e.g., the coordination engine 208) receives the request and first determines whether a physical infusion device 12 is available (404). For example, the server can maintain or access a queue data store of infusion devices within a hospital network. This data store can be continuously updated to identify which of the infusion devices are currently active (e.g., registered on the network and able to receive communications). In this regard, the server 208 can query the queue data store for an idle infusion device corresponding to the infusion device identified in the request (e.g., including 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 data of the request (406). If the pump is available and configured according to the requested infusion device, then the pump is reserved for an instant scanning and verification procedure. In this regard, the server can lock the pump for server use, preventing it from being used in the clinical environment with a patient until the scanning and verification process is complete. The server can then transmit a response to the requester (e.g., the server requesting) identifying the physical pump (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 coordinating server 208 can create a virtual instance of a pump (410). In this regard, the coordination engine 208 can comprise a software development sandbox in which virtual instances of infusion devices can be modeled and interacted with as if they were real physical devices. The virtual instances can be able to execute the same or similar software utilized by the corresponding physical devices (e.g., in the contained virtual environment) and generate graphical images of their physical user interfaces as if the user was viewing the physical device, including programmed readouts and operational parameter values. For software utilized by infusion devices that provide graphical displays of their entire user interfaces, each display can be captured and returned to the calling server as part of the response.

[0071] The virtual instance can extend (e.g., via a sandbox) the virtual communication interface for communicating with the remote system using a message protocol similar or identical to that of the physical infusion device it models. In this way, the virtual instance is able to receive and process APRs 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 instructs the virtual instance about the infusion of the medication.

[0072] With respect to the identification of the virtual instance, the server (e.g., coordination engine 208) communicates a response (412) identifying the test virtual instance to the pharmacy information system (e.g., EMR system 202). The server (e.g., 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 a physical environment or created virtually, as previously described.

[0073] Figure 5A A first example process 500 for remotely automatically scanning and validating clinical order device configurations is depicted in accordance with aspects of the subject technology. For purposes of illustration, various blocks of the example process 500 are described herein with reference to the Figure 1A Figure 1B Figure 1C Figure 2 Figure 3 Figure 4 and associated components and / or processes described herein. One or more of the blocks of the process 500 can be implemented, for example, by one or more computing devices including, for example, the server 30 and / or the medical device 12. In some implementations, one or more of the blocks can be implemented based on one or more machine learning algorithms. In some implementations, one or more of the blocks can be implemented separately from the other blocks and by one or more different processors or devices. Further for explanatory purposes, to the extent that the blocks of the example process 500 are described as occurring in serial or linear fashion, in some implementations, multiple blocks of the example process 500 can occur in parallel. Additionally, the blocks of the example process 500 need not occur in the order shown, and / or one or more of the blocks of the example process 500 need not occur.

[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 to be sent an automatic programming request (APR) to be communicated to the identified test instance, including validation information for validating clinical order data. The depicted example describes how the test instance processes the request.

[0075] ​​​​​In the depicted example, the APR is received at a test instance (502). In the case that the physical test instance (e.g., a free 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. When the test instance is a virtual instance, the virtual instance extends the virtual communication interface for use in communicating with the server using the same message protocol as the physical infusion device. In this regard, the auto-program command is received and processed in the normal manner to instruct the test instance.

[0076] The test instance receives and begins processing of the APR. In this regard, the test instance (and / or processor or system) determines whether the APR and its contents are compliant (504). This compliance determination can be based on data fields included in the APR (e.g., in the authentication information). For example, the test instance determines whether the information in the APR corresponds to the drug library loaded into the memory of the test instance, and / or whether the information matches or is an acceptable match to the information of the drug library, or whether there is any discrepancy 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 auto-programming the pump with the order alone. If an expected field is omitted, the APR can be determined to be non-compliant. The compliance determination can be based on values included within the data fields of the APR. For example, if a specified value for a parameter is outside of the configured 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 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 within the memory of the pump for the drug. The pump can search based on the name of the drug or based on certain parameters provided in the APR. Determining whether the request is compliant can also include determining whether it is compliant with a protocol that is understandable to the test instance.

[0077] If the information of the APR, such as, for example, the drug concentration or other parameters, is outside of an 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). An misalignment error can also be returned if a parameter, such as a concentration or other parameter, is outside of an allowed range (e.g., a clinically defined dose error reduction range). The error message can then be communicated to the server 30 (508) or can be queued for communication with other messages.

[0078] If the APR is (at least initially) understood, the test instance can (optionally) send an acknowledgement back to the server (510) that the APR is compliant and that the APR will be handled by the test instance. Responsive to determining that the APR is compliant or after determining that the APR is compliant, the test instance can then proceed to configure itself (512) in accordance with the information received in the APR. In this regard, the APR can identify a drug, and the test instance can determine that a drug library loaded into the test instance includes the drug. The test instance can then set operational parameters of the test instance based on 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 a patient using parameters associated with (or indexed by) the information identified in the APR.

[0079] If no errors are generated (e.g., the parameters are 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 prescription set 204). As part of the response, the test instance can generate one or more images (e.g., screen shots) of a graphical user interface that would be presented by the infusion device configured in accordance with the automated programming command (514). As previously described, the APR response can include a step through of the user interface represented by a series of images illustrating what the user interface of the physical infusion device will display during acceptance and configuration of the parameters loaded in response to the APR. In this regard, any errors apparent through the user interface can be captured and communicated in the response for subsequent evaluation of any misalignment errors.

[0080] The test instance, the server hosting the test instance, or a server responsible for communicating with the test instance (e.g., the coordination engine 208) generates a response message including one or more images (516). In addition to any images, as previously described, the response from the test instance to the APR can include information related to the results of the internal processing of the APR by the test instance in addition to the attestation information. The response can 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., an acknowledgement 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 can include the images in binary form). Once the response is generated, the response can be communicated 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., the EMR server or the coordination engine server), determines whether the test instance should be deactivated; e.g., decomposed, deleted, terminated, discarded, and / or removed from memory (518). In some embodiments, the test instance or the server responsible for causing the test instance to be created waits until it specifically receives instructions to deactivate the test instance. In some embodiments, multiple APRs are intended for a single test instance, and the test instance or server can wait until all APRs are received and processed, and then deactivate the test instance. In some embodiments, the server responsible for causing the test instance to be created or initiated can provide an indication to the test instance indicating how many APRs are to be sent, or how many APRs (or a single APR) will be present before the test instance should be deactivated. Additionally, or in the alternative, each APR can indicate its sequence number relative to other APRs specified for the test instance. When the last sequence number is reached, the test instance can be deactivated (520). If the APR (or first instruction) indicates that more APRs are expected, then the test instance can wait to receive the next APR (502).

[0082] Figure 5B An example process flow 501 for remotely automatically scanning and validating clinical order device configuration is depicted in accordance with aspects of the subject technology. For purposes of explanation, various blocks of the example process flow 501 are described herein with reference to Figure 5A and further with reference to Figure 1A , Figure 1B , Figure 1C , Figure 2 , Figure 3 and Figure 4 and 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 or causes to be sent an automated programming request (APR) to be transmitted to the identified test instance. According to various embodiments, the APR can include information for programming the infusion device in accordance with a patient order. In this regard, the order can include or be associated with an identifier and / or name for a medication, a volume to be infused, a medication amount or concentration, a dosage unit, a diluent volume, and other parameters. According to various embodiments, some or all of this information is provided as validation information for validating the clinical order data.

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

[0085] If the APR is (at least initially) understood, the test instance can (optionally) send a confirmation back to the server (510) that the APR is compliant and that the APR will be processed by the test instance. The confirmation message can indicate whether the message is well formatted (e.g., all fields are present, valid, etc.), and / or whether the requested parameters and / or limits are accepted. The confirmation message can include information within the drug library on the (simulated) pump that corresponds to the APR or the information provided with the APR. For example, the confirmation can provide an alias for a drug identified in the APR or an order identified by the APR. Some example message fields and values that can 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 can then store (511) the data in the database 37. In this way, all data for the test can be collected by the database for later retrieval and analysis to determine the degree of misalignment between the EMR and / or the prescription set system deployed into the hospital organization and the drug library (e.g., as simulated by the test instance). In some implementations, the confirmation message(s) can not include data that can be stored, or the message(s) can not be sent or stored at all. In such implementations, the test instance can begin the main processing (512, 514) as described with respect to Figure 5A and the information can be returned (516a) with the data returned in the APR response message as described with respect to Figure 5AThe returned data can include, for example, user interface screenshots and workflow fields and values that would be presented by the actual infusion device during automated programming based on the received APR. The data returned in the APR response message and the captured screenshots can then be stored (517a) in the database 37 for further analysis. Some example message fields and values that can be included in the APR response message 516 are further described in Table 2.

[0089]

[0090] Table 2

[0091] The data fields and values returned with 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 from values sent in the APR. For example, BSA (body surface area) can be calculated based on the weight provided in the APR, or from looking up the patient’s weight 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 calculations based on the APR at the device, and accepted the programming (e.g., without changes). In some embodiments, calculations performed by the test instance can result in termination of the programming, and the test instance will report the reason for 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 concentration provided and the patient’s weight, and the VTBI can exceed the available volume. Thus, the test instance can terminate the infusion and report the error and the calculated parameters, as previously and further described below. The APR response message (516) can also indicate precision misalignment. For example, the message can indicate that the simulated infusion device accepted one decimal point precision when four decimal points were provided (or vice versa), or accepted a subset of a string (e.g., 16 of 18 characters of a patient identifier). Notably, some or all of these calculations can be performed during the misalignment reported in the preliminary processing (504) and confirmation message (510), including, for example, captured screenshots 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 initiate and begin the infusion 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 messages inform the EMR system what was initiated and include certain values that the infusion device is reporting. This information can reflect the APR data and / or can include changes made at the device. The EMR system can wait for the status messages and close the workflow related to the APR upon receiving the messages.

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

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

[0095]

[0096] Table 3

[0097] Each message received from (or sent to) the test instance can include, for example, a unique identifier provided with the original APR. In this regard, all stored data along with the APR can be stored in the database for collective retrieval. After storing the status message data, the EMR can shut down the current APR test. If there are more data sets identified for testing (and / or APRs), the EMR system can repeat (525) the process for each data set to be tested. In this regard, multiple APRs can be launched by the script to test the drug library in the prescription set against the drug library deployed in the field, or to test whether the drug library is suitable for deployment in the field with its data fields conforming to expected data fields based on known prescription set information. Figure 5B

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

[0099] Figure 6A 、 Figure 6B and Figure 6C depicts 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 can be displayed on the display 6a of the 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 by the infusion device for processing, and no misalignment errors are received, the infusion device will display (e.g., on the display 6a) a series of programming confirmation displays in a predetermined workflow. In this manner, the clinician can review only the parameters that were populated by way of the APR into the designated fields, 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 dose units from the drug library stored on the device. In some cases, where the APR includes patient information (e.g., patient identifier), patient parameters such as patient weight can also be loaded and displayed. As depicted, there can be multiple screens of confirmations.

[0101] According to various implementations, a graphical user interface screen can be captured for each step of the procedure associated with the APR. When a physical device is used as the test instance and / or manual confirmation is required, the test instance can capture each screen as it is confirmed by the clinician. In an automated implementation, the test instance can simulate a single click on "next step" (e.g., Figure 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) can be captured. The captured image can then be appended to the APR response and returned to the requesting system, as previously described.

[0102] Figure 6D An example user interface 608 is depicted in which an automated programming request results in an error, in accordance with various aspects of the subject technology. If the APR is well-formed, a confirmation can be sent to the requesting system to indicate that the message was understood. However, as described in this example, the data included in the APR can violate agency rules. In such cases, the test instance can capture an image of the user interface showing 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, one screen can be approved (e.g., Figure 6A ), but subsequent steps can include a violation value. In such cases, the image(s) of the UI prior to the error can be included in the response transmitted by the test instance. The system can simulate acceptance of the error in order to capture all screens to complete the APR programming.

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

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

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

[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 the medication information stored in a prescription set is consistent with the medication information stored in one or more medication libraries configured to be used by infusion devices in a hospital network (e.g., in medication libraries currently deployed or designated for deployment to infusion devices). The pharmacy information system can include a record system such as the prescription set 204 and / or the 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 a known type of infusion device that can store medication libraries designated for verification.

[0107] With further reference to 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 a physical operating environment. A server receiving the identification information (e.g., server 30 including the coordination engine 208) creates and / or maintains a pathway for communicating with the test instance. For example, the server can query a queue data store (e.g., in database 37) of idle infusion devices corresponding to the infusion device identified (e.g., by type, model, capabilities, etc.) in the request. If a matching described idle infusion device is identified within the hospital network, the device can 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 can be locked for use as the test instance, preventing it from being used by a patient until it is released after the procedure.

[0108] In some embodiments, the pharmacy information system utilizes the infusion device to confirm availability of the infusion device. For example, the server can find the device in the queue data store and then query the device location on the network 10 using the device’s identifier 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 a virtual interface for the device so that the requesting server within the pharmacy information system can communicate with the device, including sending APRs to the device and receiving responses.

[0109] If a device is not available, e.g., the device is not free in the queue data store or its availability cannot be confirmed, the server can 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 implementations, the virtual instance will be created without first determining whether a free physical device exists. In some implementations, the server can generate multiple virtual instances, and the queue data store can be used to identify a free virtual instance. The virtual instance can be locked until after the process so that it is prevented from being used by other servers.

[0110] Each virtual instance can extend a virtual communication interface for communicating with remote systems using the message protocol of the infusion device, and for receiving and processing an automatic programming command (APR) that indicates a configuration of the infusion device for an infusion of a medication (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 implementations, the virtual instance can execute the same software that is executed in the corresponding physical device. The pharmacy information system, alone or via the 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 to be available or is virtually generated, an automatic programming command (or APR) is communicated to the identified test instance (706). In some implementations, the APR is communicated by the record system. The APR can be received by the coordination engine 208 before it is communicated to the identified test instance, and the coordination engine 208 can coordinate the communication between the record system and the test instance.

[0112] The automatic programming command can include verification information for verifying clinical order data. The clinical order data can correspond to data stored in the prescription set 204 and / or stored in a 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 align with each other. In this regard, the verification information can directly correspond to information within the prescription set and can 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 the infusion device. For example, the drug library can be stored in database 37 and periodically deployed to the infusion device. The verification information can include and / or identify information in the prescription set 204 that is also expected in the corresponding drug library. Once received by the test instance, the APR (and verification information) causes the test instance to configure by the identified drug library information from the drug library deployed to the test instance. If the verification information sent with the APR matches the drug library information, the configuration will pass. Otherwise, as previously described, the configuration can result in a misalignment error.

[0114] Based on the automatic programming commands 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 of or reference to a graphical user interface that would be presented by the infusion device configured according to the automatic programming commands. According to various embodiments, the programming response identifies one or more discrepancies between the verification information (e.g., based on the prescription set 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 has no control over how the APR is processed. In the case of a virtual instance, the APR is processed as if it was sent to a physical device executing the same software. Thus, in some embodiments, the test instance or coordinating server can receive the image and use optical character recognition to extract text from the image, and then compare the extracted text to the expected test for the clinical order associated with the APR. Based on the comparison, a misalignment error can be identified and the programming response can be updated with the misalignment error along with an identification of the field associated with the error. In some embodiments, the image can be compared to 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 walk-through of multiple screens recreating the infusion device user interface as it would appear if a user were to view the response at the device upon receipt of the APR.

[0116] After the programmed response is generated, the programmed response is provided to the record system for storage (710). The response can be provided by the coordination engine 208 to the EMR system 202. In implementations in which the coordination engine is omitted, the response can be provided directly to the EMR system 202. In some implementations, 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 hyperlinks to extract the images from the second database.

[0117] Many of the above-described example processes 400, 500, and 700, and related features and applications, can also be implemented as software processes that are specified as a set of instructions that are recorded on a computer readable storage medium (also referred to as computer readable medium), and that are executable by a processing unit (e.g., one or more processors, a processor core of a processor, or other processing units). When these instructions are executed by one or more processing unit(s), they cause the processing unit(s) 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 over wired or wireless communication links.

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

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

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

[0121] Electronic system 800 can include various types of computer-readable media and interfaces for various other types of computer-readable media. In the depicted example, electronic system 800 includes a bus 808, processing unit(s) 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 implementations, electronic system 800 can include or be integrated with other computing devices or circuitry for operating the various components and methods previously described.

[0122] ​The bus 808 collectively represents all system, peripheral and chipset buses that communicatively connect the various internal devices of the electronic system 800. For instance, the bus 808 communicatively connects the (one or more) processing unit(s) 812 with the ROM 810, the system memory 804, and the persistent storage device 802.

[0123] From these various memory units, the (one or more) processing units 812 retrieve instructions to execute (e.g., whether those instructions are executed from a non-transitory medium or received from a communications interface) and data to process in order to execute the processes of the subject disclosure. The (one or more) processing units can be single-core or multi-core processors.

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

[0125] Other embodiments use a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) as the permanent storage device 802. Like the permanent storage device 802, the system memory 804 is a read-and-write memory device. However, unlike the permanent storage device 802, the system memory 804 is a volatile read-and-write memory, such as a random access memory. The system memory 804 stores some of the instructions and data that the processor needs at runtime. In some embodiments, the processes of the subject disclosure are stored in the system memory 804, the permanent storage device 802, and / or the ROM 810. From these various memory units, the (one or more) processing units 812 retrieve instructions to execute and data to process in order to execute the processes of some embodiments.

[0126] The bus 408 also connects to the input and output device interfaces 814 and 806. The input device interface 814 enables the user to communicate information and select commands to the electronic system. Input devices used with the input device interface 814 include, for example, alphanumeric keyboards and the pointing devices (also called “cursor control devices”). 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, printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some embodiments include devices such as a touchscreen that functions as both input and output devices.

[0127] Furthermore, as Figure 8As shown, bus 808 also couples electronic system 800 to a network (not shown) through network interface 816. Network interface 816 can include, for example, a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. Network interface 816 can also include hardware (e.g., Ethernet hardware) for connecting the computer to a network, such as the Internet, in a portion of one or more networks, such as a local area network (“LAN”), a wide area network (“WAN”), a wireless LAN, or an intranet. Any or all components of electronic system 800 can be used in conjunction with the subject disclosure.

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

[0129] Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine -readable or computer-readable medium (also referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-level DVD-ROM), a variety of recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and / or solid-state hard drives, only read and recordable Blu-ray® discs, any other optical or magnetic media, and floppy disks. Computer-readable media can store computer programs, which are executable by at least one processing unit and include sets 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 are executed by a computer, an electronic component, or a microprocessor using an interpreter.

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

[0131] As used in the specification and any claims, the terms “computer,” “server,” “processor,” and “memory” all refer to electronic or other technological devices. These terms do not encompass humans or groups of humans. For the purposes of the specification, the term display or being displayed means display on an electronic device. As used in the specification and any claims, the terms “computer-readable medium” and “computer-readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

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

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

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

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

[0136] It can be appreciated that the specific order or hierarchy of steps in the processes disclosed are illustrations. Based upon design choices, the specific order or hierarchy of steps in the processes can be re-arranged, or omitted. Some steps can be performed at the same time. The accompanying method claims present elements of the various steps in the order in which they are presented in the examples, and are not meant to be limited to the specific order or hierarchy presented.

[0137] The subject technology is illustrated as clauses:

[0138] For convenience, the various examples of aspects of the disclosure have been described as numbered clauses (1, 2, 3, etc.). These are provided for ease of reference and do not limit the subject technology. The clauses are not mutually exclusive combinations of features. Formulation of clauses as paragraphs of claim does not imply that the clauses are mutually exclusive.

[0139] Clause 1. A system for remotely scanning and validating clinical order device configurations, 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 a test instance to be created based on the request; cause an auto-programming command to be transmitted to the identified test instance, the auto-programming command comprising validation information for validating clinical order data; generate a programming response comprising an image or a reference to an image of a graphical user interface that would be presented by the infusion device configured according to the validation information based on the auto-programming command transmitted to the test instance; and provide the programming response for storage in a records system.

[0140] Clause 2. The system of clause 1, wherein the auto-programming command is received from the records system prior to being transmitted to the identified test instance.

[0141] Clause 3. The system of clause 1 or clause 2, wherein the instructions further cause the system to: transmit an identifier of the test instance to the records system.

[0142] Clause 4. The system of any of clauses 1-3, wherein causing the test instance to be created and identified comprises the system being caused to: identify the 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 auto-programming command is transmitted to the infusion device via the interface.

[0143] Clause 5. The system of clause 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 of idle infusion devices corresponding to the infusion device.

[0144] Clause 6. The system of any of clauses 1-3, wherein causing the test instance to be created comprises the system being caused to: query a queue data store of idle infusion devices corresponding to the infusion device; determine that an 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 of clauses 1-6, wherein the validation information identifies drug library information stored in a drug library configured for deployment by the infusion device; and wherein the instructions cause the auto-programming command to be transmitted to the identified test instance comprises: the auto-programming command causing the test instance to be configured by the identified drug library information deployed to the test instance from the drug library.

[0146] Clause 8. The system of clause 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 for the infusion device and for receiving and processing automated programming commands, wherein the test instance comprises the virtual instance, and wherein the automated programming commands are communicated to the virtual instance via the virtual communication interface.

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

[0148] Clause 10. The system of any of clauses 1-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 of clauses 1-10, wherein the programming response identifies one or more discrepancies between data stored in the pharmacy system and programming data stored within a drug library used by the test instance.

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

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

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

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

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

[0155] Clause 17. The method of any of clauses 12-16, wherein the automatic programming command comprises identifying verification information of drug library information stored in a drug library, the drug library 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 to the test instance from the drug library.

[0156] Clause 18. The method of any of clauses 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 comprises the virtual instance, and wherein the automatic programming command is communicated to the virtual instance via the virtual communication interface.

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

[0158] Clause 20. The method of any of clauses 12-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 automatic 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 that, when executed by a processor, cause an infusion device to implement the method of any of clauses 12-20.

[0160] Further considerations:

[0161] It can be appreciated that the particular order or hierarchy of steps in the processes disclosed is an example. Based upon design preferences, it can be appreciated that the specific order or hierarchy of steps in the processes can be rearranged. Some of the steps can be performed at the same time. The accompanying method claims present elements of the various steps in the 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 descriptions provide various examples of the subject technology and are not intended in any way to limit the scope of the subject technology. Various modifications will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language claims, wherein reference to an item means at least one, unless otherwise indicated. The use of the negative term “does not” or “does not” does not mean “zero” unless otherwise indicated. The term “some” refers to one or more unless otherwise indicated. Male pronouns include female and neutral genders (e.g., his and her and its), and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the inventions described herein.

[0163] The verbs “configured to,” “operable to,” and “programmed to” do not imply any particular tangible or intangible modification of a subject, but, rather, are intended to be synonymous with the verbs “serving the purpose,” “operable to serve the purpose,” and “programmed to serve the purpose” respectively. For example, a processor configured to monitor and control operations or a component can also mean the processor being programmed to monitor and control operations or the processor being operable to monitor and control operations. Likewise, a processor configured to execute code can be interpreted to mean a processor programmed to execute code or a processor operable to execute code.

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

[0165] Phrases such as “aspect” do not imply that a particular aspect is critical, essential, or mandatory to the subject technology, or that the aspects applying to all configurations of the subject technology. Disclosures relating to an aspect can apply to all configurations, or one or more configurations. An aspect can provide one or more examples. Phrases such as “aspect” can refer to one or more aspects, and vice versa. Phrases such as “embodiment” do not imply that a particular embodiment is critical, essential, or mandatory to the subject technology, or that the embodiment applies to all configurations of the subject technology. Disclosures relating to an embodiment can apply to all embodiments, or one or more embodiments. An embodiment can provide one or more examples. Phrases such as “embodiment” can refer to one or more embodiments, and vice versa. Phrases such as “configuration” do not imply that a particular configuration is critical, essential, or mandatory to the subject technology, or that the configuration applies to all configurations of the subject technology. Disclosures relating to a configuration can apply to all configurations, or one or more configurations. A configuration can provide one or more examples. Phrases such as “configuration” 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) can refer to a web-based interface including data fields and / or other control elements for receiving input signals or providing electronic information and / or for providing information to a user in response to any received input signals. Control elements can 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 of the device presenting the UI. The UI can be implemented using technologies such as HyperText Markup Language (HTML), FLASH TM , JAVA TM ,.NET TM , C, C++, web services, or Rich Site Summary (RSS), in whole or in part. In some embodiments, the UI can be included in a standalone client (e.g., thick client, fat client) configured to communicate (e.g., send or receive data) in accordance with one or more aspects described. The communication can be to or from a medical device or server in communication therewith.

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

[0168] As used herein, the term “provide” or “provide” encompasses a wide variety of actions. For example, “providing” can include storing a value at a location on a storage device for later retrieval, 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” can also include encoding, decoding, encrypting, decrypting, verifying, authenticating, etc., via hardware components.

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

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

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

[0172] In any embodiment, 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, a remote location can be another location (e.g., office, laboratory, etc.) in the same city, another location in a different city, another location in a different state, another location in a different country, etc. Thus, when one item is indicated as being "remote" from another item, this 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. To "communicate" information is to transmit the data representing that information as an electrical, electromagnetic, or optical signal via a suitable communication channel (e.g., dedicated or public network). To "forward" an item is to transport the item from one location to the next in any manner, whether by physically transporting the item or otherwise (where possible), including, in the case of data, at least physically transporting a medium carrying the data or communicating the data, where possible. Examples of communication media include radio or infrared transmission channels as well as a network connection to another computer or networking device, as well as the Internet, or include electronic mail transmission and information recorded on websites etc.

Claims

1. A system for remotely scanning and validating clinical order device configurations, 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 to validate clinical order data; based on the request, determine that an idle infusion device is not available for validating the clinical order data; in response to the idle infusion device being unavailable, instantiate a virtual infusion device as the test instance based at least in part on the request, wherein the virtual infusion device extends a virtual communication interface for communicating with external systems using a message protocol similar or identical to a physical infusion device it models, and is configured to process automated programming commands in the same manner as the physical infusion device it models; cause automated programming commands to be communicated to the virtual infusion device using the message protocol, the automated programming commands including validation information for validating the clinical order data; based on the automated programming commands communicated to the virtual infusion device, receive a programming response from the virtual infusion device including an image of a graphical user interface or a reference to the image, the graphical user interface generated by the virtual infusion device and that would be presented by the physical infusion device it models when configured according to the validation information for validating the clinical order data, wherein the programming response indicates that a fault has occurred and the image visually identifies an error indicating the fault as it would be presented by the physical infusion device; provide the programming response for storage in a record system; provide a user interface including results of one or more automated programming command faults including the fault indicated by the programming response for display to a user; in response to a user selection of the programming response, provide the image visually identifying the error for display to the user in relation to access to editable input fields for correcting the fault; receive a correction to the fault via the input fields and utilize the correction to update a drug library or medication database to eliminate a misalignment of data that would otherwise cause an infusion device to stop using for manual correction by a clinician or technician.

2. The system of claim 1, wherein, the automated programming commands are received from the record system prior to being communicated to the virtual infusion device.

3. The system of claim 1 or claim 2, wherein, the instructions further cause the system to: communicate an identifier of the virtual infusion device to the record system.

4. The system of claim 1 or claim 2, wherein, the drug library is updated with the correction, and wherein the instructions further cause the system to: receive a designation of the updated drug library in relation to the correction for deployment to one or more corresponding devices employing a drug library associated with the fault via a network; and cause deployment of the updated drug library.

5. The system of claim 4, wherein, the instructions further cause the system to: query a queue data store of the idle infusion device.

6. The system of claim 1 or claim 2, wherein the validation information identifies drug library information stored in a drug library configured for deployment by the infusion device; and the record system is a record system of a plurality of record systems, each record system of the plurality of record systems being associated with a different infusion device of a plurality of infusion devices. wherein the instructions cause the automatic programming commands to be transmitted to the virtual infusion device include the automatic programming commands causing the virtual infusion device to be configured by the identified drug library information deployed from the drug library to the test instance.

7. The system of claim 1, wherein, The instructions further cause the system to: format the programming response for the recordation system.

8. The system of claim 7, wherein, The instructions further cause the system to: extract text from the image using optical character recognition; and compare the extracted text to expected text for a clinical order associated with the automatic programming commands, wherein formatting the programming response includes updating the programming response to include a result of the comparison.

9. The system of claim 1 or claim 2, wherein, The programming response identifies one or more discrepancies between data stored in a pharmacy system and programming data stored within a drug library used by the virtual infusion device.

10. A method for remotely scanning and validating clinical order device configuration, comprising: transmitting, to a server, a request for a test instance of an infusion device to validate clinical order data; based on the request, determining that an idle infusion device is not available for validating the clinical order data; in response to the idle infusion device being unavailable, instantiating a virtual infusion device as the test instance based at least in part on the request, wherein the virtual infusion device extends a virtual communication interface for communicating with external systems using a message protocol similar or identical to a physical infusion device it models, and is configured to process automatic programming commands in the same manner as the physical infusion device it models; identifying clinical order data associated with a medication; causing automatic programming commands to be transmitted to the virtual infusion device using the message protocol to validate the identified clinical order data, the automatic programming commands including validation information for validating the clinical order data; based on the automatic programming commands transmitted to the virtual infusion device, receiving a programming response comprising an image of a graphical user interface or a reference to the image, the graphical user interface generated by the virtual infusion device and that would be presented by the physical infusion device it models when configured according to the validation information for validating the clinical order data, wherein the programming response indicates that a fault has occurred and the image visually identifies an error indicating the fault as it would be presented by the physical infusion device; providing the programming response for storage in a recordation system; providing a user interface comprising a result of one or more automatic programming command faults including the fault indicated by the programming response for display to a user; in response to a user selection of the programming response, providing the image visually identifying the error for display to the user in relation to access to editable input fields for correcting the fault; receiving a correction to the fault via the input fields and utilizing the correction to update a drug library or medication database to eliminate misalignment of data that would otherwise cause an infusion device to stop using for manual correction by a clinician or technician.

11. The method of claim 10, further comprising: performing image analysis of the image, the image analysis including comparing the image to a reference image associated with a clinical order to determine whether the image corresponds to the reference image; and identifying the error in the clinical order data based on whether the image corresponds to the reference image.

12. The method of claim 10 or claim 11, further comprising: identifying the infusion device in a physical operating environment prior to transmitting the request.

13. The method of claim 10 or claim 11, wherein, the medication library is updated with the correction, the method further comprising: receiving, in association with the correction, a designation of the updated medication library for deployment to one or more corresponding devices that employ the medication library associated with the malfunction via a network; and causing deployment of the updated medication library.

14. The method of claim 10 or claim 11, wherein, the automatic programming command includes validation information that identifies medication library information stored in a medication library that is configured for deployment by the infusion device, the method further comprising: the automatic programming command causes the virtual infusion device to be configured by the identified medication library information deployed to the test instance from a medication library.

15. The method of claim 10 or claim 11, 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 automatic programming request; and formatting the programming response by updating the programming response to include a result of the comparison.

16. A non-transitory computer readable medium comprising instructions that, when executed by a processor, cause an infusion device to perform the method of any one of claims 10 to 15.

Images