Computer-based methods, systems, and devices for electronic patient care.

Abstract

This invention provides a medical error reduction system (DERS) and method for electronic patient care. [Solution] DERS allows a user who is the administrator of the DERS Editor Service to log in to the DERS hosting environment, log in to the DERS database within the DERS host environment, and execute a database update script in the DERS database. The update script can update the DERS lookup tables in the DERS database and can update the DERS lookup tables used by all institutions or organizations using the DERS Editor Service. DERS also allows the user to verify that the database update script is correct and load an instance of the DERS Inspection Agency, which the user can use to verify whether the updated lookup tables in the DERS database are correct.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 61 / 740,474, filed on December 21, 2012, entitled "System, Method, and Apparatus for Communicating Data" (Attorney Docket No. J80), which is hereby incorporated by reference in its entirety. This application is also a partial continuation of U.S. Patent Application No. 13 / 723,253, filed on December 21, 2012, entitled "System, Method, and Apparatus for Electronic Patient Care", now published as U.S. Patent Application Publication No. 2013 - 0191413(A1) on July 25, 2013 (Attorney Docket No. J85), and U.S. Patent Application No. 13 / 723,253 claims priority and benefit to the following. U.S. Provisional Patent Application No. 61 / 578,649, filed on December 21, 2011, entitled "System, Method, and Apparatus for Infusing Fluid" (Attorney Docket No. J02), U.S. Provisional Patent Application No. 61 / 578,658, filed on December 21, 2011, entitled "System, Method, and Apparatus for Estimating Liquid Delivery" (Attorney Docket No. J04), U.S. Provisional Patent Application No. 61 / 578,674, filed on December 21, 2011, entitled "System, Method, and Apparatus for Dispensing Oral Medications" (Attorney Docket No. J05), U.S. Provisional Patent Application No. 61 / 651,322, filed on May 24, 2012, entitled "System, Method, and Apparatus for Electronic Patient Care" (Attorney Docket No. J46), and U.S. Provisional Patent Application No. 61 / 679,117, filed on August 3, 2012, with the title "System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow" (Agent Reference Number J30). These applications are all incorporated herein by reference. U.S. Patent Application No. 13 / 723,253 is a derivative of U.S. Patent Application No. 13 / 333,574, filed on December 21, 2011, with the title of the invention "System, Method, and Apparatus for Electronic Patient Care," and is currently published on July 19, 2012, U.S. Patent Application Publication No. US-2012-0185267(A1), (Agent Reference Number I97), and This is a continuation-of-part application of PCT application PCT / US11 / 66588, titled "System, Method, and Apparatus for Electronic Patient Care" (Agent Reference Number I97WO), filed on 21 December 2011, and both applications are incorporated herein by reference in their entirety. U.S. Patent Application No. 13 / 333,574 is a continuation-in-part application of U.S. Patent Application No. 13 / 011,543, titled “Electronic Patient Monitoring System,” filed on 21 January 2011, and currently published on 22 December 2011, U.S. Patent Publication No. US-2011-0313789(A1) (Agent Reference Number I52). U.S. Patent Application No. 13 / 011,543 claims priority over U.S. Provisional Patent Application No. 61 / 297,544, titled “Electronic Order Intermediation System for a Medical Facility” (Agent Reference Number H53), filed on 22 January 2010. Both applications are incorporated herein by reference. This application is a continuation of U.S. Patent Application No. 13 / 723,239, titled "System, Method, and Apparatus for Electronic Patient Care," filed on 21 December 2012, and currently U.S. Patent Application Publication No. US-2013-0297330(A1) (Agent Reference Number J77), published on 7 November 2013, and claims priority and interest in the following: U.S. Provisional Patent Application No. 61 / 578,649, filed on December 21, 2011, with the title of the invention "System, Method, and Apparatus for Infusing Fluid" (Agent Reference Number J02), U.S. Provisional Patent Application No. 61 / 578,658, filed on December 21, 2011, with the title of the invention "System, Method, and Apparatus for Estimating Liquid Delivery" (Agent Reference Number J04), U.S. Provisional Patent Application No. 61 / 578,674, filed on December 21, 2011, with the title of the invention "System, Method, and Apparatus for Dispensing Oral Medications" (Agent Reference Number J05), U.S. Provisional Patent Application No. 61 / 651,322, filed on May 24, 2012, with the title of the invention "System, Method, and Apparatus for Electronic Patient Care" (Agent Reference Number J46), and U.S. Provisional Patent Application No. 61 / 679,117, filed on August 3, 2012, with the title "System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow" (Agent Reference Number J30). All applications are incorporated herein by reference. U.S. Patent Application No. 13 / 723,239 claims priority and interest in the following, and is also a continuation-in-part application: U.S. Patent Application No. 13 / 011,543, filed on January 21, 2011, with the title "Electronic Patient Monitoring System," is a continuation application of U.S. Patent Application Publication No. US-2011-0313789(A1) (Agent Reference Number I52), published on December 22, 2011. U.S. Patent Application No. 13 / 011,543 claims priority over U.S. Provisional Patent Application No. 61 / 297,544, filed on January 22, 2010, with the title "Electronic Order Intermediation System for a Medical Facility" (Agent Reference Number H53), filed on December 21, 2011, with the title "System, Method, and Apparatus for Electronic Patient Monitoring System." "Care," currently U.S. Patent Application Publication No. US-2012-0185267(A1) (Agent Reference Number I97), published on July 19, 2012, and PCT application PCT / US11 / 66588, filed on December 21, 2011, with the title of the invention "System, Method, and Apparatus for Electronic Patient Care," is currently published as international patent application WO2013 / 095459 (agent reference number I97WO) on September 12, 2013. All applications are incorporated herein by reference. This application is a continuation of U.S. Patent Application No. 13 / 723,242, filed on December 21, 2012, with the title of the invention "System, Method, and Apparatus for Electronic Patient Care," and is currently a continuation of U.S. Patent Application Publication No. US-2013-0317753(A1) (Agent Reference Number J78), published on November 28, 2013. U.S. Patent Application No. 13 / 723,242 is, We claim priority and interest in U.S. Provisional Patent Application No. 61 / 651,322, titled "System, Method, and Apparatus for Electronic Patient Care" (Agent Reference Number J46), filed on 24 May 2012, which is incorporated herein by reference in its entirety. This application is a continuation of U.S. Patent Application No. 13 / 900,655, titled "System, Method, and Apparatus for Electronic Patient Care," filed on 23 May 2013, and currently published on 28 November 2013, U.S. Patent Application Publication No. US-2013-0317837(A1) (Agent Reference Number K66). U.S. Patent Application No. 13 / 900,655 claims priority and benefit over U.S. Provisional Patent Application No. 61 / 651,322, titled "System, Method, and Apparatus for Electronic Patient Care" (Agent Reference Number J46), filed on 24 May 2012, and both applications are incorporated herein by reference. U.S. Patent Application No. 13 / 900,655 is also a continuation-in-part application claiming priority and interest in the following: U.S. Patent Application No. 13 / 480,444, filed on May 24, 2012, with the title of the invention "Blood Treatment Systems and Methods," currently published on February 14, 2013, U.S. Patent Application Publication No. US-2013-0037485(A1) (Agent Reference Number J43), and PCT application no. PCT / US12 / 00257, filed on May 24, 2012, with the title of the invention "Blood Treatment Systems and Methods," is currently published as international patent application publication no. WO / 2012 / 161744 (agent reference number J43WO) on November 29, 2012. This application is a continuation of PCT application PCT / US13 / 42350, titled "System, Method, and Apparatus for Electronic Patient Care" (Agent reference number K66WO), filed on 23 May 2013, which claims priority and benefit over U.S. Provisional Patent Application 61 / 651,322, titled "System, Method, and Apparatus for Electronic Patient Care" (Agent reference number J46), filed on 24 May 2012, and both applications are incorporated herein by reference in their entirety. PCT application PCT / US13 / 42350 is also a continuation-in-part application claiming priority and interest in the following: U.S. Patent Application No. 13 / 480,444, filed on May 24, 2012, with the title of the invention "Blood Treatment Systems and Methods," currently published on February 14, 2013, U.S. Patent Application Publication No. US-2013-0037485(A1) (Agent Reference Number J43), and PCT application no. PCT / US12 / 00257, filed on May 24, 2012, with the title of the invention "Blood Treatment Systems and Methods," is currently published as international patent application publication no. WO / 2012 / 161744 (agent reference number J43WO) on November 29, 2012. This application may also relate to one or more of the following patent applications filed on December 21, 2012, all of which are incorporated herein by reference. Regular application for "System, Method, and Apparatus for Clamping" (Agent reference number J47), No. 13 / 723,238. Regular application for "System, Method, and Apparatus for Dispensing Oral Medications" (Agent reference number J74), No. 13 / 723,235, PCT application for "System, Method, and Apparatus for Dispensing Oral Medications" (Agent reference number J74WO), PCT / US12 / 71131. Regular application for "System, Method, and Apparatus for Estimating Liquid Delivery" (Agent reference number J75), No. 13 / 724,568. Regular application for "System, Method, and Apparatus for Infusing Fluid" (Agent reference number J76), No. 13 / 725,790. PCT application for "System, Method, and Apparatus for Infusing Fluid" (Agent reference number J76WO), PCT / US12 / 71490. Regular application for "System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow" (Agent reference number J79), No. 13 / 723,244. PCT application for "System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow" (Agent reference number J79WO), PCT / US12 / 71142. Regular application for "System, Method, and Apparatus for Estimating Liquid Delivery" (Agent reference number J81), No. 13 / 723,251, and PCT application for "System, Method, and Apparatus for Estimating Liquid Delivery" (Agent reference number J81WO), PCT / US12 / 71112. This application may also relate to one or more of the following patent applications, all of which are incorporated herein by reference. U.S. Provisional Patent Application No. 61 / 738,447, filed on December 18, 2012, with the title of the invention "System, Method, and Apparatus for Detecting Air in a Fluid Line Using Active Rectification" (Agent Reference Number J32). U.S. Patent Application No. 13 / 840,339, filed on March 15, 2013, with the title of the invention "Apparatus for Infusing Fluid" (Agent Reference Number K14), PCT application PCT / US13 / 32445, filed on March 15, 2013, with the title of the invention "Apparatus for Infusing Fluid" (agent reference number K14WO), U.S. Patent Application No. 13 / 833,432, filed on March 15, 2013, with the title of the invention "Syringe Pump and Related Method" (Agent Reference Number K21), U.S. Patent Application No. 13 / 836,497, filed on March 15, 2013, title of invention "System and Apparatus for Electronic Patient Care" (Agent Reference Number K22), U.S. Patent Application No. 13 / 833,712, filed on March 15, 2013, title of invention "System, Method, and Apparatus for Clamping" (Agent Reference Number K23), U.S. Patent Application No. 13 / 834,030, filed on March 15, 2013, with the title "System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow" (Agent Reference Number K28), U.S. Provisional Patent Application No. 61 / 860,398, filed on July 31, 2013, with the title of the invention "System, Method, and Apparatus for Bubble Detection in a Fluid Line Using a Split-Ring Resonator" (Agent Reference Number J31), U.S. Provisional Patent Application No. 61 / 900,431, filed on November 6, 2013, with the title of the invention "System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow" (Agent Reference Number K52), U.S. Provisional Patent Application No. 61 / 894,801, filed on October 23, 2013, with the title of the invention "Syringe Pump and Related Method" (Agent Reference Number K88), U.S. Provisional Patent Application No. 61 / 843,574, filed on July 8, 2013, with the title of the invention "System, Method, and Apparatus for Clamping" (Agent Reference Number K75), U.S. Patent Application No. 13 / 971,258, filed on August 20, 2013, with the title of the invention "Electronic Patient Monitoring System" (Agent Reference Number K84), U.S. Provisional Patent Application No. 61 / 904,123, filed on November 14, 2013, with the title of the invention "Syringe Pump and Related Method" (Agent Reference Number L33), U.S. Patent Application No. 14 / 101,848, filed on December 10, 2013, with the title "System, Method, and Apparatus for Detecting Air in a Fluid Line Using Active Rectification" (Agent Reference Number L05), The U.S. patent application for "System, Method, and Apparatus for Communicating Data" (agent reference number L49), filed on December 20, 2013, A PCT application for "System, Method, and Apparatus for Communicating Data" (agent reference number L49WO) was filed on December 20, 2013. The U.S. patent application for "Computer-Implemented Method, System, and Apparatus for Electronic Patient Care" (Agent Reference Number K50), filed on December 20, 2013, The U.S. patent application for "System, Method, and Apparatus for Electronic Patient Care" filed on December 20, 2013 (agency reference number L52), and A PCT application for "System, Method, and Apparatus for Electronic Patient Care" (agent reference number L52WO) was filed on December 20, 2013.

[0002] This disclosure relates to patient care. More specifically, this disclosure relates to electronic patient care systems and devices. [Background technology]

[0003] Nursing care for patients often involves directly administering fluids, such as medications, to them. This can be achieved using gravity-feed tubes connected to liquid containers (e.g., IV bags). Fluids and medications may also be administered via forced infusion. Administering fluids and medications to patients often requires communication among multiple parties (e.g., doctors, nurses, pharmacists). Such communication is prone to miscommunication, errors, or other incidents that may result in the patient receiving the wrong amount of fluid. [Overview of the project] [Means for solving the problem]

[0004] According to exemplary embodiments of the present disclosure relating to electronic patient care, a medical error reduction system includes medical error reduction software used in creating and revising at least one drug library configured for use in at least one medical device. The software is configured to provide a set of privileges to a set of users, the set of privileges assigning a certain degree of software functionality to the set of users, the certain degree of software functionality defining the ability of users to modify at least one drug library. The medical error reduction system also includes at least one server and at least one editor computer, the editor computer being in communication with the server over a network and comprising a processor being in communication with a display.

[0005] According to one embodiment of the present disclosure, a medical error reduction system may include medical error reduction software used in creating and revising at least one drug library. The software may be configured to provide one of several sets of privileges to each of several sets of users. Each of the sets of privileges may be configured to assign a certain degree of software functionality to one of the several sets of users. The certain degree of software functionality may be configured to define the ability of a user to modify at least one drug library. The medical error reduction system may include at least one server. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a display and a processor in a communication state. The at least one editor computer and at least one server may be configured to communicate over a network in a client / server model. Each of the at least one drug library may be used in at least one medical device.

[0006] In some embodiments of the above system, at least one drug library may be organized into a hierarchy. In some embodiments, the hierarchy may include multiple nursing areas under at least one nursing group. In some embodiments, each level of the hierarchy may include several delivery parameters for at least one medical device. In some embodiments, each of the at least one drug library may include multiple entries, each corresponding to a specific drug. In some embodiments, at least one drug library may include several parameters that indicate the operation of at least one medical device. In some embodiments, the drug library may include multiple programming limit values ​​for at least one medical device. In some embodiments, the medical error reduction software may further be configured to provide quality improvement information to the user. In some embodiments, at least one of a set of privileges may assign the privilege to one of a set of users to inspect the drug library. In some embodiments, at least one of a set of privileges may assign the privilege to one of a set of users to edit the drug library. In some embodiments, at least one of a set of privileges may assign the privilege to one of a set of users to edit or create a privilege set. In some embodiments, at least one of several sets of privileges can assign user-additional privileges to one of several sets of users. In some embodiments, several sets of privileges assigned to each of several sets of users can enforce a collaborative process among the sets of users to create and revise at least one drug library.

[0007] According to one embodiment of the present disclosure, a medical error reduction system can include at least one server. The medical error reduction system can include at least one editor computer. Each of the at least one editor computers can include a processor in communication with a display. The at least one editor computer and the at least one server may be configured to communicate via a network in a client / server model. The medical error reduction system can include medical error reduction software configured to be executed by the at least one server. The medical error reduction software can be accessed via the at least one editor computer for use in creating and revising at least one drug library. Each of the at least one drug libraries can be used in at least one medical device. Each of the at least one medical devices can include a medical device processor and a medical device graphical user interface configured to display a user interface. The user interface can communicate information and can be used to program each respective medical device. Each of the at least one drug libraries can include a plurality of entries to guide a user in programming the at least one medical device. The medical error reduction software may be configured to display a simulated medical device graphical user interface. The simulated medical device graphical user interface can mimic the behavior of the medical device graphical user interface of a medical device using a drug library selected from the at least one drug library.

[0008] In some embodiments, the simulated medical device graphical user interface is context-sensitive. In some embodiments, the medical error reduction software may include several privilege sets. Each privilege set can be assigned to one of several user sets. Each of several privilege sets may assign a certain degree of software functionality to each of the several user sets. In some embodiments, the simulated medical device graphical user interface may be a software function that can toggle several privilege sets on or off. In some embodiments, each of at least one drug library may be organized hierarchically. In some embodiments, the hierarchy may include several nursing areas under at least one nursing group. In some embodiments, each level of the hierarchy may include several fluid delivery parameters for at least one medical device. In some embodiments, each of at least one drug library may include several entries, each corresponding to a specific drug. In some embodiments, at least one drug library may include several parameters that indicate the operation of at least one medical device. In some embodiments, the drug library may include several programming limit values ​​for at least one medical device. In some embodiments, the medical error reduction software may further be configured to provide quality improvement information to the user.

[0009] According to another embodiment of the present disclosure, a medical device for delivering a pharmaceutical to a patient can include a controller configured to control the operation of a pump mechanism for delivering the pharmaceutical. The medical device can include a display. The medical device can include a computer-readable memory configured to store program code for a drug library. The drug library can include a plurality of entries. The plurality of entries can include at least one entry corresponding to a portion of a facility. There may be at least one drug entry for each such entry. Each of the at least one drug entries may be associated with parameters. At least one drug entry in the drug library may be associated with a broad drug category rather than being associated with a specific drug. The medical device can include a processor configured to display a graphical user interface on the display of the medical device. The graphical user interface can be used by a user to program the controller using the drug library.

[0010] In some embodiments, a user can program the delivery of a drug to a patient by selecting one of at least one drug entries in a drug library that are associated with a broad drug category rather than a specific drug. In some embodiments, at least one drug entry in a drug library that are associated with a broad drug category rather than a specific drug may be associated with at least one parameter that governs the delivery of the drug. In some embodiments, the drug library may be created or modified using medical error reduction software. In some embodiments, the display may be a touchscreen display. In some embodiments, at least one of the at least one drug entries in a drug library that are associated with a broad drug category rather than a specific drug may allow a user to program the medical device to deliver the drug in a per-hour rate mode. In some embodiments, multiple entries may each be associated with at least one parameter. In some embodiments, at least one of the at least one parameters can be a drug delivery parameter.

[0011] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may include multiple entries. Each of the at least one drug library may be used in at least one medical device. The software may be configured to provide one of a set of privileges to each of a set of users. Each of the set of privileges may be configured to allocate a certain degree of software functionality to one of the set of users. The medical error reduction system may include at least one server. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The at least one editor computer and the at least one server may be configured to communicate over a network in a client / server model. At least one of the set of users may use the software to request that at least a portion of at least one drug library be modified.

[0012] In some embodiments, at least one of a set of privileges may be configured to allow a user to reject the implementation of a change. In some embodiments, at least one of a set of privileges may be configured to allow a user to accept the implementation of a change. In some embodiments, at least one of a set of privileges may be configured to allow a user to submit a query about a change. In some embodiments, at least one of a set of privileges may be configured to allow a user to propose revisions to a change. In some embodiments, the server may be configured to run medical error reduction software. In some embodiments, certain software functions may be configured to define a user's ability to modify at least one drug library. In some embodiments, at least one medical device may be an infusion pump.

[0013] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library may be used in at least one medical device. A medical error reduction system may include at least one server configured to run medical error reduction software. The medical error reduction system may also include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface can be used by one or more users to edit at least one drug library. The at least one editor computer and the at least one server may be configured to communicate over a network. At least one of the one or more users may request changes to at least one drug library by submitting an electronic change request.

[0014] In some embodiments, at least one medical device may be an infusion pump. In some embodiments, electronic change requests can be linked to medical data. In some embodiments, medical data can be stored in an electronic database to provide contextual information. In some embodiments, the electronic database can reside in a host environment. In some embodiments, medical data may be generated from at least one medical device. In some embodiments, medical data may be stored in an electronic database. In some embodiments, medical data may be associated with one of at least one drug libraries used by the at least one medical device that generated the medical data. In some embodiments, medical data may be displayed in tabular form. In some embodiments, medical data may be displayed in chart form. In some embodiments, medical data may be displayed in graph form. In some embodiments, medical data may be displayed in diagram form. In some embodiments, medical data may be displayed in the form of infusion cases. In some embodiments, users can search for medical data using drug library editing software. In some embodiments, users can filter medical data using drug library editing software. In some embodiments, medical data may be displayed in a user-selectable format. In some embodiments, users can access only medical data corresponding to one version of one of the at least one libraries currently being edited. In some embodiments, multiple entries may each be associated with one or more infusion parameters. In some embodiments, at least one of one or more users may accept an electronic change request. In some embodiments, at least one of one or more users may respond to an electronic change request. In some embodiments, at least one of one or more users may propose modifications to an electronic change request. In some embodiments, at least one of one or more users may reject an electronic change request.

[0015] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library may be used in at least one medical device. The drug library editing software may run on a server. The medical error reduction system may include at least one drug library database. The medical error reduction system may include at least one medical data database. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface can be used by a user to edit at least one drug library. At least one editor computer, at least one drug library database, and at least one medical data database may be configured to communicate over a network. While editing at least one drug library, the user can access medical data using the drug library editing software.

[0016] In some embodiments, medical data may be stored in at least one medical data database. In some embodiments, at least one medical data database may be stored in a host environment. In some embodiments, medical data may be displayed in chart form. In some embodiments, medical data may be displayed in graph form. In some embodiments, medical data may be displayed in table form. In some embodiments, medical data may be displayed in diagram form. In some embodiments, medical data may be displayed in the form of infusion cases. In some embodiments, medical data may be displayed in a user-selectable format. In some embodiments, the accessed medical data is searchable. In some embodiments, the accessed medical data can be filtered by applying filters. In some embodiments, the filter may be a filter of device type. In some embodiments, the filter may be a filter of data category. In some embodiments, the filter may be a treatment-based criterion. In some embodiments, the filter may be a medical device identifier. In some embodiments, the filter may be a caregiver identifier. In some embodiments, the filter may be an area-based criterion. In some embodiments, the filter may be a drug criterion. In some embodiments, the drug criterion may be a drug identifier. In some embodiments, the drug criterion may be a drug type. In some embodiments, at least one drug library database may be located in a host environment. In some embodiments, the medical device may be an infusion pump.

[0017] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may include multiple entries. Each of the at least one drug library may be used in at least one medical device. The drug library editing software may be run on a server. The medical error reduction system may include at least one drug library database. The medical error reduction system may include at least one medical data database. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface may be used by a user to edit at least one drug library. The at least one editor computer, the at least one drug library database, and the at least one medical data database may be configured to communicate over a network. When creating or revising at least one drug library, the drug library editing software may be configured to display medical data in the at least one medical data database on the user interface and to filter the medical data using filter criteria.

[0018] In some embodiments, at least one medical device may be an infusion pump. In some embodiments, at least one drug library database may be present in the host environment. In some embodiments, at least one medical data database may be present in the host environment. In some embodiments, the filter criteria may be user-selectable. In some embodiments, the filter criteria may be the type of medical device. In some embodiments, the filter criteria can be data categories. In some embodiments, the filter criteria can be treatment-based criteria. In some embodiments, the filter criteria can be medical device identifiers. In some embodiments, the filter criteria can be caregiver identifiers. In some embodiments, the filter criteria can be nursing area-based criteria. In some embodiments, the filter criteria can be drug criteria. In some embodiments, the drug criteria can be drug identifiers. In some embodiments, the drug criteria can be drug types. In some embodiments, the filter criteria can be applied through interaction with medical data displayed in the user interface to display a subset of the medical data. In some embodiments, the filter criteria can be applied through interaction with medical data displayed in the user interface to examine the medical data in detail. In some embodiments, the medical data can be displayed in the user interface in one or more of several formats specified by the user.

[0019] According to one embodiment of the present disclosure, a medical device may include a processor. The medical device may include a graphical user interface. The processor may be configured to generate at least one screen for display in the graphical user interface. At least one of the at least one screen may include one or more parameter values. The processor may further be configured to visually change the font of at least one of the one or more parameter values ​​in response to a change in one or more parameter values.

[0020] In some embodiments, the change is a change in the number of digits of one or more parameter values. In some embodiments, the processor may be configured to visually change the font by changing the font size. In some embodiments, the processor may be configured to visually change the font by changing the font color. In some embodiments, at least one of the one or more parameter values ​​must be specified by the user. In some embodiments, one of the one or more parameter values ​​may be the patient's weight. In some embodiments, one of the one or more parameter values ​​may be the patient's body surface area. In some embodiments, one of the one or more parameter values ​​may be the dose value. In some embodiments, one of the one or more parameter values ​​may be the time value. In some embodiments, one of the one or more parameter values ​​may be the amount of the planned infusion volume. In some embodiments, one of the one or more parameter values ​​may be the infusion rate value. In some embodiments, one of the one or more parameter values ​​may be the concentration value of the drug. In some embodiments, at least one or more parameter values ​​may be pre-programmed. In some embodiments, the processor may be configured to visually change the font by reducing the size of the parameter values.

[0021] According to one embodiment of the present disclosure, a medical device may include a graphical user interface. The medical device may include a processor. The processor may be configured to generate at least one screen for display on the graphical user interface. At least one of the at least one screen may be a treatment in progress screen. The treatment in progress screen may include a pressure indicator showing the pressure of the fluid in the infusion line.

[0022] In some embodiments, the pressure indicator may be a pressure trend indicator. In some embodiments, the pressure trend indicator may show the pressure trend over the past four hours. In some embodiments, the pressure indicator may be a bar. In some embodiments, the bar may contain several intervals. In some embodiments, the pressure indicator may be configured to show different pressures by filling a different number of intervals. In some embodiments, the pressure indicator may be configured to show different pressures by filling the bar with different amounts. In some embodiments, the graphical user interface may be a touch screen.

[0023] According to one embodiment of the present disclosure, a medical device may include a graphical user interface. The medical device may include a processor. The processor may be configured to generate at least one screen for display on the graphical user interface. At least one of the at least one screen may be a treatment in progress screen, which is displayed when the medical device is performing treatment. The treatment in progress screen may include a drug indicator that shows the drug being delivered by the medical device. The processor may color-code at least a portion of the drug indicator displayed on the user interface with one of a plurality of colors, depending on one of a plurality of classifications assigned to the drug.

[0024] In some embodiments, the graphical user interface can be a touch screen. In some embodiments, the processor can be in communication with memory storing a drug library used in the medical device. In some embodiments, the drug library can hold color coding information for a portion of the drug indicator. In some embodiments, at least one of at least one screen can be a program screen that specifies the drug to be delivered by the medical device. In some embodiments, at least one of a plurality of classifications can be a high-risk classification. In some embodiments, at least one of a plurality of classifications can be a drug type. In some embodiments, at least one of a plurality of classifications can be an anesthetic classification. In some embodiments, the drug indicator can include the name of the drug. In some embodiments, the drug indicator can include a non-text label. In some embodiments, the non-text label is the only color-coded portion of the drug indicator.

[0025] According to one embodiment of the present disclosure, a medical device may include a graphical user interface. The medical device may include a processor. The processor may be configured to generate at least one screen for display on the graphical user interface. The medical device may include computer-readable memory. The computer-readable memory may store a number of treatment-related parameter values ​​that can be programmed into the medical device. At least one of the parameter values ​​may be a user-overridable limit value for the treatment parameter value. The user-overridable limit value for the treatment parameter value can be overridden by one or more users via the graphical user interface. The processor may display a label next to the treatment parameter value in response to the user-overridable limit value being overridden.

[0026] In some embodiments, the graphical user interface may be a touch screen. In some embodiments, at least one of at least one screen may display a limit violation notification. In some embodiments, the limit violation notification may not display the overrideable limit value. In some embodiments, the limit violation notification may include an override option. In some embodiments, user-overrideable limits for therapeutic parameter values ​​may require both a first user and a second user to override the limit value via the graphical user interface. In some embodiments, multiple therapeutic parameter values ​​that can be programmed into the medical device may be part of a drug library file stored in computer-readable memory. In some embodiments, the label may be a non-text label.

[0027] According to one embodiment of the present disclosure, a medical device may include a graphical user interface. The medical device may include a processor. The processor may be configured to generate at least one screen for display on the graphical user interface. The medical device may include computer-readable memory. The computer-readable memory may store a plurality of pharmaceuticals that can be delivered by the medical device. The pharmaceuticals may be organized according to one or more pharmaceutical categories. Each pharmaceutical may further be associated with one or more parameter values ​​related to a treatment that can be programmed into the medical device. A user may use the graphical user interface to program the medical device to perform a treatment. At least one step in programming the medical device may include selecting a pharmaceutical category containing pharmaceuticals to be delivered by the medical device.

[0028] In some embodiments, the graphical user interface can be a touch screen. In some embodiments, multiple drugs and one or more drug categories are part of a drug library file. In some embodiments, drug categories are searchable via the graphical user interface. In some embodiments, drug categories are filterable via the graphical user interface. In some embodiments, at least one of one or more parameter values ​​can be a user-overridable parameter limit.

[0029] According to one embodiment of the present disclosure, a medical error reduction system may include medical error reduction software used to create and revise at least one drug library configured for use in at least one medical device. The software may be configured to provide one of several sets of privileges to each of several sets of users. Each of the sets of privileges may be configured to assign a certain degree of software functionality to one of the several sets of users. The certain degree of software functionality may be configured to define the ability of a user to modify at least one drug library. The medical error reduction system may include at least one server. The medical error reduction system may include at least one editor computer having a display and a processor in a communication state. The at least one editor computer may be configured to communicate with at least one server over a network in a client / server model.

[0030] According to one embodiment of the present disclosure, a medical error reduction system may include a medical device. The medical device may include a medical device processor. The medical device may include a medical device graphical user interface configured to allow a user to program the medical device. The medical error reduction system may include at least one server. The medical error reduction system may include at least one editor computer having a display and a processor in a communication state. The at least one editor computer may be configured to communicate with at least one server over a network in a client / server model. The medical error reduction system may include medical error reduction software, which runs on at least one server for use in creating and revising at least one drug library and is configured to be accessible via at least one editor computer. The at least one drug library may be used with at least one medical device and may include multiple entries that guide a user to program at least one medical device. The medical error reduction software may further be configured to display a simulated medical device graphical user interface. The simulated medical device graphical user interface may use one of the at least one drug libraries to mimic the behavior of the medical device graphical user interface of a medical device.

[0031] According to one embodiment of the present disclosure, a medical device for delivering a drug to a patient may include a controller configured to control the operation of a pump mechanism for delivering the drug. The medical device may include a display. The medical device may include computer-readable memory configured to store program code for a drug library. The drug library may have multiple entries. The multiple entries may include at least one entry corresponding to a portion of a facility. For each such entry, the multiple entries may further include at least one drug entry corresponding to a portion of a facility. The medical device may include a processor configured to display a graphical user interface on the display of the medical device. A graphical user interface can be used by the user to program the controller using a drug library. The user can select one of at least one drug entries corresponding to a portion of the facility to program the delivery of medication to patients.

[0032] In some embodiments, at least one drug entry may include parameters associated with that entry. In some embodiments, the drug library may further include at least one drug entry associated with a broad drug category rather than a specific drug. In some embodiments, a user can select one of the at least one drug entries in the drug library associated with a broad drug category rather than a specific drug to program the delivery of medication to a patient.

[0033] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library for use in at least one medical device. The at least one drug library may include multiple entries. The software may be configured to provide at least one of multiple sets of privileges to each of multiple sets of users. Each of the multiple sets of privileges may be configured to assign a certain degree of software functionality to one of the multiple sets of users. The certain degree of software functionality may be configured to define the ability of a user to modify at least one drug library. The medical error reduction system may include at least one server configured to run the drug library editing software. The medical error reduction system may include at least one editor computer having a processor in communication with a user interface. The at least one editor computer may be configured to communicate with at least one server over a network in a client / server model. At least one of the multiple sets of users may use the at least one editor computer to access the drug library editing software and request changes to at least one drug library.

[0034] In some embodiments, at least one of a set of privileges may be configured to allow a user to either reject or approve the implementation of a requested change to at least one drug library.

[0035] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may include multiple entries. The at least one drug library may be used in at least one medical device. The medical error reduction system may include at least one server configured to run the drug library editing software. The medical error reduction system may include at least one editor computer having a processor in communication with a user interface. The user interface may be used by a user to edit at least one drug library. The at least one editor computer may be configured to communicate with at least one server over a network in a client / server model so that the at least one editor computer can access the drug library editing software. A user may request changes to at least one drug library by submitting an electronic change request through the user interface.

[0036] In some embodiments, electronic change requests can be linked to medical data in an electronic database to provide status information.

[0037] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may include multiple entries. Each of the at least one drug library may be used for at least one medical device. The drug library editing software may be run by a server. The medical error reduction system may include at least one drug library database. The medical error reduction system may include at least one medical data database. The medical error reduction system may include a server, at least one drug library database, and at least one editor computer configured to communicate with the at least one medical data database over a network. The at least one editor computer may have a processor in communication with a user interface. The user interface may be used by a user to edit at least one drug library using at least one drug library editing software. While editing at least one drug library, the user may use the drug library editing software to access medical data in at least one medical data database.

[0038] In some embodiments, while editing at least one drug library, the user can access medical data in at least one medical data database using drug library editing software. In some embodiments, the medical data may be in at least one form of charts, graphs, plots, and figures displayed in the user interface. In some embodiments, while editing at least one drug library, the user can use drug library editing software to display medical data in at least one medical data database in the user interface and filter the medical data so that only medical data of interest to the user is displayed in the user interface.

[0039] According to one embodiment of the present disclosure, a medical device may include a graphical user interface. The medical device may include a processor. The processor may be configured to generate at least one screen for display in the graphical user interface. The at least one screen may include at least one parameter value. The processor may further be configured to visually change the font of at least one parameter value in response to a change in the number of digits of at least one parameter value.

[0040] In some embodiments, at least one screen may include a treatment in progress screen, which may include a pressure indicator showing the pressure of the fluid in the infusion line. In some embodiments, at least one screen may be a treatment in progress screen. The treatment in progress screen may include a drug indicator showing the drug being delivered by the medical device. The processor may further configure the drug indicator displayed on the user interface to be color-coded with one of several colors. Each of the several colors may correspond to a drug classification. In some embodiments, the medical device may have computer-readable memory. The computer-readable memory may store several treatment-related parameter values ​​that can be programmed into the medical device. At least one of the parameter values ​​may be a user-overridable limit for the treatment parameter value. The user-overridable limit for the treatment parameter value can be overridden by the user via a graphical user interface. The processor may further configure the processor to display a label next to the treatment parameter value in response to the user overriding the user-overridable limit. In some embodiments, the computer-readable memory may be configured to store several drugs that can be delivered by the medical device. Each drug may be organized into one or more drug categories. Each drug may be further associated with one or more treatment-related parameter values ​​that can be programmed into the medical device. A user can use a graphical user interface to program the medical device by selecting at least one drug category containing the drugs to be delivered by the medical device.

[0041] According to one embodiment of the present disclosure, a medical error reduction system may include medical error reduction software used to create and revise at least one drug library. The software may be configured to provide each of several users with a set of privileges. The set of privileges may be configured to assign a certain degree of software functionality to each of several users. The certain degree of software functionality may be configured to define the ability of a user to modify at least one drug library. The medical error reduction system may include at least one server. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a display and a processor in a communication state. The at least one editor computer and at least one server may be configured to communicate over a network in a client / server model. Each of the at least one drug library may be used in at least one medical device.

[0042] In some embodiments, each of at least one drug library may be organized hierarchically. In some embodiments, the hierarchy may include multiple nursing areas under at least one nursing group. In some embodiments, each level of the hierarchy may include several delivery parameters for at least one medical device. In some embodiments, each of at least one drug library may include multiple entries, each corresponding to a specific drug. In some embodiments, at least one drug library may include several parameters that indicate the operation of at least one medical device. In some embodiments, the drug library may include multiple programming limit values ​​for at least one medical device. In some embodiments, the medical error reduction software may be configured to provide further quality improvement information to multiple users. In some embodiments, a set of privileges can be configured to assign privileges to inspect the drug library. In some embodiments, a set of privileges can be configured to assign privileges to edit the drug library. In some embodiments, a set of privileges can be configured to assign privileges to edit or create. In some embodiments, a set of privileges can be configured to assign user-addition privileges. In some embodiments, a set of privileges assigned to each of multiple users can compel a collaborative process among those users to create and revise at least one drug library.

[0043] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise several drug libraries. Each of the drug libraries may contain multiple entries. Each of the drug libraries may be used for at least one medical device. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface may be used by one or more users to edit at least one drug library. The drug library editing software may be configured to take entries from multiple entries in a first drug library among several drug libraries and place them in a second drug library among several drug libraries.

[0044] In some embodiments, the system may further include at least one server configured to run medical error reduction software. In some embodiments, several drug libraries may be stored in a drug library database. In some embodiments, the drug library database may reside in a host environment. In some embodiments, one or more users may specify from a group of entries that they want to include in a second drug library from a first drug library among several drug libraries. In some embodiments, both the first drug library among several drug libraries and the second drug library among several drug libraries may belong to a subset of drug libraries within several drug libraries. In some embodiments, a subset of drug libraries may be associated with a set of permissions that allow one or more users to access that subset of drug libraries. In some embodiments, the set of permissions does not allow another one or more users to access the subset of drug libraries.

[0045] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library may be used in at least one medical device. The drug library editing software may be run on a server. The medical error reduction system may include at least one drug library database that stores at least one drug library. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface may be used by a user to edit at least one drug library. The at least one editor computer and the at least one drug library database may be configured to communicate over a network. Multiple entries may contain one or more clinical recommendations.

[0046] In some embodiments, the drug library database resides in a host environment. In some embodiments, one or more clinical recommendations may be free-text entries. In some embodiments, one or more clinical recommendations may include images. In some embodiments, one or more clinical recommendations may include documents. In some embodiments, the length of one or more clinical recommendations may be limited to between 0 and 100 characters. In some embodiments, each of one or more clinical recommendations may be associated with a short-text clinical recommendation. In some embodiments, the length of the short-text clinical recommendation may be limited to between 0 and 100 characters. In some embodiments, the short-text clinical recommendation may be displayed on at least one screen of the graphic user interface of at least one medical device. In some embodiments, each of at least one clinical recommendation may be associated with a drug entry in at least one drug library.

[0047] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library may be used in at least one medical device. The drug library editing software may be run on a server. The medical error reduction system may include at least one drug library database that stores at least one drug library. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface may be used by a user to edit at least one drug library. The at least one editor computer and the at least one drug library database may be configured to communicate over a network. The drug library editing software may be configured to allow a user to enter notes about one or more of the multiple entries.

[0048] In some embodiments, the drug library database may reside in a host environment. In some embodiments, notes may be free-text entries. In some embodiments, notes may include images. In some embodiments, notes may include documents. In some embodiments, the drug library editing software may be configured to allow a user to enter notes for one or more subsets of multiple entries. In some embodiments, the drug library editing software may be configured to allow a user to enter notes for each of multiple entries. In some embodiments, each of the multiple entries associated with a note may be depicted on the user interface along with a note indicator. In some embodiments, the note may be displayed on the user interface when the user interacts with the note indicator.

[0049] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library may be used in at least one medical device. The drug library editing software may be run on a server. The medical error reduction system may include at least one drug library database that stores at least one drug library. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor that is in communication with a user interface. The user interface can be used by a user to edit at least one drug library. The at least one editor computer and the at least one drug library database may be configured to communicate over a network. Multiple entries may include wash parameters.

[0050] In some embodiments, the cleaning parameter can govern the cleaning of a fluid line associated with at least one medical device. In some embodiments, the cleaning parameter can include a default fluid delivery parameter value to be used by the medical device when at least one medical device cleans a fluid line associated with it. In some embodiments, the cleaning parameter can include a planned fluid delivery volume. In some embodiments, the cleaning parameter can include a fluid delivery flow rate. In some embodiments, the cleaning parameter can include a time.

[0051] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may include multiple entries. Each of the at least one drug library may be used for at least one medical device. The drug library editing software may be run on a server. The medical error reduction system may include at least one drug library database that stores at least one drug library. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface may be used by a user to edit at least one drug library. The at least one editor computer and the at least one drug library database may be configured to communicate over a network. The drug library editing software may be configured to display a user-customizable screen that provides the user with desired summary information.

[0052] In some embodiments, a user-customizable screen may include one or more widgets. In some embodiments, the user can select one or more widgets to include in the user-customizable screen. In some embodiments, one of the one or more widgets may be a progress widget. In some embodiments, one of the one or more widgets may be a trends widget. In some embodiments, one of the one or more widgets may be an overview widget. In some embodiments, one of the one or more widgets may be a quick links widget. In some embodiments, one of the one or more widgets may be a change request widget. In some embodiments, one of the one or more widgets may be a feedback widget. In some embodiments, one of the one or more widgets may be a medical data widget. In some embodiments, one of the one or more widgets may be a change review widget. In some embodiments, one of the one or more widgets may be an administrator comments widget. In some embodiments, a user can select one or more widgets from a list of permitted widgets. In some embodiments, a user may be assigned a specific role within the medical error reduction software, and the list of permitted widgets may be associated with that specific role. In some embodiments, the system may further include a user database. In some embodiments, user-customizable screens, once customized, can be stored in the user database and associated with the user. In some embodiments, user-customizable screens may be selected from several loadable customized screen settings.

[0053] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software used to create and revise at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library may be used in at least one medical device. The drug library editing software may be run on a server. The medical error reduction system may include at least one drug library database that stores at least one drug library. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface may be used by a user to edit at least one drug library. The at least one editor computer and the at least one drug library database may be configured to communicate over a network. The user may use the drug library editing software to compare two or more entries from a plurality of entries. The comparison may be displayed on the user interface.

[0054] In some embodiments, the comparison may be displayed in a table in the user interface. In some embodiments, the comparison may be a side-by-side comparison. In some embodiments, the difference between two or more entries being compared may be visually displayed in the user interface. In some embodiments, the comparison may include an option to display only the difference. In some embodiments, interacting with the option to show only differences allows the comparison to switch between a state where only the differences between two or more entries out of a group of entries are displayed, and a state where all information associated with two or more entries out of a group of entries is displayed. In some embodiments, the comparison may include an editing option that can be used to open one of two or more entries out of a group of entries for editing.

[0055] According to one embodiment of the present disclosure, a method for generating a drug library file may include the step of assigning one of a set of privileges to each of a set of users. The set of privileges may be configured to allocate a certain degree of software functionality within drug library editing software. The certain degree of software functionality may be configured to define the ability of a user to modify at least one drug library. A method for generating a drug library file may include the step of creating a drug library using at least one editor computer. Each of the at least one editor computer may have a processor in communication with a user interface. The user interface may be used by a user to edit at least one drug library using drug library editing software. Creating a drug library may include the steps of specifying an appropriate user among the set of users, the appropriate user being defined by a set of privileges, specifying a master drug list for an organization, defining drug records for one or more parts of the organization, and verifying the defined drug records. The method may include the step of approving the drug library for publication to at least one medical device within the organization.

[0056] In some embodiments, one of a set of privileges may be assigned the privilege to edit. In some embodiments, one of a set of privileges may be assigned the privilege to inspect. In some embodiments, the step of specifying a master drug list may include the step of selecting several drugs from a prescription database. In some embodiments, the step of defining drug records for one or more parts of an organization may include the step of selecting desired drugs from the master drug list for each of one or more parts of the organization. In some embodiments, the step of defining drug records for one or more parts of an organization may include the step of defining several parameters for each desired drug. In some embodiments, the step of validating a defined drug record may include the step of inspecting the defined drug record. In some embodiments, the step of validating a defined drug record may include the step of editing and revising the defined drug record. In some embodiments, the step of generating a drug library file may further include the step of performing a test creation stage on the drug library file in which the drug library file is inspected with a medical device for testing. In some embodiments, the step of generating a drug library file may further include the step of performing a test creation stage on the drug library file in which the drug library file is inspected on a user interface of a simulated medical device. In some embodiments, the step of verifying a defined drug record may include the step of checking the defined drug record using a user interface of a simulated medical device.

[0057] According to one embodiment of the present disclosure, a method for placing a drug library file in at least one medical device includes the step of creating a drug library file. The above method may include a step of approving a drug library file for publication to at least one medical device. The above method may include a step of sending a notification to the user via the editor service of the drug error reduction system. The above method may include a step of downloading the drug library file to the device gateway. The above method may include a step of distributing the drug library file to at least one medical device via a network that the device gateway can communicate with at least one medical device.

[0058] In some embodiments, the method may further include the step of a user instructing the device gateway to download a drug library file. In some embodiments, the method may further include the step of selecting at least one medical device from a list of medical devices. In some embodiments, the method may further include the step of the device gateway periodically checking whether there are any updates to the drug library file. In some embodiments, the method may further include the step of at least one medical device verifying the validity of the drug library file. In some embodiments, the method may further include the step of each of the at least one medical device sending a confirmation message to the device gateway if the validity verification of the drug library file is successful and it has been updated.

[0059] Other embodiments described above will become clearer from the detailed descriptions of the various embodiments of this disclosure provided below with reference to the drawings. [Brief explanation of the drawing]

[0060] [Figure 1] This is a block diagram of an electronic patient nursing system according to one embodiment of the present disclosure. [Figure 2] This block diagram shows several embodiments of the system shown in Figure 1, according to one embodiment of the present disclosure. [Figure 3]This diagram illustrates an aggregation of several facilities for communications according to one embodiment of the present disclosure. [Figure 4] This is a diagram illustrating an electronic patient nursing system according to one embodiment of the present disclosure. [Figure 5] This is a block diagram illustrating several aspects of electronic communication between a medical device and a device application, according to one embodiment of the present disclosure. [Figure 6] This is a state diagram illustrating a method for programming an infusion device according to one embodiment of the present disclosure. [Figure 7] A diagram illustrating a software program that can be executed on a processor, wherein the software program and processor are configured to implement a publishing / subscription model for use in the facility gateway of Figure 1, and the application and device gateways shown in Figures 2 and 4, according to one embodiment of the present disclosure. [Figure 8] A diagram illustrating a software program that can be executed on a processor, wherein the software program and the processor are configured to implement a capability registration model according to one embodiment of the present disclosure. [Figure 9] A diagram illustrating a software program that can be executed on a processor, wherein the software program and the processor are configured to implement a drug safety method used to generate files for a drug management library according to one embodiment of the present disclosure. [Figure 10] This is an exemplary conceptual diagram illustrating in detail the possible roles, responsibilities, and privileges of various users and stakeholders who may be involved in the creation of a drug management library file, according to one embodiment of this disclosure. [Figure 11a] This figure outlines an exemplary hierarchical organizational structure of a drug management library ("DAL") file according to one embodiment of the present disclosure. [Figure 11b] This figure outlines an exemplary hierarchical organizational structure of a drug management library file according to one embodiment of the present disclosure. [Figure 12]This flowchart details several exemplary steps that may be part of the setup phase of a drug error reduction system for drug management library file creation, according to one embodiment of the present disclosure. [Figure 13] This flowchart details some exemplary steps that can be used to update a reference table loaded into a database of a drug error reduction system according to one embodiment of the present disclosure. [Figure 14] This flowchart shows some exemplary steps that can be used to set up institutional and organizational hierarchies in a database of a drug error reduction system according to one embodiment of the present disclosure. [Figure 15] This flowchart shows some exemplary steps that can be used when allowing subscribers to access the editor of a drug error reduction system. [Figure 16a] This flowchart details several exemplary steps that can be used to set up various aspects of a drug error reduction system within an organization or institution, according to one embodiment of the present disclosure. [Figure 16b] This flowchart details several exemplary steps that can be used to define users, groups to which each user belongs, and various permissions and privileges for each user, in relation to an editor for a drug error reduction system according to one embodiment of the present disclosure. [Figure 17] This flowchart details some exemplary steps that can be used to update various aspects of a drug error reduction system within an organization or institution, according to one embodiment of the present disclosure. [Figure 18] This flowchart details some exemplary steps that can be used to create or update an institutional / organizational master drug list according to one embodiment of the present disclosure. [Figure 19]This flowchart details some exemplary steps that can be used to add clinical recommendation entries to a database according to one embodiment of the present disclosure. [Figure 20] This flowchart details several exemplary steps that can be used to change the general settings of an institution or organization, according to one embodiment of the present disclosure. [Figure 21] This flowchart details some exemplary steps that can be used to add a nursing group to a drug management library file according to one embodiment of the present disclosure. [Figure 22] This flowchart details several exemplary steps that can be used to add a nursing area to a drug management library file according to one embodiment of the present disclosure. [Figure 23] This flowchart details some exemplary steps that can be used when verifying a nursing area according to one embodiment of the present disclosure. [Figure 24] This flowchart details some exemplary steps that can be used to update a nursing area according to one embodiment of the present disclosure. [Figure 25] This flowchart details some exemplary steps that can be used to add a drug record or medication record to a designated nursing area, according to one embodiment of the present disclosure. [Figure 26] This flowchart details some exemplary steps that can be used to review a list of medications for a specific nursing area, according to one embodiment of the present disclosure. [Figure 27] This flowchart details some exemplary steps that can be used to update a drug list according to one embodiment of the present disclosure. [Figure 28] This flowchart details some exemplary steps that can be used to re-verify a drug list according to one embodiment of the present disclosure. [Figure 29] This flowchart details some exemplary steps that can be used when submitting a drug management library file for approval, according to one embodiment of this disclosure. [Figure 30] This flowchart details some exemplary steps that can be used to prepare a drug management library file for public release, according to one embodiment of the present disclosure. [Figure 31a] This flowchart details several exemplary steps that can be used to place drug management library files into various system components according to one embodiment of the present disclosure. [Figure 31b] This is an exemplary flowchart illustrating in detail several steps that can be used to package and stage resources to be exposed to a facility gateway, according to one embodiment of the present disclosure. [Figure 31c] This flowchart details some exemplary steps that can be used to track the placement of various resources according to one embodiment of the present disclosure. [Figure 32] This flowchart details some exemplary steps that can be used to update an existing drug management library file according to one embodiment of the present disclosure. [Figure 33] This flowchart details several exemplary steps that can be used to update an institution / organization's master drug list according to one embodiment of the present disclosure. [Figure 34] This flowchart details some exemplary steps that can be used to update a list of clinical recommendations according to one embodiment of the present disclosure. [Figure 35] This flowchart details several exemplary steps that can be used to update the general settings of an organization / institution according to one embodiment of the present disclosure. [Figure 36]This flowchart details some exemplary steps that can be used to update a nursing area according to one embodiment of the present disclosure. [Figure 37] This flowchart details some exemplary steps that can be used to update medication records in a nursing area according to one embodiment of the present disclosure. [Figure 38] This flowchart details some exemplary steps that can be used to create and store a drug management library report according to one embodiment of the present disclosure. [Figure 39] This flowchart details some exemplary steps that can be used to create a differential report of a drug management library according to one embodiment of the present disclosure. [Figure 40] This flowchart details some exemplary steps that can be used to create an organization-wide drug management library comparison report according to one embodiment of the present disclosure. [Figure 41] This flowchart details some exemplary steps that can be used to create an inter-organizational drug management library comparison report according to one embodiment of the present disclosure. [Figure 42] This flowchart details several exemplary steps that can be followed to create a drug management library history report according to one embodiment of the present disclosure. [Figure 43] This flowchart details some exemplary steps that can be used to log in to an editor of a drug error reduction system according to one embodiment of the present disclosure. [Figure 44] This is an exemplary flowchart illustrating in detail several steps that can be used to change the password for a drug error reduction system editor service according to one embodiment of the present disclosure. [Figure 45]This flowchart details some exemplary steps that can be used to recover a password for a drug error reduction system editor service according to one embodiment of the present disclosure. [Figure 46] This flowchart details some exemplary steps that can be used to check drug library entries using a medical device programming simulator according to one embodiment of the present disclosure. [Figure 47] This flowchart details some exemplary steps that can be used to compare records in a drug management library file according to one embodiment of the present disclosure. [Figure 48] This flowchart details some exemplary steps that can be used to update a drug management library file on a medical device according to one embodiment of the present disclosure. [Figure 49] This flowchart details some exemplary steps that can be used to update a DAL file on a medical device according to one embodiment of the present disclosure. [Figure 50] This flowchart details some exemplary steps that can be used to configure a user interface for a drug error reduction system editor service or a continuous quality improvement ("CQI") service according to one embodiment of the present disclosure. [Figure 51] This flowchart details several exemplary steps that can be used to view and utilize continuous quality improvement data according to one embodiment of the present disclosure. [Figure 52] This flowchart details some exemplary steps that can be used to display a desired continuous quality improvement report in a user interface according to one embodiment of the present disclosure. [Figure 53]This flowchart details some exemplary steps that can be used to set up a continuous quality improvement report according to one embodiment of the present disclosure. [Figure 54] This flowchart details some exemplary steps that can be used to set up a continuous quality improvement report according to one embodiment of the present disclosure. [Figure 55] This flowchart details several exemplary steps that can be used to filter continuous quality improvement data using an organizational / institutional hierarchy, according to one embodiment of the present disclosure. [Figure 56] This flowchart details some exemplary steps that can be used to filter continuous quality improvement data using a date range or time frame, according to one embodiment of the present disclosure. [Figure 57] This flowchart details several exemplary steps that can be used to apply filters to continuous quality improvement data based on user-defined, custom-configured filtering criteria, according to one embodiment of the present disclosure. [Figure 58] This flowchart details some exemplary steps that can be used to modify the appearance of continuous quality improvement data, such as a continuous quality improvement report, in a user interface, according to one embodiment of the present disclosure. [Figure 59] This flowchart details several exemplary steps that can be used to change the time unit of a continuous quality improvement report based on user input, according to one embodiment of the present invention. [Figure 60] This flowchart details several exemplary steps that can be used to hide or display panels displayed in a continuous quality improvement report, according to one embodiment of the present invention. [Figure 61]This flowchart details several exemplary steps that can be used to switch between summary view and detail view within a continuous quality improvement report, according to one embodiment of the present invention. [Figure 62] This flowchart details several exemplary steps that can be used to sort CQI data in a CQI report according to one embodiment of the present invention. [Figure 63] This flowchart details several exemplary steps that can be used to switch between a count view and a date view in a CQI report, according to one embodiment of the present invention. [Figure 64] This flowchart details some exemplary steps that can be used to select a utility on a user interface that allows a user to perform one or more functions, according to one embodiment of the present disclosure. [Figure 65] This flowchart details some exemplary steps that can be used to print a continuous quality improvement report according to one embodiment of the present disclosure. [Figure 66] This flowchart details some exemplary steps that can be used to download a continuous quality improvement report according to one embodiment of the present disclosure. [Figure 67] This flowchart details some exemplary steps that can be used to send continuous quality improvement reports by email, according to one embodiment of the present disclosure. [Figure 68] This flowchart details some exemplary steps that can be used to export data from a continuous quality improvement report according to one embodiment of the present disclosure. [Figure 69] This flowchart details some exemplary steps that can be used to schedule the automated generation and distribution of continuous quality improvement reports according to one embodiment of the present disclosure. [Figure 70]This flowchart shows some exemplary steps that can be used to generate and distribute a scheduled, ongoing quality improvement report according to one embodiment of the present disclosure. [Figure 71] A flowchart shows some exemplary steps that can be used to generate an automated continuous quality improvement summary report according to one embodiment of the present disclosure. [Figure 72] This figure shows an exemplary graphical user interface login screen that may be presented to a user when the user attempts to access the Drug Error Reduction System Editor Service or the Continuous Quality Improvement Service, according to one embodiment of the present disclosure. [Figure 73] This figure shows an exemplary graphical user interface login screen that may be presented to a user when the user attempts to access the Drug Error Reduction System Editor Service or the Continuous Quality Improvement Service, according to one embodiment of the present disclosure. [Figure 74] This figure shows an exemplary initialization screen that can be displayed in a user interface according to one embodiment of the present disclosure. [Figure 75] This figure shows an exemplary initialization wizard screen according to one embodiment of the present disclosure. [Figure 76] This figure shows an exemplary initialization wizard screen according to one embodiment of the present disclosure. [Figure 77] This figure shows an exemplary initialization wizard screen according to one embodiment of the present disclosure. [Figure 78] This figure shows an exemplary embodiment of a "Welcome" screen that can be displayed in a user interface, such as the user interface of a drug error reduction system editor service, according to one embodiment of the present disclosure. [Figure 79] This figure shows an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 80]This figure shows an exemplary nursing area screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 81] This figure shows an exemplary nursing area addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 82] This figure shows an exemplary nursing area addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 83] This figure shows an exemplary nursing area addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 84] This figure shows an exemplary nursing area addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 85] This figure shows an exemplary nursing area addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 86] This figure shows an exemplary nursing area addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 87] This figure shows an exemplary nursing area screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 88] This figure shows an exemplary drug screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 89]This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 90] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 91] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 92] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 93] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 94] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 95] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 96] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 97] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 98] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 99] This figure shows an exemplary drug screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 100] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 101] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 102] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 103] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 104] This figure shows an exemplary drug record addition screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 105] This figure shows an exemplary drug screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 106] This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 107] This figure shows an exemplary drug screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 108] This figure shows an exemplary drug record comparison screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 109] This figure shows an exemplary drug screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 110] This figure shows an exemplary drug record comparison screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 111] This figure shows an exemplary drug record comparison screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 112] This figure shows an exemplary medical device simulator screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 113] This figure shows an exemplary medical device simulator screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 114] This figure shows an exemplary medical device simulator screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 115] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 116] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 117] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 118] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 119] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 120] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 121] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 122] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 123] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 124] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 125] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 126] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 127] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 128] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 129] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 130] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 131] This figure shows an exemplary continuous quality improvement screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 132] This figure shows an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 133] This figure shows an example of a dashboard screen of a drug error reduction system editor where feedback items are accessed, according to one embodiment of the present disclosure. [Figure 134]This figure shows an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 135] This figure shows an example of a dashboard screen of a drug error reduction system editor where a change request is being accessed, according to one embodiment of the present disclosure. [Figure 136] This figure shows an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 137] This figure shows an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 138] This figure shows an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 139] This figure shows an example of a dashboard screen of a drug error reduction system editor where a change request is being accessed, according to one embodiment of the present disclosure. [Figure 140] This figure shows an example of a dashboard screen of a drug error reduction system editor where a change request is being accessed, according to one embodiment of the present disclosure. [Figure 141] This figure shows an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 142] This figure shows an example of a dashboard screen of a drug error reduction system editor, according to one embodiment of the present disclosure, where the proposed changes are accessed for inspection. [Figure 143] This figure shows an example of a dashboard screen of a drug error reduction system editor, according to one embodiment of the present disclosure, where the proposed changes are accessed for inspection. [Figure 144] This figure shows an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 145] This figure shows an example of a dashboard screen of a drug error reduction system editor, according to one embodiment of the present disclosure, where the proposed changes are accessed for inspection. [Figure 146] This figure shows an example of a dashboard screen of a drug error reduction system editor in which a user is using a search utility, according to one embodiment of the present disclosure. [Figure 147] This figure shows an example of an inspection screen that can be displayed on a user interface, such as the user interface of a drug error reduction system, according to one embodiment of the present disclosure. [Figure 148] This figure shows an example of an inspection screen that can be displayed on a user interface, such as the user interface of a drug error reduction system, according to one embodiment of the present disclosure. [Figure 149] This figure shows an example of an inspection screen that can be displayed on a user interface, such as the user interface of a drug error reduction system, according to one embodiment of the present disclosure. [Figure 150] This figure shows an example of an inspection screen that can be displayed on a user interface, such as the user interface of a drug error reduction system, according to one embodiment of the present disclosure. [Figure 151] This figure shows an example of an inspection screen that can be displayed on a user interface, such as the user interface of a drug error reduction system, according to one embodiment of the present disclosure. [Figure 152] This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 153] This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 154] This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 155]This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 156] This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 157] This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 158] This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 159] This figure shows an exemplary drug library entry screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 160] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 161] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 162] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 163] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 164] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 165] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 166] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 167] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 168] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 169] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 170] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 171] This figure shows an exemplary master drug list screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 172] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 173] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 174] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 175] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 176] This figure shows an exemplary master drug list screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 177] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 178] This figure shows an exemplary drug library screen that can be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 179] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 180] This figure shows exemplary prompts that may be displayed in a user interface, such as a user interface for a drug error reduction system, according to one embodiment of the present disclosure. [Figure 181] This is a block diagram of an exemplary software architecture for an exemplary medical device according to one embodiment of the present disclosure. [Figure 182]This flowchart details several exemplary steps that can be used to attach a syringe to a medical device when preparing to administer an intravenous fluid using a medical device, according to one embodiment of the present disclosure. [Figure 183] This flowchart details some exemplary steps that can be used to prime an IV line of a medical device according to one embodiment of the present disclosure. [Figure 184] This flowchart details several exemplary steps that can be used to load a dosing set into a medical device such as a high-capacity pump, according to one embodiment of the present disclosure. [Figure 185] This flowchart details several exemplary steps that can be used to select the drug nursing area, drug, clinical use, and concentration when programming an infusion in a medical device, according to one embodiment of the present disclosure. [Figure 186] This flowchart details some exemplary steps that can be used to program infusion in a medical device according to one embodiment of the present disclosure. [Figure 187] This flowchart details some exemplary steps that can be used to determine whether a parameter entered into a medical device, according to one embodiment of the present disclosure, is outside the limits defined for that parameter. [Figure 188] This flowchart details some exemplary steps that can be used to perform a primary continuous infusion according to one embodiment of the present disclosure. [Figure 189] This flowchart details some exemplary steps that can be used to deliver a drug bolus in a medical device according to one embodiment of the present disclosure. [Figure 190] This flowchart details some exemplary steps that can be used to perform a secondary infusion according to one embodiment of the present disclosure. [Figure 191]This is an exemplary flowchart illustrating in detail several steps that can be used to perform multi-step infusion in a medical device according to one embodiment of the present disclosure. [Figure 192] This flowchart details some exemplary steps that can be used to gradually increase an intravenous fluid administered by a medical device, according to one embodiment of the present disclosure. [Figure 193] This flowchart details some exemplary steps that can be used when an intravenous fluid being administered by a medical device is nearing completion, according to one embodiment of the present disclosure. [Figure 194] This flowchart details several steps that can be used to detect and eliminate air contamination in a medical device line according to one embodiment of the present disclosure. [Figure 195] This flowchart details some exemplary steps that can be used to detect and resolve blockages in an infusion line associated with a medical device, according to one embodiment of the present disclosure. [Figure 196] This flowchart, according to one embodiment of the present disclosure, details several steps that can be used to change the nursing area corresponding to a medical device during the course of treatment. [Figure 197] This flowchart details some exemplary steps that can be used to discontinue an ongoing infusion in a medical device according to one embodiment of the present disclosure. [Figure 198] This flowchart details some exemplary steps that can be used when the battery level of a medical device drops to a predetermined level, according to one embodiment of the present disclosure. [Figure 199] This flowchart details several steps that can be used to lock and unlock the user interface of a medical device according to one embodiment of the present disclosure. [Figure 200]This flowchart details some exemplary steps that can be used to turn off the power to a medical device or put a medical device into sleep mode, according to one embodiment of the present disclosure. [Figure 201] This flowchart details several steps that can be used to clean an IV line associated with a medical device, according to one embodiment of the present disclosure. [Figure 202] This flowchart details some exemplary steps that can be used to attach a replacement syringe to a medical device during infusion, according to one embodiment of the present disclosure. [Figure 203] This flowchart details some exemplary steps that can be used to prepare a relay infusion using several medical devices according to one embodiment of the present disclosure. [Figure 204] This flowchart details some exemplary steps that can be used when a medical device forming part of a set relay infusion is removed from a medical device rack, according to one embodiment of the present disclosure. [Figure 205] This flowchart details some exemplary steps that can be used when a medical device forming part of a set relay infusion is removed from a medical device rack, according to one embodiment of the present disclosure. [Figure 206] This figure shows an exemplary startup screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 207] This figure shows an exemplary startup screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 208] This figure shows an exemplary startup screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 209]This figure shows an exemplary login screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 210] This figure shows an exemplary login screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 211] This figure shows an exemplary login screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 212] This figure shows an exemplary nursing group selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 213] This figure shows an exemplary nursing area selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 214] This figure shows an exemplary patient selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 215] This figure shows an exemplary drug selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 216] This figure shows an exemplary drug selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 217] This figure shows an exemplary drug selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 218] This figure shows an exemplary drug selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 219] This figure shows an exemplary drug selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 220] This figure shows an exemplary clinical use selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 221] This figure shows an exemplary clinical use selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 222] This figure shows an exemplary concentration selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 223] This figure shows an exemplary patient weight input screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 224] This figure shows an exemplary patient weight input screen that can be displayed in a user interface, such as a user interface for a medical device according to one embodiment of this disclosure. [Figure 225] This figure shows an exemplary patient weight input screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 226] This figure shows an exemplary administration set loading screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 227] This figure shows an exemplary problem-solving screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 228]This figure shows an exemplary syringe loading screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 229] This figure shows an exemplary syringe selection screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 230] This figure shows an exemplary treatment program screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 231] This figure shows an exemplary treatment program screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 232] This figure shows an exemplary treatment program screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 232] This figure shows an exemplary treatment program screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 233] This figure shows an exemplary treatment program screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 234] This figure shows an exemplary treatment program screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 235] This figure shows an exemplary treatment program screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 236]This figure shows an exemplary limit override screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 237] This figure shows an exemplary second user approval screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 238] This figure shows an exemplary treatment program screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 239] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 240] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 241] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 242] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 243] This disclosure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of this disclosure. [Figure 244] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 245]This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 246] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 247] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 248] This figure shows an exemplary screen displayed when treatment is discontinued, which may be shown on a user interface such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 249] This figure shows an exemplary alarm screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 250] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 251] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 252] This figure shows an exemplary locked treatment in progress screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 253] This figure shows an exemplary treatment in progress screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 254]This figure shows an exemplary treatment completion screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 255] This figure shows an exemplary treatment completion screen that can be displayed on a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 256] This figure shows an exemplary notification settings screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Figure 257] This figure shows an exemplary treatment parameter screen that can be displayed in a user interface, such as a user interface for a medical device, according to one embodiment of the present disclosure. [Modes for carrying out the invention]

[0061] Figure 1 shows a block diagram of an electronic patient care system 1 according to one embodiment of the present disclosure. System 1 includes a facility IT application / service 11, a facility 10, and a cloud service 2.

[0062] Facility 10 is a hospital, clinic, medical facility, outpatient nursing center, emergency nursing center, or a combination or group thereof. Facility 10 may include a facility gateway 21, and various medical devices 26 can communicate with facility IT applications / services 11 and / or cloud services 2. Facility 10 includes various medical devices 26 operated and used by nurses 9 for patients receiving care at Facility 10. Medical devices 26 include infusion pumps, peristaltic pumps, syringe pumps, kidney disease devices, physiological parameter monitoring devices, other patient nursing devices, or any combination thereof.

[0063] The facility gateway 21 can be hosted, reside in the cloud, maintained for facility 10 by a service provider, controlled and maintained by a combination of service provider and / or facility IT 18 staff, and / or implemented in a virtual or physical environment. In some embodiments, the facility gateway 21 can be implemented in equipment located in a patient's home. The facility gateway 21 can be used by hospitals, nursing groups, integrated delivery networks ("IDN"), integrated service groups or clinics, clinic clusters, central clinics, or other healthcare facilities or infrastructure.

[0064] A medical technician 19 can use the medical technician PC tool 20 to update the software of the device 26. The medical technician PC tool 20 is a browser-based tool for medical technician users 19 to monitor the health status of the medical device 26, view log files, track maintenance activities, and manage software / firmware installations. The medical technician 19 is a hospital employee (or contract service) who can install, update, and maintain the medical device 26 (including infusion pumps) to ensure that the medical device functions correctly. The medical technician PC tool 20 can interface with the device 26 via physical data connections such as USB or serial cable connections, enabling the medical technician 19 to perform the services described above. The medical technician 19 can also update the device 26 wirelessly using the device manager 24.

[0065] Device 26 can communicate with facility IT applications / services 11 (via communication link 343) and / or cloud services 2 (via communication link 344) via the facility gateway 21. Communication links 343 and 344 can use WiFi, Ethernet, TCP / IP, WiMAX, fiber optic cable, or any other known communication technology.

[0066] Device 26 can communicate with the facility gateway 21 by establishing communication with the device gateway 22 (for example, via registration). The facility gateway 21 can be a computer, virtual machine, hardware device, software device, hosted device, running software, etc., or any combination thereof. The device gateway 22 can be software executable by the facility gateway 21. Device 26 can communicate with the device gateway 22 using web services. In some specific embodiments, only the medical device 26 initiates communication with the device gateway 22 (and therefore the facility gateway 21). The device gateway 22 may include a message routing engine that supports both a publish / subscribe mechanism and a point-to-point routing mechanism. The device gateway 22 may also provide name resolution and capability registration functions. For small-scale object persistence, object-relational mapping can be used in the device gateway 22 (for example, by using an object-relational mapping (ORM) engine). In addition to, or instead of, the device manager 24 may also provide name resolution and / or registration functions.

[0067] In some embodiments of this disclosure, one of the devices 26 is a monitoring client, such as a tablet computer, tablet device, PDA, smartphone, laptop computer, or touchscreen computer. The monitoring client among the devices 26 may have a monitoring client application within the device application 23, thereby enabling the caregiver to communicate with other devices of the devices 26. The monitoring client can be used to receive status information from the medical device among the devices 26, receive CQI messages from the medical device among the devices 26, receive reportable medical events (RBEs) or reportable clinical events (RCEs) from the medical device among the devices 26, program the medical device among the devices 26, or communicate with the medical device among the devices 26 in other ways.

[0068] The communication link 343 between the device 26 and the facility gateway 21 may use WiFi, Ethernet, TCP / IP, WiMAX, fiber optic cable, or any other known communication technology. In some embodiments of this disclosure, the device 26 communicates with the facility gateway 21 via a cellular connection (e.g., the communication link 343 includes a cellular connection). For example, one or more devices 26 may be located in a patient's home, a clinic, an outdoor facility (e.g., a tent facility), an emergency location, another location, or any combination thereof.

[0069] The device gateway 22 can provide: (1) component registration and license management (e.g., using the device manager 24); (2) an installation storage location for receiving, maintaining, and tracking new versions of installable components such as device firmware / software, drug management libraries, enterprise application software, and infrastructure software (e.g., operating system publishing, application servers, database management systems ("DBMS")); and / or (3) message routing capabilities, such as delivering messages both between applications within the facility gateway 21 and with external subsystems (e.g., cloud service 2).

[0070] The deployment environment in which the medical device 26 maintains an active network connection with the device gateway 22 is referred to as the "connected environment," which can be achieved using a wireless network (IEEE 802.11b / g / n) as described above. Also as mentioned above, in other embodiments, the network connection can be achieved using other technologies such as cellular technology.

[0071] The environment in which device 26 does not maintain a wireless connection is referred to as the “standard environment.” However, it can still connect to components of enterprise applications and external subsystems. In this particular embodiment, the device gateway 22 also performs all three roles for components of enterprise applications and external subsystems, while a medical technician 19 (e.g., using the medical technician PC tool 26) is used for message exchange related to device 26, and messages can be stored on an external media device (e.g., a memory stick).

[0072] Event subscribers, such as device application 23, can improve the accuracy of the event stream and republish higher-quality events to device gateway 22. Reportable biomed events ("RBEs"), as described below, are included in the events republished by such applications. RBEs can be reported to cloud service 2 as CQI messages. In some embodiments, an application running on facility gateway 21 is a medical server that subscribes to RBEs and stores them in a local database within facility gateway 21.

[0073] A medical technician 19 can access the device manager 24 using their browser and request a device status report for one of the devices 26. The UI of the device manager 24 can instruct the medical server to access the database and generate an HTML / JS page for the medical technician 19 to display in their browser.

[0074] In some embodiments, before a new medical device 26 is authorized to be used with the device gateway 22, the medical technician 19 must register the new device using its sequential number. This can be enabled using asymmetric key (public-private key pair) encryption and can be done as part of the manufacturing process. Once one of the medical devices 26 is registered with the device gateway 22, the medical technician 19 configures the wireless protocol and encryption settings for that device. Upon registration of one of the medical devices 26 with the device gateway 22, the device reports its initial settings, including model, options, and versions of hardware, firmware, and device control software, for storage in the device gateway 22 and / or device manager 24. Similarly, if a device is removed from the list of authorized devices in the device gateway 22, the medical technician 19 can deregister that device.

[0075] Each medical device 26 can perform a self-check at startup and publish an event containing the results to the device gateway 22. Furthermore, since medical devices 26 may operate on a daily basis with long time intervals between restarts, they can schedule and perform self-checks automatically at times that do not interfere with patient safety and / or treatment.

[0076] The facility gateway 21 includes device applications 23 capable of communicating data using a publish / subscribe type data connection (described below). Each device application 23 may correspond to a specific type and / or model of device 26. These applications can give the medical devices 26 software intelligence by receiving, filtering, and analyzing unprocessed events and retransmitting higher-level interpretations. Each type of medical device (of the medical devices 26) may have a corresponding device application (within the device application 23).

[0077] The facility gateway 21 also includes an equipment manager 24 that controls, manages, or monitors the equipment 26. For example, the equipment manager 24 can be used to update and / or download configuration files (e.g., DAL files) to one of the equipment 26. As previously mentioned, medical technicians 19 can control updates to the software, firmware, or configuration files of the equipment 26. The equipment manager 24 can provide browser-based tools for IT managers and / or technicians 18 to monitor the health of the hardware, software, and network resources used to support the performance of patient care. In other words, the facility gateway 21 can be managed by the facility's IT employees / contractors 18.

[0078] When a new version of the Drug Management Library ("DAL") is released, the DAL Manager 5 can send the DAL file to the device gateway 22 via a secure messaging link to notify the medical technician 19 that the new version is available. This notification specifies the device type, the location of the DAL, documentation, URL of the release notes, URL of the installer, checksum, and installation dependencies. In some embodiments of this disclosure, the device manager 24 can access the new DAL file, receive the DAL file from the device gateway 22, receive the DAL file directly from the DAL Manager 5, and / or use that DAL file to control updates to the medical device 26.

[0079] In certain embodiments, the medical technician 19 uses the URL of the release notes (e.g., via the webpage of the device manager 24 and / or the medical technician PC tool 20) to access information about the upgrade, downloads and verifies the DAL file using the installer URL and checksum, and saves it to the storage location of the device gateway 22. The medical technician 19 then selects one or more medical devices 26 as the destination for copying the new DAL file. The selected one or more medical devices 26 can then be notified (e.g., via the device gateway 22) that the new DAL file is available. When the medical device (of which the medical device 26 has been selected for the update) is next restarted, the selected group of medical devices 26 installs the new DAL version (canceling the installation if an error occurs) and notifies the device gateway 22 and / or the device manager 24 of the result. Any of the procedures for updating the DAL file described herein can be used to update the firmware, software, OS, or other configuration files of one of the medical devices 26.

[0080] The facility gateway 21 may also include an integrated API 25, which enables the devices 26, device applications 23, and / or device managers 24 to communicate with various databases of the facility IT applications 11, such as the patient information system 16, electronic medical records 17, computerized physician order entry 14, laboratory information system 15, real-time location services 12, and / or other databases or services 13. The integrated API 25 enables components within the facility gateway 21 to interact with the facility IT applications / services 11. The facility gateway 21 can communicate with the facility IT applications 11 via a communication link 341, which may include a wireless link, a wired link, a TCP / IP link, an Internet link, a software communication link, a hardware communication link, or other communication methods or technologies.

[0081] The facility IT application / service 11 supports the hospital's management functions (e.g., admissions / discharges, transfers, coding, billing, collection, etc.). The integrated API 25 isolates the differences between applications 12-17 of the facility IT application 11 from applications 23-24, the device gateway 22, and / or devices 26. For example, one of the devices 26 can request programming information from the device gateway 22 (or push programming information to one of the devices 26). Patient ID, pump ID, drug, and flow rate can be placed in one or more of the facility IT applications 11, and the integrated API 25 provides a common format for communicating that information to the devices 26, regardless of the requirements or demands of the facility IT application 11. This information can be collected by the integrated API 25 querying each of the facility IT applications 11 to retrieve data and providing that data to the devices 26 in a standardized format. The integrated API 25 may be usable with various facility IT applications 12-17 having different formats, data standards, communication standards, encryption standards, etc., but provides a standard interface with applications 22-24 and / or equipment 26.

[0082] The integrated API 25 facilitates the automated programming of one or more devices 26. A prescription may be sent from one of the servers of the facility IT application 14. The integrated API 25 can receive the prescription, reformat it, and send it to the device gateway 22. The facility gateway 21 may include a clinical server, which writes prescription events to a permanent cache. The clinical server can initiate the automated programming workflow. This workflow can identify the medical device 26 corresponding to the target patient and send a command message to the individual device of the medical device 26 instructing it to load the prescription. The individual device of the medical device 26 notifies the sender that it has received the prescription and displays a notification on its display. The clinician can locate the medication bag and verify that the medication and patient are correct using, for example, a barcode reader on the individual medical device 26. The individual medical device 26 then verifies that the medication matches the prescription, and the clinician can begin administration. The individual medical device 26 completes the automated programming workflow by sending a message to the clinical server via the device gateway.

[0083] Caregivers can use the UI to check the programming of medical devices within device 26. Clinicians can locate medications and use the user interface of individual medical devices within device 26 to check the automatic programming parameters of medical devices within device 26, and / or manually program medical devices within device 26.

[0084] PIS16 is a departmental system used by pharmacists8 to receive, check, track, and record prescription drug orders. The EMR17 system tracks a patient's medical history (encounters, tests, diagnoses, procedures, etc.) within a healthcare setting. CPOE14 is a system used by physicians and nurses9 to order clinical tests, prescription drugs, medical imaging, and other clinical procedures. LIS15 is a departmental system used by laboratory technicians to receive and process orders for clinical specimens (e.g., tissue, blood, urine, etc.). RTLS12 tracks the location and status of equipment26. Others13 can be any other databases used for patient care.

[0085] Cloud Service 2 includes a cloud-hosted Infusion Safety Manager 3 ("ISM"). The term "Infusion Safety Manager" may be used herein synonymously with "Hosted Safety Manager" ("HSM"). HSM 3 includes a Continuous Quality Improvement ("CQI") Manager 4 and a DAL Manager 5. Risk management officers 6, nursing managers 7, and pharmacists 8 can all review CQI messages acquired by the CQI Manager 4 to assist in the progress and improvement of DAL files via the DAL Manager 5. DAL files can then be downloaded to one or more of the devices 26. The DAL Manager 5 may include or be associated with a Drug Error Reduction System ("DERS") editor (e.g., the DERS editor 112 in Figure 4, described below).

[0086] Figure 2 is a block diagram showing several embodiments of the system of Figure 1 according to one embodiment of the present disclosure. That is, Figure 2 shows some embodiments of Figure 1 in more detail.

[0087] The equipment gateway 40, equipment manager 41, and integrated API 65 are all part of the facility gateway 21 in Figure 1. The high-capacity pump application 44, syringe pump application 43, and other applications 42 are all part of the equipment application 23 in Figure 1. The equipment manager 41 with associated database 45 can be the equipment manager 24 in Figure 1.

[0088] The high-volume pump ("LVP") application 44 is an application that corresponds to the LVP 36. The syringe application 43 is an application that corresponds to the syringe pump 38, and the other applications 42 are applications that correspond to other devices 39. The other applications 42 and other devices 39 can correspond to any medical device.

[0089] The device gateway 40 provides publish / subscribe data connections 58-64. Applications 42, 43, and 44 also provide publish / subscribe data connections 49-57. The publish / subscribe messaging pattern enables communication between the device gateway 40 and / or applications 41, 42, 43, 44, 65, and 72. However, in other embodiments, a different messaging pattern may be used for communication.

[0090] The CQI listener 72 subscribes to various data feeds from applications 42, 43, and 44 and reports CQI messages to the CQI manager 29, which can store them in the database 30. The CQI listener 72 can report the unprocessed results of published connections 49-57 and / or 58-64 and / or configure the format of those results.

[0091] In some embodiments, applications 42, 43, and 44 format the unprocessed events from each of the devices 36-39 (received via subscription to topics registered by the device gateway 40) into CQI messages. Applications 42, 43, and 44 can register CQI topics that are subscribed to by the CQI listener 72. Applications 42, 43, and 44 publish CQI messages to those CQI topics, thereby allowing the CQI listener 72 to receive the CQI messages. The CQI listener 72 sends the CQI messages to the cloud service 28.

[0092] In certain embodiments, a single GUI interface 33 can be used to view CQI messages in the database 30, while simultaneously creating DAL files 35 used for devices 36, 37, 38, and 39. Software updates 34 can also be sent to the device gateway 40 to update medical devices 36, 37, 38, and 39.

[0093] Figure 3 shows Figure 73 illustrating an aggregation of several facilities 76-80 for communication according to one embodiment of the present disclosure. Each of the facilities 76-80 may include a facility gateway 21 (see Figure 2) for communicating with a cloud service such as an infusion safety manager 74. In some embodiments, the facilities 76-80 are part of a group of facilities that share a common infusion safety manager 74 that is inaccessible from other facilities not in the group of facilities 76-80. The group of facilities 76-80 in Figure 3 communicates with the infusion safety manager via a communication link 344. Such a configuration can be used to combine the group of facilities 76-80 into a larger organization such as an Integrated Delivery Network (IDN) 75.

[0094] Figure 4 illustrates an electronic patient care system 81 according to one embodiment of the present disclosure. The system 81 includes a facility, for example, a hospital network 82, and a cloud service 83.

[0095] The hospital network 82 includes a hospital information network 84, an EMR 85, a CPOE 86, a PIS 87, a LIS 88, an integration engine 89, an integration capability component 90, a clinical status manager 91, databases 92, 95, 98, a medical application 94, a CQI listener 93, a pump application 96, a syringe application 97, a device gateway 99, a firewall 100, and medical devices 101. In some embodiments, systems 84-88 may be outside the hospital network 82. A team of healthcare technicians 102 may be able to use the medical application 94.

[0096] The cloud service 83 includes databases 104, 105, 106, 113, a firewall 103, a CQI receiver 108, a CQI server 109, a CQI UI 110, and a DERS editor 112. Pharmacists and clinicians 111 may interface with the DERS editor 112 and / or the CQI UI 110. Security staff 107 may interface with the CQI UI 110 and / or the DERS editor 112. The DERS editor 112 and / or the CQI UI 110 may be a browser-based interface. In some embodiments, the DERS editor 112 and the CQI UI 110 may be accessed from the same browser-based interface.

[0097] HIS84 supports hospital management functions (e.g., admissions, discharges, transfers, coding, billing, collection). EMR85 tracks patients' medical history (encounters, tests, diagnoses, procedures, etc.) within healthcare institutions. CPOE86 is a system used by physicians to order clinical tests, prescription drugs, medical imaging, and other clinical procedures. PIS97 is a departmental system used by pharmacists to receive, verify, track, and record prescription drug orders. LIS88 is a departmental system used by laboratory technicians to receive and process orders for clinical specimens (e.g., tissue, blood, urine, etc.). The hospital integration engine 89 provides message translation capabilities that enable information systems 84-88 to interact with each other and external systems. Most of these engines can support various dialects of HL7. The integration engine is located in the device gateway 99 and can interact with HIS, EMR, and PIS through the hospital integration engine 89. The device gateway 99 provides a message routing engine that supports both publishing / subscription mechanisms and point-to-point routing mechanisms. The device gateway 99 also provides name resolution and capability registration functions.

[0098] Various devices 101 are used to treat patients, such as infusion devices that deliver drugs, nutrients, and hydration to patients in liquid form via intravenous (IV), subcutaneous, or other routes. Pump application 96 and syringe application 97 are applications that give software intelligence to the medical devices 101 by receiving, filtering, and analyzing unprocessed events and retransmitting higher-level interpretations. Each type of medical device within device 101 may have a corresponding device application, such as one of applications 96-97.

[0099] Using each infusion device of the machine 101, the delivery of a specific infusion fluid (e.g., a liquid form of hydration, nutrition, blood, or drug) to a specific patient can be controlled. Adjustments to the loading amount, bolus amount, or dosage in the form of a titration method can be regarded as separate infusion stages of a single parent infusion. A collection of infusions or infusion events for the same patient as part of the same treatment is regarded as an "infusion case (Story)" and can be recorded in the CQI server 109.

[0100] Infusions can be organized into a preparation stage, a programming stage, and a delivery stage. In the preparation stage, the clinician checks the infusion fluid, the patient, and the pump, connects the tubing from the infusion fluid to the pump and from the pump to the patient, and these can be recorded in the CQI server 109. In the programming stage, the clinician enters the dosage parameters into the pump, and the pump checks the parameters using the installed DAL version (this can also be recorded in the CQI server 109). In the delivery stage, the pump delivers the specified amount of infusion fluid at the programmed rate.

[0101] Each medical device 101 can detect alarm conditions (i.e., a situation where the pump is not infusing fluids), as well as warning and advisory conditions, which may or may not have serious safety consequences. Each medical device 101 can attempt to establish a secure network connection with the device gateway 99. For each infusion, each medical device 101 collects programming, infusion status, and exception events and provides them to the device gateway 99 so that they can be reported to the CQI receiver 108 as CQI messages. Each medical device 101 communicates these events to the device gateway 99, which then passes the data (directly or indirectly) to the CQI receiver 108. In some embodiments, if one of the medical devices 101 is unable to establish or maintain a valid connection with the device gateway 99, the medical device stores these events in an internal buffer so that a medical technician 102 can copy the stored events to a portable medium (e.g., a memory stick), with or without using a medical application 94. In some embodiments, the events can be downloaded via a medical application 94 running on a personal computer connected to the medical device via a USB cable.

[0102] The medical application 94 provides a browser-based tool for medical technician users 102 to monitor the health status of the medical device 101, view log files, track maintenance activities, and manage software / firmware installations. Log files, maintenance logs, and software / firmware installation and upgrade tracking data can be stored in the database 95.

[0103] The device gateway 99 can be an in-hospital device that connects to all devices 101 associated with a particular patient. In another embodiment, the device gateway 99 is a software application that can run on a facility gateway. In yet another embodiment, the device gateway 99 is software that can run on an in-hospital device (e.g., a small computer). The device gateway 99 can be a message router, a service registry, and / or a pump usage rights registry. Device applications 96-97 can register message types and publish messages to the gateway device 99. Any medical device 101, including a sensor that can be plugged into one of the medical devices 101 (see other 37 in Figure 2) (e.g., a PCA respiratory monitor), can publish data via the gateway device 99. Device applications 96-97 can function as "information refineries." Each device application 96-97 subscribes to messages from a specific type of in-hospital device among the medical devices 101 via the gateway device 99. Each device application 96-97 can synthesize CQI information, clinical information, and medical information contained in the event stream received from one or more medical devices 101 through the device gateway 99. In some embodiments, each device application 96-97 republishes its higher-level events to the device gateway 99 or to other subscribers such as a CQI listener 93.

[0104] In some embodiments, portions of the CQI message can be used for automated documentation, automated programming, and billing functions. In several other embodiments, the CQI message can be used for automated documentation from the medical device 101 to the EMR85 and / or automated programming of the medical device 101 from the eMAR system (e.g., part of the HIS84). The CQI message may include drug safety events and latency information.

[0105] The CQI listener 93 subscribes to events related to the continuous quality improvement of drug safety and ensures that they are reliably communicated to the host environment. The CQI listener 93 can store events in the database 98 for periodic transmission to the CQI receiver 108 (through the firewall 103).

[0106] The CQI receiver 108, CQI server 109, and CQI UI 110 can be provided within the host environment 83 (i.e., as a cloud service). To reduce inconsistencies between user queries and CQI data updates, a master / slave database replica (with database 105 as the master and 106 as the slave) can be used in the host environment 83. The CQI server 109 can post-process CQI events into a (reportable) summary form and store it in database 105 to reduce response times for top-level queries and presentation requests. The CQI UI 110 can provide a set of standard reports (compliance, limit violations, incremental safety, stage-by-stage events, and priority-by-priority events). The CQI server 109 can support query APIs used by the DERS editor 112 and CQI UI 110 for more detailed summaries and to examine specific CQI messages in detail.

[0107] The CQI server 109 provides analysis and query services to users using the CQI UI 110. The CQI server 109 can provide users of the CQI UI 110 with a summary table of aggregated and updated CQI messages (at configurable intervals). The purpose of this summary table is to reduce the response time of top-level CQI queries. This summary may include the following statistical indicators, namely (1) the programming mode used, such as infusions using DERS limits and infusions using wildcards; (2) violations of recommended limits and absolute limits; (3) safety information for escalation, such as setting increases / decreases in escalation amounts and violations of dose limits; (4) reportable clinical events by priority (e.g., RCE149 in Figure 5 described below); and / or (5) reportable clinical events by infusion stage (e.g., RCE149 in Figure 5 described below). Each of these summaries can calculate subtotals corresponding to the following data views: (1) organization name, (2) institution name (e.g., facility name), (3) nursing area, (4) time, and / or (5) week.

[0108] By using the Web Service Query API, the CQI UI 110 and / or DERS Editor 112 can select (1) aggregates per data view filtered by a specified selector, (2) RCE details per infusion, and / or (3) actual programming, limit, and infusion statistics (i.e., infusion cases) per patient. In some specific embodiments, the DERS Editor 112 and / or any system of the hosted service 83 may be based on a J2EE-compliant application server. Databases 104, 105, 106, and 113 may use a database administration server.

[0109] Once J2EE and the database management server are installed and configured, the following shared database tables can be imported to initialize the DERS database 113: (1) reference tables for measurement units and administration modes, (2) access control tables for administrative users, roles, privileges, and permissions, (3) DERS drug list, (4) nursing area list for the National Nursing Quality Index Database (NDNQI), (5) institution attributes, and / or (6) database tables required by the DERS editor 112. The DERS editor 112 can be used to add or edit organizations, regions, and / or access controls (each with or without attributes).

[0110] In one embodiment, the DERS editor 112 and / or the DERS database 113 can run in a single application server and database environment for multiple facilities 82. In yet another embodiment, each facility 82 can be hosted in its own virtual environment (e.g., Cloud Service 2).

[0111] In some specific embodiments, the CQI UI 110 and / or DERS editor 112 may support an HTTP / Javascript interface for users running a web browser to generate CQI reports and perform interactive detailed investigation operations.

[0112] CQI messages are received by the CQI receiver 108, which stores them in the database 105. If not all CQI messages received by the CQI receiver 108 can be processed at a predetermined rate, and / or if the buffer of the CQI receiver 108 is full, the CQI messages are temporarily stored in the database 104, and when the load on the CQI receiver 108 decreases, the messages can be retrieved from the CQI receiver 108 and stored in the database 105. The database 105 may be replicated by the database 106. The database 106 can be accessed by a user via the CQI server 109 using either the CQI user interface 110 and / or the DERS editor 112.

[0113] The records in CQI databases 105 and 106 depend on the DERS editor 112. The record includes (1) a reference table of measurement units and administration modes, (2) an access control table of administrative users, roles, privileges, and permissions, (3) a DERS drug list, (4) an NDNQI nursing area list, and / or (5) institutional attributes.

[0114] These references depend on the version of the DERS editor database 113, so consistency is desirable. One option is to share those tables between databases 113, 105, and 106. While this option is convenient, it increases the spatial join between the two databases, 113 and 105 and 106. Alternatively, the join can be reduced by maintaining read-only copies of those tables within the CQI databases 105 and 106 and implementing a procedure to update the tables when they are modified in the DERS editor 112.

[0115] The access control for CQI databases 105 and 106 is structurally similar to that of the DERS database 113, but the content may differ. Several users can be defined in the CQI server 109, but not in the DERS editor 112. Even for users appearing in both, permissions may differ (for example, some CQI data may be read-only). In some embodiments, users and their permissions and access credentials can be stored in a user database 7000, which can reside in a host environment.

[0116] Certain database tables (e.g., reportable clinical events or statistical summaries) may be required in CQI databases 105 and 106, and these can be constructed when CQI databases 105 and 106 are created.

[0117] The CQI UI 110 and / or the DERS editor 112 can each generate a DAL file 114 using data obtained from the CQI server 109 (and therefore data from database 106), as well as data obtained from the DERS editor 112 (and therefore using database 113).

[0118] The clinical condition manager 91 acts as an intermediary between the device gateway 99 and the integration engine 89, coordinating asynchronous workflows involving several parties and components.

[0119] Pharmacists and selected clinicians 111 use the DERS editor 112 to define drug limits for the institution and create a DAL file 114 (which can be in XML format, for example). Drug limits can be defined using a clearly defined, carefully managed, and well-documented process, along with controlled publication procedures. Drug limits can be specified using the DERS editor 112 in the DAL manager 5. Facility 82 can facilitate subsequent inter-institutional comparisons by using a common reference model for medications, nursing areas, administration modes, etc. DERS Editor 112 can be executed in host environment 83 so that users can access it using a web browser. In some embodiments, no client-side software is required to execute DERS Editor 112, except for a sufficient browser. DERS Editor 112 can provide drug limit values and default values compiled for each of the nursing area, medications, clinical use, drug concentration, etc. DERS Editor 112 can aggregate the search and analysis of CQI-related insights for improving the next DAL version by corresponding to the query interface with CQI Server 109.

[0120] In some embodiments, a prescription database 7002 can also be included. Prescription database 7002 can include a master list of medications and drugs that may be included in various DAL files 114. Prescription database 7002 can interface with DERS Editor 112 and the CQI Server. DERS Editor 112 can retrieve data from prescription database 7002 when creating DAL files 114. Thereby, it helps to ensure data consistency among various DAL files and facilitates the comparison of multiple DAL files 114.

[0121] FIG. 5 shows a block diagram 144 illustrating some aspects of the communication between a medical device 145 (e.g., an infusion pump) and a device application 151 (e.g., a pump application) according to an embodiment of the present disclosure. Here, the pump 145 will be described with reference to FIG. 5, but it is contemplated that any other medical device may be used instead of or in conjunction with the pump 145 to generate an event 146.

[0122] Block diagram 144 shows a medical device 145 (e.g., an infusion pump) communicating events 146 (e.g., pump events) to the device gateway 147. Pump events 146 are CQI messages, or the basis for CQI messages, or other data such as raw data from the medical device 145. Pump events 146 are operational parameters, infusion parameters, and / or other operational events. In some specific embodiments, pump events 146 can use the Simple Object Access Protocol ("SOAP") which uses web service ("WS") addressing. In some embodiments, events 146 are communicated using Representational State Transfer ("REST") which can use the full HTTP (or HTTPS) protocol.

[0123] Event 146 is, for example, an event like the one shown in Table 1 below.

[0124] [Table 1] JPEG2026065131000003.jpg234155 JPEG2026065131000004.jpg192149Table 1

[0125] Items labeled 1, 2, 3, 4, 5, 6, 7, 8, and 9 in Table 1 are categorized as pump events. When the medical device 145 is not connected to the device gateway 147, these events are stored in a buffer in the local memory of the medical device 145. When connected (and reconnected), these events are published to the device gateway 147 using a secure protocol, such as SSL, SSH, symmetric key encryption, and / or asymmetric key encryption. Alternatively, these events may be copied to a portable storage medium and manually published to the device gateway 147. As described above, the device gateway 147 can function (or include) a publish / subscribe engine configured to send pump events to relevant subscribers.

[0126] Referring again to Figure 1, pump events can be sent to the CQI manager 4, which is related to the equipment events of equipment 26. These events can be used to monitor the entire group of medical equipment 26 across multiple facilities 10. For example, a set of equipment hardware status 9.71 can be converted into a CQI message and communicated to the CQI manager 4. Users can log in to the CQI manager 4 to plan maintenance events, order new parts based on data, provide maintenance for predictive or preventive purposes, and / or order new parts for preventive or predictive reasons. Users can use deterministic heuristics to determine what to order, when to order it, and / or when to instruct some of the equipment 26 at various facilities 10 for maintenance. The CQI manager 4 can be used to manage the supply chain of parts for the group of equipment 26 and can provide real-time information about the status of the group of equipment 26. For example, a set of equipment hardware status may include battery information such as the current at full charge, indicating the health of the built-in battery. For all or a subset of the devices 26 in several facilities 10, if the battery health falls below a predetermined threshold, the CQI manager 4 can automatically order new batteries. In addition, or instead, the CQI manager 4 can automatically schedule battery replacement for the identified devices 26.

[0127] Referring again to Figure 5, a device application 151 (for example, a pump application configured to work with a pump) can be run on the gateway 147 (which may be different hardware and / or software depending on the embodiment). The device application 151 subscribes to events published by the medical device 145.

[0128] The pump application 151 processes the stream of raw events and refines it into a higher-level stream of clinical events, e.g., reportable clinical events 149, which may be reported to a server of a hosted cloud service for storage (e.g., database 30 in Figure 2).

[0129] In some embodiments of this disclosure, the device application 151 is deployed on the J2EE application server as a message-driven bean ("MDB"). The MDB is a stateless component that subscribes to a Java Message Service (JMS) topic, such as a pump topic 150. When a message becomes available, the application server on the device gateway 147 can start the device application 151 in a worker thread.

[0130] The equipment application 151 is a stateful component that holds one instance of a pump handler 153 for each pump 145 located in the engine. The pump dispatcher 152 maintains a reference table of pump handlers 153, using the sequential number of the pump 145 as a unique key.

[0131] The pump MDB accesses the pump application 151 using the application server's naming service. The pump MDB obtains the sequential number of pump 145 from the message header and uses the pump dispatcher 152 to find the appropriate pump handler from among the pump handlers 153. If an individual pump handler 153 is busy (e.g., processing another message or in another thread), the pump MDB places the message in the pump dispatcher 152's queue (ensuring that messages are processed in order). If an individual pump handler 153 is not in use, the pump MDB requests the individual pump handler 153 to process the event. Each pump handler 153 maintains a set of finite state machines ("FSMs"), and each FSM processes a subset of relevant pump events (see Table 1 above), including pump FSM 156, program FSM 157, and fluid delivery FSM 158.

[0132] The pump FSM156 is the top-level state machine that handles events not belonging to any particular infusion. The program FSM157 is a child state machine that is activated when the infusion programming context begins and is responsible for handling infusion programming events. The fluid delivery FSM158 is a child state machine that is activated when the execution of an infusion begins and is responsible for handling operational events during the infusion. Since secondary infusions (including load, bolus, or escalation) may be programmed while a primary infusion is in progress, separate programming FSM157 and fluid delivery FSM158 can be used.

[0133] An operational model of the medical device 145, for example, a pump FSM 156, can be used to construct a reportable clinical event (RCE) 149 or a reportable medical event (RBE) 148. For example, the pump FSM 156 can track the pump 145 when it completes one infusion and restarts another infusion that was interrupted, track the programming of one infusion while another infusion is running, and / or track two or more high-priority operational alarms that may occur at the same time. In other words, the pump FSM 156 can include nested state models.

[0134] Each pump handler 153 may also maintain several context objects that hold information about the programming and infusion context. Such context objects are generated as medical events (to track pump usage) upon completion and are retained so that they can be recovered if the pump application 151 needs to be restarted. Context objects may include infusion status, infusion mode, and infusion interval. Infusion status includes programming / infusion status data for primary and secondary infusions. Infusion mode includes programming / infusion status data for specific doses / flow rates (e.g., load, bolus, and / or escalation). Infusion interval includes infusion status over the operating period within a single infusion mode (e.g., pump running, stopped, alarm triggered, etc.). When a pump event 146 is processed, the respective FSM 156, 157, or 158 transitions to a new state, creates, updates, or deletes a context object, and outputs a reportable event (CQI message), such as a reportable medical event 148 or a reportable clinical event 149. A list of reportable clinical events in specific embodiments of this disclosure is shown in Table 2.

[0135] [Table 2] JPEG2026065131000006.jpg187154 JPEG2026065131000007.jpg140152Table 2

[0136] Referring to Figure 4, the CQI listener 93 in Figure 4 can run within each facility 82, connect to an equipment gateway (99 in Figure 4 or 147 in Figure 5), and subscribe to CQI RCE 149 or CQI RBE 148. The CQI listener 93 in Figure 4 can establish a secure private connection with the CQI receiver 108 (see Figure 4) in the host environment 83. This connection may be a physical connection (always connected) or a logical connection (temporary connection when sending messages).

[0137] The device gateway 147 can send an RCE 149 or RBE 148 to the CQI listener 93. The CQI listener 93 can guarantee message persistence (i.e., that messages are not lost during transmission due to network congestion or disconnections). As a result, the CQI listener 93 can (1) store each message to be transmitted in a local permanent queue (for buffering), (2) send each RCE 149 and / or RBE 148 from the front of the queue to the CQI receiver 108, and / or (3) remove the message after receiving an acknowledgment from the CQI receiver 108.

[0138] The CQI receiver 108 runs within the host environment of the host environment 83. The CQI receiver 108 waits for and accepts requests for secure network connections from one or more CQI listeners 93. The CQI receiver 108 receives RCE 149 from each connected CQI listener 93. The CQI receiver 108 can guarantee message persistence and therefore writes each RCE 149 to the database 105 upon receipt. The CQI receiver 108 can (1) store each received message (CQI message) in a local permanent queue (for buffering purposes), (2) add each CQI message from the head of the queue to the end of a table in the CQI event database, (3) notify the CQI listener 93 that sent the message of receipt, and (4) remove the CQI message from the local queue (as it is in the CQI event database 105 and is secure).

[0139] As described above, the CQI event database 105 is implemented using a master / slave replication model, where database 105 is the master and database 106 is the slave. In this configuration, in some specific embodiments, there are two copies of the CQI event database with the same schema. When insert, update, and delete transactions are applied to the master database 105, the database management system (DBMS) within database 105 can write the changes to a journal and send unnotified changes to the slave database 106.

[0140] Each CQI message (e.g., RCE) may belong to a specific agency. This agency reference must match the agency that operates the medical device (e.g., medical device 101 in Figure 4 or medical device 145 in Figure 5) and has published the drug management library (DAL) located in that device. Consequently, the CQI databases 105 and 106 may require a list of agencies that are consistent with the DERS database 113.

[0141] Figure 6 is a state diagram illustrating a programming method 161 for an infusion device (for example, in device 16 in Figure 1) according to one embodiment of the present disclosure. Method 161 is initiated with a user capable of taking the device's UI and interface.

[0142] Intravenous fluid programming begins in the state indicated as "Start" in the diagram. State 162 is when basic mode programming is used (for example, when a DERS compliance exception device is used). When programming is performed using a DERS compliance exception device, the method transitions to state 165, in which state the drug programming is complete.

[0143] In state 166, DERS-based protection is used, dosage parameters are programmed into the device, and if no limit violations are detected, the procedure transitions to state 165. If a recommended limit violation or an absolute limit violation is detected, method 161 transitions to state 167. In the case of a recommended limit, the clinician can restart method 161 from state 166 by (1) overriding the recommended limit to advance the method to state 165, (2) programming the infusion attributes without changing the contents of the infusion and proceeding to state 165 if no new violations are found, or proceeding to state 167 if new violations are found, or (3) changing the contents of the infusion (e.g., changing the drug, nursing area, clinical use, and / or concentration).

[0144] If an absolute limit is detected, the method is required to transition from state 166 to state 167, and then transition back to state 166 in state 167, not allowing the clinician to override the DERS violation.

[0145] Infusion method 161 can be canceled during many conditions. In basic mode programming condition 162, the clinician can cancel the infusion before programming is complete. In DERS programming condition 166, the clinician can cancel the infusion before programming is complete. In condition 167, if a violation of the DERS recommended limit or absolute limit is detected, the clinician can cancel the infusion.

[0146] In state 165, the medical device displays a "Start Infusion" button, and the caregiver presses this button to transition the medical device to state 163 and begin infusion. In state 163, a pause button may be present on the user interface, and when this button is pressed, the device pauses, transitioning it to state 164. In state 164, a continue button may be present on the user interface, and when this button is pressed, the device returns to state 163 and treatment continues. If a fatal error (a predetermined set of errors) is detected in state 163 and / or 164, method 161 transitions to the termination state.

[0147] Once the infusion is complete, the pump sends an infusion completion message to the clinical server via the device gateway. The clinical server associates the completion event with the prescription record. The clinical server can then format the IHE automated documentation message and send it to one of the facility IT applications 11 (see Figure 1) for, for example, recording in the electronic medical record ("eMar"), updating the patient's electronic medical record (EMR) 17, and / or updating the hospital billing system to record that the drug infusion was successful.

[0148] Figure 7 illustrates a publishing / subscription model 168 used by the facility gateway 21 in Figure 1, applications 41, 42, 43, and 44 in Figure 2 or 4, and the equipment gateway 40, according to one embodiment of the present disclosure.

[0149] This model uses a publishing / subscription engine 169 that allows publishers 171 to register one or more topics 170 with the publishing / subscription engine 169. Once a topic 170 is registered, one or more subscribers 172 can subscribe to that topic 170. In some specific embodiments, subscribers 172 can subscribe using guaranteed subscriptions to the topic 170. When one of the publishers 171 posts an event related to topic 170, all subscribers 172 who subscribe to that topic 170 receive data from the publishing / subscription engine 169.

[0150] A publisher (publisher 171) can register one or more topics 170. Each topic 170 can be unique. One or more subscribers 172 can subscribe to one or more topics 170 and receive events from them. When publisher 171 posts an event for a specific topic within topic 170 (e.g., "Topic 1"), all subscribers who subscribe to Topic 1 within topic 170 will receive the event, while subscribers who do not subscribe to Topic 1 within topic 170 will not receive the event. A subscriber 172 who subscribes to another topic within topic 170 (e.g., Topic 2) but not to Topic 1 will not receive the outgoing event corresponding only to Topic 1.

[0151] Topic 170 can, in some embodiments, provide a certain level of indirectness and allow for the anonymity of publisher 171 and subscriber 172. The publishing / subscription engine 169 can make communication one-way and asynchronous (e.g., "fire and forget" type communication). The publishing / subscription engine 169 can provide persistent message delivery on both sides. The persistent topic of topic 170 can ensure that messages are not lost even if the publishing / subscription engine 169 fails. The persistent subscription used for subscriber 172 can ensure that messages are not missed when subscriber 172 is not running.

[0152] The publishing / subscription engine 169 can be part of the device gateway 22, part of any other software within the facility gateway 21, or a standalone application as shown in Figure 1. The publishing / subscription engine 169 can be part of the device gateway 40, applications 41-44, or a standalone application as shown in Figure 2. The publishing / subscription engine 169 can be part of the device gateway 99 in Figure 4, parts of applications 94, 96, and 97, or a standalone application as shown in Figure 4.

[0153] Figure 8 shows a capability registration model 173 according to one embodiment of the present disclosure. Provider 176 registers its capability 175 with a capability registry 174. Capability 175 may include two aspects: an interface and attributes. The interface is a list of request / response pairs and notifications (bidirectional). Attributes are agreed service level parameters that specify limitations on the quality of delivery (e.g., response time, error rate and recovery policy, cost, etc.).

[0154] The initiator 177 can communicate with the capability registry 174 to discover capability 175 and bind to capability 175. The initiator 177 can then request information from the provider 176 and receive a response. The capability registry 174 can be part of the device gateway 22, part of any other software in the facility gateway 21, or a standalone application as shown in Figure 1. The capability registry 174 can be part of the device gateway 40, applications 41-44, or a standalone application as shown in Figure 2. The capability registry 174 can be part of the device gateway 99 in Figure 4, parts of applications 94, 96, and 97, or a standalone application as shown in Figure 4. In some specific embodiments, the capability registry 174 can assist or replace the publish / subscribe engine 169.

[0155] Figure 9 shows a drug safety method 115 used to generate a DAL file according to one embodiment of the present disclosure. Method 115 can be used with System 1 in Figure 1, System 27 in Figure 2, System 81 in Figure 4, or any other electronic patient nursing system. Method 115 is just one of many methods that can be used to generate a DAL file; they may differ depending on the embodiment.

[0156] Stakeholders such as pharmacies and clinical nursing areas (e.g., users selected from 6, 7, 8, 9, 18, and 19 in Figure 1, or 102, 107, and 111 in Figure 4) can be selected to assist in the generation and definition of the DAL file 35 (see Figure 2), which includes drug administration safety rules that can take into account the type of drug, clinical nursing group, clinical nursing area, mode (e.g., volume-based, flow-based, or weight-based, administration policy (load, bolus, ramp), etc.), concentration, etc.

[0157] Method 115 includes operations 116 and 117. Operation 116 includes operations 118-125 as subordinate operations, and operation 117 includes operations 126-127 as subordinate operations. Operation 116 generates a DAL file, and operation 117 monitors the use of the DAL file and helps notify of updates to the DAL file 35 (see Figure 2).

[0158] Operation 122 sets up a DAL file, for example, an initial DAL file or a template DAL file that does not contain field entries. Operation 123 receives changes to the DAL file according to input from one of the selected users (for example, via the DERS editor 112 in Figure 4). Operation 121 checks the DAL file by running the medical device simulator, for example, via the DERS editor 112 in Figure 4. After checking in operation 121, the experimental DAL file can be published (electronically) in operation 120. The experimental DAL file is approved in operation 118. However, adjustments can also be made to the DAL after the experimental version is completed. Operation 118 can be performed by clicking the "Approve" button in a web browser to approve the use of the referenced file (referenced, for example, by version number or creation date).

[0159] In operation 119, the DAL file is published and sent to the medical device. In operation 125, the CQI server retrieves reference data (i.e., drug, nursing area, administration mode, etc.) from the DAL file. Once the DAL is published, the file containing the drug record is published to both the hospital and the CQI environment. After publication in operation 119, medical technicians can install the DAL file on each device. In operation 126, the medical device sends a CQI event to the CQI receiver 108. The CQI event sent in operation 126 may be generated during treatment performed by the device using the DAL file in operation 127.

[0160] During operation, medical devices generate CQI events (i.e., CQI messages). CQI messages may include information such as when a normal infusion was administered, when the infusion skipped a DERS test, when recommended limits were exceeded and overridden, and / or when recommended or absolute limits were exceeded and the treatment was reprogrammed.

[0161] CQI events are sent to the CQI server in operation 126, where the server collects and stores them. Safety personnel can manage a report summarizing these events and provide the ability to conduct a detailed investigation to find opportunities to improve procedures in operation 124. Similarly, in operation 124, pharmacists and clinicians can query the CQI database to find opportunities to improve drug records when the DAL file is next published. In other words, in operation 124, CQI messages are analyzed or reviewed. In operation 123, changes can be made to the DAL file to create a new version of the DAL file. Then, as described above, the new DAL file can be reviewed, experimentally created, and published.

[0162] In some embodiments, creating a DAL file using a DERS editor such as the DERS editor 112 in Figure 4 is a collaborative process involving several individuals or stakeholders. By accessing the DERS editor and interacting with its user interface, all individuals or stakeholders involved in creating the DAL file can contribute to its creation. In some embodiments, accessing the DERS editor does not require any client-side software other than a sufficient web browser. In some embodiments, the DERS editor's user interface can be accessed via an application such as a tablet computer. Individuals or stakeholders involved in creating the DAL file can access the DERS editor and contribute to the DAL file using a computer with internet capabilities, a tablet computer, a smartphone, etc.

[0163] Each individual or party involved in the construction of a DAL file may have specific roles, responsibilities, and / or privileges assigned to them. Such roles can be assigned using access control lists (ACLs) and / or role-based access control (RBAC) models. Roles and responsibilities can be performed as part of the methods used to generate the DAL file. Roles, responsibilities, privileges, etc., can be assigned to build a collaborative process. Assigning them can also encourage as much input and oversight as possible for DAL file generation. This ensures that the DAL file created in the collaborative process is well-crafted and minimizes drug errors as much as possible. Various user roles and privileges can be stored in a user database (not shown) hosted within the host environment. In some embodiments, various roles and privileges may instead be stored in a DERS database.

[0164] The DERS editor also allows users to provide voluntary contributions, feedback, requests, comments, annotations, questions, etc., which can be used to build or improve DAL files. If a user discovers problems, concerns, or potential improvements during the experimental creation, simulation, or daily use of a DAL file, they can submit a change request to address them. Such requests can be linked to CQI data or specific CQI reports to provide context to the reviewer.

[0165] CQI data can be easily accessed when contributing to DAL files, and the degree of access may vary depending on the user or stakeholder. This information can be presented in an easy-to-understand format within the DERS editor's user interface. In some embodiments, at least a portion of this data can be presented in the form of graphs, diagrams, or other visual aids. Users can also use the DERS editor to remove unnecessary CQI data, thereby presenting them with a more concise data set focused on the data of interest. The availability of this CQI data can be used by individuals or stakeholders to help notify decisions regarding changes to various items, etc. This data can also be used to evaluate the appropriateness of various entries in the DAL file.

[0166] Furthermore, the creation and modification of DAL files via the DERS editor can be made a fully traceable process. Each input or modification made in the DERS editor can be linked to a unique user login or ID associated with a specific individual or party. Each item that can be modified within the DERS editor can be associated with a stored history record that contains all past comments, annotations, changes, requests, parameter values, etc. related to that item.

[0167] Figure 10 shows an exemplary conceptual diagram illustrating the possible roles, responsibilities, and privileges of individuals and stakeholders involved in collaboratively creating a DAL file. This exemplary diagram is just one of many possible examples, and different configurations are possible in alternative embodiments. For example, some parties / stakeholders may be combined or omitted. Roles and responsibilities may also differ. As shown in the diagram, roles, responsibilities, and privileges can be assigned to facilitate the creation of a thoughtful DAL file that minimizes the likelihood of potential drug errors. In this exemplary embodiment, publishing the DAL file requires multiple reviews of the entries and agreement from multiple parties.

[0168] Each party can contribute to the DAL file using a DERS editor, such as the DERS editor 112 shown in Figure 4. In some embodiments, various parties can access the DERS editor via a user interface that can be accessed via a web browser. Several parties are shown on the left side of the figure. Other embodiments may include even more parties, or fewer parties than those shown in the figure. Depending on the embodiment, some parties are a single individual, while in other embodiments they are at least one group of multiple individuals. In some embodiments, two different parties may actually be the same individual or person performing different roles. The parties shown in the example in Figure 10 include a drug library administrator 200, a resource clinician 202, a checking pharmacist 204, a dispensing consultant 206, and a clinical consultant 208. In this exemplary embodiment, the parties can be divided into two broad categories: administrators or editing users (drug library administrator 200) and checking users (resource clinician 202, checking pharmacist 204, dispensing consultant 206, and clinical consultant 208).

[0169] The drug library administrator 200 is one or more individuals, such as a physician, caregiver, or pharmacist. In some embodiments, the drug library administrator 200 is, for example, pharmacist 8 as shown in Figure 1, or safety staff 107 as shown in Figure 4. The drug library administrator 200 can be granted administrator capabilities within the DERS editor. That is, the drug library administrator 200 can have editing privileges, thereby giving them the ability to modify most, if not all, of the modifiable entries and to ultimately oversee the changes to the proposed DAL file. The drug library administrator 200 can have privileges to use most, if not all, of the functions of the DERS editor. The drug library administrator 200 may also be required to approve the finalized DAL file before it is published for use in various medical devices.

[0170] In some embodiments, the resource clinician 202 is one or more individuals such as a physician, nurse, or nursing supervisor. In some embodiments, the resource clinician 202 is the nursing supervisor 7 and / or nurse 9 in Figure 1. In some embodiments, the resource clinician 202 is the pharmacy and clinician in Figure 4. The resource clinician 202 may have the ability to review, comment on, annotate, and suggest changes to DAL files via the DERS editor. The resource clinician 202 can be divided into several subgroups. For example, in some embodiments, the resource clinician 202 can be divided into nursing area groups.

[0171] In some embodiments, the inspecting pharmacist 204 is one or more individuals such as pharmacists. In some embodiments, the inspecting pharmacist 204 is pharmacist 8 in Figure 1. The inspecting pharmacist 204 can inspect all entries in the DAL file via the DERS editor to check for any entries that may require revision. The inspecting pharmacist 204 may also have the ability to comment on, annotate, and request changes to various entries in the DAL file.

[0172] In some embodiments, the dispensing consultant 206 is one or more individuals, such as pharmacists. In some embodiments, the dispensing consultant 206 is pharmacist 8 in Figure 1. The dispensing consultant 206 can review one or more portions of all entries in the DAL file via the DERS editor. The dispensing consultant 206 can check for any entries that may need revision, and may also have the ability to comment on, annotate, and request changes to various entries in the DAL file.

[0173] In some embodiments, the clinical consultant 208 is one or more individuals such as a physician, nurse, nursing supervisor, risk manager, or other appropriate staff member. In some embodiments, the clinical consultant 208 is the nursing supervisor 7, nurse 9, medical technician 19, and / or risk manager 6 in Figure 1. In some embodiments, the clinical consultant 208 is the safety staff 107 in Figure 4. The clinical consultant 208 may be involved in making a trial DAL file. The clinical consultant 208 may have the ability to review, comment on, annotate, etc., entries in the DAL file or parts of entries in the DAL file.

[0174] As shown in Figure 10, DERS is first set up in DERS setup operation 122. This operation allows various parties to be identified and assigned user IDs, thereby granting them different degrees of DERS functionality. This operation also allows the environment in which DAL files are used to be divided into several different sub-environments or groups. This can be done according to the organizational hierarchy of the environment. For example, a hospital can be divided into the nursing groups that comprise it (ICU, ER, NICU, oncology, etc.).

[0175] In various embodiments, the roles, responsibilities, and privileges assigned to each party may differ. For example, in some embodiments, a larger number of parties may be required to approve the DAL file before it is made public for use in various medical devices. Different parties can be assigned higher or lower levels of software functionality.

[0176] Next, in the drug list customization step 210, one or more DERS drug lists can be set up. As shown in the illustrative conceptual diagram, the drug library administrator 200 may be the only party with the privilege to perform this. In some embodiments, this step may be performed by a pharmacist, for example. In drug list customization step 210, all drugs available in one or more facilities using DAL can be combined into a single list. Also, if a drug has several different names or aliases, these can be defined and associated with each drug. Other information can also be defined for each drug. The complete drug list created in drug list customization step 210 can be used in subsequent steps to ensure consistency and improve efficiency. In some embodiments, the complete drug list can be created by selecting drugs from a master list or by selecting drugs provided by the DERS editor service. In some embodiments, the complete drug list can be created by selecting various drugs from a master list of drugs stored in a prescription database in the host environment.

[0177] In the example in Figure 10, step 212 of the nursing area drug record allows the drug library administrator 200 to perform a sub-step 214 to select drugs and specify records. In this sub-step, various drugs identified in step 210 can be selected for inclusion in a specific sub-department or nursing area / group of the institution. For example, in a hospital, a subset of drugs defined in step 210 can be selected as drugs used in the hospital's intensive care unit. The various drugs selected for each nursing group can then have their records modified to suit the needs of each nursing area within that nursing group. For example, in this step, drugs for a particular nursing area may have various designations such as clinical use, concentration, and restrictions. In some embodiments, this step can be performed by one or more pharmacists in addition to, or together with, the drug library administrator 200.

[0178] Once the drug selection and record designation substep 214 of the nursing area drug record step 212 is completed, the verification substep 216 for each nursing area can be performed by at least one resource clinician 202. In this substep, the selected drugs and their records are checked and verified for each nursing area. In a hospital, one or more nurses or physicians who are responsible for or work in a particular nursing area can be the resource clinician 202 who performs this substep for that nursing area. In this substep, the resource clinician 202 can provide feedback on the various drug selections and records for each nursing area.

[0179] In inspection step 218, the drug selections and records made in nursing area drug record step 212 are reviewed to ensure they are appropriate and correct. In the example in Figure 10, in the editing and revision substep 220, the drug library administrator 200 edits and modifies records that may require such action. This may include addressing feedback or requests generated by the resource clinician 202 in nursing area drug record step 212. It may also include addressing any feedback, concerns, requests, etc., from other parties involved in inspection step 218.

[0180] In inspection step 218, the substep of inspection 222 for each nursing area can be performed by at least one resource clinician 202. In this substep, selected medications and their records are inspected for each nursing area. In a hospital, one or more nurses or physicians who are responsible for or work in a particular nursing area can be the resource clinician 202 performing this substep for that nursing area. In this substep, the resource clinician 202 can provide feedback or requests for changes regarding the various medication selections and records for each nursing area.

[0181] Furthermore, the substeps of the inter-nursing area inspection substep 224 and the nursing group inspection substep 226 can be performed by the inspection pharmacist 204 and the dispensing consultant 206, respectively. In the inter-nursing area inspection substep 224, the inspection pharmacist 204 inspects the drugs selected for each nursing area and their records, and can generate feedback indicating any concerns, suggestions, or requests. In the substep of the nursing group inspection 226, the dispensing consultant 206 can inspect the nursing group's drug list, drug records, and feedback indicating any concerns, suggestions, or requests. There may be multiple dispensing consultants 206, each assigned to a specific nursing group. In some cases, the dispensing consultant 206 may also inspect other records. For example, in some cases, dispensing consultant 206 may also review records for all drugs within the institution that are considered to pose a high risk if delivered incorrectly.

[0182] In the experimental creation step 228, all parties shown in Figure 10 (and possibly other parties not shown in Figure 10) participate in the experimental creation of the new DAL file generated through steps 210, 212, and 218. In the experimental creation step 228, various parties can use the pump simulator in the DERS UI to inspect or check all entries in each nursing area. In some embodiments, a temporary DAL file can be created and sent to the medical device for testing. Various parties can inspect and check that DAL file in the UI of the medical device for testing. Feedback generated by the various parties involved in the experimental creation step 228 is addressed, and any necessary changes can be made to the DAL file.

[0183] To complete a DAL file, it may need to go through approval step 230. In this step, various parties can approve the DAL file and thus make it available to medical devices within the institution. In the example in Figure 10, the drug library administrator 200 and resource clinician 202 are required to approve the DAL file. Depending on the implementation, the number of parties required to approve the DAL file before publication may be greater or less. After approval step 230, the DAL file can be made available for use within the institution.

[0184] In various embodiments, DAL files can be structured hierarchically. That is, a DAL file can contain multiple higher-level and lower-level entries, or parent and child entries, that specify the settings of the DAL file. These entries can be structured in various hierarchical levels. As you move down the hierarchy, the entries in the DAL file can become more specific. For example, a parent entry broadly defines parameters and limitations, while child entries can further narrow down or refine those parameters and limitations.

[0185] Figure 11a shows an example of a hierarchical structure of a DAL file. As shown in the figure, the example hierarchical structure shown in Figure 11a resembles an institutional / organizational hierarchy. In some embodiments, the hierarchical structure of a DAL file may differ. For example, some DAL files may not include the nursing group and / or organizational hierarchy shown in Figure 11a. This may be particularly true for DAL files used in small, independent institutions.

[0186] As shown in the diagram, the top level of the exemplary hierarchy for DAL files can be the organization 2350 in which the DAL files are used. Below organization 2350, there can be constituent agencies 2352 that make up organization 2350. Depending on the DAL file, agency 2352 may be at the top level of the DAL file hierarchy. This is the case, for example, when a DAL file is created in agency 2352, which is not part of organization 2350.

[0187] Each institution 2352 can be divided into several nursing groups 2354. Each nursing group 2354 can contain several nursing areas 2356. A nursing group 2354 is an organizational category to which several nursing areas 2356 can belong. For example, several ICU-type nursing areas 2356 (e.g., neonatal, pediatric, adult, internal medicine, surgery, cardiology, neurology, trauma, burn, etc.) can be grouped together to form an ICU nursing group 2354. Each nursing area 2356 may include several unique drug or medication records 2358 associated with that nursing area 2356.

[0188] Several parameters can be defined at various levels of the hierarchy. The definition of such parameters can be part of the process by which the DAL file is created. Such parameters may include, but are not limited to, various operational settings, data format settings, acceptable input ranges or values ​​for data in medical devices, and safety measures (guardrails) or limitations for treatments and medical devices. Several examples of settings that can be defined in a DAL file are described herein. Other settings may be included in some embodiments. In some cases, values ​​defined at higher levels in the hierarchy may function as parent values ​​for other values ​​defined at lower levels in the hierarchy.

[0189] In some embodiments, the same parameter can be defined at multiple levels of the hierarchy. In such embodiments, when a user specifies a parameter value at a lower level of the hierarchy, the child parameter value (the value defined at the lower level of the hierarchy) can default to the value defined in the parent parameter (the value defined at the higher level of the hierarchy). The user can change the values ​​of those children. In some embodiments, the user may only be able to change the value to a more restrictive value. For example, suppose a user defines an absolute upper limit for patient weight at the nursing group level. That value can then function as the default setting for the same parameter in any nursing area included in that nursing group. If the nursing group includes a nursing area for pediatric patients, the user may want to make the high absolute limit for patient weight more restrictive, and may be allowed to do so. Such inheritance of parameter values ​​can facilitate the creation and improvement of DAL files, as well as increase usability and efficiency.

[0190] As another example, nursing group 2354 may have several drugs associated with it. A drug record 2358 corresponding to a drug defined at the nursing area 2356 level within nursing group 2354 can specify the clinical use and concentration of that particular drug appropriate for that particular nursing area 2356. For example, in nursing group 2354 consisting of five nursing areas 2356 that use similar drugs, the user only needs to add the common drugs to the nursing group 2354 level, rather than adding them once for each nursing area 2356 of nursing group 2354. Adding a drug to nursing group 2354 will then allow that drug to be added to the nursing area 2356 of that nursing group. Also, in some embodiments, the user can define some or all parameters for each common drug at the nursing group 2354 level. Those parameters may then be inherited as default values ​​for their respective child parameters in each nursing area 2356 within nursing group 2354. Such a configuration facilitates the creation and improvement of DAL files, while also increasing usability and efficiency.

[0191] Furthermore, in some embodiments, some levels of the exemplary DAL file hierarchy can be divided into several sublevels. For example, drug record 2358 can be divided into general drug settings, clinical use settings, and settings for specific concentrations of the drug. Such sublevels can further have their own hierarchical structures.

[0192] Figure 11b shows another exemplary embodiment 4500 of the DAL file hierarchy. As shown in the figure, the DAL file hierarchy 4500 shown in Figure 11b includes several additional levels compared to the hierarchy shown in Figure 11a. Other embodiments may include different levels or a different number of levels. Users may be able to define various parameter values ​​to create DAL files at each level shown in the figure. In some embodiments, the same parameter value or related parameter value may be defined at multiple levels of the hierarchy. In such cases, a value defined at a higher level of the DAL file hierarchy 4500 can act as the parent value of the same or related value at a lower level of the DAL file hierarchy 4500. It should also be noted that each level of the DAL file hierarchy that makes up the higher levels of the DAL file hierarchy 4500 may have multiple components. For example, referring again to Figure 11a, multiple nursing groups 2354 may constitute one institution 2352.

[0193] As shown in Figure 11b, the top level of the DAL file hierarchy 4500 is the IDN or organization 2350. One level below that is the region 4502. This level may be included in cases where the IDN includes several institutions dispersed across a wide geographical area. In other embodiments, this level of hierarchy can be used to create groups of similar institutions (e.g., emergency nursing centers, clinics, etc.).

[0194] The next level of the DAL file hierarchy 4500 is shared. Users can define various settings at the institution level 2352. Users can also define general settings 4504. Users can also define medications and medication categories 4506 at this level. In some embodiments, this may be done at a higher level of the DAL file hierarchy 4500. These can be defined by creating a master medication list for one institution and then dividing it into several categories. Users can also define parameters for medications and categories 4506. Any values ​​defined at this shared level of the DAL file hierarchy 4500 can serve as parent settings at the nursing group level 2354 of the DAL file hierarchy 4500.

[0195] Users can define various parameters at the nursing group 2354 level of the DAL file hierarchy 4500. Users can define one or more drug records 2358 and their parameters for each nursing group 2354. The parameters defined in nursing group 2354 can function as parent settings for any drug record 2358 defined in nursing group 2354. The parameter settings in nursing group 2354 can also function as parent settings for entries in nursing area 2356 within nursing group 2354. Furthermore, drug records 2358 and their associated parameters defined in nursing group 2354 can be automatically included in nursing area 2356 within nursing group 2354.

[0196] Users can define various parameters at the nursing area 2356 level of the DAL file hierarchy 4500. For each nursing area 2356, users can define one or more drug records 2358 and their parameters. The parameters defined in a nursing area 2356 can function as parent settings for any drug record 2358 defined in that nursing area 2356.

[0197] As shown in the figure, drug record 2358 is divided into several sublevels. In the exemplary embodiment of Figure 11b, drug record 2358 contains a sublevel of drug 4508, which is at the top of its internal hierarchy. The user can select a drug name from the master drug list to fill in the sublevels of this hierarchy. This may correspond to any parent value defined for that drug in the master drug list or drug category list. The user may also define other parameters in the sublevel of drug 4508. Any value defined in the sublevel of drug 4508 can function as a parent value for the sublevel of clinical use 4510. The user can define various parameters in the sublevel of clinical use 4510. These values ​​can function as parent values ​​for the sublevel of concentration 4512. The user may also define various parameters in the sublevel of concentration 4512.

[0198] Figures 12–71 show several exemplary flowcharts illustrating in detail several aspects of the use of the DERS editor. These flowcharts and the steps shown in them are illustrative only. In other embodiments, the use of the DERS editor may differ from that shown and described in Figures 12–71. For example, some steps may not be performed, or may not be performed in the same order as those shown and described herein. Some embodiments may include different or additional steps. It should also be recognized that some of the flowcharts shown in the figures only illustrate in detail one example of a number of possible ways of achieving the same result. Many embodiments may include multiple alternative workflows that can be employed to achieve the same final result. For the sake of brevity, not all alternative workflows considered within the scope of this disclosure are shown in the figures. The flowcharts shown and described in Figures 12–71 may be related to the various screens shown and described in Figures 72–181.

[0199] Figure 12 shows a flowchart detailing several exemplary steps that may be part of the DERS setup 122 (see, for example, Figure 9) stage for creating a DAL file. The steps detailed in the flowchart of Figure 12 can be performed before using the DERS editor in a healthcare institution. In step 240, the user can log in to the DERS hosting environment. The user may be part of the host IT of the host environment 83 in Figure 4. In some embodiments, the user is the administrator of the DERS editor service. In step 242, the user can log in to the DERS database in the DERS hosting environment. In some embodiments, the DERS database is the DERS database 113 shown in Figure 4. In step 244, the user can execute a database loading script into the DERS database. This loading script can load DERS lookup tables into the DERS database. The loading script can load DERS lookup tables used by all institutions and organizations using the DERS editor service. The reference table can load information into the database such as drugs, drug aliases, drug substitutes, drug combination contraindications, nursing area types, roles, measurement units, comment types, approval / verification status, and various attributes. In step 246, the user can verify that the database loading script is correct. In step 248, the user can load an instance of the DERS laboratory for testing. In step 249, the user can use this instance to verify that the reference table loaded into the DERS database is correct. The steps detailed in the flowchart in Figure 12 can be performed by users who have direct or remote access to the DERS host environment.

[0200] Figure 13 shows a flowchart detailing several exemplary steps that can be used to update lookup tables loaded into the DERS database. In some embodiments, the lookup tables may be the lookup tables described with respect to Figure 12. In step 250, the user logs into the DERS hosting environment. The user may be part of the host IT of the host environment 83 in Figure 4. In some embodiments, the user is the administrator of the DERS editor service. In step 252, the user can log into the DERS database in the DERS host environment. In some embodiments, the DERS database is the DERS database 113 shown in Figure 4. In step 254, the user can execute a database update script on the DERS database. This update script can update the DERS lookup tables in the DERS database. This update script can update the DERS lookup tables used by all agencies or organizations using the DERS editor service. In step 256, the user can verify that the database update script is correct. In step 258, the user can load an instance of the Inspection Agency DERS. In step 259, the user can use this instance to verify that the updated lookup tables in the DERS database are correct. The steps detailed in the flowchart in Figure 13 can be performed by a user who has direct or remote access to the DERS host environment.

[0201] Figure 14 shows a flowchart illustrating several exemplary steps that can be used to establish an institutional and organizational hierarchy in the DERS database. The various steps shown in the flowchart of Figure 14 can be performed as part of the DERS setup 122 (see, for example, Figure 9) phase of DAL file creation. In step 260, the organizational structure of an institution or organization is determined. In the simplest case, there is only one institution that uses its own DAL and has no parent organization. In other cases, one organization may contain several different institutions, all of which use the same DAL. In some cases, one organization may contain several different institutions and use at least two different DAL files. If the DERS database is used by an organization, it may include a field for the institution name. This name can be used for data comparison within the organization and can be included in CQI messages from institutions within the organization.

[0202] In step 262, a loading / update script for the organizational schema can be created. In step 264, the user logs into the DERS host environment. The user may be part of the host IT of host environment 83 in Figure 4. In some embodiments, the user is the administrator of the DERS editor service. In step 266, the user can log into the DERS database in the DERS host environment. In some embodiments, the DERS database is DERS database 113 shown in Figure 4. In step 268, the user can execute a database update script on the DERS database. This update script can create one or more new databases for the specified organizational schema. In step 270, the user can verify that the database update script is correct. In step 272, the user can load an instance of the inspection agency DERS. The user can use this instance to verify that the organizational schema updated in the DERS database is correct. The steps detailed in the flowchart of Figure 14 can be performed by a user who has direct or remote access to the DERS host environment.

[0203] Figure 15 shows a flowchart illustrating several exemplary steps that can be used when granting a subscribing institution access to the DERS Editor. In step 280, the institution or organization can sign an agreement with the provider of the DERS Editor service to subscribe to the DERS service. In step 282, the DERS Editor service can be configured to accommodate the new institution or organization. In some embodiments, this may involve setting up a database and application server for the new institution or organization. In some other embodiments, a new data set may be created in an existing database for the new institution or organization. This step can be performed by the host IT corresponding to the host environment where the DERS Editor service database, servers, etc. reside. In some embodiments, step 282 may involve performing the steps detailed in Figure 14.

[0204] In step 284, a DERS Editor Service employee (for example, the host IT in host environment 83 in Figure 4) can create a user account for an institutional or organizational user. In some embodiments, this user is a drug library administrator, such as the drug library administrator 200 shown in Figure 10. Access information for that user account can also be provided to the institutional or organizational user in this step. In step 286, the institutional or organizational user can log in to the DERS Editor. In some embodiments, the institutional user may be prompted to change their password in step 286. Then, in step 288, the institutional user can be provided with training by a DERS Editor Service employee, which will enable the institutional user to access the DERS Editor.

[0205] Figure 16a shows a flowchart detailing several exemplary steps that can be used to set up various forms of DERS within an organization or institution. Specifically, the exemplary steps shown in the flowchart of Figure 16a can be used to define users, the groups to which each user belongs, and the various permissions and privileges for each user. The steps shown in Figure 16a can be part of the DERS setup 122 steps (see, for example, Figure 9). In step 300, the user can log in to the DERS editor. In some embodiments, the user is the drug library administrator 200 in Figure 10. This can be done by accessing the user interface of the DERS editor. As mentioned above, the user interface can be accessed via a suitable web browser, and no client-side software is required. Then, in step 302, the user can proceed to the user editor on the DERS editor user interface. The user can then proceed to any of steps 304, 306, 308, and 310.

[0206] In step 304, change the group permission value for group A. In step 306, change the group permission value for group B. In step 308, change the group permission value for group C. In step 310, change the group permission value for group D. Groups A through D can be various categories of institutional employees that may exist. For example, one of groups A through D could be a pharmacist group, another a medical technologist group, yet another a nursing supervisor group, and the last a safety officer group. In various embodiments, there may be other groups corresponding to other categories of institutional or organizational employees. In some embodiments, groups can be defined by the user. In some embodiments, groups can be predefined and have a set of default group permission values ​​provided by the DERS editor service. In some embodiments, there may be no groups, and permissions may be assigned based on a specific user. Also, some groups may include subgroups (not shown). Using the assignable permissions, users can customize groups or subgroups to best suit the needs and / or current structure of their institution / organization.

[0207] Table 3 lists the possible permissions in specific embodiments of this disclosure.

[0208] [Table 3] JPEG2026065131000009.jpg62149

[0209] Continuing to refer to Figure 16a, in step 312 the user may also choose to create a new user. This may involve defining a username and temporary password for the new user. It may also involve providing an email address for the new user. The user can then proceed to any of steps 314, 316, 318, and 320. If the user selected an existing user in step 313, they can also choose to proceed from there to any of steps 314, 316, 318, and 320. In step 314, the user can assign the newly created or existing user to group A. In step 316, the user can assign the newly created or existing user to group B. In step 318, the user can assign the newly created or existing user to group C. In step 320, the user can assign the newly created or existing user to group D. In some embodiments, the user can assign the newly created or existing user to two or more groups. In some embodiments, additional steps (not shown) may be included that allow the user to further assign the newly created or existing user to other groups or subgroups.

[0210] In step 321, the DERS editor service can save the changes to the database. In some embodiments, the database is the DERS database 113 shown in Figure 4. In other embodiments, the database is, for example, a user database in the host environment. In step 322a, the DERS editor service can notify the relevant user that changes have been made. For example, if a new user account is created, the new user can be notified. As shown in 322b, in some embodiments, this may involve sending an automatically generated email message to the new user. In embodiments where the DERS editor is accessible via a suitable web browser, this message may provide the new user with a hyperlink to the DERS editor. This message may include account information and instructions detailing how the new user should use the DERS editor. It may also include a password and access information for the newly created user. Alternatively, this information may be provided to the new user manually.

[0211] Figure 16b shows a flowchart detailing several exemplary steps that can be used to define users, the groups to which each user belongs, and the various permissions and privileges for each user. The exemplary flowchart shown in Figure 16b illustrates several steps that can be used for a web browser-based DERS editor service. In step 4400, a user can log in to the DERS editor and indicate that they wish to use the user editor. In step 4402, the web hierarchy corresponding to the DERS editor can render the user editor page. The user can then choose to add a new user or update / delete an existing user.

[0212] In step 4404, the user can indicate that they wish to add a new user. Then, in step 4406, the web hierarchy corresponding to the DERS editor can render the user addition page. Then, in step 4408, the user can add various user metadata about the new user. Once the various user metadata about the new user has been added, in step 4410, the web hierarchy can create user credentials for the new user. In step 4412, the new user data can be inserted into the database. This database is, for example, the DERS editor database 113 in Figure 4, or the user database in the host environment.

[0213] When new user data is added to the database, or when a user indicates in step 4414 that they wish to update an existing user, in step 4416 the web hierarchy can retrieve the user's privileges and information. In step 4418, a query record set for the requested user can be constructed and sent to the web hierarchy. Then, in step 4420, the web hierarchy can render a user editor interface for the selected user. In step 4422, the user can make desired edits to the user and submit any changes. Such edits may include, but are not limited to, changes to group assignments, changes to privileges, deletion of users, and assignment of user responsibilities. In step 4424, the web hierarchy can update the user account data. In step 4426, the edited user data may be written to or stored in the database. Also in step 4426, a success notification may be sent to the web hierarchy to indicate that the database update was successful. In step 4428, the web hierarchy may display a success dialog box to indicate that the user account information has been updated.

[0214] Figure 17 shows a flowchart detailing several exemplary steps that can be used to update various aspects of DERS within an organization or institution. Specifically, the exemplary steps shown in the flowchart of Figure 17 can be used to update users, the groups to which each user belongs, and the various permissions and privileges for each user. In step 330, the user can log in to the DERS editor. In some embodiments, the user is the drug library administrator 200 in Figure 10. This can be done by accessing the user interface of the DERS editor. As mentioned above, the user interface can be accessed via a suitable web browser, and no client-side software is required. Then, in step 332, the user can proceed to the user editor on the DERS editor user interface. The user can then perform any of steps 334, 336, and / or 338. Performing these steps may involve following steps similar to those illustrated and described in relation to Figures 16a and 16b. In step 334, the user can change the various permissions for a group, for example, one of groups A-D shown in Figure 16a. In step 336, the user can add users to a previously created group. This can be done to add, for example, a newly hired employee to the group. In step 338, the user can individually change the permissions of users who have access to the DERS editor. In some embodiments, this step may not be included. In some embodiments, this step may be included, but steps 334 and 336 may not be included. The former may be suitable for relatively large and / or complex organizations. The latter may be suitable for small organizations or medical cases with a small total number of DERS editor users. Once the user has finished updating various aspects of the DERS editor, in step 339, the DERS editor service can save the changes made to the database. This database is database 113 in Figure 4, or in some embodiments, the user database.In step 340, the DERS editor service can notify the target users of the update. This can be achieved by sending an automatically generated email to the target users.

[0215] Figure 18 shows a flowchart detailing several exemplary steps that can be used to create or update an institution / organization's master drug list. In some embodiments, the steps shown in the flowchart of Figure 18 can be part of the drug list customization 210 described in relation to Figure 10. In step 350, the user proceeds to the institution or organization's drug list on the DERS editor user interface. Next, in step 352, the DERS editor service can display the drug list editor. The user is, for example, a drug library administrator, such as drug library administrator 200 in Figure 10. In other embodiments, the user is a pharmacist or a user granted permission 0.04 in Table 3. Proceeding to the drug list of an institution or organization, the user can either import the drug list from the DERS editor service or select one or more drugs from a master list provided by the DERS editor service.

[0216] If the user chooses to import a list from the DERS Editor Service, in step 356, the DERS Editor Service may prompt the user to select the drug list to import. This step may involve displaying a list of importable lists stored in the DERS Editor Service or a database associated with the DERS Editor Service. In step 358, the user can import the desired list. Then, in step 359, the DERS Editor Service can update the institution / organization's drug list to include the imported entries. If the user wishes to add more drugs to the institution / organization's drug list, the user can import another drug list or select drugs from a master drug list accessed via the DERS Editor Service. Once the user has finished updating or creating the institution / organization's drug list, the user can proceed to step 366, which will be described later in this specification.

[0217] If the user does not import a drug list, or if the user wishes to import a drug list and add additional drugs, the user can add the desired drugs to the organization's drug list by proceeding to step 360. In step 360, the DERS editor service may prompt the user to select drugs to add to the drug list, as shown in step 361. Such drugs may be selected by the user from a master drug list provided by the DERS editor service in some embodiments. Then, in step 362, the DERS editor service may prompt the user to enter an alias or other name for that drug. In step 363, the user may provide an alias. In step 364, the DERS editor service may request the user to provide additional information about the added drug. In step 365, the user may provide any additional information. If the user wishes to add other drugs to the organization's drug list after completing step 365, the user may decide whether to import a drug list or select drugs from the master list and proceed as described above.

[0218] Once the user has finished adding medications to the medication list, the user can proceed to step 366. In step 366, the user can indicate that they have finished adding the medications. Then, in step 367, the DERS editor service can prompt the user to save the created or updated medication list for the institution or organization. Then, in step 368, the user can save the created or updated medication list, thereby saving the medication list to a database such as the DERS database. Next, in step 369, the DERS editor service can notify the relevant users of the institution or organization that the medication list has been created or updated. For example, the DERS editor service can notify all users responsible for creating or maintaining medication lists for nursing areas that the institution / organization's medication list has been created or updated.

[0219] Referring to Figure 19, a flowchart detailing several exemplary steps that can be used when adding clinical recommendation entries to a database is shown. Clinical recommendations can provide medical device users with information about a drug. This information may include administration guidelines, information from prescriptions, contraindications, etc. In various embodiments, clinical recommendations may include text, images or graphics, and / or electronic files such as PDFs. Clinical recommendations can be free-text entries where users can enter any desired content. Depending on the embodiment, several types of clinical recommendations may be included. For example, depending on the embodiment, short-text clinical recommendations and detailed clinical recommendations may be included. Short-text clinical recommendations may be limited to a predetermined number of characters (e.g., 40 characters) so that they can be easily displayed in the medical device's graphic user interface.

[0220] These steps can be performed as part of the drug list customization 210 described in relation to Figure 10. In step 370, the user proceeds to the clinical recommendation list. The user can then decide whether to import the clinical recommendation list from the DERS editor service or add their own clinical recommendations to the clinical recommendation list. If the user decides to import the list of clinical recommendations from the DERS editor service, they can import the list in step 372. If the user decides to add their own clinical recommendations to the list, they can proceed to step 374 to add their clinical recommendations. The user can repeat step 374 as many times as necessary until they have finished adding clinical recommendations to the clinical recommendation list. In step 376, the user can log out and save the changes to the clinical recommendation list of the institution or organization. The changes can be saved in the DERS database. In step 378, the DERS editor service can notify all relevant users that the clinical recommendation list has been updated. In some embodiments, step 378 may include automatically sending an email to the relevant users notifying them of the changes.

[0221] In some embodiments, an additional step may be included that allows the user to upload files (e.g., images, documents, etc.) to the clinical recommendation. In some embodiments, the clinical recommendation cannot be added to, modified, etc. at the clinical use level. Instead, such a recommendation can be added to the drug record if the drug record is defined by the user. In some embodiments, the user can define the clinical use of the drug, as well as various clinical uses and concentrations of the drug.

[0222] Figure 20 shows a flowchart detailing several exemplary steps that can be used to change the general settings of an institution or organization. These steps can be performed as part of the DERS setup phase (see, for example, Figure 9). In step 380, the user proceeds to a list of general settings on the DERS editor user interface. As mentioned above, the list can be accessed via a suitable web browser and no client-side software is required. In some embodiments, in step 381, the DERS editor service may prompt the user to enter values ​​for various general settings. Then, in step 382, ​​the user can change, enter, update, etc., the desired values ​​of the general settings. In step 384, the user can log out and save the changes made to the general settings. The changes can be saved in the DERS database. Then, in step 386, the DERS editor service may notify all applicable users that the general settings have been changed. A non-restrictive list of possible general settings in the specific embodiments of this disclosure is shown in Table 4.

[0223] [Table 4]

[0224] Figure 21 shows a flowchart detailing several exemplary steps that can be used when adding a nursing group to an institution or organization. As described in detail above in relation to Figures 11a-11b, within the DAL file, an organization or institution can be divided into several sub-areas or groups that reflect, for example, departments within that organization or institution. The steps shown in Figure 21 can be part of the DERS setup 122 stage (see, for example, Figure 9). In step 2370, the user proceeds to the nursing group list on the DERS editor user interface. In step 2372, the user chooses to add a new nursing group to the list. When adding a new nursing group to the nursing group list, the user may have several options. In some embodiments, the user may start with an empty or nearly empty template. In the flowchart of the embodiment shown in Figure 21, the user may also choose to expedite the process by copying information about existing nursing groups. If the user chooses to copy an existing nursing group, the user proceeds to step 2374. In step 2374, the user specifies the existing nursing group they want to copy and copies it. Then, in step 2376, the user can change the type of the nursing group by changing the nursing group type to the new nursing group type. In some embodiments, the user can also adjust the nursing group settings in step 2376.

[0225] If the user chooses not to copy an existing nursing group, or if no existing nursing groups exist, the user can proceed to step 2378. In step 2378, the user specifies the type of new nursing group to be added to the list. This step may include selecting a nursing group from a list of possible nursing group types. The nursing group type can be a broad category encompassing multiple nursing areas within an institution or organization. Examples of nursing groups include ICU, emergency, pediatric, neonatal, adult, step-down, surgical, psychiatric, etc.

[0226] The user can proceed from step 2376 or step 2378 to step 2380. In step 2380, the user can rename the nursing group to match the name used for that nursing group within the institution or organization. In step 2382, the user can specify the various users to be associated with the newly created nursing group. For example, in step 2382, the user can specify several clinicians who will work for or be responsible for that nursing group. The user can also specify other individuals within the institution or organization who may be responsible for reviewing the new nursing group or contributing to the new nursing group.

[0227] In step 2384, the user can define various nursing group parameters for a new nursing group. This may involve changing default values, filling in empty templates, modifying copied values, etc. A non-restrictive list of possible nursing group parameters in a particular embodiment of this disclosure is shown in Table 5.

[0228] [Table 5]

[0229] Once nursing group parameters are specified, in step 2386, the user can save the new values. The nursing group and parameter values ​​can be saved in the DERS editor database. Then, in step 2388, the user can notify that the new nursing group is ready for review by the person responsible for reviewing it. Then, in step 2390, the DERS editor service can notify the relevant user that the nursing group has been created and is ready for review. This can be done via an automatically generated email.

[0230] In some embodiments, similar steps can be followed to add a nursing area to, for example, a DAL file. While the screens used in the DERS editor user interface may differ, the user can define similar information and parameters for the nursing area. In some embodiments, some of the nursing group parameters shown in Table 5 can instead be defined at the nursing area level, or they can also be defined at the nursing area level. Nursing group parameters can function as parent parameters for nursing areas. For example, nursing group parameters can be the default settings for the same parameters at the nursing area level. Additionally, when defining a nursing group, the user can create a list of medications that may be used within that nursing group. This can be achieved by following steps similar to those illustrated and described in relation to Figure 18.

[0231] Figure 22 shows a flowchart detailing several exemplary steps that can be used when adding a nursing area to an institution or organization. As described above in relation to Figures 11a-11b, an organization or institution can be divided into several sub-areas or groups that reflect, for example, departments within that organization or institution. The steps shown in Figure 22 can be part of the DERS setup stage 122 (see, for example, Figure 9). In step 390, the user proceeds to the nursing area list on the DERS editor user interface. In step 392, the user chooses to add a new nursing area to the list. When adding a new nursing area to the nursing area list, the user may have several options. In some embodiments, the user may start with an empty or nearly empty template. In the flowchart of the embodiment shown in Figure 22, the user may also choose to expedite the process by copying information about an existing nursing area. If the user chooses to copy an existing nursing area, the user can proceed to step 394. In step 394, the user specifies the existing nursing area they want to copy and copies that nursing area. Next, in step 398, the user can change the type of nursing area by changing the nursing area type to a new nursing area type. In some embodiments, the user can also adjust the nursing area settings in step 398.

[0232] If the user chooses not to copy an existing nursing area, or if no existing nursing areas exist, the user may proceed to step 396. In step 396, the user specifies the type of new nursing area to be added to the list. This step may include selecting a nursing area from a list of possible nursing area types. A non-restrictive list of possible nursing areas in a particular embodiment of this disclosure is shown in Table 6.

[0233] [Table 6] JPEG2026065131000013.jpg176150

[0234] The user can proceed from step 396 or step 398 to step 400. In step 400, the user can rename the nursing area to match the name used for that nursing area within the institution or organization. In step 401, the user can specify the nursing group (if any) to which the new nursing area belongs. In step 402, the user can specify the various users associated with the newly created nursing area. For example, the user can specify several clinicians who will work in or be responsible for that nursing area. The user can also specify other individuals within the institution or organization who may be responsible for reviewing or contributing to the new nursing area.

[0235] In step 404, the user can define various nursing area parameters for the new nursing area. This may involve changing default values, filling in empty templates, modifying copied values, etc. In some embodiments, the parent parameter values, i.e., values ​​defined for the same parameter at the nursing group level, can be automatically used as default values ​​for the child parameters at the nursing area level. A non-restrictive list of possible nursing area parameters in specific embodiments of this disclosure is shown in Table 7.

[0236] [Table 7] JPEG2026065131000015.jpg130150

[0237] Once nursing area parameters are specified, the user can save the new values ​​in step 406. Nursing area and parameter values ​​can be saved in the DERS editor database. Then, in step 408, the user can notify that the new nursing area is ready for inspection by the person responsible for inspecting that nursing area. Then, in step 410, the DERS editor service can notify the relevant user that the nursing area has been created and is ready for inspection. This can be done via an automatically generated email.

[0238] Referring next to Figure 23, a flowchart detailing several exemplary steps that can be used when verifying nursing areas is shown. Similar steps may also be suitable for verifying nursing groups. These steps may need to be performed by all designated inspectors before the DAL file containing that nursing area can be published. In some embodiments, these steps can define one of many processes that must be completed before the DAL file can be published. These steps may be performed in some embodiments as part of the inspection stage 121 in Figure 9, or as part of substeps 216 of the per-nursing-area verification, substep 222 of the per-nursing-area inspection, substep 224 of the inter-nursing-area inspection, and / or substep 226 of the nursing-area inspection in Figure 10. The steps shown in Figure 23 can be performed by one or more parties. For example, the steps may be performed by the nursing supervisor 7, pharmacist 8, risk management officer 6, and / or medical technician 19 in Figure 1. These steps may be performed by the resource clinician 202, inspection pharmacist 204, dispensing consultant 206, and / or clinical consultant 208 in Figure 10. The steps shown in Figure 23 can be completed using the user interface of the DERS editor, which can be accessed through a suitable internet browser.

[0239] In step 420, the user performing the inspection can proceed to the nursing area list. In some embodiments, then in step 421, the DERS editor may prompt the user performing the inspection to select a nursing area from the list. In step 422, the user performing the inspection can select the nursing area they wish to inspect or are responsible for inspecting. In some embodiments, the user performing the inspection may be responsible for inspecting all items, elements, parameters, etc., of the nursing area. In some embodiments, the user performing the inspection may be responsible for only some of the items, elements, parameters, etc., of the nursing area. In step 424, the user performing the inspection can inspect the elements of the nursing area.

[0240] In some embodiments, the user performing the inspection may be required to enter comments on all items, elements, or parameters of the nursing area when inspecting the nursing area. In the exemplary flowchart shown in Figure 23, when the user performing the inspection inspects various parameters of the nursing group, the user is required to approve the items, elements, parameters, etc., or to enter comments on the items, elements, parameters, etc. If the user performing the inspection has no concerns or questions regarding an element, in step 425 the user can indicate that they have verified that element.

[0241] If the user performing the review does not approve an item, element, parameter, etc., for the nursing area, or has other comments / feedback / questions, the user can proceed from step 424 to step 426. In step 426, the user performing the review can enter comments or questions, or provide feedback, regarding a specific item, element, parameter, etc., for the nursing area. As a hypothetical example, if the parameter for the upper absolute limit value of patient weight in the neonatal intensive care unit is specified as 70 kg, the reviewer could enter a comment such as, "This limit seems very high. It is probably a typo and a zero was added to the input. Shouldn't this value be lowered?" In some embodiments, comments may also include requests for changes, which may be accepted or rejected. If there are comments, questions, or feedback, they can be linked to the parameter so that other users or parties can see them and, in some cases, influence the comments or feedback. In some embodiments, the user performing the review may include various attachments, links, photos, CQI data, etc., in the comments.

[0242] When a user performing an inspection verifies or comments on items, elements, parameters, etc., they can return to step 424 if there are further items, elements, parameters, etc. to be inspected. If there is nothing left in the nursing area that requires inspection, the user performing the inspection may choose to provide general feedback on that nursing area. In step 428, the user can provide general feedback or comments on the entire nursing area. The comments, questions, and / or feedback provided in step 428 can be linked to the nursing area so that other users can see them and, in some cases, interact with the comments or feedback. Once the user performing the inspection has provided all the general comments and feedback they wish to offer, they can indicate in step 429 that they have completed the inspection. Various comments, questions, and feedback can be saved in the DERS editor database.

[0243] When a user notifies that they have finished inspecting a nursing area, in step 430, the DERS editor service may send a notification informing the user that they have finished inspecting the nursing area. This notification can be sent to other users or parties and may take the form of an automatically generated email message. This message may be sent to a drug library administrator, such as the drug library administrator 200 shown in Figure 10. In some embodiments, the DAL file containing the nursing area may not be published until at least one party or user has responded to all comments, questions, and feedback provided in steps 426 and 428.

[0244] Figure 24 shows a flowchart detailing several exemplary steps that can be used to update a nursing area. Specifically, the exemplary flowchart in Figure 24 details several steps that can be used to update a nursing area after an inspection has been completed. The inspection process can be similar to the process described and illustrated in relation to Figure 23. The steps shown in the exemplary flowchart in Figure 24 can be part of the editing and revision sub-steps 220 shown in Figure 10. The steps shown in Figure 24 can be performed by a user such as a drug library administrator. Nursing groups can also be updated using steps similar to those in Figure 24.

[0245] In step 440, the user can proceed to the nursing area list on the DERS editor user interface. In some embodiments, the DERS editor user interface can be accessed via a suitable web browser. In some embodiments, in step 441, the DERS editor service may prompt the user to select a nursing area. In step 442, the user can select the nursing area they wish to revise. In step 444, the user reviews any comments, questions, or feedback regarding the new nursing area, or the parameters of the new nursing area. The user may take several actions in response to each comment, question, or feedback provided.

[0246] If the user performing the inspection has a question about a nursing area or parameters within a nursing area, the user can proceed to step 446. In step 446, the user can enter an answer to the question. This answer can then be made visible to the user who performed the initial inspection. In some embodiments, after the user provides an answer in step 446, the DERS editor service can notify the user who asked the question that the answer is now visible. This notification can be sent as part of step 448. In some embodiments, the user performing the inspection may respond to the answer if necessary, or may need to indicate that they have received a satisfactory answer.

[0247] If the user who performed the review has entered comments, questions, or feedback that are not easily understood or that require further discussion, the user may proceed to step 450. In step 450, the user may enter a question regarding the initial input of the user who performed the review. This question can then be made available for the user who performed the initial review to view and respond to. In some embodiments, after the user enters a question in step 450, the DERS editor service may notify the user who performed the review that a question regarding their comments, questions, or feedback has been entered. This notification may be sent as part of step 452.

[0248] If a user who has performed an inspection has entered a comment, question, or feedback that includes a request to change the parameters of a nursing area, the user may accept or reject the change request. If the user accepts the change, they can proceed to step 454 and change the parameters of the nursing area in accordance with the change request. If the user decides to reject the change request submitted by the user who performed the inspection, the user can reject the request in step 456. In some embodiments, the user can accept or reject the change request by interacting with one or more virtual buttons included as part of the change request on the DERS editor user interface. In such embodiments, if the change request is accepted, the parameters of that nursing area can be automatically changed.

[0249] If a user who has performed an inspection enters comments or feedback that do not include change requests, do not raise questions, and do not require a response, the user may be asked to mark the comments or feedback as "read" in step 458.

[0250] When a comment, question, or feedback is addressed, the DERS editor service can update the DERS inspection status information in step 459. The user can then inspect other comments, questions, and feedback until all comments, questions, and feedback from the user who performed the inspection have been addressed. Once all comments, questions, and feedback have been addressed, the user can proceed to step 460. In step 460, the user can indicate that they have finished updating the nursing area. The update can be saved, and then the user can log out of the DERS editor in step 462.

[0251] In step 464, the DERS editor service can notify all relevant users that the nursing area has been updated and is ready for re-verification. In some embodiments, this notification may consist of an automatically generated email message. The re-verification process is described in relation to Figure 23 and may be similar to the process illustrated.

[0252] Referring to Figure 25, a flowchart detailing several exemplary steps that can be used to add drug records or medication records to a designated nursing area is shown. The terms “drug record” and “medication record” are used synonymously herein. These drug records can define the medications that may be used within a nursing area, as well as any restrictions, characteristics, etc., that may apply to those medications. The exemplary steps shown in the flowchart of Figure 25 can be performed as part of the drug selection and record designation sub-step 214 shown in Figure 10. In some embodiments, the steps in Figure 25 can be performed by a drug library administrator, such as the drug library administrator 200 shown in Figure 10. In other embodiments, another person, such as a pharmacist or another party, may be responsible for adding drug records to the nursing area. In some embodiments, drug records can be added to a nursing group using similar steps.

[0253] In step 470, the user can proceed to the list of nursing areas on the DERS editor user interface. Then, in step 471, the user can select the nursing area to which to add a drug record. In some embodiments, it may be possible to prevent the addition of a drug record to a nursing area unless its parameters have been predefined and validated. In such embodiments, the definition and validation of parameters can be achieved by performing steps similar to those illustrated and described in relation to Figures 22-24.

[0254] When a user is ready to add a drug record to a nursing area, the user can decide to add a specific drug or choose to add an unspecified drug. If the user chooses to add a specific drug, they can either copy a drug record from an existing group (step 474) or define the drug and create a drug record for the nursing area (step 476). If the user chooses to copy a drug record, they can proceed to step 474. In step 474, the user can copy a drug record for the desired drug from an existing nursing area. In some embodiments, this may involve selecting a drug record from a list of drug records displayed in the DERS user interface. Depending on the embodiment and circumstances, the user may also be able to copy drug records from different institutions. This may be particularly true, for example, if the institution is part of an IDN.

[0255] When a drug record is copied, all the rules and concentration records corresponding to that drug are also copied. In some embodiments, the user can choose not to copy some or all of the rules and / or concentration records when copying a drug record to a new nursing area. After copying the drug record, the user can repeat step 474 for any number of records required, or perform step 476 to add further drug records. If there are no more drugs to add to the nursing area after copying the drug record, the user can proceed to step 486, which will be described later in this specification. In some embodiments, a step may be included that allows the user to make adjustments and modifications to the copied nursing area.

[0256] Step 476 can be performed if the user wants to create a drug record without copying a record from another nursing area. In this step, the user can define the name of the drug for which the drug record will be created. In some embodiments, the user can select the name of the drug from a master list of drugs. Such a list may be provided by the DERS editor service or may be created within the institution or organization. A non-restrictive list of possible drug record parameters in specific embodiments of this disclosure is shown in Table 8.

[0257] [Table 8]

[0258] After defining the drug name and various drug parameters in a drug record, the user may be required to define one or more sets of rules for each drug record. Each set of rules may, in some embodiments, be provided in response to a specific clinical use of the drug or medication. The terms "set of rules" and "clinical use" are used synonymously herein. A drug may have, for example, a set of rules specifying the method of delivery when delivered as a body weight-based infusion, and another set of rules specifying the method of delivery when delivered as an intermittent infusion. An unrestricted list of other possible clinical uses may include non-body weight-based infusions, body surface area (BSA)-based infusions, continuous infusions, etc.

[0259] In some embodiments, such as the one shown in Figure 25, the user can choose to copy a set of rules for a drug from an existing drug record (step 478) or define their own set of rules for the drug (step 480). If the user chooses to copy a set of rules, they can proceed to step 478. In step 478, the user can select the set of rules to copy from an existing drug record. This may involve selecting the desired set of rules from a list displayed in the DERS editor user interface. Depending on the embodiment and circumstances, the user may also be able to copy a set of rules from a different institution. This may be particularly true, for example, if the institution is part of an IDN.

[0260] When a set of rules is copied, all concentration records corresponding to that set of rules are also copied. In some embodiments, the user can choose not to copy certain concentration records or all concentration records when copying a set of rules. After copying a set of rules, the user can repeat step 478 for as many sets of rules as needed, or perform step 480 to add further sets of rules. If, after copying a set of rules, there are no more drug records or sets of rules to add to the nursing area, the user can proceed to step 486. Step 486 will be described later in this specification. Depending on the embodiment, the step may include a step in which the user can edit or modify the set of rules that have been copied.

[0261] Step 480 can be performed by the user if they wish to create a set of rules in a drug record without copying an existing set of rules. In this step, the user can create a set of rules and define parameters for that set of rules. In some embodiments, depending on the type of set of rules being created, the user may be required to define different parameters. A non-restrictive list of possible rule set parameters in specific embodiments of this disclosure is shown in Table 9.

[0262] [Table 9] JPEG2026065131000018.jpg156148 JPEG2026065131000019.jpg135155 JPEG2026065131000020.jpg130155

[0263] Once a set of rules and its parameters are defined, the user may be required to define one or more concentration records for each set of rules. Each concentration record can be created for each concentration of the drug used in a particular set of rules. In some embodiments, such as the embodiment shown in Figure 25, the user can choose to copy the concentration records corresponding to the rule set of an existing drug record (step 482) or to define their own concentration records for the rule set (step 484).

[0264] If the user chooses to copy a concentration record, the user can proceed to step 482. In step 482, the user can select a concentration record to copy from an existing set of rules. After copying the concentration record, the user can repeat step 482 for any number of concentration records required, or proceed to step 484 to add further concentration records. If, after copying the concentration record, there are no more drug records, sets of rules, or concentration records to add to that nursing area, the user can proceed to step 486. Step 486 is described later in this specification. Some embodiments may include additional steps that allow the user to modify or adjust the copied concentration record.

[0265] Step 484 can be performed by the user if they wish to create a concentration record for a set of rules without copying an existing concentration record. In this step, the user can create a concentration record and define the parameters for that concentration record. A non-restrictive list of possible concentration record parameters in a particular embodiment of this disclosure is shown in Table 10.

[0266] [Table 10] JPEG2026065131000022.jpg156148 JPEG2026065131000023.jpg135155 JPEG2026065131000024.jpg135161

[0267] Upon completing step 484, the user can add further concentration records to the set of rules, further set of rules to the drug record, or further drug record to the nursing area. If, after completing step 484, there are no further drug records, set of rules, or concentration records to add to the nursing area, the user can proceed to step 486, which will be described later in this specification. In some embodiments, the various parameters defined in Tables 8-10 may be defined at different DAL file hierarchy levels than those shown herein. For example, some values ​​defined at the set of rules level may, in some embodiments, be defined at the drug record level.

[0268] As described above, in some embodiments, the user may choose to add drug records for unspecified drugs. Such records can function as wildcards or quasi-wildcards. That is, such drug records can define a broad parameter that governs the use of any number of unspecified drugs. Using such records, for example, the user can operate an infusion pump in volume per duration mode without being constrained by any limits defined by the user within the DERS editor. Using drug records for unspecified drugs allows caregivers to initiate treatment more quickly in emergency situations. It can also be useful when it is necessary to use a drug that is not on the drug list for a particular nursing area (for example, when using experimental drugs or investigational drugs). Such drug records may also be useful in special cases where the limits defined in DERS may not be appropriate for the situation. For example, if a patient who is extremely overweight requires infusion, the limits defined via the DERS editor may not allow for the administration of clinically effective infusion. In such cases, the user can use drug records for unspecified drugs to circumvent the limits and administer infusion that may produce the desired effect.

[0269] As described above, such drug records can also be set as quasi-wildcards. For example, drug records for unspecified drugs can be set to be given parameters that can define the drug category or subcategories. Drug categories, though not limited to these, can include blood products, investigational drugs, IV solutions, drugs, etc. This can be useful to provide greater flexibility when needed while applying some of the safety measures that can be created in the DERS editor. In some embodiments, when a user selects drug records for some or all unspecified drugs, the user may be prompted to enter text explaining which drugs to use and why to deliver those drugs using the corresponding drug record for the unspecified drugs.

[0270] When adding a drug record for an unspecified drug, the user can either copy the unspecified drug from another nursing area (step 472) or create a new unspecified drug (step 473). If the user decides to copy a drug record for an unspecified drug, they can select and copy the desired record by performing step 472. If the user wants to create a drug record for an unspecified drug, they can create the drug record and its various parameters in step 473. In some embodiments, the user may be able to define desired parameters for an unspecified drug. Such parameters may include some or all of the parameters included in Tables 7-9. This allows the user to adjust the drug record for unspecified drugs to be broader or narrower as needed. If the user wants to add more drugs to the nursing area list after completing step 472 or step 473, they can do so as described above.

[0271] Once the user has finished adding or creating medications for a nursing area, the user can proceed to step 486. In step 486, the user logs out, informing that the medication list for the nursing area is ready for review by the corresponding review user. In step 488, the DERS editor service can notify the corresponding review user that the medication list for the nursing area is ready for review. This notification can be in the form of an automatically generated email from the DERS editor service. The medication list can be saved in the DERS database.

[0272] Figure 26 shows a flowchart detailing several exemplary steps that can be used when reviewing a medication list for a specific nursing area. Similar steps can also be used to review a medication list for a nursing group. The medication list can be created by following steps similar to those described in Figure 25. The exemplary steps shown in the flowchart of Figure 26 can be part of the 121 review stages illustrated and described in relation to Figure 9. The steps shown in Figure 26 can be part of the sub-steps 216 for verification per nursing area, 222 for review per nursing area, 224 for review between nursing areas, and / or 226 for review between nursing areas, which were illustrated and described in relation to Figure 10. The exemplary steps shown in the flowchart of Figure 26 can be performed by at least one user performing the review. The users performing the review are, for example, the nursing supervisor 7, pharmacist 8, risk management supervisor 6, and / or medical technician 19 in Figure 1. The users performing the review are, for example, the resource clinician 202, reviewing pharmacist 204, dispensing consultant 206, and / or clinical consultant 208 in Figure 10.

[0273] In step 490, the user performing the inspection can proceed to the nursing area list on the DERS editor user interface. Then, in step 492, the user performing the inspection can select the nursing area associated with the drug list they wish to inspect. In step 494, the user performing the inspection can inspect items or parameters within the drug list. In some embodiments, the items and parameters that the user is asked to inspect can be displayed to the user on the DERS editor user interface as a work list, window, widget, etc. In some embodiments, the user may not need to proceed to the nursing area list to inspect the drug list. In some embodiments, the user performing the inspection can inspect items in the drug list via a medical device simulator on the DERS editor user interface. Such a medical device simulator can simulate how the drug list would look when used with a particular medical device. In some embodiments, the user can proceed to an inspection screen or drug screen to inspect the drug list.

[0274] When an item is checked, the user performing the check can enter comments or verify that the item is appropriate and does not require any changes. If the user decides to comment on an item, they proceed to step 495 and can provide any comments they wish. If the user decides to verify an item, they proceed to step 496 and can indicate that the item has been verified. Once step 495 or step 496 is completed for an item, in step 498, the DERS Editor Service can update the check status of that nursing area and / or item on the DERS database. If there are still items that need to be checked, the user performing the check can return to step 494. This can be repeated until all items and parameters in the drug list have been checked.

[0275] When there are no more items or parameters to check in the drug list, the user performing the check can proceed to step 499. In step 499, the DERS editor service can display a list of comments made by the user during the check. In step 500, the user performing the check can check, supplement, or revise the comments they have made. If the user performing the check has general comments about the drug list or its elements, they can enter those comments in step 502. If the user performing the check has no general comments about the drug list or its elements, or has already entered all such comments, they can indicate in step 504 that they have completed the check. Then, in step 506, the user performing the check can log out of the DERS editor. In step 508, the DERS editor service can notify another user, such as the drug library administrator, that the user performing the check has completed the drug list check.

[0276] Referring to Figure 27, a flowchart detailing several exemplary steps that can be used to update a drug list is shown. The steps shown in Figure 27 can be performed after a drug list corresponding to a specific nursing area has been reviewed. Similar steps can also be used to update nursing groups. The drug list review can be performed using the steps detailed in Figure 26. The steps shown in the exemplary flowchart of Figure 27 can be part of the editing and revision sub-steps 220 shown in Figure 10. The steps shown in Figure 27 can be performed by a user, such as a drug library administrator. In some embodiments, one or more users can collaborate to update the drug list. For example, a drug library administrator can work with a pharmacist to update the drug list.

[0277] In step 510, the user can proceed to the nursing area list on the DERS editor user interface. In some embodiments, the DERS editor user interface can be accessed via a suitable web browser. Then, in step 512, the user can select the nursing area with the drug list they wish to revise. In some embodiments, the user does not need to select a nursing area and can update the drug list using the inspection screen, drug screen, etc., on the DERS editor user interface. In step 514, the user inspects any comments, questions, or feedback regarding the drug list or any items or parameters within the drug list. The user can take several actions in response to each comment, question, or feedback provided.

[0278] If the user performing the inspection has a question about the drug list or parameters within the drug list, the user can proceed to step 516. In step 516, the user can enter an answer to the question, and that answer can then be made visible to the user who initially performed the inspection. In some embodiments, after the user provides the answer in step 516, the DERS editor service can notify the user who asked the question that the answer is now visible. This notification can be sent as part of step 518. In some embodiments, the user performing the inspection may respond to the answer if necessary, or may be required to indicate that a satisfactory answer has been received.

[0279] If the user who performed the review has entered comments, questions, or feedback that are not easily understood or that require further discussion, the user may proceed to step 520. In step 520, the user may enter a question regarding the initial input of the user who performed the review, and this question may be made available for the initial user who performed the review to view and respond to. In some embodiments, after the user enters a question in step 520, the DERS editor service may notify the user who performed the review that a question regarding comments, questions, or feedback from the user who performed the review has been entered. This notification may be sent as part of step 522. In some embodiments, the user may enter a response or question using the same field. In such embodiments, the notification sent in step 518 or step 522 may simply indicate that a response has been submitted.

[0280] If a user who has performed an inspection enters a comment, question, or feedback that includes a request to change an item or parameter in the drug list, the user may accept or reject the change request. If the user accepts the change, the process proceeds to step 524, where the item or parameter in the drug list can be changed according to the change request. If the user decides to reject the change request from the user who performed the inspection, the user can reject the request in step 526. In some embodiments, the user can accept or reject the change request by interacting with one or more virtual buttons included as part of the change request on the DERS editor user interface. In such embodiments, if the change request is accepted, the item or parameter in the drug list can be automatically changed.

[0281] If a user performing an inspection enters a comment or feedback that does not include a change request, does not raise a question, and does not require a response, the user may be asked to mark that comment or feedback as "read" in step 528.

[0282] Once a comment, question, or feedback is addressed, the user can review other comments, questions, and feedback until all comments, questions, and feedback from the user who performed the review have been addressed. Once all comments, questions, and feedback have been addressed, the user can proceed to step 530. In step 530, the user can indicate that they have finished updating the drug list. The update can be saved to the DERS database, and then in step 532, the user can log out of the DERS editor.

[0283] In step 534, the DERS editor service can notify all relevant users that the drug list has been updated and is ready for re-verification. In some embodiments, this notification may consist of an automatically generated email message. The notification may be sent to all reviewing users who initially reviewed the drug list. The re-verification process can be similar to the process described and illustrated in relation to Figure 26. In some embodiments, the re-verification process can be similar to the process detailed in Figure 28.

[0284] Figure 28 shows a flowchart detailing several exemplary steps that can be used to re-verify a drug list. The exemplary steps shown in the flowchart of Figure 28 can be performed by at least one reviewing user. The reviewing users are, for example, the nursing supervisor 7, pharmacist 8, risk management supervisor 6, and / or medical technician 19 in Figure 1. The reviewing users are, for example, the resource clinician 202, reviewing pharmacist 204, dispensing consultant 206, and / or clinical consultant 208 in Figure 10.

[0285] In step 540, the user performing the inspection can proceed to the nursing area list on the DERS editor user interface. Then, in step 542, the user performing the inspection can select the nursing area with the drug list they wish to inspect. In some embodiments, the inspection does not need to be performed by proceeding to the nursing area list. In some embodiments, the user can inspect entries from, for example, the inspection screen, task list widget, or drug list screen of the DERS user interface. In step 543, a list of items requiring inspection may be displayed on the DERS editor user interface by the DERS editor service. In some embodiments, the user can apply filters on the DERS editor user interface to cause the DERS editor service to generate and display such a list. In step 544, the user performing the inspection can inspect items or parameters that have been changed or have comments by selecting them from the list. In some embodiments, the user performing the inspection can inspect drug list items via a medical device simulator on the DERS editor user interface. Such a medical device simulator can simulate how the drug list would look when used with a particular medical device.

[0286] Some embodiments, including the embodiment shown in Figure 28, may include step 545 in which the DERS editor service displays the inspection history of an item. This inspection history can provide the user with the history of why changes were made to the item. For example, the inspection history may include a list of comments, questions, and responses about the item, and accepted or rejected change requests. The inspection history may include the item's original setting or value, and other past settings or values ​​for the item. Values, comments, questions, responses, and accepted / rejected change requests for an item can be stored in a database, such as the DERS database, once they are created, generated, and submitted.

[0287] After reviewing an item, the user performing the review can enter comments or verify that the item or parameter appears appropriate and does not require any changes. If the user decides to comment on an item, they can proceed to step 546 and provide any comments they wish. If the user decides to verify an item, they can proceed to step 547 to indicate that the item has been verified. Once step 546 or step 547 is completed for an item, the DERS editor service can update the review status of that drug list in step 548. If there are still items or parameters that require review, the user can return to step 544. This process can be repeated until all items and parameters in the drug list have been reviewed.

[0288] When there are no more items or parameters that require review in the drug list, the user performing the review can proceed to step 550. In step 550, the user performing the review can indicate that the review is complete. Then, in step 552, the user performing the review can log out of the DERS editor. In step 554, the DERS editor service can notify another user, such as the drug library administrator, that the user who performed the review has completed the drug list review. If there are still unresolved issues, questions, feedback, and / or comments, the user can update the drug list again and re-verify the drug list. This can be done until all users agree on the drug list and there are no more questions regarding the drug list. The list can be updated again by following steps similar to those illustrated and described in relation to Figure 27.

[0289] Figure 29 shows a flowchart detailing several exemplary steps that can be used when submitting a DAL file for approval. These steps can be performed after the DAL file has been created / updated as described above and has undergone various inspection and verification processes. In some embodiments, these steps can be performed after a trial creation of the DAL file has been performed. The exemplary steps shown in the flowchart of Figure 29 can be performed by a user or party, such as a drug library administrator or other party.

[0290] In step 560, the user verifies that all nursing areas, drug records, and other items created / updated in the DERS editor have been verified by the user responsible for their verification and inspection. Once all nursing areas, drug records, and other items have been verified, in step 562, the user can notify that the created / updated DAL file is ready for approval by the person responsible for approving the publication of the DAL file. In some embodiments, the person responsible for approval is an officer of the institution or organization. Once the user completes step 562, the DERS editor service can notify the person responsible for approving the publication of the DAL file in step 564 that the DAL file is ready for approval. Then, in step 566, the user can log out of the DERS editor service.

[0291] Based on procedures defined by various institutions or organizations, different individuals responsible for approving DAL files for publication can review and approve created / updated DAL files. In some embodiments, such procedures may include steps similar to the review and verification process described above. Once a DAL file is approved, it can be made ready for publication by following several steps, as shown in the illustrative flowchart in Figure 30. As shown in Figure 30, a user, such as a drug library administrator, can receive a notification from the DERS Editor Service informing them that a created / updated DAL file has been approved (step 580). Upon receiving the notification that the DAL file has been approved, the user can proceed to step 582 and log in to the DERS Editor Service. Then, in step 584, the user can verify that all persons responsible for approving DAL files have indeed approved the DAL file. In step 586, the user can notify that the DAL file is ready for publication to various medical devices within the institution or organization.

[0292] Referring to Figure 31a, a flowchart detailing several exemplary steps that can be used to deploy DAL files to various system components is shown. The steps shown in Figure 31a can be performed after the DAL file has been approved and made available for publication through a process similar to that described in relation to Figures 29-30. The various components include, in particular, any number of medical devices such as the CQI server 109 in Figure 4, the device gateway 99 in Figure 4, and the device 26 in Figure 1. The steps shown in Figure 31a can be performed by any number of users or parties. In some specific embodiments, the steps shown in Figure 31a can be performed by users such as the facility IT 18 in Figure 1, the medical technician 19, or the medical technician 102 in Figure 4. The DAL file can be transmitted over a secure connection. Depending on the embodiment, the DAL file may be transmitted using a Secure Sockets Layer (SSL) connection in particular.

[0293] The exemplary flowchart shown in Figure 31a begins in step 590, when the DERS editor service notifies the CQI user that the DAL file is published and ready for deployment. In step 592, the CQI user receives the notification generated in step 590. Then, in step 594, the CQI user can log on to the CQI application. The CQI application can be accessed by the user without requiring client-side software. This can be achieved, for example, via a suitable web browser. Then, in step 596, the CQI user can use the CQI application to deploy the DAL file to the CQI service. In some cases, the CQI user is a medical technician.

[0294] In step 598, the CQI application can notify the DERS editor service that the placement of the DAL file to the CQI service was successful. Then, in step 600, the DERS editor service can notify the user that the DAL file is ready to be placed on the device gateway. In step 602, the user receives notification that the DAL is ready to be placed on the device gateway. In some embodiments, the user receiving this notification is a medical technician. Then, in step 604, the user can log in to the device gateway application. In step 606, the user can instruct the device gateway application to download the DAL to the device gateway. In step 608, the device gateway application can request the DAL file from the DERS editor service. In step 610, the DERS editor service can provide the DAL to the device gateway.

[0295] Users can choose to deploy DAL files to various medical devices in several ways. In the exemplary embodiment shown in Figure 31a, users can deploy DAL files using a device gateway or manually. If the user decides to deploy DAL files using a device gateway, the DAL files can be deployed remotely to the medical device in step 612. The user can deploy DAL files manually by proceeding to step 614. Manual deployment may be desirable or necessary in some situations. For example, manual deployment may be necessary in a disconnected environment. In step 614, the user can log in to the DERS editor service. Then, in step 616, the user can load the DAL files to a local storage device using the DERS editor service for manual deployment to the medical device. The local storage device may be a USB memory stick, an external or portable hard drive, etc. In step 618, the user can manually deploy DAL files to the medical device by connecting the local storage device to the medical device and downloading the DAL files from the local storage device to the medical device.

[0296] Figure 31b shows an exemplary flowchart detailing several steps that can be used to package and stage resources to be exposed to a facility gateway. Such resources are, in some embodiments, DALs. In step 4700, the user can select the resources they wish to expose. Then, in step 4702, the resources can be signed using a cryptographic algorithm. In step 4704, the files can be hashed. In some embodiments, additional packing steps may be included. For example, in some embodiments, a compression step may be included. In some embodiments, an encryption step may be included. The packing steps used depend on the type of file being exposed.

[0297] In step 4706, the location for the hash stage can be determined. In some embodiments, this stage location is a location in a database. Then, in step 4708, the signed hash can be copied to the stage location. Then, in step 4710, the original signed hash file can be saved to the archive location. In some embodiments, this archive location is a database or other file system. In step 4712, a notification message can be generated addressed to the Facility Data Exchange Unit, which is sent to each facility gateway that is notified of the availability of the resource. This notification may include information such as the file type, the file hash, the file's unique identifier, and the facility gateway identifier. In step 4714, the notification message can be posted to the Facility Data Exchange Unit, which may then send the notification message to the target receiving facility gateway.

[0298] Figure 31c shows a flowchart detailing several exemplary steps that can be used to track the placement of various resources. Such resources include DAL files and any number of other resources. These steps can be performed on the user interface, which in some embodiments is the user interface of the DERS editor. In step 4730, the user selects a specific resource whose placement they want to track. This resource can be selected from a list of traceable resources stored in memory associated with the equipment manager. Then, in step 4732, the equipment manager in the host environment can query the database for the version of the selected resource in each agency. In some embodiments, the database may only be able to query information about the agency associated with the user. Then, in step 4734, the equipment manager can display an agency list detailing the last version of the resource downloaded to each agency. If the user wants more detailed information about the placement of a resource version in a particular agency, the user can select the desired agency from the list in step 4736. In step 4738, the equipment manager can query the database to determine how many of each resource version are placed in the selected agency. In step 4740, a list of versions and the number of versions placed in the selected agency can be displayed.

[0299] Once a DAL file is created and deployed, it may be necessary or desirable to update it. During use, it may become apparent that some of the constraints in the limits of a DAL file, particularly those governing the delivery of specific medications, are too strict. For example, if a nurse in a nursing area finds that they frequently have to select medication records for unspecified drugs in order to deliver a particular medication in an effective therapeutic manner, one or more nurses may request a change to the limits for that particular drug or nursing area. Changes to the DAL file may also be necessary when hospital policies change or when new drugs enter the market. Figure 32 shows a flowchart detailing some exemplary steps that can be used to update an existing DAL file.

[0300] In step 620, the user performing the review can log on to the DERS editor service and indicate that they wish to enter an update or change request for the current DAL. The user performing the review can then select the type of request they wish to submit. In step 622, the user performing the review can enter, for example, general comments. The user performing the review may also choose to enter more specific comments. In some embodiments, the user can enter comments relating to any of the various hierarchical levels of the DAL file. In step 624, the user performing the review can select a specific nursing area for which they wish to submit an update request. In some embodiments, an additional step (not shown) for creating an update request for a nursing group may be included. In step 626, the user performing the review can enter general comments about the nursing area, or proceed to step 628 if they wish to make a more specific request. In step 626, the user can also enter an update request for parameter values ​​defined in the nursing area.

[0301] In step 628, the user performing the review can select a specific drug record within the nursing area for which they wish to enter an update request. If the user performing the review wants to enter a general update request for a drug record, they can do so in step 630. In this step, the user can also request updates for parameter values ​​defined in the drug record. If the user performing the review wants to make the update request more specific, they can proceed to step 632. In step 632, the user can select a set of rules for the drug record for which they wish to submit an update request. If the user performing the review wants to submit an update request for the set of rules in general, they can enter the update request in step 634. In step 634, the user can also submit an update request for parameters defined at the level of the set of rules. If the user performing the review wants to enter a more specific update request, they can proceed to step 636. In step 636, the user performing the review can select a specific concentration record from the set of rules for which they wish to create an update request. In step 638, the user performing the review can enter the update request for that concentration record. The update request can be entered in the update request field displayed in the DERS editor user interface.

[0302] Once the user performing the check has completed any of steps 622, 626, 630, 634, or 638, the user can proceed to step 640. In step 640, the user performing the check can submit the entered update request. The submitted update request can be saved in the DERS database. Then, in step 642, the DERS editor service can notify at least one other user that an update request has been submitted. The DERS editor service can notify, for example, the drug library administrator that an update request has been submitted. The user performing the check can then add further update requests to the current DAL file by returning to step 620 if necessary.

[0303] In some embodiments, the user performing the inspection can select elements, items, parameters, etc. (e.g., nursing areas) in the DAL file before performing step 620. This can be done by using the DERS editor user interface to navigate to the desired DAL entry. Once the user has navigated to the desired entry, they can indicate in step 620 that they wish to enter an update request. This will display an update request field, in which the user can enter the update request. Then, in step 640, the user can enter and submit the update request for that item.

[0304] Figure 33 shows a flowchart detailing several exemplary steps that can be used to update an institution / organization's drug list. This may be necessary when new drugs enter the market or when generic versions of existing drugs become available. It may also be necessary if the institution / organization expands and adds nursing areas that use drugs that were not previously required by the institution. Updating the drug list can also add experimental drugs or drugs for clinical trials to the institution / organization's drug list. The steps shown in Figure 33 can be performed by the drug library administrator and / or pharmacist. In some embodiments, other users may also be able to perform these steps.

[0305] In step 650, the user proceeds to the institutional / organization's drug list in the DERS editor. Next, in step 652, the DERS editor service can display the institution / organization's drug list to the user. The user can then choose to add a drug to the drug list by creating an entry for a new drug (step 656) or by selecting a drug from the master drug list provided by the DERS editor service (step 654). This selection can be made by clicking virtual buttons on the user interface. If the user decides to select a drug from the master drug list, the user can proceed to step 654. In step 654, the user can select a drug from the master drug list. A search mechanism may be included for this step to allow the user to more quickly find the drug they want to add to the organization's drug list. If the user decides to enter a drug without using the master drug list, or if they cannot find the desired drug in the master drug list, the user can proceed to step 656. In step 656, the user can enter a new drug into the organization's drug list. In this step, the user can also define parameters that can be associated with the new drug. Then, in step 657, the DERS editor service can add the organization's new drug to the DERS database. Once the new drug has been added to the organization's drug list, in step 658, the DERS editor service can notify all users responsible for creating drug lists for nursing groups and nursing areas that the organization's drug list has been updated.

[0306] Figure 34 shows a flowchart detailing several exemplary steps that can be used to update the clinical recommendation list. The exemplary steps shown in Figure 34 can be performed by a drug library administrator, pharmacist, or other user. In step 660, the user navigates to the clinical recommendation list on the DERS editor. Then, in step 662, the DERS editor service can display the institutional / organizational clinical recommendation list. In the exemplary embodiment shown in Figure 34, the user can update an existing list by adding clinical recommendations to the list or by changing the clinical recommendations currently in the list. In step 664, the user can add clinical recommendations to the list. In step 666, the user can update the clinical recommendations in the list.

[0307] Once an update to the clinical recommendation list is created, the user can make further updates to the list by returning to the clinical recommendation list displayed in step 662 if necessary. When the user has finished updating the institutional / organizational clinical recommendation list, the user can proceed to step 672. In step 672, the user can log out of the DERS editor and indicate that the clinical recommendation list should be saved. Then, in step 674, the DERS editor service can save the updates to the database. The database can be the DERS editor database. In step 676, the DERS editor service can notify the user responsible for creating the nursing area drug list that the institutional / organizational clinical recommendation list has been updated.

[0308] In some embodiments, the user may not update clinical recommendations by selecting or adding to a displayed list of clinical recommendations. Instead, the user can navigate to a specific entry in the DAL file (e.g., clinical use) and add a clinical recommendation corresponding to that specific entry. This can be done by modifying the clinical recommendation parameters for the desired entry.

[0309] Referring to Figure 35, a flowchart detailing several exemplary steps that can be used to update the general settings of an institution / organization is shown. These steps can be performed by the drug library administrator in some embodiments. In step 680, the user can proceed to the general settings on the DERS editor. Then, in step 682, the DERS editor service can display the general settings. In step 684, the user can update the general settings as needed. In step 686, the user can indicate that they have finished updating the general settings and wish to save them. In step 687, the DERS editor service can save the institution / organization's general settings to the DERS editor database. In step 688, the DERS editor service can notify the relevant user that the general settings have been changed.

[0310] Figure 36 shows a flowchart detailing several exemplary steps that can be used to update nursing areas. In some embodiments, nursing groups can also be updated using steps similar to those shown in Figure 36. In step 690, the user can proceed to the nursing area list. In step 692, the user selects the nursing area they wish to update. The user can then choose to update several aspects of that nursing area. The user can update a list or group of users who have administrative permission for a particular nursing area. This can be done in step 694. In particular, administrative permission for a nursing area can give the user the ability to edit the entries and parameters of that nursing area. The user can also choose to update a list or group of users who are responsible for inspecting that nursing area. This can be done in step 696. In step 698, the user can also modify the entries or parameters of a nursing area.

[0311] After performing an update, the user returns to step 692 and can perform further updates if desired. If the user has finished updating, in step 700 the updated nursing area can be saved to the DERS database. Then, in step 702, the DERS editor service can notify the relevant user that the nursing area has been updated. If necessary, the DERS editor service can also notify the relevant user that the nursing area is ready for inspection. In some embodiments, the inspection and verification process corresponding to the update of the nursing area can be the same as or similar to the process described above with respect to Figures 23 and 24.

[0312] Figure 37 shows a flowchart detailing several exemplary steps that can be used to update medication records in a nursing area. Similar steps can be used to update medication records in nursing groups. Such updates can be made in response to various update requests submitted by users performing inspections. Update requests can be submitted, for example, by following steps similar to those illustrated and described with respect to Figure 32. Such updates may also be made when it is necessary to add new medications to the medication list in a nursing area. Medication records in a nursing area may also be updated if analysis of CQI data from medical devices using the DAL file indicates that a value in one or more medication records in the DAL file may be inappropriate.

[0313] In step 710, the user can proceed to the nursing area list on the DERS editor. In some embodiments, the DERS editor service may then prompt the user to select a nursing area from the displayed list of nursing areas in step 712. Then, in step 714, the user can select the nursing area they wish to update. In some embodiments, the user does not need to proceed to the nursing area list to update a drug record. For example, the user can proceed to the drug list or check screen on the DERS user interface to update the entry.

[0314] Users may be able to update drug records in nursing areas in several ways. In Figure 37, a user can add a drug record to a nursing area by performing step 716. Step 716 can be performed by following several steps, such as those illustrated and described in relation to Figure 25. Users can also update drug records in nursing areas. To update, in step 718, an existing drug record in the nursing area can be selected. Then, in step 720, the user can modify that drug record, the set of rules for the drug record, and / or the concentration record for the drug record.

[0315] The user can also update medication records in the nursing area by addressing any submitted update requests. To address a submitted update request, the user can select the submitted update request from a list of update requests in step 722. Such a list may be, for example, part of a work list, window, widget, etc., that details the update requests, comments, questions, etc., for which the user is responsible for reviewing. In other embodiments, update requests can be selected without selecting from a list. Once an update request is selected, the user may have several options. If the user agrees to the request, they can accept it. In this example, the user can proceed to step 724. In step 724, the user makes changes in the DERS editor based on the accepted update request. In some embodiments, the user can make changes by manually updating the record by following steps similar to steps 718 and 720 shown in Figure 37. Preferably, the user...

Claims

1. It is configured to create, check, and / or edit a drug library; Set a set of privileges for allocating a certain degree of software functionality to the aforementioned drug library; A medical error reduction system equipped with medical error reduction software.

2. The system further comprises a server configured to run the aforementioned software; The system according to claim 1.

3. The editor computer further comprises a processor configured to communicate with a display and / or user interface over a network in a client / server model; The system according to claim 1.

4. The aforementioned drug library is configured for use in medical devices; The system according to claim 1.

5. The aforementioned certain degree of software functionality is configured to define the ability to modify the drug library; The system according to claim 1.

6. The aforementioned drug library was configured for hierarchy; The system according to claim 1.

7. The aforementioned hierarchy includes nursing areas below the nursing group; The system according to claim 6.

8. The aforementioned hierarchy levels include the fluid delivery parameters of the medical device; The system according to claim 6.

9. The drug library comprises entries corresponding to drugs; The system according to claim 1.

10. The drug library includes parameters configured to notify the operation of the medical device; The system according to claim 1.

11. The aforementioned drug library includes programming limits for medical devices; The system according to claim 1.

12. The aforementioned software is configured to provide quality improvement information; The system according to claim 1.

13. The aforementioned set of privileges enables the creation, inspection, and / or editing of drug libraries; The system according to claim 1.

14. The aforementioned set of privileges allows for the creation, inspection, and / or editing of privilege sets; The system according to claim 1.

15. The aforementioned set of privileges allows for the addition and / or removal of users; The system according to claim 1.

16. The aforementioned set of privileges compels collaboration in the creation and / or editing of the drug library; The system according to claim 1.

17. The editor computer further includes a processor configured to communicate with a display and / or user interface over a network in a client / server model, The editor computer and the server were configured to communicate over a network in a client / server model; The system according to claim 2.

18. The aforementioned set of privileges enables requests for changes to the drug library; The system according to claim 1.

19. The aforementioned set of privileges enables the acceptance and / or rejection of requests for changes to the drug library; The system according to claim 18.

20. The aforementioned set of privileges allows for the submission of questions regarding the aforementioned changes; The system according to claim 18.

21. The aforementioned set of privileges allows for the proposal of revisions relating to the aforementioned changes; The system according to claim 18.

22. The aforementioned medical device includes an infusion pump; The system according to claim 4.

23. The editor computer is configured to provide access to the medical error reduction software; The system according to claim 1.

24. Creating a drug library; Specify the master drug list; Defining drug records; Verifying the aforementioned drug record; and, The configuration includes enabling a set of privileges to authorize the disclosure of the drug record to a medical device; How to generate a drug library.

25. The aforementioned designation includes selecting a drug from a prescription database; The method according to claim 24.

26. The above definition includes selecting a drug from the master drug list; The method according to claim 24.

27. The above definition includes defining the parameters of the drug; The method according to claim 26.

28. The verification described above includes checking the drug record; The method according to claim 24.

29. The verification described above includes editing and / or revising the drug record; The method according to claim 24.

30. The verification described above includes checking the drug record using the user interface of a simulated medical device; The method according to claim 24.

31. Further comprising creating a drug library file, and including performing a trial creation step of the drug library file, which includes testing the drug library file of a medical device for testing; The method according to claim 24.

32. The process further comprises creating a drug library file and performing a trial creation step of the drug library file, which includes testing the drug library with a user interface of a simulated medical device; The method according to claim 24.

Images