Computer-implemented method, system and apparatus for electronic patient care

Abstract

The invention relates to a computer-implemented method, system and apparatus for electronic patient care. A medical error reduction system includes medical error reduction software for creating and revising a drug library. The software is configured to provide a set of privileges to a user. The privilege set is used to allocate a certain level of software functions to users. The level of software functionality is configured to define the ability of the user to alter the drug library. The medical error reduction system may include an editor computer including a processor in communication with a display. The editor computer and the server may be configured to communicate over the network using a client-server based model. The drug library is used in medical equipment.

Description

[0001] This application is a divisional application. The filing date of the original application is December 20, 2013, with application number 202111145036.5, and the invention name is "Computer-implemented methods, systems and devices for electronic patient care." The aforementioned Chinese patent application 202111145036.5 is itself a divisional application of the Chinese patent application with application number 201810383996.7. The aforementioned Chinese patent application 201810383996.7 is itself a divisional application of the Chinese patent application with application number 201380072050.4. In addition, the divisional notice of the Chinese patent application 202111145036.5 was pointed out to have the defect of lack of unity.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is a nonprovisional application claiming priority to U.S. Provisional Patent Application Serial No. 61 / 740,474 (Attorney Docket No. J80), entitled System, Method, and Apparatus for Communicating Data, filed on December 21, 2012, the entire contents of which are incorporated herein by reference.

[0004] This application is also a continuation-in-part of U.S. patent application Ser. No. 13 / 723,253, filed Dec. 21, 2012, entitled System, Method, and Apparatus for Electronic Patient Care, now a U.S. Publication No. US-2013-0191413-A1 (Attorney Docket No. J85), published Jul. 25, 2013, which claims priority to:

[0005] U.S. Provisional Patent Application Serial No. 61 / 578,649, filed on December 21, 2011, and entitled "System, Method, and Apparatus for Infusing Fluid" (Attorney Docket No. J02);

[0006] U.S. Provisional Patent Application Serial No. 61 / 578,658, filed on December 21, 2011, and entitled "System, Method, and Apparatus for Estimating Liquid Delivery" (Attorney Docket No. J04);

[0007] U.S. Provisional Patent Application Serial No. 61 / 578,674, filed December 21, 2011, and entitled System, Method, and Apparatus for Dispensing Oral Medications (Attorney Docket No. J05);

[0008] US Provisional Patent Application Serial No. 61 / 651,322, filed May 24, 2012, and entitled "System, Method, and Apparatus for Electronic Patient Care" (Attorney Docket No. J46); and

[0009] U.S. Provisional Patent Application Serial No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, and entitled System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow, each of which is incorporated herein by reference in its entirety.

[0010] U.S. Patent Application Serial No. 13 / 723,253 is a continuation-in-part of U.S. Patent Application Serial No. 13 / 333,574, filed on December 21, 2011, and entitled System, Method, and Apparatus for Electronic Patient Care, now published on July 19, 2012, U.S. Publication No. US-2012-0185267-A1 (Attorney Docket No. 197), and

[0011] PCT Application Serial No. PCT / US11 / 66588 (Attorney Docket No. 197WO), filed December 21, 2011, and entitled "System, Method, and Apparatus for Electronic Patient Care," both of which are hereby incorporated by reference in their entireties.

[0012] U.S. patent application serial number 13 / 333,574, filed on January 21, 2011, and entitled Electronic Patient Monitoring System, is a continuation-in-part application of U.S. Publication No. US-2011-0313789-A1 (Agent Docket No. I52), published on December 22, 2011, which claims priority to U.S. Provisional Patent Application No. 61 / 297,544 (Agent Docket No. H53), filed on January 22, 2010, and entitled Electronic Order Intermediation System for a Medical Facility. The entire contents of the above two applications are incorporated herein by reference.

[0013] This application is also a continuation-in-part of U.S. patent application Ser. No. 13 / 723,239, filed on Dec. 21, 2012, entitled System, Method, and Apparatus for Electronic Patient Care, now published on Nov. 7, 2013, U.S. Publication No. US-2013-0297330-A1 (Attorney Docket No. J77), which claims priority to:

[0014] U.S. provisional patent application serial number 61 / 578,649, entitled “System, Method, and Apparatus for Infusing Fluid,” filed on December 21, 2011 (attorney docket number J02);

[0015] U.S. Provisional Patent Application Serial No. 61 / 578,658, entitled "System, Method, and Apparatus for Estimating Liquid Delivery," filed on December 21, 2011 (Attorney Docket No. J04);

[0016] U.S. Provisional Patent Application Serial No. 61 / 578,674, filed December 21, 2011, entitled System, Method, and Apparatus for Dispensing Oral Medications (Attorney Docket No. J05);

[0017] U.S. Provisional Patent Application Serial No. 61 / 651,322, filed May 24, 2012, entitled "System, Method, and Apparatus for Electronic Patient Care" (Attorney Docket No. J46); and

[0018] U.S. Provisional Patent Application Serial No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, and entitled System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow, each of which is incorporated herein by reference in its entirety.

[0019] US patent application Ser. No. 13 / 723,239 claims priority to the continuation-in-part application of:

[0020] U.S. Patent Application Serial No. 13 / 333,574, filed December 21, 2011, and entitled System, Method, and Apparatus for Electronic Patient Care, now published as U.S. Publication No. US-2012-0185267-A1 (Attorney Docket No. 197), on July 19, 2012, is a continuation-in-part of U.S. Patent Application Serial No. 13 / 011,543, filed January 21, 2011, and entitled Electronic Patient Monitoring System, now published as U.S. Publication No. US-2011-0313789-A1 (Attorney Docket No. 152), on December 22, 2011, which claims a patent application filed January 22, 2010, and entitled Electronic Order Intermediation System for a Medical Device. Priority to U.S. Provisional Patent Application Serial No. 61 / 297,544, (Attorney Docket No. H53), filed in the name of Facility; and

[0021] PCT Application Serial No. PCT / US11 / 66588, filed on December 21, 2011, and entitled System, Method, and Apparatus for Electronic Patient Care, now International Publication No. WO 2013 / 095459 (Attorney Docket No. 197WO), filed on September 12, 2013, the entire contents of each of which are incorporated herein by reference.

[0022] This application is also a continuation-in-part of U.S. patent application Ser. No. 13 / 723,242, filed on Dec. 21, 2012, entitled System, Method, and Apparatus for Electronic Patient Care, now published on Nov. 28, 2013, U.S. Publication No. US-2013-0317753-A1 (Attorney Docket No. J78), which claims priority to:

[0023] US Provisional Patent Application Serial No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, is hereby incorporated by reference in its entirety.

[0024] This application is also a continuation-in-part of US Serial No. 13 / 900,655, filed on May 23, 2013, and entitled System, Method, and Apparatus for Electronic Patient Care, now published on November 28, 2013, US Publication No. US-2013-0317837-A1 (Attorney Docket No. K66), which claims priority to US Provisional Patent Application Serial No. 61 / 651,322 (Attorney Docket No. J46), filed on May 24, 2012, and entitled System, Method, and Apparatus for Electronic Patient Care, the entire contents of which are incorporated herein by reference.

[0025] US Patent Application Serial No. 13 / 900,655 is also a continuation-in-part application claiming priority to:

[0026] U.S. Patent Application Serial No. 13 / 480,444, filed May 24, 2012, and entitled Blood Treatment Systems and Methods, now U.S. Publication No. US-2013-0037485-A1, filed February 14, 2013 (Attorney Docket No. J43); and

[0027] PCT application serial number PCT / US12 / 00257, filed on May 24, 2012, and entitled "Blood Treatment Systems and Methods," was published on November 29, 2012, under International Publication No. WO / 2012 / 161744 (attorney docket No. J43WO).

[0028] This application is also a continuation-in-part of PCT application serial number No. PCT / US13 / 42350 (attorney docket No. K66WO) filed on May 23, 2013 and entitled System, Method, and Apparatus for Electronic Patient Care, which claims priority to U.S. provisional patent application serial number No. 61 / 651,322 (attorney docket No. J46) filed on May 24, 2012 and entitled System, Method, and Apparatus for Electronic Patient Care, the entire contents of which are incorporated herein by reference.

[0029] PCT Application Serial No. PCT / US13 / 42350 is also a continuation-in-part application claiming priority to:

[0030] U.S. Patent Application Serial No. 13 / 480,444, filed May 24, 2012, and entitled Blood Treatment Systems and Methods, now published February 14, 2013, U.S. Publication No. US-2013-0037485-A1 (Attorney Docket No. J43); and

[0031] PCT application serial number PCT / US12 / 00257, filed on May 24, 2012, and entitled Blood Treatment Systems and Methods, now published on November 29, 2012, International Publication No. WO / 2012 / 161744 (attorney docket No. J43WO).

[0032] This application may also be related to one or more of the following patent applications filed on December 21, 2012, the entire contents of which are incorporated herein by reference:

[0033] Nonprovisional application System, Method, and Apparatus for Clamping (Attorney Docket No. J47), Serial No. 13 / 723,238;

[0034] Nonprovisional application for System, Method, and Apparatus for Dispensing Oral Medications (Attorney Docket No. J74), Serial No. 13 / 723,235;

[0035] PCT application "System, Method, and Apparatus for Dispensing Oral Medications," attorney docket No. J74WO, serial No. PCT / US12 / 71131;

[0036] Nonprovisional application System, Method, and Apparatus for Estimating Liquid Delivery (Attorney Docket No. J75), Serial No. 13 / 724,568;

[0037] Nonprovisional application System, Method, and Apparatus for Infusing Fluid (Attorney Doceket No. J76), Serial No. 13 / 725,790;

[0038] PCT application System, Method, and Apparatus for Infusing Fluid (Attorney Docket No. J76WO), Serial No. PCT / US12 / 71490;

[0039] Nonprovisional application System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Attorney Docket No. J79), Serial No. 13 / 723,244;

[0040] PCT application System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Attorney Docket No. J79WO), Serial No. PCT / US12 / 71142;

[0041] Nonprovisional Application System, Method, and Apparatus for Estimating Liquid Delivery (Attorney Docket No. J81), Serial No. 13 / 723,251; and

[0042] PCT application System, Method, and Apparatus for Estimating Liquid Delivery (attorney docket No. J81WO), serial number No. PCT / US12 / 71112.

[0043] This application may also be related to one or more of the following patent applications, the entire contents of which are incorporated herein by reference:

[0044] U.S. Provisional Patent Application Serial No. 61 / 738,447, filed on December 18, 2012, and entitled “System, Method, and Apparatus for Detecting Air in a Fluid Line Using Active Rectification” (Attorney Docket No. J32);

[0045] U.S. patent application serial number 13 / 840,339, filed on March 15, 2013, and entitled Apparatus for Infusing Fluid (Attorney Docket No. K14);

[0046] PCT application serial number PCT / US13 / 32445, filed on March 15, 2013, and entitled Apparatus for Infusing Fluid (attorney docket number K14WO);

[0047] U.S. patent application Ser. No. 13 / 833,432, filed on March 15, 2013, and entitled Syringe Pump and Related Method (Attorney Docket No. K21);

[0048] U.S. patent application Ser. No. 13 / 836,497, filed on March 15, 2013, and entitled System and Apparatus for Electronic Patient Care (Attorney Docket No. K22);

[0049] U.S. patent application Ser. No. 13 / 833,712, filed on March 15, 2013, and entitled “System, Method, and Apparatus for Clamping” (Attorney Docket No. K23);

[0050] U.S. patent application Ser. No. 13 / 834,030, filed on March 15, 2013, and entitled “System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow” (Attorney Docket No. K28);

[0051] U.S. Provisional Patent Application Serial No. 61 / 860,398, filed on July 31, 2013, and entitled “System, Method, and Apparatus for Bubble Detection in a Fluid Line Using a Split-Ring Resonator” (Attorney Docket No. J31);

[0052] U.S. Provisional Patent Application Serial No. 61 / 900,431, filed on November 6, 2013, and entitled “System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow” (Attorney Docket No. K52);

[0053] U.S. Provisional Patent Application Serial No. 61 / 894,801, filed on October 23, 2013, and entitled Syringe Pump and Related Method (Attorney Docket No. K88);

[0054] U.S. Provisional Patent Application Serial No. 61 / 843,574, filed July 8, 2013, and entitled “System, Method, and Apparatus for Clamping” (Attorney Docket No. K75);

[0055] U.S. patent application Ser. No. 13 / 971,258 (Attorney Docket No. K84), filed Aug. 20, 2013, and entitled Electronic Patient Monitoring System;

[0056] U.S. Provisional Patent Application Serial No. 61 / 904,123, filed on November 14, 2013, and entitled Syringe Pump and Related Method (Attorney Docket No. L33);

[0057] U.S. patent application Ser. No. 14 / 101,848, filed Dec. 10, 2013, and entitled “System, Method, and Apparatus for Detecting Air in a Fluid Line Using Active Rectification” (Attorney Docket No. L05);

[0058] U.S. patent application “System, Method, and Apparatus for Communicating Data” filed on December 20, 2013 (Attorney Docket No. L49);

[0059] PCT application System, Method, and Apparatus for Communicating Data filed on December 20, 2013 (Attorney Docket No. L49WO);

[0060] U.S. patent application “Computer-Implemented Method, System, and Apparatus for Electronic Patient Care” filed on December 20, 2013 (Attorney Docket No. K50);

[0061] US patent application System, Method, and Apparatus for Electronic Patient Care filed on December 20, 2013 (Attorney Docket No. L52); and

[0062] PCT application System, Method, and Apparatus for Electronic Patient Care filed on December 20, 2013 (Attorney Docket No. L52WO). Technical Field

[0063] The present disclosure relates to patient care. More particularly, the present disclosure relates to systems and devices for electronic patient care. Background Art

[0064] Patient care often involves administering fluids, such as medications, to a patient by direct injection. This can be accomplished through gravity-fed tubing connected to a reservoir (e.g., an IV bag). Fluids or medications can be administered by forced injection. Administering fluids or medications to a patient often requires interaction among multiple parties (e.g., a physician, a caregiver, and a pharmacist). These interactions can be subject to miscommunication, errors, or other events that result in an inaccurate amount of fluid administered to the patient. Summary of the Invention

[0065] According to an exemplary embodiment of the present disclosure involving electronic patient care, a medical error reduction system includes medical error reduction software for creating and modifying at least one drug library configured for use in at least one medication device. The software is configured to provide a set of privileges to a set of users. The privilege set assigns a level of software functionality to the set of users, the level of software functionality configured to define the user's ability to modify the at least one drug library. The medical error reduction system also includes at least one server and at least one editing computer. The editing computer communicates with the server via a network and includes a processor in communication with a display.

[0066] According to an embodiment of the present disclosure, a medical error reduction system may include medical error reduction software for creating and revising at least one drug library. The software may be configured to provide one of a plurality of privilege sets to each of a plurality of user sets. Each of the plurality of privilege sets may be used to assign a certain level of software functionality to one of the plurality of user sets. The level of software functionality may be configured to define a user's ability 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 include a processor that communicates with a display. The at least one editor computer and the at least one server may be configured to communicate via a network using a client-server model. Each of the at least one drug library is used in at least one medical device.

[0067] In some embodiments of the system, each of the at least one drug library may be organized into a hierarchy. In some embodiments, the hierarchy may include multiple care areas located below at least one care group. In some embodiments, each hierarchy may include multiple delivery parameters for at least one medical device. In some embodiments, each of the at least one drug library may include multiple entries corresponding to specific medications. In some embodiments, the at least one drug library may include multiple parameters that inform the operation of the at least one medical device. In some embodiments, the drug library may include multiple programming restrictions for the at least one medical device. In some embodiments, the medical error reduction software may be further configured to provide quality improvement information to users. In some embodiments, at least one of the plurality of privilege sets may assign drug library review privileges to one of the plurality of user sets. In some embodiments, at least one of the plurality of privilege sets may assign drug library edit privileges to one of the plurality of user sets. In some embodiments, at least one of the plurality of privilege sets may assign privilege set edit or create privileges to one of the plurality of user sets. In some embodiments, at least one of the plurality of privilege sets may assign add user privileges to one of the plurality of user sets. In some embodiments, the plurality of privilege sets assigned to one of the plurality of user sets may enforce a collaborative process among the plurality of user sets for creating and revising the at least one drug library.

[0068] According to an embodiment of the present disclosure, a 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 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 using a client-server model. The medical error reduction system may include medical error reduction software, configured to be executed by the at least one server. The medical error reduction software may be accessed by the at least one editor computer and used to create and revise at least one drug library. Each of the at least one drug library may be used in at least one medical device. The at least one medical device may include a medical device processor and a medical device graphical user interface configured to display a user interface. The user interface may convey information that may be used to program its respective medical device. Each of the at least one drug library may contain a plurality of entries that guide a user of the at least one medical device in programming. The medical error reduction software may be configured to display a simulated medical device graphical user interface. The simulated medical device graphical user interface may use a selected drug library of the at least one drug library to mimic the behavior of the medical device graphical user interface for the medical device.

[0069] In some embodiments, the simulated medical device graphical user interface is context-sensitive. In some embodiments, the medical error reduction software may include multiple privilege sets. Each of the multiple privilege sets may be assigned to one of a plurality of user sets. The multiple privilege sets may respectively assign a level of software functionality to each of the plurality of user sets. In some embodiments, the simulated medical device graphical user interface may be a software functionality that can be turned on or off for the multiple privilege sets. In some embodiments, each of the at least one drug library may be organized hierarchically. In some embodiments, the hierarchy may include multiple care areas located below at least one care group. In some embodiments, each layer of the hierarchy may include multiple delivery parameters for at least one medical device. In some embodiments, each of the at least one drug library may include multiple entries that may respectively correspond to specific medications. In some embodiments, the at least one drug library may include multiple parameters that inform the operation of the at least one medical device. In some embodiments, the drug library may include multiple programming limits for the at least one medical device. In some embodiments, the medical error reduction software may be further configured to provide quality improvement information to the user.

[0070] According to another 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 pumping mechanism that delivers the drug. The medical device may include a display. The medical device may include a computer-readable memory configured to store program code for a drug library. The drug library may contain a plurality of entries. The plurality of entries include at least one entry corresponding to a portion of a facility. For each such entry, there may be at least one drug entry. Each of the at least one drug entry has parameters associated therewith. At least one drug entry in the drug library is not associated with a specific drug, but rather with a broad drug category. The medical device may include a processor configured to display a graphical user interface on the display of the medical device. The graphical user interface is used by a user to program the controller with the drug library.

[0071] In some embodiments, a user can select one of at least one drug entry in a drug library that is not associated with a specific drug, but rather is associated with a broad drug category, to program the delivery of a drug to a patient. In some embodiments, at least one drug entry in a drug library that is not associated with a specific drug, but rather is associated with a broad drug category, is associated with at least one parameter for managing drug delivery. In some embodiments, the drug library can be created or modified by medical error reduction software. In some embodiments, the display is a touch screen display. In some embodiments, at least one of the at least one drug entry in the drug library that is not associated with a specific drug, but rather is associated with a broad drug category, allows a user to program a medical device to deliver the drug in a volume per hour mode. In some embodiments, each of the plurality of entries is associated with at least one parameter. In some embodiments, at least one of the at least one parameter is a drug delivery parameter.

[0072] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising 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 with at least one medical device. The software may be configured to provide one of multiple privilege sets to each of multiple user sets, each of the multiple privilege sets being used to assign a certain level of software functionality to one of the multiple user sets. 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 include a processor that communicates with a user interface. The at least one editor computer and the at least one server may be configured to communicate over a network using a client-server model. At least one of the multiple user sets may use the software to request a change to at least a portion of the at least one drug library.

[0073] In some embodiments, at least one of the plurality of privilege sets can be configured to allow a user to deny implementation of a change. In some embodiments, at least one of the plurality of privilege sets can be configured to accept implementation of a change. In some embodiments, at least one of the plurality of privilege sets can be configured to allow a user to submit an issue with a change. In some embodiments, at least one of the plurality of privilege sets can be configured to allow a user to propose a revision of a change. In some embodiments, the server can be configured to execute medical error reduction software. In some embodiments, the level of software functionality can be configured to define a user's ability to change at least one drug library. In some embodiments, at least one medical device can be an infusion pump.

[0074] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising 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 with at least one medical device. The medical error reduction system may include at least one server configured to execute the medical error reduction software. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may include a processor that communicates with a user interface. The user interface may be used by one or more users to edit the at least one drug library. The at least one editor computer and the at least one server may be configured to communicate via a network. At least one of the one or more users may request a change to the at least one drug library by submitting an electronic change request.

[0075] In some embodiments, at least one medical device may be an infusion pump. In some embodiments, the electronic change request may be linked to medical data. In some embodiments, the medical data is stored in an electronic database to provide contextual information. In some embodiments, the electronic database is in a hosted environment. In some embodiments, the medical data is generated by at least one medical device. In some embodiments, the medical data is stored in the electronic database and is associated with one of at least one drug libraries used in the at least one medical device that generated the medical data. In some embodiments, the medical data is displayed in a table. In some embodiments, the medical data is displayed in a chart. In some embodiments, the medical data is displayed in a graph. In some embodiments, the medical data is displayed in a line chart. In some embodiments, the medical data is displayed as infusion details. In some embodiments, a user can search the medical data using drug library editing software. In some embodiments, a user can filter the medical data using drug library editing software. In some embodiments, the medical data is displayed in a user-selectable format. In some embodiments, a user can only access medical data for the version of the at least one drug library currently being edited. In some embodiments, the multiple entries each relate to one or more delivery parameters. In some embodiments, at least one of the one or more users may accept the electronic change request. In some embodiments, at least one of the one or more users may respond to the electronic change request. In some embodiments, at least one of the one or more users may submit a change to the electronic change request. In some embodiments, at least one of the one or more users may reject the electronic change request.

[0076] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library is for use with at least one medical device. The drug library editing software is executed 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 at least one editor computer. Each of the at least one editor computer includes a processor that communicates with a user interface. The user interface is configured to allow a user to edit the 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 via a network. When editing the at least one drug library, the user may use the drug library editing software to access the medical data.

[0077] In some embodiments, the medical data may be stored in at least one medical data database. In some embodiments, the at least one medical data database is stored in a hosted environment. In some embodiments, the medical data is displayed in the form of a chart. In some embodiments, the medical data is displayed in the form of a graph. In some embodiments, the medical data is displayed in the form of a table. In some embodiments, the medical data is displayed in the form of a graph. In some embodiments, the medical data is displayed in the form of an infusion detail. In some embodiments, the medical data is displayed in a user-selectable format. In some embodiments, the accessed medical data may be searchable. In some embodiments, the accessed medical data may be filtered by applying a filter. In some embodiments, the filter may be a device class filter. In some embodiments, the filter may be a data category. In some embodiments, the filter may be based on treatment criteria. 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 based on region criteria. 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, the at least one drug library database is in a hosted environment. In some embodiments, the medical device may be an infusion pump.

[0078] In some embodiments, a medical error reduction system may include drug library editing software for creating and revising at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library is for use with at least one medical device, and the drug library editing software is executed 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 at least one editor computer, each of the at least one editor computer including a processor that communicates with a user interface. The user interface is configured for a user to edit the at least one drug library, and 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 via a network. When creating or revising the at least one drug library, the drug library editing software may be configured to display medical data from the at least one medical data database on the user interface and filter the medical data using filter criteria.

[0079] In some embodiments, at least one medical device may be an infusion pump. In some embodiments, at least one drug library database is in a hosted environment. In some embodiments, at least one medical data database is in a hosted environment. In some embodiments, the filter criteria may be user-selectable. In some embodiments, the filter criteria may be a medical device type. In some embodiments, the filter criteria may be a data category. In some embodiments, the filter criteria may be a treatment-based criterion. In some embodiments, the filter criteria may be a medical device identifier. In some embodiments, the filter criteria may be a caregiver identifier. In some embodiments, the filter criteria may be a nursing area-based criterion. In some embodiments, the filter criteria may be a drug criterion. In some embodiments, the drug criterion may be a drug identifier. In some embodiments, the filter criteria may be a drug type. In some embodiments, filter criteria are applied to display a subset of the medical data by interacting with the medical data displayed on the user interface. In some embodiments, filter criteria are applied to drill down into the medical data by interacting with the medical data displayed on the user interface. In some embodiments, the medical data is displayed on the user interface in one or more of a plurality of user-specified formats.

[0080] According to an 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 on the graphical user interface. At least one of the at least one screen includes one or more parameter values. The processor may be further configured to visually change a font of at least one of the one or more parameter values ​​in response to a change in the one or more parameter values.

[0081] In some embodiments, the change may be a change in the order of magnitude of one or more parameter values. In some embodiments, the processor may be configured to visually change the font by changing the size of the font. In some embodiments, the processor may be configured to visually change the font by changing the color of the font. 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 a dose value. In some embodiments, one of the one or more parameter values ​​may be a time value. In some embodiments, one of the one or more parameter values ​​may be a volume to be infused. In some embodiments, one of the one or more parameter values ​​may be an infusion rate value. In some embodiments, one of the one or more parameter values ​​may be a drug concentration value. In some embodiments, at least one or more parameter values ​​are preprogrammed. In some embodiments, the processor may be configured to visually change the font by reducing the size of the parameter value.

[0082] According to an 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 indicating the pressure of fluid in an infusion line.

[0083] In some embodiments, the pressure indicator can be a pressure trend indicator. In some embodiments, the pressure trend indicator illustrates the pressure trend over the last four hours. In some embodiments, the pressure indicator can be a bar. In some embodiments, the bar includes multiple segments. In some embodiments, the pressure indicator can be configured to indicate different pressures by filling different segments. In some embodiments, the pressure indicator can be configured to indicate different pressures by filling the bar by different amounts. In some embodiments, the graphical user interface can be a touch screen.

[0084] According to an 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 displayed when the medical device is delivering treatment. The treatment-in-progress screen includes a medication indicator representing a medication being delivered by the medical device. The processor color-codes at least a portion of the medication indicator displayed on the user interface with one of a plurality of colors determined by a classification of a plurality of classifications assigned to the medication.

[0085] In some embodiments, the graphical user interface can be a touch screen. In some embodiments, the processor communicates with a memory storing a library of drugs for use with the medical device. In some embodiments, the drug library can include color-coded information for a portion of the drug indicator. In some embodiments, at least one of the at least one screen can be a programming screen in which a drug to be delivered by the medical device is specified. In some embodiments, at least one of the plurality of classifications can be a high-risk classification. In some embodiments, at least one of the plurality of classifications can be a drug type. In some embodiments, at least one of the plurality of classifications can be an anesthetic classification. In some embodiments, the drug indicator includes a name for the drug. In some embodiments, the drug indicator includes a non-textual indicia. In some embodiments, the non-textual indicia can be the color-coded portion of the drug indicator.

[0086] According to an 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 a computer-readable memory. The computer-readable memory stores a plurality of parameter values ​​related to a therapy programmed into the medical device. At least one of the parameter values ​​may be a value for a user-overridable limit on the therapy parameter value. The user-overridable limit on the therapy parameter value may be overridable by one or more users via the graphical user interface. In response to overriding the user-overridable limit, the processor causes a marker to be displayed adjacent to the therapy parameter value.

[0087] In some embodiments, the graphical user interface can be a touch screen. In some embodiments, at least one of the at least one screen displays a limit violation notification. In some embodiments, the limit violation notification does not display the value of the overridable limit. In some embodiments, the limit violation notification includes an override option. In some embodiments, user-overridable limits for treatment parameter values ​​require a first user and a second user to override the limit via the graphical user interface. In some embodiments, the plurality of parameter values ​​associated with a treatment that can be programmed into the medical device can be part of a drug library file stored in a computer-readable memory. In some embodiments, the label can be a non-text label.

[0088] According to an 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 a computer-readable memory. The computer-readable memory may store a plurality of medications to be delivered by the medical device. The medications may be organized into one or more medication categories. Each medication may further be associated with one or more parameter values ​​related to a treatment that may be programmed into the medical device. A user may use the graphical user interface to program the medical device to deliver the treatment. At least one step in programming the medical device may include selecting a medication category that includes the medication to be delivered by the medical device.

[0089] In some embodiments, the graphical user interface can be a touch screen. In some embodiments, the plurality of drugs and one or more drug categories can be part of a drug library file. In some embodiments, drug categories can be searched via the graphical user interface. In some embodiments, drug categories can be filtered via the graphical user interface. In some embodiments, at least one of the one or more parameter values ​​can be a user-overrideable parameter limit.

[0090] According to an embodiment of the present disclosure, a medical error reduction system may include medical error reduction software for creating and revising at least one drug library. The at least one drug library may be configured for use in at least one medical device. The software may be configured to provide one of a plurality of privilege sets to each of a plurality of user sets. Each of the plurality of privilege sets may be used to assign a certain level of software functionality to one of the plurality of user sets. The level of software functionality may be configured to define a user's ability to modify the 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. The at least one editor computer includes a processor in communication with a display. The at least one editor computer may be configured to communicate with the at least one server via a network using a client-server model.

[0091] According to an 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 (GUI) configured to allow a user to program the medical device. The medical device may include at least one server. The medical error reduction system may include at least one editor computer including a processor in communication with a display. The at least one editor computer may be configured to communicate with the at least one server via a network using a client-server model. The medical error reduction system may include medical error reduction software configured to be executed by the at least one server and accessed by the at least one editor computer for creating and revising at least one drug library. The at least one drug library is used in at least one medical device and includes a plurality of entries to guide user programming of the at least one medical device. The medical error reduction software may be further configured to display a simulated medical device GUI. The simulated medical device GUI uses one of the at least one drug libraries to mimic the behavior of a medical device GUI for the medical device.

[0092] According to an embodiment of the present disclosure, a medical device for delivering medication to a patient may include a controller configured to control the operation of a pumping mechanism that achieves medication delivery. The medical device may include a display. The medical device may include a computer-readable memory configured to store program code for a drug library. The drug library has a plurality of entries. The plurality of entries include at least one entry corresponding to a portion of a facility. For each entry, the plurality of entries may further include at least one drug entry corresponding to the portion of the facility. The medical device may include a processor configured to display a graphical user interface on the display of the medical device. The graphical user interface is used by a user to program the controller to use the drug library. The user can program the delivery of medication to the patient using one of the at least one drug entry corresponding to the portion of the facility.

[0093] In some embodiments, at least one drug entry includes parameters associated therewith. In some embodiments, the drug library may further include at least one drug that is not associated with a specific drug, but rather associated with a broad drug category. In some embodiments, a user may select one of the at least one drugs in the drug library that is not associated with a specific drug, but rather associated with a broad drug category, to program the delivery of a drug to a patient.

[0094] According to an embodiment of the present disclosure, a medical error reduction system may include medical drug library editing software for creating and revising at least one drug library for use with at least one medical device. The at least one drug library may contain multiple entries. The software may be configured to provide one of multiple privilege sets to each of multiple user sets. Each of the multiple privilege sets may be used to assign a certain level of software functionality to one of the multiple user sets. The level of software functionality may be configured to define the user's ability to change the at least one drug library. The medical error reduction system may include at least one server configured to execute the drug library editing software. The medical error reduction system may include at least one editor computer including a processor that communicates with a user interface. The at least one editor computer may be configured to communicate with the at least one server via a network using a client-server model. At least one of the multiple user sets may use the at least one editor computer to access the drug library editing software and request to change the at least one drug library.

[0095] In some embodiments, at least one of the plurality of privilege sets may be further configured to allow the user to deny implementation of the requested change to the at least one drug library or to accept implementation of the requested change to the at least one drug library.

[0096] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising at least one drug library. The at least one drug library includes a plurality of entries. The at least one drug library is for use with at least one medical device. The medical error reduction system may include at least one server configured to execute the drug library editing software. The medical error reduction system may include at least one editor computer including a processor in communication with a user interface. The user interface is configured to be used by a user to edit the at least one drug library. The at least one editor computer may be configured to communicate with the at least one server via a network using a client-server model, so that the at least one editor computer can access the drug library editing software. The user may request a change to the at least one drug library by submitting an electronic change request via the user interface.

[0097] In some embodiments, the electronic change request may be linked to medical data in an electronic database to provide contextual information.

[0098] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising at least one drug library. The at least one drug library includes a plurality of entries. Each of the at least one drug library is for use with at least one medical device. The drug library editing software is executed 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 at least one editor computer configured to communicate with the server, at least one drug library database, and at least one medical data database via a network. The at least one editor computer includes a processor in communication with a user interface. The user interface is used by a user to use the at least one drug library editing software to edit the at least one drug library. When editing the at least one drug library, the user can use the drug library editing software to access medical data from the at least one medical data database.

[0099] In some embodiments, when editing at least one drug library, a user may use drug library editing software to access medical data from at least one medical data database. In some embodiments, the medical data is displayed on the user interface in the form of at least one of a chart, a graph, a schematic diagram, and a graph. In some embodiments, when editing at least one drug library, a user may use the drug library editing software to display medical data from at least one medical data database on the user interface and filter the medical data so that only the medical data of interest to the user is displayed on the user interface.

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

[0101] In some embodiments, at least one screen includes a treatment-in-progress screen, the treatment-in-progress screen including a pressure indicator indicating 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 medication indicator indicating a medication being delivered by the medical device, and the processor may be further configured to color-code the medication indicator displayed on the user interface in one of a plurality of colors, one of the plurality of colors corresponding to a classification of the medication. In some embodiments, the medical device may include a computer-readable memory. The computer-readable memory stores a plurality of parameter values ​​related to a therapy programmed into the medical device. At least one of the parameter values ​​may be a user-overridable limit for the therapy parameter value. The user-overridable limit for the therapy parameter value may be overridable by the user via the graphical user interface. The processor may be further configured to display a marker adjacent to the therapy parameter value in response to the user overriding the user-overridable limit. In some embodiments, the computer-readable memory may be configured to store a plurality of medications that may be delivered by the medical device. Each medication may comprise one or more medication categories. Each medication may further be associated with one or more parameter values ​​related to the therapy programmed into the medical device. The user may use the graphical user interface to program the medical device to at least select a medication category that includes the medication to be delivered by the medical device.

[0102] According to an embodiment of the present disclosure, a medical error reduction system may include medical error reduction software for creating and revising at least one drug library. The software may be configured to provide a privilege set to each of a plurality of users. The privilege set may be used to assign a certain level of software functionality to each of the plurality of users. The level of software functionality may be configured to define the user's ability 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 includes a processor that communicates with a display, and the at least one editor computer and the at least one server may be configured to communicate via a network using a client-server model. Each of the at least one drug library is used in at least one medical device.

[0103] In some embodiments, each of the at least one drug library is organized into a hierarchy. In some embodiments, the hierarchy includes multiple care areas located below at least one care group. In some embodiments, each layer of the hierarchy includes multiple delivery parameters for at least one medical device. In some embodiments, each of the at least one drug library includes multiple entries corresponding to specific medications. In some embodiments, the at least one drug library includes multiple parameters that inform the operation of the at least one medical device. In some embodiments, the drug library includes multiple programming restrictions for the at least one medical device. In some embodiments, the medical error reduction software can be further configured to provide quality improvement information to multiple users. In some embodiments, the privilege set can be configured to assign drug library review privileges. In some embodiments, the privilege set can be configured to assign drug library edit privileges. In some embodiments, the privilege set can be configured to assign edit or create privileges. In some embodiments, the privilege set can be configured to assign add user privileges. In some embodiments, the privilege set assigned to each of the multiple users is for creating and revising the at least one drug library, enforcing a collaborative process between the multiple users.

[0104] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising multiple drug libraries. The multiple drug libraries may each contain multiple entries. Each of the multiple drug libraries is used with 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 includes a processor that communicates with a user interface. The user interface is used by one or more users to edit at least one drug library. The drug library editing software may be configured to import entries from a plurality of entries in a first drug library among the multiple drug libraries into a second drug library among the multiple drug libraries.

[0105] In some embodiments, the system may further include at least one server that can be configured to execute medical error reduction software. In some embodiments, a plurality of drug libraries are stored in a drug library database. In some embodiments, the drug library database is in a managed environment. In some embodiments, one or more users can specify that they want to import entries from a first drug library of the plurality of drug libraries into a second drug library of the plurality of drug libraries. In some embodiments, the first drug library in the plurality of drug libraries and the second drug library in the plurality of drug libraries both belong to a subset of the drug libraries of the plurality of drug libraries. In some embodiments, the subset of the drug library is associated with a permission set that allows access to the subset of the drug library by one or more users. In some embodiments, the permission set does not allow access to the subset of the drug library by another one or more users.

[0106] According to an embodiment of the present disclosure, a medical error reduction system includes drug library editing software for creating and revising at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library is used with at least one medical device, and the drug library editing software is executed by a server. The medical error reduction system may include at least one drug library database storing the 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 includes a processor that communicates with a user interface. The user interface can be used by a user to edit the at least one drug library. The at least one editor computer and the at least one drug library database can be configured to communicate via a network. The multiple entries include one or more clinical consultations.

[0107] In some embodiments, the drug library database is in a managed environment. In some embodiments, one or more clinical consultations can be free text entries. In some embodiments, one or more clinical consultations include images. In some embodiments, one or more clinical consultations include documents. In some embodiments, one or more clinical consultations are limited to a length between 0 and 100 characters. In some embodiments, each of the one or more clinical consultations is related to a short text clinical consultation. In some embodiments, the short text clinical consultation is limited to a length between 0 and 100 characters. In some embodiments, the short text clinical consultation is displayed on at least one screen of a graphical user interface of at least one medical device. In some embodiments, each of the one or more clinical consultations is displayed on at least one screen of a graphical user interface of at least one medical device. In some embodiments, each of the one or more clinical consultations is related to a drug entry in at least one drug library.

[0108] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library is used with at least one medical device, and the drug library editing software is executed by a server. The medical error reduction system may include at least one drug library database storing the 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 includes a processor that communicates with a user interface. The user interface can be used by a user to edit the at least one drug library. The at least one editor computer and the at least one drug library database can be configured to communicate via a network. The drug library editing software can be configured to allow a user to enter comments for one or more of the multiple entries.

[0109] In some embodiments, the drug library database is in a managed environment. In some embodiments, the annotation can be a free text entry. In some embodiments, the annotation includes an image. In some embodiments, the annotation includes a document. In some embodiments, the drug library editing software can be configured to allow a user to enter annotations for one or more subsets of a plurality of entries. In some embodiments, the drug library editing software can be configured to allow a user to enter annotations for each of a plurality of entries. In some embodiments, each of the plurality of entries related to the annotation is illustrated on the user interface via an annotation indicator. In some embodiments, user interaction with the annotation indicator causes the annotation to be displayed on the user interface.

[0110] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library is used with at least one medical device, and the drug library editing software is executed by a server. The medical error reduction system may include at least one drug library database storing the 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 includes a processor that communicates with a user interface. The user interface can be used by a user to edit the at least one drug library. The at least one editor computer and the at least one drug library database can be configured to communicate via a network. The multiple entries include flushing parameters.

[0111] In some embodiments, flushing parameters manage flushing of fluid lines associated with at least one medical device. In some embodiments, the flushing parameters include default delivery parameter values ​​to be used by the at least one medical device when flushing the fluid lines associated with the medical device. In some embodiments, the flushing parameters include a volume to be delivered. In some embodiments, the flushing parameters include a delivery rate. In some embodiments, the flushing parameters include a time.

[0112] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library is used with at least one medical device, and the drug library editing software is executed by a server. The medical error reduction system may include at least one drug library database storing the 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 includes a processor that communicates with a user interface. The user interface can be used by a user to edit the at least one drug library. The at least one editor computer and the at least one drug library database can be configured to communicate via a network. The drug library editing software can be configured to display a user-customizable screen that provides the user with the information they need at a glance.

[0113] In some embodiments, a user-customizable screen includes one or more plug-ins. In some embodiments, a user can select one or more plug-ins to be included on the user-customizable screen. In some embodiments, one of the one or more plug-ins can be a progress plug-in. In some embodiments, one of the one or more plug-ins can be a trends plug-in. In some embodiments, one of the one or more plug-ins can be an overview plug-in. In some embodiments, one of the one or more plug-ins can be a quick links plug-in. In some embodiments, one of the one or more plug-ins can be a change request plug-in. In some embodiments, one of the one or more plug-ins can be a feedback plug-in. In some embodiments, one of the one or more plug-ins can be a medical data plug-in. In some embodiments, one of the one or more plug-ins can be a change review plug-in. In some embodiments, one of the one or more plug-ins can be an administrator comment plug-in. In some embodiments, the user selects one or more plug-ins from a list of approved plug-ins. In some embodiments, the user is assigned a specific role in the medical error reduction software, and the list of approved plug-ins is associated with the specific role. In some embodiments, the system can further include a user database. In some embodiments, once customized, the user-customizable screen is stored in the user database and associated with the user. In some embodiments, the user-customizable screen can be selected from a plurality of loadable custom screen configurations.

[0114] According to an embodiment of the present disclosure, a medical error reduction system may include drug library editing software for creating and revising at least one drug library. The at least one drug library may contain multiple entries. Each of the at least one drug library is used with at least one medical device. The drug library editing software is executed by a server. The medical error reduction system may include at least one drug library database storing the 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 includes a processor that communicates with a user interface. The user interface can be used by a user to edit the at least one drug library. The at least one editor computer and the at least one drug library database can be configured to communicate via a network. The user can use the drug library editing software to compare two or more of the multiple entries. The comparison is displayed on the user interface.

[0115] In some embodiments, the comparison is displayed in a table on the user interface. In some embodiments, the comparison can be a side-by-side comparison. In some embodiments, the user interface visually represents the differences between two or more items in the comparison. In some embodiments, the comparison includes a differences-only option. In some embodiments, interacting with the differences-only option can trigger a comparison between a state showing only the differences between two or more of the plurality of items and a state showing all information related to the two or more of the plurality of items. In some embodiments, the comparison includes an edit option that can be used to open one of two or more of the plurality of items for editing.

[0116] According to an embodiment of the present disclosure, a method for generating a drug library file may include: assigning one of a plurality of privilege sets to each of a plurality of user sets, the plurality of privilege sets may be used to allocate a certain level of software functionality in drug library editing software, and the software functionality of this level may be configured to define the user's ability to change at least one drug library. The method for generating a drug library file may include creating a drug library using at least one editor computer. Each of the at least one editor computer includes a processor that communicates with a user interface. The user interface is used by a user to edit at least one drug library using the drug library editing software. Creating a drug library may include appropriate users of the plurality of user sets, defining the appropriate users by a plurality of privilege sets, specifying a master drug list for an institution, defining drug records for one or more parts of the institution, and verifying the defined drug records. The method may include approving the drug library for release to at least one medical device in the institution.

[0117] In some embodiments, one of the plurality of privilege sets assigns edit privileges. In some embodiments, one of the plurality of privilege sets assigns review privileges. In some embodiments, specifying a master medication list includes selecting a plurality of medications from a prescription database. In some embodiments, defining medication records for one or more parts of an organization includes selecting required medications from a master medication list for each of the one or more parts of the organization. In some embodiments, defining medication records for the one or more parts of an organization includes defining a plurality of parameters for each of the required medications. In some embodiments, verifying the defined medication records includes reviewing the defined medication records. In some embodiments, verifying the defined medication records includes editing and revising the defined medication records. In some embodiments, generating a drug library file may further include implementing a pilot phase for the drug library file, wherein the drug library file is tested on a test medical device. In some embodiments, generating a drug library file may further include implementing a pilot phase for the drug library file, wherein the drug library file is tested on a simulated medical device user interface. In some embodiments, verifying the defined medication records includes reviewing the defined medical device using a simulated medical device user interface.

[0118] In certain embodiments of the present disclosure, a method for deploying a drug library file to at least one medical device may include creating a drug library file. The method may include approving the drug library file for release to the at least one medical device. The method may include sending a notification to a user via a medication error reduction system editor service. The method may include downloading the drug library file to a device gateway. The method may include propagating the drug library file to the at least one medical device over a network that allows the device gateway to communicate with the at least one medical device.

[0119] In some embodiments, the method may further include downloading the drug library file to the device gateway in response to a user command. In some embodiments, the method may further include selecting at least one medical device from a list of medical devices. In some embodiments, the method may further include the device gateway periodically checking for updates to the drug library file. In some embodiments, the method may further include verifying the drug library file by the at least one medical device. In some embodiments, the method may further include sending a confirmation message from each of the at least one medical device to the device gateway if the drug library file has been successfully verified and updated. BRIEF DESCRIPTION OF THE DRAWINGS

[0120] These and other aspects will be apparent from the following detailed description of various embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0121] Figure 1 A block diagram illustrating a system for electronic patient care according to the present disclosure;

[0122] Figure 2 The embodiment according to the present invention is shown Figure 1 A block diagram of some aspects of the system;

[0123] Figure 3 A diagram illustrating an aggregation of several devices for communication according to an embodiment of the present disclosure;

[0124] Figure 4 A diagram illustrating an example system for electronic patient care according to an embodiment of the present disclosure;

[0125] Figure 5 is a block diagram illustrating some aspects of electronic communication between a medical device and a device application according to an embodiment of the present disclosure;

[0126] Figure 6 A state diagram illustrating a method of programming an infusion device according to an embodiment of the present disclosure;

[0127] Figure 7According to an embodiment of the present disclosure, an example software program can be executed on a processor, the software program and the processor are configured to implement Figure 1 Device Gateway, and Figure 2 The publish-subscribe model used by the application and device gateway;

[0128] Figure 8 According to an embodiment of the present disclosure, an example software program executable on a processor is provided, the software program and the processor being configured to implement a capability-registration model;

[0129] Figure 9 According to an embodiment of the present disclosure, an example software program executable on a processor is provided, the software program and the processor being configured to implement a drug safety method for generating a drug supervision and management library file;

[0130] Figure 10 An exemplary schematic diagram detailing possible tasks, responsibilities, and privileges for various users and parties that may be involved in creating a drug administration library document, according to an embodiment of the present disclosure, is illustrated;

[0131] FIG11a is a diagram illustrating an exemplary hierarchical organizational structure of a summary drug administration library ("DAL") file, according to an embodiment of the present disclosure;

[0132] FIG. 11 b is a diagram illustrating an exemplary hierarchical structure of a summary drug supervision and management library file according to an embodiment of the present disclosure;

[0133] Figure 12 A flow chart illustrating a number of exemplary steps that may be part of a medication error reduction system setup phase of a medication management library file, according to an embodiment of the present disclosure;

[0134] Figure 13 A flowchart detailing a number of exemplary steps that may be used to update a reference table loaded into a medication error reduction system, according to an embodiment of the present disclosure;

[0135] Figure 14 According to an embodiment of the present disclosure, a flowchart illustrating a number of exemplary steps that may be used in an institutional and organizational hierarchy in a medication error reduction system is detailed;

[0136] Figure 15 A flowchart illustrating a number of exemplary steps that may be used when a subscriber accesses a medication error reduction system editor;

[0137] FIG16 a is a flowchart illustrating a number of exemplary steps that may be used to establish various aspects of a medication error reduction system within an organization or institution, according to an embodiment of the present disclosure;

[0138] FIG16 b is a flow diagram illustrating a number of exemplary steps for specifying users, the groups to which they belong, and their various rights and privileges in relation to a medication error reduction system editor, according to an embodiment of the present disclosure;

[0139] Figure 17 A flowchart illustrating a number of exemplary steps that may be used to update various aspects of a medication error reduction system within an organization or institution, according to an embodiment of the present disclosure;

[0140] Figure 18 A flow chart illustrating a number of exemplary steps that may be used to create or update an institution / organization master medication list, according to an embodiment of the present disclosure;

[0141] Figure 19 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to add a clinical consultation entry to a database is illustrated;

[0142] Figure 20 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to modify a general setting for an institution or organization is illustrated;

[0143] Figure 21 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to add a care group to a medication management library file is shown;

[0144] Figure 22 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to add a care area to a medication management library file is shown;

[0145] Figure 23 A flowchart detailing a number of exemplary steps that may be used in verification of a care area is shown, according to an embodiment of the present disclosure;

[0146] Figure 24 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update a care area is shown;

[0147] Figure 25 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to add a medication record or a medication use record to a particular care area is shown;

[0148] Figure 26 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to review a medication list for a particular care area is illustrated;

[0149] Figure 27 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update a medication list is shown;

[0150] Figure 28 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to recheck a medication list is shown;

[0151] Figure 29 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to submit a drug regulatory library file for approval is illustrated;

[0152] Figure 30 According to an embodiment of the present disclosure, a flowchart detailing a plurality of exemplary steps that may be used to place a drug administration library file under conditions for release is shown;

[0153] FIG31 a illustrates a flowchart detailing a number of exemplary steps that may be used to deploy a drug administration library file on a number of system components, according to an embodiment of the present disclosure;

[0154] FIG31 b illustrates a flowchart detailing several exemplary steps that may be used to package and stage resources for publication to a device gateway, according to an embodiment of the present disclosure;

[0155] FIG31 c illustrates a flowchart detailing a number of exemplary steps that may be used to track the deployment of various resources, according to an embodiment of the present disclosure;

[0156] Figure 32 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update a pre-existing drug administration library file is shown;

[0157] Figure 33 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update an institution / organization's master medication list is illustrated;

[0158] Figure 34 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update a clinical advisory list is illustrated;

[0159] Figure 35 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update general settings for an institution / organization is illustrated;

[0160] Figure 36 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update a care area is shown;

[0161] Figure 37According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update medication records for a care area is illustrated;

[0162] Figure 38 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to create and save a drug administration library report is shown;

[0163] Figure 39 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to create a drug administration library discrepancy report is illustrated;

[0164] Figure 40 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to create a comparison report of drug administration libraries within an organization is illustrated;

[0165] Figure 41 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to create an inter-organizational drug administration library comparison report is illustrated;

[0166] Figure 42 According to an embodiment of the present disclosure, a flowchart detailing a plurality of exemplary steps following creation of a drug administration library history report is illustrated;

[0167] Figure 43 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to log into a medication error reduction system editor is shown;

[0168] Figure 44 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to modify a password for a medication error reduction system editor service is illustrated;

[0169] Figure 45 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to recover a password for a medication error reduction system editor service is illustrated;

[0170] Figure 46 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to review a drug library item using a medical device programming simulator is illustrated;

[0171] Figure 47 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to compare records in a drug administration library file is shown;

[0172] Figure 48According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update a drug supervision library file on a medical device is shown;

[0173] Figure 49 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to update a DAL file on a medical device is shown;

[0174] Figure 50 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to configure a user interface for a medication error reduction system editor service or a continuous quality improvement ("CQI") service is illustrated;

[0175] Figure 51 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to browse and reuse continuous quality improvement data is illustrated;

[0176] Figure 52 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to display a desired continuous quality improvement report on a user interface is illustrated;

[0177] Figure 53 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to configure a continuous quality improvement report is illustrated;

[0178] Figure 54 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to configure a continuous quality improvement report is illustrated;

[0179] Figure 55 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to apply filters to continuous quality improvement data is illustrated;

[0180] Figure 56 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to apply filters to continuous quality improvement data using a date range or time frame is illustrated;

[0181] Figure 57 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to apply filters to continuous quality improvement data based on user-specified, customized filtering criteria is illustrated;

[0182] Figure 58 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to modify the appearance of continuous quality improvement data, such as a continuous quality improvement report, on a user interface is illustrated;

[0183] Figure 59 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to modify time units in a continuous quality improvement report based on user input is illustrated;

[0184] Figure 60 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to hide a displayed panel or to display a hidden panel is shown;

[0185] Figure 61 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to alternate between an overview and a detail of a continuous quality improvement report is illustrated;

[0186] Figure 62 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to sort CQI data in a CQI report is shown;

[0187] Figure 63 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to permute between count browsing and date browsing of a CQI report is shown;

[0188] Figure 64 According to an embodiment of the present disclosure, a flowchart is shown detailing a plurality of exemplary steps that may be used to select a tool on a user interface that allows a user to perform a function or functions;

[0189] Figure 65 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to print a continuous quality improvement report is illustrated;

[0190] Figure 66 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to download a continuous quality improvement report is illustrated;

[0191] Figure 67 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to email a continuous quality improvement report is shown;

[0192] Figure 68 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to derive data from a continuous quality improvement report is illustrated;

[0193] Figure 69 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to schedule a continuous quality improvement report for automatic generation and distribution is illustrated;

[0194] Figure 70According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to generate and distribute a planned continuous quality improvement report is illustrated;

[0195] Figure 71 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to generate an automated continuous quality improvement summary report is illustrated;

[0196] Figure 72 According to an embodiment of the present disclosure, an exemplary graphical user interface login screen presented to a user when the user attempts to access the medication error reduction system editor service or the continuous quality improvement service is illustrated;

[0197] Figure 73 According to an embodiment of the present disclosure, an exemplary graphical user interface login screen presented to a user when the user attempts to access the medication error reduction system editor service or the continuous quality improvement service is illustrated;

[0198] Figure 74 According to an embodiment of the present disclosure, an exemplary initialization screen that may be displayed on a user interface is illustrated;

[0199] Figure 75 According to an embodiment of the present disclosure, an exemplary initialization wizard screen is illustrated;

[0200] Figure 76 According to an embodiment of the present disclosure, an exemplary initialization wizard screen is illustrated;

[0201] Figure 77 According to an embodiment of the present disclosure, an exemplary initialization wizard screen is illustrated;

[0202] Figure 78 Illustrated is an exemplary embodiment of a “Welcome” screen that may be displayed on a user interface, such as a medication error reduction system editor service user interface, according to an embodiment of the present disclosure;

[0203] Figure 79 An example of a medication error reduction system editor dashboard screen is illustrated according to an embodiment of the present disclosure;

[0204] Figure 80 An exemplary care area screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0205] Figure 81 An exemplary add care area screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0206] Figure 82An exemplary add care area screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0207] Figure 83 An exemplary add care area screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0208] Figure 84 An exemplary add care area screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0209] Figure 85 An exemplary add care area screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0210] Figure 86 An exemplary add care area screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0211] Figure 87 An exemplary care area screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0212] Figure 88 According to an embodiment of the present disclosure, an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0213] Figure 89 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0214] Figure 90 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0215] Figure 91 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0216] Figure 92 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0217] Figure 93According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0218] Figure 94 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0219] Figure 95 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0220] Figure 96 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0221] Figure 97 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0222] Figure 98 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0223] Figure 99 According to an embodiment of the present disclosure, an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0224] Figure 100 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0225] Figure 101 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0226] Figure 102 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0227] Figure 103 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0228] Figure 104 According to an embodiment of the present disclosure, an exemplary add medication record screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0229] Figure 105 According to an embodiment of the present disclosure, an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0230] Figure 106 According to an embodiment of the present disclosure, an exemplary drug library item screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0231] Figure 107 According to an embodiment of the present disclosure, an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0232] Figure 108 According to an embodiment of the present disclosure, an exemplary medication record comparison screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0233] Figure 109 According to an embodiment of the present disclosure, an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0234] Figure 110 According to an embodiment of the present disclosure, an exemplary medication record comparison screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0235] Figure 111 According to an embodiment of the present disclosure, an exemplary medication record comparison screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0236] Figure 112 An exemplary medical device simulator screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0237] Figure 113 An exemplary medical device simulator screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0238] Figure 114 An exemplary medical device simulator screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated according to an embodiment of the present disclosure;

[0239] Figure 115 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0240] Figure 116 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0241] Figure 117 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0242] Figure 118 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0243] Figure 119 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0244] Figure 120 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0245] Figure 121 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0246] Figure 122 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0247] Figure 123 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0248] Figure 124 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0249] Figure 125 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0250] Figure 126 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0251] Figure 127 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0252] Figure 128 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0253] Figure 129 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0254] Figure 130 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0255] Figure 131 According to an embodiment of the present disclosure, an exemplary continuous quality improvement screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0256] Figure 132 According to an embodiment of the present disclosure, an example of a medication error reduction system editor dashboard screen is illustrated;

[0257] Figure 133 According to an embodiment of the present disclosure, an example of a medication error reduction system editor dashboard screen is illustrated in which a feedback item has been accessed;

[0258] Figure 134 According to an embodiment of the present disclosure, an example of a medication error reduction system editor dashboard screen is illustrated;

[0259] Figure 135 An example of a medication error reduction system editor dashboard screen is shown in which a change request has been accessed, according to an embodiment of the present disclosure;

[0260] Figure 136 According to an embodiment of the present disclosure, an example of a medication error reduction system editor dashboard screen is illustrated;

[0261] Figure 137 According to an embodiment of the present disclosure, an example of a medication error reduction system editor dashboard screen is illustrated;

[0262] Figure 138 According to an embodiment of the present disclosure, an example of a medication error reduction system editor dashboard screen is illustrated;

[0263] Figure 139 An example of a medication error reduction system editor dashboard screen is shown in which a change request has been accessed, according to an embodiment of the present disclosure;

[0264] Figure 140 An example of a medication error reduction system editor dashboard screen is shown in which a change request has been accessed, according to an embodiment of the present disclosure;

[0265] Figure 141 According to an embodiment of the present disclosure, an example of a medication error reduction system editor dashboard screen is illustrated;

[0266] Figure 142 An example of a medication error reduction system editor dashboard screen is illustrated in which a proposed change has been accessed for review, according to an embodiment of the present disclosure;

[0267] Figure 143 An example of a medication error reduction system editor dashboard screen is illustrated in which a proposed change has been accessed for review, according to an embodiment of the present disclosure;

[0268] Figure 144 According to an embodiment of the present disclosure, an example of a medication error reduction system editor dashboard screen is illustrated;

[0269] Figure 145 An example of a medication error reduction system editor dashboard screen is illustrated in which a proposed change has been accessed for review, according to an embodiment of the present disclosure;

[0270] Figure 146 An example of a medication error reduction system editor dashboard screen is shown in which a user is using a search tool, according to an embodiment of the present disclosure;

[0271] Figure 147 According to an embodiment of the present disclosure, an example of a review screen that may be displayed on a user interface, such as a medication error reduction system user interface, is illustrated;

[0272] Figure 148 According to an embodiment of the present disclosure, an example of a review screen that may be displayed on a user interface, such as a medication error reduction system user interface, is illustrated;

[0273] Figure 149 According to an embodiment of the present disclosure, an example of a review screen that may be displayed on a user interface, such as a medication error reduction system user interface, is illustrated;

[0274] Figure 150 According to an embodiment of the present disclosure, an example of a review screen that may be displayed on a user interface, such as a medication error reduction system user interface, is illustrated;

[0275] Figure 151 According to an embodiment of the present disclosure, an example of a review screen that may be displayed on a user interface, such as a medication error reduction system user interface, is illustrated;

[0276] Figure 152 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0277] Figure 153 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0278] Figure 154 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0279] Figure 155 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0280] Figure 156 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0281] Figure 157 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0282] Figure 158 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0283] Figure 159 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0284] Figure 160 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0285] Figure 161 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0286] Figure 162 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0287] Figure 163 According to an embodiment of the present disclosure, an exemplary drug library input screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0288] Figure 164 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0289] Figure 165 According to an embodiment of the present disclosure, an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0290] Figure 166 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a medication error reduction system user interface, is illustrated;

[0291] Figure 167 According to an embodiment of the present disclosure, an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0292] Figure 168 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0293] Figure 169 According to an embodiment of the present disclosure, an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0294] Figure 170 According to an embodiment of the present disclosure, an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0295] Figure 171 According to an embodiment of the present disclosure, an exemplary primary medication list screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0296] Figure 172According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0297] Figure 173 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0298] Figure 174 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0299] Figure 175 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0300] Figure 176 According to an embodiment of the present disclosure, an exemplary primary medication list screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0301] Figure 177 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0302] Figure 178 According to an embodiment of the present disclosure, an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0303] Figure 179 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0304] Figure 180 According to an embodiment of the present disclosure, an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, is illustrated;

[0305] Figure 181 According to an embodiment of the present disclosure, an exemplary software architecture block diagram for an exemplary medical device is illustrated;

[0306] Figure 182 According to an embodiment of the present disclosure, a flowchart is shown detailing a number of exemplary steps that may be used to install a syringe on a medical device when preparing for an infusion through the medical device;

[0307] Figure 183 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to prime an IV line of a medical device is illustrated;

[0308] Figure 184 According to an embodiment of the present disclosure, a flowchart is shown detailing several exemplary steps that may be used to install an administration set in a medical device;

[0309] Figure 185 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to select a care area, medication, clinical application, and concentration for a medication when programming an infusion on a medical device is shown;

[0310] Figure 186 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to program an infusion on a medical device is shown;

[0311] Figure 187 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to determine whether a parameter entered on a medical device falls outside of limits defined for that parameter is shown;

[0312] Figure 188 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to deliver a primary continuous infusion is shown;

[0313] Figure 189 According to an embodiment of the present disclosure, a flowchart detailing several exemplary steps that may be used to deliver a bolus of medication via a medical device is shown;

[0314] Figure 190 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to deliver an adjunct infusion is shown;

[0315] Figure 191 According to an embodiment of the present disclosure, a flowchart is shown detailing several exemplary steps that may be used to deliver a multi-level infusion through a medical device;

[0316] Figure 192 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to titrate an infusion administered by a medical device is illustrated;

[0317] Figure 193 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used at or near the end of an infusion administered by a medical device is illustrated;

[0318] Figure 194 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to detect and resolve line conditions of a medical device is illustrated;

[0319] Figure 195 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to detect and resolve an occlusion of an infusion line associated with a medical device is illustrated;

[0320] Figure 196 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to change a care zone of a medical device during treatment is shown;

[0321] Figure 197 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to stop an ongoing infusion on a medical device is shown;

[0322] Figure 198 According to an embodiment of the present disclosure, a flowchart is illustrated detailing a number of exemplary steps that may be used if a battery of a medical device becomes below a predetermined level;

[0323] Figure 199 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to lock and unlock a user interface of a medical device is shown;

[0324] Figure 200 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to power off a medical device or put the medical device to sleep is illustrated;

[0325] Figure 201 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used to flush an IV line associated with a medical device is illustrated;

[0326] Figure 202 A flowchart detailing several exemplary steps that may be used to install a replacement syringe on a medical device during an infusion procedure is shown, according to an embodiment of the present disclosure;

[0327] Figure 203 According to an embodiment of the present disclosure, a flowchart detailing several exemplary steps for setting up a split infusion using several medical devices is shown;

[0328] Figure 204 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used if a medical device is removed from a medical device rack as part of an established split-range infusion is illustrated;

[0329] Figure 205 According to an embodiment of the present disclosure, a flowchart detailing a number of exemplary steps that may be used in the event of removing a medical device from a medical device rack as part of an established split-range infusion is illustrated;

[0330] Figure 206 According to an embodiment of the present disclosure, an exemplary startup screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0331] Figure 207 According to an embodiment of the present disclosure, an exemplary startup screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0332] Figure 208 According to an embodiment of the present disclosure, an exemplary startup screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0333] Figure 209 According to an embodiment of the present disclosure, an exemplary login screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0334] Figure 210 According to an embodiment of the present disclosure, an exemplary login screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0335] Figure 211 According to an embodiment of the present disclosure, an exemplary login screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0336] Figure 212 According to an embodiment of the present disclosure, an exemplary select care group screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0337] Figure 213 According to an embodiment of the present disclosure, an exemplary select care group screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0338] Figure 214 According to an embodiment of the present disclosure, an exemplary Select Patient screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0339] Figure 215 According to an embodiment of the present disclosure, an exemplary select medication screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0340] Figure 216 According to an embodiment of the present disclosure, an exemplary select medication screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0341] Figure 217According to an embodiment of the present disclosure, an exemplary select medication screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0342] Figure 218 According to an embodiment of the present disclosure, an exemplary select medication screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0343] Figure 219 According to an embodiment of the present disclosure, an exemplary select medication screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0344] Figure 220 According to an embodiment of the present disclosure, an exemplary select clinical application screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0345] Figure 221 According to an embodiment of the present disclosure, an exemplary select clinical application screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0346] Figure 222 According to an embodiment of the present disclosure, an exemplary select concentration screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0347] Figure 223 According to an embodiment of the present disclosure, an exemplary select input patient weight screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0348] Figure 224 According to an embodiment of the present disclosure, an exemplary select input patient weight screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0349] Figure 225 According to an embodiment of the present disclosure, an exemplary select input patient weight screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0350] Figure 226 According to an embodiment of the present disclosure, an exemplary loading drip device screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0351] Figure 227 According to an embodiment of the present disclosure, an exemplary troubleshooting screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0352] Figure 228According to an embodiment of the present disclosure, an exemplary load syringe screen is illustrated that may be displayed on a user interface, such as a user interface of a medical device;

[0353] Figure 229 According to an embodiment of the present disclosure, an exemplary select syringe screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0354] Figure 230 According to an embodiment of the present disclosure, an exemplary treatment programming screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0355] Figure 231 According to an embodiment of the present disclosure, an exemplary treatment programming screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0356] Figure 232 According to an embodiment of the present disclosure, an exemplary treatment programming screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0357] Figure 233 According to an embodiment of the present disclosure, an exemplary treatment programming screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0358] Figure 234 According to an embodiment of the present disclosure, an exemplary treatment programming screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0359] Figure 235 According to an embodiment of the present disclosure, an exemplary treatment programming screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0360] Figure 236 An exemplary extreme reload screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated according to an embodiment of the present disclosure;

[0361] Figure 237 According to an embodiment of the present disclosure, an exemplary second user permission screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0362] Figure 238 According to an embodiment of the present disclosure, an exemplary treatment programming screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0363] Figure 239 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0364] Figure 240 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0365] Figure 241 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0366] Figure 242 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0367] Figure 243 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0368] Figure 244 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0369] Figure 245 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0370] Figure 246 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0371] Figure 247 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0372] Figure 248 According to an embodiment of the present disclosure, an exemplary treatment stop screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0373] Figure 249 According to an embodiment of the present disclosure, an exemplary warning screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0374] Figure 250 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0375] Figure 251According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0376] Figure 252 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0377] Figure 253 According to an embodiment of the present disclosure, an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0378] Figure 254 According to an embodiment of the present disclosure, an exemplary treatment completion screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0379] Figure 255 According to an embodiment of the present disclosure, an exemplary treatment completion screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0380] Figure 256 According to an embodiment of the present disclosure, an exemplary notification setting screen that may be displayed on a user interface, such as a user interface of a medical device, is illustrated;

[0381] Figure 257 According to an embodiment of the present disclosure, exemplary treatment parameter screens are illustrated that may be displayed on a user interface, such as a user interface of a medical device. DETAILED DESCRIPTION

[0382] Figure 1 A block diagram of a system 1 for electronic patient care according to an embodiment of the present disclosure is shown. The system 1 includes facility IT applications / services 11, a facility 10, and a cloud service 2.

[0383] Facility 10 may be a hospital, clinic, medical office, outpatient center, emergency room, or a combination or group of the foregoing. Facility 10 may include a facility gateway 21 that enables various medical devices 26 to communicate with facility IT applications / services 11 and / or with cloud services 2. Facility 10 includes various medical devices 26 that can be operated by nurses 9 and used on patients cared for at facility 10. Medical devices 26 may be infusion pumps, peristaltic pumps, syringe pumps, nephrology equipment, physiological parameter monitoring devices, other patient care devices, or some combination of the foregoing.

[0384] The facility gateway 21 may be hosted, in the cloud, maintained by a service provider for the facility 10, controlled, maintained, or serviced by a combination of the service provider and / or facility IT staff 18, and / or implemented in a virtual or physical environment. In some embodiments, the facility gateway 21 may be in an appliance in a patient's home. The facility gateway 21 may be used by a hospital, a care group, an integrated distribution network ("IDN"), an integrated service group or clinic, a cluster of clinics, a central clinic, or other care facility or infrastructure.

[0385] The Biomed PC Tool 20 can be used by the Biomed Technician 19 to update the software of the device 26. The Biomed PC Tool 20 can be a browser-based tool for the Biomed Technician 19 to monitor the health of their medical devices 26, browse log files, track maintenance personnel activity, and manage software / firmware installation. The Biomed Technician 19 can be a hospital employee (or contracted service) who installs, updates, and services the medical devices 26 (including infusion pumps) to ensure they are in proper working order. The Biomed PC Tool 20 can be connected to the device 26 via a physical data connection, such as a USB connection or a serial cable connection, so that the Biomed Technician 19 can perform these services. The Biomed Technician 19 can also use the Device Manager 24 to update the device 26 wirelessly.

[0386] Medical devices 26 communicate with facility IT applications / services 11 (via communication link 343) and / or cloud services 2 (via communication link 344) via facility gateway 21. Communication links 343 and 344 may use WiFi, Ethernet, TCP / IP, WiMax, fiber optic cables, or any other known communication technology.

[0387] The device 26 communicates with the facility gateway 21 by establishing communication with the device gateway 22 (e.g., by registering). The facility gateway 21 can be a computer, a virtual machine, a hardware device, a software device, a hosted device, executed software, etc., or some combination thereof. The device gateway 22 can be software executed by the facility gateway 21. The medical 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 thus with the facility gateway 21). The device gateway 22 can include a message routing engine that supports publish / subscribe and point-to-point routing mechanisms. The device gateway 22 can also provide name resolution and capability registry capabilities. Object-relational mapping can be used by the device gateway 22 for small-scale object persistence (e.g., using an object-relational mapping (ORM) engine). Additionally or alternatively, the device manager 24 can provide name resolution and / or registry capabilities.

[0388] In some embodiments of the present disclosure, a device in devices 26 is a monitoring client, such as a tablet, a tablet device, a PDA, a smart phone, a laptop, or a touch screen-based computer. The monitoring client of device 26 may have a monitoring client application within device applications 23, allowing a caregiver to communicate with other devices of device 26. The monitoring client may be used to receive status information from the medical device of device 26, receive CQI messages from the medical device of device 26, receive reportable biomedical events (RBEs) or reportable clinical events (RCEs) from the medical device of device 26, program the medical device of device 26, or communicate with the medical device of device 26.

[0389] The communication link 343 between the device 26 and the facility gateway 21 can use WiFi, Ethernet, TCP / IP, WiMax, fiber optic cable, or any other known communication technology. In some embodiments of the present 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 can be located in a patient's home, in a clinic, in an on-site medical facility (e.g., a tent medical facility), at an emergency location, at another location, or some combination thereof.

[0390] The device gateway 22 may provide: (1) component registration and licensing management (e.g., using the device manager 24); (2) an installation repository for receiving, maintaining, and tracking new installable components, such as device firmware / software, drug regulatory libraries, enterprise application software, and architecture software (e.g., operating system versions, application servers, database management systems (“DBMS”)); and / or (3) message routing capabilities for distributing messages between applications within the facility gateway 21 and with external subsystems (e.g., cloud services 2).

[0391] The deployment environment in which the medical device 26 maintains an effective network connection with the device gateway 22 is called a connection environment, and as previously described, can be implemented using a wireless network (IEEE 802.11b / g / n). As previously described, in other embodiments, network connectivity can be implemented using other technologies, such as cellular technology.

[0392] An environment in which device 26 does not maintain a wireless connection is referred to as a standard environment, despite the fact that the enterprise application components and external subsystems may still be connected. In this particular embodiment, device gateway 22 still performs all three tasks for the enterprise application components and external subsystems, while message exchanges involving device 26 can use biomedical technician 19 (e.g., using device 26) to store messages in an external medical device (e.g., a memory stick).

[0393] Event subscribers, such as device applications 23, can refine the event stream and republish higher-level events back to the device gateway 22. Reportable biomedical events ("RBEs"), as described below, will be among the events republished by these applications. RBEs can be reported to the cloud service 2 as CQI messages. In some embodiments, the application running on the facility gateway 21 is a biomedical server that subscribes to RBEs and stores them in a local database within the facility gateway 21.

[0394] Biomed technicians 19 can use their browser to access device manager 24 and request a device status report for devices 26. The UI of device manager 24 can instruct the biomed server to access the database and generate an HTML / JS page for the browser to display to the biomed technician 19.

[0395] In some embodiments, when authorizing a new device of medical device 26 for use with the device gateway 22, the biomedical technician 19 must register the new device using its serial number. This can be cryptographically authenticated using asymmetric keys (public / private key pairs) and can be performed as part of the manufacturing process. Whenever a device of medical device 26 is registered with the device gateway 22, the biomedical technician 19 configures its wireless protocol and encryption settings. Whenever a medical device 26 is registered with the device gateway 22, the medical device reports its initial configuration, including model, options, and hardware, firmware, and device control software versions, for storage within the device gateway 22 and / or within the device manager 24. Similarly, when a device is removed from the list of authorized devices of the device gateway 22, the biomedical technician 19 can deregister it.

[0396] Each of the medical devices 26 can run self-tests upon startup and publish events containing the results to the device gateway 22. In addition, because the medical devices 26 can routinely run for long intervals between restarts, the medical devices 26 can automatically order and run certain self-tests at times that do not interfere with patient safety and / or treatment.

[0397] The facility gateway 21 includes device applications 23 that can communicate data using a publish-subscribe data connection (described below). Each device application in the device applications 23 can be used for a specific type and / or model of device 26. These applications can provide intelligent software for the medical devices 26 by receiving, filtering, and analyzing raw events and retransmitting higher-level interpretations. Each type of medical device (of the medical devices 26) can have a corresponding device application (of the device applications 23).

[0398] The facility gateway 21 also includes a device manager 24 for controlling, managing, or monitoring devices 26. For example, the device manager 24 can be used to update and / or download configuration files (e.g., DAL files) to the devices 26. As previously described, the biomedical technician 19 can control updates to the software, firmware, and / or configuration files of the devices 26. The device manager 24 can provide IT administrators and / or technicians 18 with a browser-based tool to monitor the health of the hardware, software, and network resources used to support the delivery of patient care. That is, the facility gateway 21 can be managed by facility IT employees / contractors 18.

[0399] When a new Drug Administration Library ("DAL") version is released, a secure messaging link can send the DAL file from the DAL manager 5 to the device gateway 22 to notify the biomedical technician 19 of its availability. The notification specifies the device type, the location of the DAL, documentation, version note URL, installer URL, checksum, and installation dependencies. In some embodiments of the present disclosure, the device manager 24 has access to the new DAL file and can receive the DAL file from the device gateway 22, receive the DAL file directly from the DAL manager 5, and / or use the DAL file to control updates to the medical device 26.

[0400] In certain embodiments, the biomedical technician 19 uses the version note URL (e.g., via the device manager 24 webpage and / or via the biomedical PC tool 20) to access information about the update, and uses the installer URL and checksum to download and verify the DAL file and save it in the library of the device gateway 22. The biomedical technician 19 then selects one or more medical devices 26 to copy the new DAL file to. The selected one or more medical devices 26 are then informed (e.g., via the device gateway 22) that the new DAL file is available for them. As soon as the next medical device 26 is restarted (the medical device 26 selected for update), the selected medical device 26 installs the new DAL version (exiting on errors) and notifies the device gateway 22 and / or device manager 24 of the results. Any of the processes for updating DAL files described herein can be used to update the firmware, software, OS, or other configuration files of the medical device 26.

[0401] The facility gateway 21 may also include an integration API 25 that allows 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 (PIS) 16, electronic medical records (EMR) 17, computerized physician order entry (CPIE) 14, laboratory information system (LIS) 15, real-time location services (RTLS) 12, and / or other databases or services 13. The integration API 25 enables components within the facility gateway 21 to interoperate with the facility IT applications / services 11. The facility gateway 21 may communicate with the facility IT applications 11 via a communication link 341, which may include a wireless link, a hardwired link, a TCP / IP link, an Internet link, a software communication link, a hardware communication link, or other communication technology or techniques.

[0402] Facility IT applications / services 11 support the hospital's administrative functions (e.g., admissions, discharges, transfers, coding, billing, collections, etc.). An integration API 25 decouples the differences between applications 12-17 of facility IT applications 11 from applications 23-24, device gateway 22, and / or devices 26. For example, a device in devices 26 can request programming information from device gateway 22 (or a device in devices 26 can push programming information to a device). Patient IDs, pump IDs, medications, and flow rates may exist in one or more facility IT applications 11; the integration API 25 provides a common format for transmitting this information to devices 26, regardless of the needs or requirements of the facility IT application 11. This information can be collected by querying the integration API 25 of one of the facility IT applications 11 to obtain the data and providing it to the device 26 in a standardized format. The integration API 25 can be used with various facility IT applications 12-17 having different formats, data standards, communication standards, encryption standards, etc., while providing a standard interface for applications 22-24 and / or devices 26.

[0403] The integration API 25 facilitates automatic programming of one or more of the devices 26. A prescription can be sent from one of the servers of the facility IT application 14. The integration API 25 can receive the prescription, reformat it, and send it to the device gateway 22. The facility gateway 21 can include a clinical server that writes prescription events to a persistent cache. The clinical server can initiate an automatic programming workflow. This workflow can identify the medical device 26 corresponding to the target patient and send an instruction message to each of the medical devices 26 to load the prescription. Each of the medical devices 26 will acknowledge receipt of the prescription and display a notification on a display. The clinician can locate the medication bag and can use, for example, a barcode reader on each of the medical devices 26 to verify the medication and the patient. Each of the medical devices 26 can then confirm that the medication matches the prescription, and the clinician can begin administering the medication. Each of the medical devices 26 completes the automatic programming workflow by sending a message to the clinical server via the device gateway.

[0404] The caregiver can use the UI to verify the programming of the medical device of device 26. The clinician determines the medication location and uses the respective medical device user interface of medical device 26 to verify the medical device auto-programming parameters of device 26 and / or manually program the medical device of medical device 26.

[0405] The PIS 16 is a departmental system used by pharmacists 8 to receive, review, track, and fill prescription orders. The EMR 17 system tracks medical histories (encounters, tests, diagnoses, procedures, etc.) in a healthcare setting. The CPOE 14 is a system used by doctors or nurses 9 to order lab tests, prescription medications, medical imaging, and other clinical procedures. The LIS 15 is a system used by laboratory technicians to receive and process orders for clinical samples (e.g., tissue, blood, urine, etc.). The RTLS 12 tracks the location and status of the equipment 26. The Other 13 can be any other database used for patient care.

[0406] The cloud service 2 includes a cloud-hosted infusion safety manager 3 ("ISM"). The infusion safety manager may be used herein interchangeably with the term hosted security manager ("HSM"). The HSM 3 includes a continuous quality improvement ("CQI") manager 4 and a DAL manager 5. A risk manager 6, a nurse administrator 7, and a pharmacist 8 may each review CQI messages retrieved by the CQI manager 4 to facilitate the development and improvement of DAL files via the DAL manager 5. Thereafter, the DAL files are downloaded to one or more devices 26. The DAL manager 5 may include or interface with a medication error reduction system ("DERS") editor (e.g., Figure 4 DERS editor 112, described below).

[0407] Figure 2 Showing an embodiment according to the present disclosure, Figure 1 A block diagram of some aspects of the system. That is, Figure 2 shows the cloud service Figure 1 More details on some aspects of .

[0408] The device gateway 40, the device manager 41 and the integration API 65 are Figure 1 The large volume application 44, the infusion pump application 43 and other applications are all part of the facility gateway 21. Figure 1 The device manager 41 including its associated database 45 may be part of the device application 23. Figure 1 Device Manager 24.

[0409] Large volume pump ("LVP") application 44 is an application for LVP 36. Syringe application 43 is an application for infusion pump 38, and other application 42 is an application for another device 39. Other application 42 and another device 39 may correspond to any medical device.

[0410] Device gateway 40 provides publish-subscribe data connections 58-64. Applications 42, 43, 44 also provide publish-subscribe data connections 49-57. The publish-subscribe messaging model provides communication between device gateway 40 and / or application device managers 41, 42, 43, 44, 65, 72. However, in other embodiments, another messaging model can be used for communication.

[0411] CQI listener 72 may subscribe to various data feeds from applications 42, 43, 44 to report CQI messages to CQI manager 29, which may store them in database 30. CQI listener 72 may report raw results for publishing connections 49-57 and / or 58-64, and / or may format them.

[0412] In some embodiments, applications 42, 43, and 44 reformat raw events from each of devices 36-39 (received via subscriptions to topics logged by device gateway 40) into CQI messages. Applications 42, 43, and 44 can log CQI topics subscribed to by CQI listener 72. Applications 42, 43, and 44 publish CQI messages to CQI topics, causing CQI listener 72 to receive the CQI messages. CQI listener 72 transmits the CQI messages to cloud service 28.

[0413] In certain embodiments, a single GUI interface 33 may be used to browse CQI messages within database 30 while generating DAL files 35 for use by devices 36, 37, 38, and 39. Software updates 34 may be sent to device gateway 40 to update medical devices 36, 37, 38, and 39.

[0414] Figure 3 An aggregated diagram showing several facilities 76-80 for communication according to an embodiment of the present disclosure Figure 73 The number of facilities 76-80 may each include a facility gateway 21 (see FIG. Cloud Services 2 ) for communicating with a cloud service, such as the infusion safety manager 74. In some embodiments, the number of facilities 76-80 is part of a group of facilities that share an infusion safety manager 74 that is not accessible to other facilities not within the facility group 76-80. Figure 3 The facility group 76-80 in the infusion safety manager communicates with the infusion safety manager via the communication link 344. This configuration may be used where a group of facilities 76-80 are grouped into a larger organization, such as an integrated delivery network (IDN) 75.

[0415] Figure 4 A diagram of a system 81 for electronic patient care according to an embodiment of the present disclosure is shown. The system 81 includes facilities such as a hospital network 82 and a cloud service 83.

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

[0417] The cloud service 83 includes databases 104, 105, 106, and 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 can access the DERS editor 112 and / or the CQI UI 110. Security personnel 107 can access the CQI UI 110 and / or the DERS editor 112. The DERS editor 112 and / or the CQI UI 110 can be browser-based interfaces. In some embodiments, the DERS editor 112 and the CQI UI 110 can be accessed by the same browser-based interface.

[0418] The HIS 84 supports the hospital's administrative functions (e.g., admissions, discharges, transfers, coding, billing, and collections). The EMR 85 tracks medical histories (encounters, tests, diagnoses, procedures, etc.) within the healthcare facility. The CPOE 86 is used by physicians to order laboratory tests, prescription medications, medical imaging, and other clinical procedures. The PIS 97 is the departmental system used by pharmacists to receive, review, track, and fill prescription medication orders. The LIS 88 is the departmental system used by laboratory technicians to receive and process orders for clinical samples (e.g., tissue, blood, urine, etc.). The hospital integration engine 89 provides message transformation capabilities that enable information systems 84-88 to interoperate with each other and with external systems. Most of these engines can map between different dialects of HL7. The integration engine can reside on a device gateway 99 to interoperate with the HIS, EMR, and PIS through the hospital integration engine 89. The device gateway 99 provides a message routing engine, supporting publish / subscribe and point-to-point routing mechanisms. The device gateway 99 also provides name resolution and capability registration capabilities.

[0419] Patients are treated using various devices 101, such as infusion devices that deliver liquid medications, nutrients, and hydration to patients via intravenous (IV), subcutaneous, or other routes. Pump application 96 and syringe application 97 are applications that provide software intelligence to medical devices 101 by receiving, filtering, and analyzing raw events and retransmitting higher-level interpretations. Each medical device in devices 101 may have a corresponding device application, such as one of applications 96-97.

[0420] Each infusion device of the device 101 can be used to control the delivery of a specific infusion (e.g., hydration, nutrients, blood, or medication in liquid form) to a specific patient. Dose adjustments or titrations in the form of loading or boluses can be considered separate infusion phases within the parent infusion. A collection of infusions or infusion events for the same patient as part of the same treatment is considered an "infusion story" that can be recorded by the CQI server 109.

[0421] Infusions can be organized into a setup phase, a programming phase, and a delivery phase. During the setup phase, the clinician verifies the infusion, the patient, and the pump, and connects the tubing from the infusion to the pump and the pump to the patient, which can be recorded by the CQI server 109. In the programming phase, the clinician enters the dosage parameters into the pump, and the pump verifies them using the installed version of the DAL (which can also be recorded by the CQI server 109, for example). In the delivery phase, the pump delivers a specific infusion volume at the programmed rate.

[0422] Each of the medical devices 101 can detect alarm conditions (i.e., situations where the pump is not delivering fluid), as well as warning and advisory conditions, which may or may not be safety-critical. Each of the medical devices 101 can attempt to establish a secure network connection with the device gateway 99. Each of the medical devices 101 can collect programming, delivery status, and abnormal events for each infusion and provide them to the device gateway 99 so that they are reported to the CQI receiver 108 as CQI messages. Each of the medical devices 101 can transmit these events to the device gateway 99, which routes the data to the CQI receiver 108 (directly or indirectly). If or when, in some embodiments, a medical device of the medical device 101 is unable to establish or maintain a working connection with the device gateway 99, the medical device can save these events in an internal buffer and allow the biomedical technician 102 to copy them to a portable medium (e.g., a memory stick) with or without the use of the biomedical application 94. In some embodiments, these events can be downloaded via the biomedical application 94 running on a personal computer having a USB cable coupled to the medical device.

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

[0424] The device gateway 99 can be a bedside device that is coupled to all devices 101 associated with a particular patient. In another embodiment, the device gateway 99 is a software application that can be executed on a facility gateway. In another embodiment, the device gateway 99 is software that can be executed on a bedside device (e.g., a small computer). The device gateway 99 can be a message router, service registry, and / or pump authorization registry. The device applications 96-97 can record message types and publish messages to the device gateway 99. Any of the medical devices 101, including medical devices that can be plugged into the medical device 101 (see Figure 2 Sensors in other 37) in the medical device 101 (e.g., a respiratory monitor inserted in the PCA) can be used to publish data via the device gateway 99. The device applications 96-97 can act as "information refiners." Each of the device applications 96-97 subscribes to messages from a specific type of bedside device of the medical device 101 via the device gateway 99. Each of the device applications 96-97 can synthesize CQI, clinical, and biomedical information from the event stream received from one or more medical devices 101 via the device gateway 99. In some embodiments, each of the device applications 96-97 republishes these higher-level events to the device gateway 99 or other subscribers, such as the CQI listener 93.

[0425] In some embodiments, some CQI messages can be used for automatic archiving, automatic programming, and settlement functions. In some other embodiments, CQI messages can be used for automatic archiving from the medical device 101 to the EMR 85 and / or automatic programming of the medical device 101 from the eMAR system (e.g., part of the HIS 84). CQI messages can include drug safety event and latency information.

[0426] The CQI listener 93 subscribes to events related to continuous quality improvement of drug safety and ensures their reliable delivery to the hosting environment. The CQI listener 93 can store events in a database 98 for periodic transmission to a CQI receiver 108 (through the firewall 103).

[0427] The CQI receiver 108, CQI server 109, and CQI UI 110 may be provided in a hosted environment cloud service 83 (i.e., a cloud service). A master-slave database replication (database 105 as the master and 106 as the slave) may be used in the hosted environment 83 to reduce conflicts between user queries and CQI data updates. The CQI server 109 may post-process CQI events into a summary (reportable) form before storing them in the database 105 to reduce response time for upper-layer queries and presentation requests. The CQI UI 110 may provide a range of standard reports (compliance, limit violations, titrated security, events by stage, and events by priority). The CQI server 109 may support a query API to be used by the DERS editor 112 and the CQI UI 110 to drill down to more detailed summaries and details of specific CQI messages.

[0428] The CQI server 109 provides analysis and query services to users using the CQI UI 110. The CQI server 109 can provide summary summaries for CQI messages to users of the CQI UI 110 and update summary tables (at configurable intervals). The purpose of these summary tables is to reduce the response time of upper-level CQI queries. These summaries can cover the following statistical metrics: (1) programming mode used, such as infusion using DERS limits vs. wildcards; (2) soft and hard limit violations; (3) titration safety information, such as titration increase / decrease settings and dose limit violations; (4) reportable clinical events by priority (e.g., Figure 5 RCEs 149, as described below); and / or (5) reportable clinical events by infusion phase (e.g., Figure 5 Each of these summaries can calculate subtotals for the following data views: (1) Organization Name; (2) Institution Name (e.g., Facility Name); (3) Nursing Area; (4) Hour; and / or (5) Week.

[0429] The Web service query API can be used to enable the CQI UI 110 and / or the DERS editor 112 to select: (1) summary totals for each of the above data views filtered by a specific item; (2) RCE details for the infusion; and / or (3) the patient's actual programming, restrictions, and infusion statistics (i.e., infusion details). In some specific embodiments, the DERS editor 112 and / or any system hosting the service 83 can be based on a J2EE-compatible application server. Databases 104, 105, 106, and 113 can utilize a database management server.

[0430] Once J2EE and the database management server are installed and configured, the following shared database tables can be imported to perform DERS database 113 initialization: (1) reference tables, such as units of measure, dosage modes, etc.; (2) access control tables for managing users, roles, privileges, and permissions; (3) DERS medication lists; (4) National Database of Nursing Technician Indicators (NDNQI) nursing area lists; (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, add or edit regions, and / or add or edit access controls (with or without attributes, respectively).

[0431] In one embodiment, the DERS editor 112 and / or DERS database 113 may run in a single application server and database environment for multiple facilities 82. In another embodiment, each institutional hospital network 82 may be hosted in its own virtual environment (eg, cloud service 2).

[0432] In some specific embodiments, the CQI UI 110 and / or the DERS editor 112 may support an HTTP / Javascript interface for generating CQI reports and interactive drill-down operations for users running a web browser.

[0433] The CQI messages are received by the CQI receiver 108, which stores them in the database 105. If the CQI receiver 108 cannot process all incoming CQI messages at a predetermined rate and / or the buffer of the CQI receiver 108 is full, the CQI messages are temporarily stored in the database 104, which can be accessed by the CQI receiver 108 for storage in the database 105 when the CQI receiver is uninstalled. The database 105 can be replicated by the database 106. The database 106 is accessible to users via the CQI server 109 using the CQI UI 110 and / or the DERS editor 112.

[0434] The records in the CQI databases 105, 106 are dependent on the DERS editor 112. The records include: (1) reference tables, such as units of measure, dosage modes, etc.; (2) access control tables for managing users, roles, privileges, and permissions; (3) DERS drug lists; (4) NDNQI care area lists; and / or (5) institutional attributes.

[0435] Because these references depend on the version of the DERS editor database, consistency is preferred. One option is to share tables between databases 113, 105, and 106. When this option is convenient, it increases the deployment coupling between the two databases 113 and 105, 106. Alternatively, coupling can be reduced by maintaining read-only copies of these tables within the CQI databases 105, 106, by updating them only when they are changed in the DERS editor 112.

[0436] The access controls for the CQI databases 105, 106 are similar in structure, but differ in content compared to the DERS database 113. Some users are defined for the CQI server 109, but not for the DERS editor 112. Even for those users that appear in both, permissions may differ (e.g., some CQI data may be read-only). In some embodiments, users and their permissions and access credentials may be stored in a user database 7000, which may be in a hosted environment.

[0437] Certain database tables (eg, reportable clinical events and statistical summaries) may be required by the CQI database 105 , 106 and may be set when the CQI database 105 , 106 is created.

[0438] The CQI UI 110 and / or the DERS editor 112 may respectively multiplex data from the CQI server 109 (and hence data from the database 106 ) and data from the DERS editor 112 (and hence via the database 113 ) to generate the DAL file 114 .

[0439] The clinical status manager 91 is an intermediary between the device gateway 99 and the integration engine 89, coordinating an asynchronous workflow involving several participants and components.

[0440] Pharmacists and select clinicians 11 use the DERS editor 112 to define drug restrictions for the institution and generate a DAL file 114 (which can be in XML format). Drug restrictions can be defined using a well-defined, carefully controlled full archive process and a controlled release process. Drug restrictions can be specified using the DERS editor 112 of the DAL manager 5. The facility 82 can use a common reference model for drugs, care areas, dosage modes, etc. to facilitate subsequent cross-institutional comparisons. The DERS editor 112 can run in a hosted environment 83, allowing users to access it using a web browser. In some embodiments, client-side software is not required to run the DERS editor 112 unless fully browsed. The DERS editor 112 can provide drug restrictions and defaults organized by care area, drug, clinical application, drug concentration, etc. The DERS editor 112 can support a query interface of the CQI server 109 to integrate queries and analysis of CQI insights to improve the next DAL version.

[0441] In some embodiments, a prescription database 7002 may also be included. The prescription database 7002 may include a comprehensive list of drugs and medications that may be included in different DAL files 114. The prescription database 7002 may be connected to the DERS editor 112 and the CQI server. The DERS editor 112 may extract from the prescription database 7002 during the creation of the DAL file 114. This helps ensure data consistency across different DAL files and facilitates comparison of multiple DAL files 114.

[0442] Figure 5 Some aspects of communication between an example medical device 145 (eg, an infusion pump) and a device application 151 (eg, a pump application) are shown according to an embodiment of the present disclosure. Figure 5 , pump 145 is described, but it is contemplated that any other medical device may be used in place of pump 145 to generate event 146 .

[0443] In the box Figure 144 1 shows a medical device 145 (e.g., an infusion pump) transmitting an event 146 (e.g., a pump event) to a device gateway 147. The pump event 146 can be a CQI message from the medical device 145, can be the basis for a CQI message, or can be other data, such as raw data. The pump event 146 can be an operating parameter, a delivery parameter, and / or other operating event. In some specific embodiments, the pump event 146 can use the Simple Object Access Protocol ("SOAP") addressing multiplexed with Web Services ("WS"). In some embodiments, the event 146 is transmitted using Representational State Transfer ("REST"), which can use the full HTTP (or HTTPS) protocol.

[0444] Event 146 may be an event as shown in Table 1 below.

[0445]

[0446]

[0447]

[0448]

[0449] Table 1

[0450] Items listed as 1, 2, 3, 4, 5, 6, 7, 8, and 9 in Table 1 are pump event classes. When the medical device 145 is not connected to the device gateway 147, these events are stored in the internal memory buffer of the medical device 145. When connected (and whenever 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 can be copied to a portable storage medium and manually published to the device gateway 147. As previously described, the device gateway 147 can act as (or include) a publish-subscribe engine configured to route pump events to interested subscribers.

[0451] Refer again Figure 1 , pump events can be sent to the CQI manager 4 related to device events for devices 26. These events can be used to monitor the entire fleet of medical devices 26 across many facilities 10. For example, the device hardware status array 9.71 can be transformed into a CQI message and transmitted to the CQI manager 4. Users can log in to the CQI manager 4 to schedule maintenance events, order new parts, provide predictive or preventive maintenance, and / or order new parts for preventive or predictive reasons. Users can use deterministic heuristics to determine what to order, when to order, and / or when to mark certain devices 26 in various facilities 10 for maintenance. The CQI manager 4 can be used to provide chain management of parts for the fleet of devices 26 and can provide real-time information about the status of the fleet of devices 26. For example, the device hardware status array can include battery information, such as current when fully charged, indicating the health of the internal batteries. For all or a subset of the devices 26 in several facilities 10, the CQI manager 4 can automatically order new batteries when the battery health falls below a predetermined threshold. Additionally or alternatively, CQI manager 4 may automatically order batteries to be replaced in those identified ones of devices 26 .

[0452] Refer again Figure 5, a device application 151 (eg, a pump application configured to work with a pump) may execute on the device gateway 147 (in some embodiments, they may be different hardware and / or software). The device application 151 subscribes to events published by the medical device 145 .

[0453] The device application 151 can process the raw event streams and refine them into a higher-level clinical event stream, such as actionable clinical events 149 that can be reported to a server hosting the cloud service for storage therein (e.g., Figure 2 database database 30).

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

[0455] The device application 151 is a stateful component and contains one pump handler 153 instance for each pump 145 deployed in the facility. The pump scheduler 152 maintains a lookup table of pump handlers 153 using the serial number of the pump 145 as a unique key.

[0456] The Pump MDB uses the application server's naming service to access the device application 151. It obtains the pump 145's serial number from the message header and uses the Pump Scheduler 152 to look up the appropriate pump handler of the Pump Handlers 153. If the respective pump handler of the Pump Handlers 153 is busy (processing another message on another thread), the Pump MDB queues the message to the Pump Scheduler 152 (to ensure that messages are processed in order). If the respective pump handler of the Pump Handlers 153 is idle, the Pump MDB requests the respective pump handler of the Pump Handlers 153 to process the event. Each pump handler of the Pump Handlers 153 maintains a set of finite state machines ("FSMs"), each of which processes a relevant subset of pump events (see Table 1 above), including a Pump FSM 156, a Program FSM 157, and a Transport FAM 158.

[0457] The Pump FSM 156 is the top-level state machine that handles events that do not pertain to any particular infusion. The Program FSM 157 is a sub-state machine that is activated when the infusion programming context is initiated and is responsible for handling infusion programming events. The Delivery FAM 158 is a sub-state machine that is activated when an infusion delivery is initiated and is responsible for handling operational events during an infusion. Separate Program FSMs 157 and Delivery FAMs 158 can be used because a secondary infusion (including a load, bolus, or titration) can be programmed while a primary infusion is in progress.

[0458] The operational mode of a medical device 145, such as a pump FSM 156, can be used to interpret reportable clinical events (RCEs) 149 or reportable biomedical events (RBEs) 148. For example, the pump FSM 156 can track when a pump 145 completes one infusion and resumes another pending infusion; tracks the programming of one infusion while another is running; and / or tracks one or more high-level operational alarms that may occur simultaneously. That is, the pump FSM 156 can include nested state models.

[0459] Each pump handler of the pump handler 153 can also maintain some context objects to save programming and delivery context information. When completed, these context objects will be generated as biomedical events (for tracking pump utilization) and will be retained for recovery when the device application 151 needs to be restarted. The context objects may include infusion state, infusion mode, and infusion segment. The infusion state includes programming / delivery state data for primary and secondary infusions. The infusion mode includes programming / delivery state data for a specific dose / rate (e.g., loading, bolus, and / or titration). The infusion segment includes delivery state (e.g., pumping, stopping, alarming, etc.) during operation within the infusion mode. After processing the pump event 146, the respective FSM 156, 157, or 158 can transition to a new state, create, update, or delete context objects, and output reportable events (CQI messages), such as reportable biomedical events 148 or reportable clinical events 149. In a specific embodiment of the present disclosure, a list of reportable clinical events is shown in Table 2 below:

[0460]

[0461]

[0462]

[0463] Table 2

[0464] refer to Figure 4 , Figure 4 A CQI listener 93 can be run in each facility 82 and can be connected to Figure 4 Device Gateway 99 or Figure 5 147 and subscribe to CQI RCEs 149 or CQI RBEs 148. Figure 4 The device gateway 99 can be in the hosting environment 83 (see Figure 4 ) establishes a confidential and secure connection with the CQI receiver 108 in the . This connection can be physical (persistent connection) or logical (transient connection when a message is transmitted).

[0465] The device gateway 147 may route RCEs 149 or RBEs 148 to the CQI listener 93. The CQI listener 93 may ensure message persistence (i.e., messages are not lost during transmission due to network congestion or disconnection). Thus, the CQI listener 93 may: (1) store each message to be delivered to a local persistent queue (for caching); (2) deliver each of the RCEs 149 and / or RBEs 148 from the head of the queue to the CQI receiver 108; and / or (3) remove the message after receiving a reply from the CQI receiver 108.

[0466] The CQI receiver 108 runs within the hosted environment within the hosted environment 83. The CQI receiver 108 listens for and receives secure network connection requests from one or more CQI listeners 93. The CQI receiver 108 receives RCEs 149 from each connected CQI listener 93. The CQI receiver 108 can ensure message persistence and therefore writes each RCE 149 to the database 105 upon receipt. The CQI receiver 108: (1) stores each message (CQI message) received in a local persistent queue (for caching); (2) appends each CQI message from the head of the queue to a table in the CQI event database; (3) acknowledges receipt of the message to the CQI listener 93 that sent the message; and (4) removes the CQI message from the local queue (because it is secure in the CQI event database 105).

[0467] As previously described, CQI event database 105 is implemented using master-slave replication. That is, database 105 is the master, and database 106 is the slave. Through this approach, in certain embodiments, there are two copies of the CQI event database with the same schema. When insert, update, and delete transactions are applied to master database 105, the database management system (DBMS) within database 105 logs the changes and can propagate unposted changes to slave database 106.

[0468] Each CQI message (e.g., RCE) may belong to a specific organization. The organization reference should be associated with the operating medical device (e.g., Figure 4 Medical Devices 101 Medical Devices or Figure 5 The CQI database 105, 106 may match the organization of the medical device 145 and publish the drug administration library (DAL) deployed in the device. Therefore, the CQI database 105, 106 may require a list of organizations that are consistent with the DERS database 113.

[0469] Figure 6 A state diagram is shown that illustrates programming an infusion device (e.g., Figure 1Method 161 of device 16). Method 161 starts with a user having access to a UI of the device.

[0470] In the state shown as the state labeled "Begin," infusion programming begins. State 162 is when basic mode programming is used (e.g., when using a DERS compliant exception device). When programming using a DERS compliant exception device, the method transitions to state 165 where drug programming is complete.

[0471] State 166 is when DERS-based protection is used and dosing parameters are programmed into the device. If no limit violation is detected, the method 161 transitions to state 165. If a soft limit violation or a hard limit violation is detected, the method 161 transitions to state 167. If it is a soft limit, the clinician can: (1) override the soft limit, causing the method to continue to state 165; (2) program the infusion attributes by leaving the infusion intent unchanged, continuing to state 165 if no new violation is found, or continuing to state 167 if a new violation is found; or (3) change the infusion intent (e.g., change the drug, care area, clinical application and / or concentration), causing the method 161 to restart at state 166.

[0472] If a soft limit is detected, the method transitions from state 166 to state 167, requiring a state transition back to state 166, and not allowing the clinician to override the DERS violation.

[0473] During a number of states, an infusion method can be canceled 161. In the Basic Mode Programming state 162, the clinician can cancel an infusion before programming is complete. In the DERS Programming state 166, the clinician can cancel before programming is complete. In the state 167 when a DERS soft or hard limit violation is detected, the clinician can cancel an infusion.

[0474] During state 165, the medical device may present an "Infusion Start" button that the caregiver can press to transition the medical device to state 163 where the infusion is started. While in state 163, a Pause button may appear on the user interface that, when pressed, pauses the device, thereby transitioning the device to state 164. While in state 164, a Continue button may appear on the user interface that, when pressed, returns the device to state 163 to continue treatment. If a fatal error (a predetermined set of errors) is detected in state 163 and / or 164, method 161 transitions to the End state.

[0475] After the infusion is completed, the pump sends an infusion complete message to the clinical server via the device gateway. The clinical server links the completion event to the prescription record. The clinical server can format the IHE automatic archiving message and send it to the facility IT application 11 (see Figure 1), for example, to record in an electronic medical record manager ("eMar"), update the patient's electronic medical record (EMR) 17, and / or update the hospital's billing system to record the successful infusion of the medication.

[0476] Figure 7 According to an embodiment of the present disclosure, an example is used by Figure 1 The facility gateway 21, by the application 41,42,43,44 and Figure 2 or Figure 4 The publish-subscribe model 168 used by the device gateway 40.

[0477] This model uses a publish / subscribe engine 169, allowing publishers 171 to register one or more topics 170 through the publish / subscribe engine 169. Once a topic 170 is registered, one or more subscribers 172 can subscribe to the topic 170. In some specific embodiments, subscribers 172 can use a pledge signature to subscribe to the topic 170. When a publisher of publisher 171 posts an event related to the topic 170, all subscribers of subscriber 172 that have subscribed to the topic 170 receive the data from the publish / subscribe engine 169.

[0478] A publisher (of publisher 171) can record one or more topics 170. Each topic of topics 170 can be a unique topic. One or more subscribers 172 can subscribe to one or more topics of topics 170 to receive events from them. When publisher 171 posts an event to a unique topic of topics 170 (e.g., "First Topic"), all subscribers to the First Topic of topics 170 will receive that event, while subscribers to topics other than the First Topic of topics 170 will not receive that event. Subscribers 172 that subscribe to other topics of topics 170 (e.g., the Second Topic) other than the First Topic will not receive events sent only to the First Topic.

[0479] In some embodiments, Topic 170 can provide a layer of indirection that anonymizes publishers 171 and subscribers 172. Publish / subscribe engine 169 can allow one-way and asynchronous communication (e.g., "fire and forget" communication). Publish / subscribe engine 169 can provide persistent messaging between the two parties. The persistent nature of Topic 170 can ensure that messages are not lost if Publish / Subscribe engine 169 fails. The persistent signatures used by subscribers 172 can ensure that subscribers 172 will not lose messages when not running.

[0480] The publish / subscribe engine 169 may be part of the device gateway 22, may be part of any other software within the facility gateway 21, or may be part of a Figure 1 The Publish / Subscribe Engine 169 may be part of the Device Gateway 40, within the applications 41-44, or may be a standalone application. Figure 2A standalone application. The publish / subscribe engine 169 can be Figure 4 The device gateway 99 may be part of the application 94, 96, 97, or may be part of the device gateway 99. Figure 4 Standalone application.

[0481] Figure 8 An example capability registry model 173 according to an embodiment of the present disclosure is shown. Providers 176 record their capabilities 175 via capability registry 174. Capabilities 175 may include two aspects: interfaces and attributes. Interfaces are lists of request / response pairs and notifications (in both directions). Attributes are service-level permission parameters that specify the limits of a delivery technician (e.g., response time, error rate and recovery strategy, cost, etc.).

[0482] The launcher 177 can communicate with the capability registry 174 to find and bind the capability 175. Thereafter, the launcher 177 can be part of the device gateway 22, can be part of any other software within the facility gateway 21, or can be Figure 1 The capability registry 174 may be part of the device gateway 40, within the applications 41-44, or may be a separate application. Figure 2 The capability registry 174 can be Figure 4 The device gateway 99 may be part of the application 94, 96, 97, or may be part of the device gateway 99. Figure 4 In some specific embodiments, the capability registry 174 can supplement or replace the publish / subscribe engine 169.

[0483] Figure 9 According to an embodiment of the present disclosure, a drug safety method 115 for generating a DAL file is shown. The method 115 is used in Figure 1 System 1, Figure 2 System 27, Figure 4 System 81, or any other electronic medical record system. Method 115 is one of many methods that can be used to generate a DAL file. Some embodiments may be different.

[0484] Participants can be selected from pharmacies, clinical care areas, etc. (e.g. Figure 1 6,7,8,9,18 and 19 or Figure 4 102, 107, and 111 of 35 (see 36) to help generate and specify DAL files containing safety rules for medication administration that take into account the type of medication, clinical care group, clinical care area, mode (e.g., total amount based, rate based, or weight based), dosing strategy (loading, bolus, ramping, etc.), concentration, etc. Figure 2 ).

[0485] Method 115 includes actions 116 and 117. Action 116 includes actions 118-125 as sub-actions and action 117 includes actions 126-127 as sub-actions. Action 116 generates a DAL file and action 117 monitors the use of the DAL file to help inform updates to the DAL file 35 (see Figure 2 ).

[0486] Action 122 sets a DAL file, such as an initial DAL file or a template DAL file without field entries. Action 123 sets the DAL file based on input from one of the selected users (e.g., Figure 4 DERS editor 112) receives notification of the DAL file. Action 121 is performed, for example, by Figure 4 The DERS editor 112 is used to run the medical device simulator and review the DAL file. After reviewing the experimental DAL file during act 121, the experimental DAL file can be published in act 120. Act 118 authorizes the experimental DAL file. Act 118 can be performed by clicking an "Approve" button on a web browser to authorize the use of the reference file (e.g., referenced by version number, creation date, etc.).

[0487] In act 119, the DAL file is published and sent to the medical device. In act 125, the CQI server imports reference data (e.g., medication, care area, dosage mode, etc.) from the DAL file. After the DAL is published, the file containing the medication record is published to the hospital and CQI environment. After the publication in act 119, the biomedical technician can install the DAL file on each device. Act 126 is the medical device sending CQI events to the CQI receiver 108. In act 127, the CQI events sent in act 126 can be generated during the treatment performed by the device using the DAL file.

[0488] During operation, the medical device generates CQI events (ie, CQI messages). CQI messages may include information about when normal infusion occurs, when infusion bypasses DERS verification, when soft limits are exceeded and overridden, and / or when soft or hard limits are exceeded and therapy is reprogrammed.

[0489] At act 126, the CQI events are transmitted to a CQI server, which collects and stores them. At act 124, the security director can run reports summarizing these events and provide drill-down capabilities to identify opportunities for process improvements. Similarly, at act 124, pharmacists and clinicians can query the CQI database to identify opportunities to improve drug records in the next release of the DAL file. That is, at act 124, the CQI messages are analyzed or reviewed. At act 123, the DAL file can be improved to create a new version of the DAL file. The new DAL file can then be reviewed, piloted, and released as described above.

[0490] In some embodiments, a DERS editor such as Figure 4 The DERS editor 112 used to create a DAL file is a collaborative process involving multiple individuals or parties. Each individual or party involved in creating the DAL file can be used to create the DAL file by accessing the DERS editor and interacting with the DERS editor user interface. In some embodiments, no client-side software may be required to access the DERS editor, except for a sufficient web browser. In some embodiments, the DERS editor user interface can be accessed via an application on a tablet or the like. The individuals or parties involved in creating the DAL file can use an internet-enabled computer, tablet, smart phone, etc. to access the DERS editor and use the DAL file.

[0491] Each person or party involved in building a DAL file can have specific assigned rules, responsibilities and / or privileges. These roles can be specified using access control lists (ACLs) and / or role-based access control (RBAC) models. Roles and responsibilities can be implemented as part of a method that can be used to generate a DAL file. Roles, responsibilities, privileges, etc. can be specified to structure the collaborative process. They can also be specified to encourage maximum input and insight into the generation of the DAL file. This can help ensure that the DAL file generated by the collaborative process is well designed and minimizes drug errors. The various roles and privileges for users can be stored in a user database (not shown) hosted in a hosted environment. In some embodiments, the various roles and privileges can be stored in a DERS database.

[0492] The DERS editor can also allow users to provide spontaneous contributions, feedback, requests, comments, notes, questions, etc. that can be used to build or improve the DAL file. If, during the experimentation with the DAL file, or during daily use, a user finds a problem, concern, opportunity for improvement, etc., the user can submit a change request to address it. These requests can rely on CQI data or specific CQI reports to provide context for the reviewer.

[0493] The CQI data may be readily accessible, perhaps to a varying degree depending on the user or parties, while being used in a DAL file. This information may be presented on the DERS editor user interface in an easily understandable manner. In some embodiments, at least some of this data may be presented in the form of graphs, charts, or other visual aids. The user may also use the DERS editor to filter out undesirable CQI data in order to present a more concise data set that is more narrowly focused on the data of interest to the user. The availability of this CQI data may be utilized by individuals or parties to help inform decisions regarding improvements to various items, etc. The data may also be used to evaluate the appropriateness of different items in the DAL file.

[0494] Alternatively, creating and modifying DAL files can be a fully traceable process via the DERS editor. Each item or modification made in the DERS editor can be tied to a unique user login or ID associated with a specific individual or party. Each modifiable item within the DERS editor can be associated with a stored history that archives all past comments, annotations, modifications, requests, parameter values, etc., regarding that item.

[0495] exist Figure 10 An exemplary schematic diagram representing possible roles, responsibilities, and privileges for various users and parties involved in collaboratively creating a DAL file is shown in FIG. The exemplary schematic diagram is one of many possible examples and in alternative embodiments, may be configured differently. For example, some participants / parties may be combined or excluded. Roles and responsibilities may also vary. As shown, roles, responsibilities, and privileges are assigned to facilitate the creation of a well-thought-out DAL file that minimizes the likelihood of potential drug errors. In an exemplary embodiment, multiple reviews and majority approval of entries are required for the DAL file to be published.

[0496] Each participant uses a DERS editor such as Figure 4 1 . A DERS editor 112 is shown that can contribute to a DAL file. In some embodiments, various participants can access the DERS editor by navigating to the DERS editor user interface in a web browser. Multiple participants are shown on the left side of the figure. Other embodiments may include additional participants or fewer participants than those shown. In some embodiments, some participants may be a single person, and in other embodiments, at least a group of multiple individuals. In some embodiments, two different participants may, in fact, be the same person or group performing different roles. Figure 10The participants shown in the example include drug library administrator 200, resource clinician 202, reviewing pharmacist 204, pharmacy advisor 206, and clinical advisor 208. In the exemplary embodiment, the participants are divided into two broad categories: administrator or editing users (drug library administrator 200) and reviewing users (resource clinician 202, reviewing pharmacist 204, pharmacy advisor 206, and clinical advisor 208).

[0497] The drug library administrator 200 may be an individual or multiple individuals, such as a doctor, a caregiver, a pharmacist, etc. In some embodiments, the drug library administrator 200 may be, for example, Figure 1 Pharmacist 8 or Figure 4 Security officer 107 is shown. The drug library administrator 200 may be a designated administrator capability in the DERS editor. That is, the drug library administrator 200 may have edit permissions that grant him the ability to change most, if not all, changeable entries, and have ultimate oversight of any proposed changes to the DAL file. The drug library administrator 200 may have privileges that allow them to access most, if not all, of the full functionality of the DERS editor. The drug library administrator 200 may be required to sign off on the finalized DAL file before it is released for use on various medical devices.

[0498] In some embodiments, the resource clinician 202 may be an individual or multiple individuals, such as a doctor, nurse, nurse manager, etc. In some embodiments, the resource clinician 202 may be Figure 1 In some embodiments, the resource clinician 202 may be a nurse manager 7 and / or nurse 9. Figure 4 The resource clinicians 202 may have the ability to review, annotate, add comments, suggest changes, etc. to the DAL file via the DERS editor. The resource clinicians 202 may be divided into multiple subgroups. For example, in some embodiments, the resource clinicians 202 may be divided into care area groups.

[0499] In some embodiments, the reviewing pharmacist 204 may be an individual or multiple individuals, such as a pharmacist, etc. In some embodiments, the reviewing pharmacist 204 may be Figure 1 Pharmacist 8. Reviewing pharmacist 204 can review all entries in the DAL file and verify any entries that may need revision via the DERS editor. Reviewing pharmacist 204 can also have the ability to comment on different entries in the DAL file, add notes, request changes, etc.

[0500] In some embodiments, the pharmacy advisor 206 may be an individual or multiple individuals, such as a pharmacist or the like. In some embodiments, the pharmacy advisor 206 may be Figure 1Pharmacist 8. Pharmacy consultant 206 can review one or more options of all entries in the DAL file via the DERS editor. Pharmacy consultant 206 can check any entries that need revision and can also have the ability to comment on, add notes, request changes, etc. to various entries in the DAL file.

[0501] In some embodiments, the clinical advisor 208 may be an individual or multiple individuals, such as a physician, nurse, nurse manager, risk manager, or other appropriate individuals. In some embodiments, the clinical advisor 208 may be Figure 1 The clinical advisor 208 may be a nurse manager 7, nurse 9, biomedical technician 19 and / or risk manager 6. Figure 4 The clinical consultant 208 may be included in the trial execution of the DAL file. The clinical consultant 208 may have the ability to review, comment, add notes, etc. on the entries in the DAL file or on some of the entries in the DAL file.

[0502] As shown in Figure 10, DERS is the first setup in the DERS setup action 122. In this action, various participants can be identified and assigned user IDs that allow different participants to differentiate the level of DERS functionality. Additionally, in this action, the environment in which the DAL file will be used can be divided into multiple different sub-environments or groupings. This can be done based on the environment organization hierarchy. For example, a hospital can be divided into its constituent care groups (ICU, ER, NICU, Oncology, etc.).

[0503] In different embodiments, the roles, responsibilities, and privileges assigned to each participant can be different. For example, in some embodiments, more participants are required to approve the DAL file before it is released for use in various medical devices. Different participants can be assigned higher or lower levels of software functionality.

[0504] Then, in the medication list customization step 210, the DERS medication list or lists are set up. As shown in the exemplary schematic, the drug library administrator 200 may be the only actor with the privileges required to complete this operation. In some embodiments, this step may be performed by, for example, a pharmacist. In the medication list customization step 210, all medications available in the facility or facilities where the DAL will be used may be compiled into a single list. Additionally, if a medication has multiple different names or aliases, these may be specified and linked to their respective medications. Additional information may also be specified for each medication. The complete list of medications created in the medication list customization step 210 may be used in subsequent steps to ensure uniqueness and efficiency of additions. In some embodiments, the entire medication list may be created by selecting medications from a master list or medications provided by the DERS editor service. In some embodiments, the entire medication list may be created by selecting various medications from a master list of medications stored on a prescription database in a hosted environment.

[0505] In the care area medication record step 212 of the example of facility 10 of FIG. , the drug library administrator 200 may perform a drug selection and record specification sub-step 214. In this sub-step, the various medications identified in step 210 may be selected for inclusion in a particular sub-department or care area / group of the institution. For example, in a hospital, a subset of the medications specified in step 210 may be selected as medications for use in the hospital's intensive care unit. Thus, the various medications selected for each care group may have records that are altered to suit the needs of each care area within the care group. For example, in this step, medications for a particular care area may have various clinical uses, concentrations, restrictions, and the like specified. In some embodiments, this step may be performed by one or more pharmacists in addition to or in conjunction with the drug library administrator 200.

[0506] After the medication selection and record specification sub-step 214 of the care area medication record step 212 is completed, a per-care area verification sub-step 216 is performed by at least one resource clinician 202. In this sub-step, the selected medications and their records are reviewed and verified for each care area. In a hospital, one or more nurses or doctors assigned to or working in a specific care area may be the resource clinician 202 performing this sub-step for that care area. During this sub-step, the resource clinician 202 can provide feedback on the various medication selections and records for each care area.

[0507] In the review step 218, the medication selections and records from the care area medication record step 212 are reviewed to ensure they are appropriate and correct. Figure 10In the example of , in the edit and revise sub-step 220, the drug library administrator 200 edits and revises records that may require such action. This may include addressing any feedback, concerns, requests, etc. from other participants involved in the review step 218.

[0508] During the review step 218, a per-care area review 222 sub-step may be performed by at least one resource clinician 202. In this sub-step, the selected medications and their records are reviewed for each care area. In a hospital, one or more nurses or physicians assigned to or working in a particular care area may be the resource clinician 202 performing this sub-step for that care area. During this sub-step, the resource clinician 202 may provide feedback or request changes regarding the various medication selections and records for each care area.

[0509] Additionally, the cross-care area review sub-step 224 and the care group review sub-step 226 can be performed by the reviewing pharmacist 204 and the pharmacy advisor 206, respectively. In the cross-care area review sub-step 224, the reviewing pharmacist 204 reviews the selected medications for each care area and their records and can generate feedback indicating any concerns, suggestions, requests, and the like. In the care group review sub-step 226, the pharmacy advisor 206 can review the care group's medication list, medication records, and provide feedback indicating any concerns, suggestions, requests, and the like. There can be multiple pharmacy advisors 206, each with a specific care group assigned to one of the multiple pharmacy advisors 206. In some examples, the pharmacy advisor 206 can also review other records. For example, in some examples, the pharmacy advisor 206 can also review the records of all medications used within the facility that are considered high risk if delivered in the wrong manner.

[0510] In trial step 228, Figure 10 All participants shown in Figure 10 210, 212, and 218. In a trial step 228, the various participants may use the pump simulator on the DERS UI to test or review all entries for each care area. In some embodiments, a temporary DAL file may be created and sent to the test medical device. The DAL file may be tested and reviewed by the various participants on the UI of the test medical device. Any feedback generated by the various participants involved in the trial step 228 may be addressed and any necessary changes may be made to the DAL file.

[0511] To complete the DAL file, the DAL file may be required to pass an approval step 230. At this step, the various participants may sign the DAL file, thereby allowing the release of medical devices into the institution. Figure 10In the example of FIG, the drug library administrator 200 and the resource clinician 202 are required to sign the DAL file. In some implementations, more or fewer participants are required to sign the DAL file before it is released. After the approval step 230, the DAL file can be released for use in the institution.

[0512] In various embodiments, a DAL file can be configured in a hierarchical manner. That is, a DAL file can include multiple upper and lower level entries, or parent entries and child entries, that specify settings for the DAL file. These can be configured in various hierarchical levels. As the level progresses, the entries for the DAL file can become more specific. Parent entries, for example, can broadly define parameters, restrictions, etc., while child entries can further narrow or refine these parameters, restrictions, etc.

[0513] FIG11 a illustrates an exemplary hierarchical configuration of a DAL file. As shown, the exemplary hierarchical configuration shown in FIG11 a is similar to the hierarchy of an institution / organization. In some embodiments, the hierarchical configuration of a DAL file may be different. For example, some DAL files may not include the care group and / or organization layers shown in FIG11 a. This is particularly true for DAL files used in small, independent institutions.

[0514] As shown, the highest level of an exemplary hierarchy for a DAL file may be organization 2350 that uses the DAL file. Below organization 2350 may be subordinate organizations 2352 that comprise organization 2350. For some DAL files, organization 2352 may be the highest level of the DAL file hierarchy. This is true, for example, when a DAL file is created for organization 2352 that is not part of organization 2350.

[0515] Each facility 2352 can be divided into multiple care groups 2354. Each care group 2354 can include multiple care areas 2356. A care group 2354 can be an organizational category to which multiple care areas 2356 belong. For example, multiple ICU-type care areas 2356 (e.g., ICUs for neonatal, pediatric, adult, medical, surgical, cardiac, neurological, trauma, burns, etc.) can form an ICU care group 2354. Each care area 2356 can include multiple specific drugs or medication records 2358 associated with that care area 2356.

[0516] At each level of the hierarchy, multiple parameters can be defined. The definition of these parameters can be a process for creating a DAL file. These parameters can include, but are not limited to, various operational settings, data formatting settings, acceptable input ranges or values ​​for data on a medical device, guardrails or limitations for a treatment or medical device, and the like. Throughout this specification, a number of possible exemplary settings that can be defined in a DAL file are described. In some embodiments, other settings may also be included. In some instances, a value defined at a higher level can serve as a parent value for other values ​​defined at a lower level.

[0517] In some embodiments, the same parameter is defined at multiple layers. In these embodiments, when a user specifies a parameter value for a lower layer, the child parameter value (the value defined at the next layer) can default to the value defined for the parent parameter (the value defined at the previous layer). The user can change these child values. In some embodiments, the user may only be able to change the value to a more stringent value. For example, a user may define a patient weight high hard limit at the care group layer. This value may serve as a default setting for the same parameter in any of the care areas included in the care group. If the care group includes a care area for pediatric patients, the user may desire to make the patient weight high hard limit more stringent and may be allowed to do so. This inheritance of parameter values ​​can help facilitate DAL file creation and improvement, as well as add ease of use and efficiency.

[0518] For another example, a care group 2354 may have multiple medications associated with it. The medication records 2358 for these medications, defined at the care area 2356 level within the care group 2354, specify the clinical use and concentration of the particular medication appropriate for the particular care area 2356. For example, in a care group 2354 consisting of five care areas 2356 that use similar medications, a user need only add the common medication at the care group 2356 level, rather than adding it once for each care area 2356 in the care group 2354. Adding a medication to a care group 2354 can ensure that the medication is added to the care areas 2356 in the care group. Furthermore, in some embodiments, a user can define some or all parameters for each common medication at the care group 2354 level. These parameters are then inherited as their respective sub-parameters for each care area 2356 in the care group 2356. These configurations can facilitate DAL file creation and improvement, as well as increase ease of use and efficiency.

[0519] Additionally, in some embodiments, some exemplary DAL file hierarchies can be divided into multiple sub-layers. For example, drug record 2358 can be divided into general drug settings, clinical application settings, and settings for specific drug concentrations. These sub-layers can also have their own hierarchical configurations.

[0520] Figure 11b illustrates another exemplary embodiment of a DAL file hierarchy 4500. As shown, the DAL file hierarchy 4500 shown in Figure 11b includes multiple additional hierarchical layers in addition to the ones shown in Figure 11a. Other embodiments may include different hierarchical layers or different multiple hierarchical layers. A user can define various parameter values ​​to create a DAL file at each layer shown. In some embodiments, the same or related parameter values ​​may be defined at multiple layers. In some such cases, a value defined at a higher level of the DAL file hierarchy 4500 may operate as a parent value for the same related value at a lower level of the DAL file hierarchy 4500. It should also be noted that each layer 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 care groups 2354 make up each institution 2352.

[0521] As shown in Figure 11b, the highest level of the DAL file hierarchy 4500 is the IDN or organization 2350. One level down is the region 4502. This layer can be included in instances where the IDN includes multiple institutions distributed over a large geographic area. In other embodiments, this layer can be used to create groups of similar institutions (e.g., urgent care centers, clinics, etc.).

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

[0523] 4. A user may define various parameters for the care group 2354 level of the DAL file hierarchy 4500. A user may define one or more medication records 2358 and parameters for those medication records 2358 for each care group 2354. The various parameters defined for a care group 2354 may serve as parent settings for any medication record defined for the care group 2354. The care group 2354 parameter settings may also serve as parent settings for entries in the care areas 2356 within the care group 2354. Additionally, any medication records 2358 and parameters associated with them defined for the care group 2354 may be automatically included in the care areas 2356 within the care group 2354.

[0524] The user may define various parameters at the care area 2356 level of the DAL file hierarchy 4500. The user may define one or more medication records 2358 and parameters for those medication records 2358 for each care area 2356. The various parameters defined for a care area 2356 may serve as parent settings for any medication record 2358 defined for the care area 2356.

[0525] As shown, the medication record 2358 is divided into multiple sub-layers. In the exemplary embodiment of Figure 11b, the medication record 2358 includes a medication 4508 sub-layer at the top of their internal hierarchy. The user can select a medication name from the master medication list to populate this sub-layer of the hierarchy. This can apply any parent value defined for that medication in the master medication list or medication category list. The user can define additional other parameters in the medication 4508 sub-layer. Any value defined for the medication 4508 sub-layer can serve as a parent value for the clinical use 4510 sub-layer. The user can define various parameters in the clinical use 4510 sub-layer. These values ​​can serve as parent values ​​for the concentration 4512 sub-layer. The user can also define various parameters in the concentration 4512 sub-layer.

[0526] Figure 12-71 The figures illustrate several exemplary flow charts detailing various methods used by the DERS editor. These flow charts and the steps shown in these flow charts are exemplary only, and in other embodiments, the use of the DERS editor may be different. Figure 12-17 . For example, some steps may not be performed or may not be performed in the same order as shown and described herein. Some embodiments may include different or additional steps. It should also be appreciated that some of the flowcharts described herein detail only one example of many possible ways to achieve the same result. Many embodiments may include multiple additional workflows that may be followed to achieve the same end result. For the sake of brevity, not all alternative workflows considered to be within the scope of this disclosure are shown. Figure 12-17 The flowchart shown and described can be used with Figure 72-181 Individual screens shown and described.

[0527] Figure 12 The diagram details the creation of a DERS setup 122 that may be a DAL file (see, for example, Figure 9 ) phase. Figure 12 In step 240, the user can log in to the DERS hosting environment. The user can be a user who Figure 4In some embodiments, the user may be a DERS editor service administrator. In step 242, the user may log into the DERS database within the DERS hosting environment. In some embodiments, the DERS database may be Figure 4 The DERS database 113 described in . In step 244, the user can run a database load script on the DERS database. The load script can load the DERS reference table into the DERS database. The load script can load the DERS reference table that will be used for all institutions and organizations that use the DERS editor service. The reference table can load drugs, drug aliases, alternative drugs, drug contraindications, care area types, roles, units of measurement, comment types, approval / verification status, various attributes, etc. into the database. In step 246, the correctness of the database load script can be confirmed by the user. In step 248, the user can load a test institution DERS instance. In step 249, the user can use this instance to test the correctness of the reference table loaded onto the DERS database. In Figure 12 The steps described in the flowchart may be performed by a user who has direct or remote access to the DERS hosting environment.

[0528] Figure 13 The figure illustrates a flowchart detailing several exemplary steps that may be used to update a reference table loaded onto a DERS database. In some embodiments, the reference table may be a reference table. Figure 12 In step 250, the user logs into the DERS hosting environment. The user can be Figure 4 In some embodiments, the user may be a DERS editor service administrator. In step 252, the user may log into the DERS database within the DERS hosting environment. In some embodiments, the DERS database may be Figure 4 The DERS database 113 is shown in FIG. In step 254, a user may run a database update script on the DERS database. The update script may update the DERS reference tables on the DERS database. The update script may update the DERS reference tables used by all agencies or organizations using the DERS editor service. In step 256, the correctness of the database update script may be confirmed by the user. In step 258, the user may load a test agency DERS instance. In step 259, the instance may be used by the user to test the correctness of the reference tables updated on the DERS database. The DERS instance may be executed by a user who has direct or remote access to the DERS hosting environment. Figure 13 The steps are detailed in the flowchart.

[0529] Figure 14The figure shows a flowchart of several exemplary steps that can be used to establish an institutional and organizational hierarchy in a DERS database. Figure 14 The different steps shown in the flowchart of the DERS setup 122 for the creation of the DAL file are performed (see for example Figure 9 ) phase. In step 260, the organizational structure of the agency or organization is determined. In the simplest case, there may be only a single agency that uses its own DAL and has no parent organization. In other cases, the organization may include multiple different agencies that all use the same DAL. In some cases, the organization may include multiple different agencies that have at least two different DAL files. In the case where the DERS database is being used by an organization, a field for the agency name may be included. This name may be used for data comparison within the organization and may be included in CQI messages from agencies within the organization.

[0530] In step 262, a load / update script for the organization scheme may be created. In step 264, a user logs into the DERS hosting environment. The user may be a Figure 4 In some embodiments, the user may be a DERS editor service administrator. In step 266, the user may log into the DERS database within the DERS hosting environment. In some embodiments, the DERS database may be Figure 4 In step 268, the user can run a database update script on the DERS database. The update script can create a new database or multiple databases for a specific organizational scheme. In step 270, the user can confirm the correctness of the database update script. In step 272, the user can load a test organization DERS instance. The user can use this instance to test the correctness of the organizational scheme updated to the DERS database. Figure 14 The steps detailed in the flowchart may be performed by a user with direct or remote access to the DERS hosting environment.

[0531] Figure 15 A flowchart is shown indicating a number of exemplary steps that may be used when a subscribing organization accesses the DERS editor. In step 280, the organization or organization may sign up for the DERS service through the DERS editor service provider. In step 282, the DERS editor service may be configured to support the new organization or organization. In some embodiments, this may include setting up a database and application server for the new organization or organization. In some other embodiments, a new data set is created within a pre-existing database for the new organization or organization. This step may be performed by a hosted IT for a hosted environment where the DERS editor service database, server, etc. resides. In some embodiments, step 282 may include executing Figure 14The steps are detailed and illustrated in .

[0532] In step 284, the DERS editor service personnel (e.g., Figure 4 The hosting IT of the hosting environment 83 can establish a user account for the user of the institution or organization. In some embodiments, the user can be a drug library administrator, such as Figure 10 Drug library administrator 200 is shown. At this step, access information for a user account may be provided to the user at the institution or organization. At step 286, the user of the institution or organization may log into the DERS editor. In some embodiments, at step 286, the user of the institution may be required to change their password. At step 288, training may be provided to the user of the institution by DERS editor service personnel. Thus, the user of the institution may access the DERS editor.

[0533] In FIG16a, a flowchart is shown detailing a number of exemplary steps that may be used to set up various aspects of a DERS within an organization or institution. Specifically, the exemplary steps shown in the flowchart of FIG16a may be used to define users, the groups to which they belong, and their permissions and privileges. The steps shown in FIG16a may be a DERS setup 122 phase (e.g., see FIG16a). Figure 9 ) part. In step 300, the user can log in to the DERS editor. In some embodiments, the user can be Figure 10 The drug library administrator 200 can access the DERS editor user interface. As described above, this can be accessed via a suitable web browser that does not require client-side software. Then, in step 302, the user can be navigated to the user editor on the DERS editor user interface. The user can then perform any of steps 304, 306, 308 and 310.

[0534] Step 304 changes the value of the group permissions for group A. Step 306 changes the value of the group permissions for group B. Step 308 changes the value of the group permissions for group C. Step 310 changes the value of the group permissions for group D. Groups AD can be different categories of possible agency employees. For example, one of Groups AD can be a group of pharmacists, another can be a group of biomedical technicians, another can be a group of nurse managers, and the last can be a group of security personnel. In different embodiments, there can be additional groups for other categories of agency or organization employees. Groups can be users defined in some embodiments. In some embodiments, groups can be predefined and can have a default set of group permissions provided by the DERS editor service. Some embodiments may not include groups, but instead assign permissions based on specific users. In addition, some groups can include subgroups (not shown). The permissions available for assignment can allow users to customize groups or subgroups that best suit the needs and / or current structure of their agency / organization.

[0535] In a specific embodiment of the present disclosure, a list of possible permissions is shown in Table 3 below:

[0536]

[0537]

[0538] Still referring to Figure 16a, in step 312, the user can also choose to create a new user. This can include defining a username and a temporary password for the new user. It can also include providing the new user's email address. The user can then proceed to steps 314, 316, 318, and 320 from step 313 where the user selects a previously existing user. In step 314, the user can assign the newly created user or the previously existing user to group A. In step 316, the user can assign the newly created user or the previously existing user to group B. In step 318, the user can assign the newly created user or the previously existing user to group C. In step 320, the user can assign the newly created user or the previously existing user to group D. In some embodiments, the user can assign the newly created user or the previously existing user to more than one group. In some embodiments, additional steps (not shown) may be included in which the user can assign the newly created user or the previously existing user to additional groups or subgroups.

[0539] In step 321, the DERS editor service may save the changes to the database. In some embodiments, the database may be Figure 4 DERS database 113. In other embodiments, the database may be, for example, a user database in a hosted environment. In step 322a, the DERS editor service may notify the appropriate users that changes have been made. For example, if a new user account is created, the new user may be notified. As shown at 322b, in some embodiments, this may include an automatically generated email message sent to the new user. In embodiments where the DERS editor is accessed via an appropriate web browser, the message may provide the new user with a hyperlink to the DERS editor. The message may include account information and instructions detailing how the new user should utilize the DERS editor. Password and access rights information for the newly created user may also be included. Alternatively, the information may be provided manually to the new user.

[0540] Figure 16b illustrates a flow chart detailing a number of exemplary steps that may be used to define users, the groups to which they belong, and their various permissions and privileges. The exemplary flow chart shown in Figure 16b illustrates the various steps used by a web browser-based DERS editor service. In step 4400, a user may log into the DERS editor and indicate that they are likely to use the user editor. Then, in step 4402, the web layer for the DERS editor may present the user editor page. The user then has the option of adding a new user or updating / deleting a previously existing user.

[0541] At step 4404, the user may indicate that they intend to add a new user. At step 4406, the web layer of the user DERS editor may present an add user page. At step 4408, the user may then add various user metadata for the new user. After adding the metadata for the new user, at step 4410, the web layer may create user credentials for the new user. At step 4412, the new user data may be inserted into the database. For example, the database may be Figure 4 The DERS editor database 113 or a user database in a hosted environment.

[0542] In step 4414, after the new user data has been added to the database, or after the user has indicated that they wish to update a pre-existing user, the web tier may retrieve user privileges and information in step 4416. In step 4418, a query record set for the requested user may be built and sent to the web tier. In step 4420, the web tier may then present the user editor interface for the selected user. In step 4422, the user may make the desired edits to the user and commit any changes. These edits may include, but are not limited to, modifying group assignments, changing privileges, deleting a user, assigning user responsibilities, and so on. In step 4424, the web tier may update the user account data. In step 4426, the data for editing the user may be written or committed to the database. Alternatively, in step 4426, a success notification may be sent to the web tier indicating the successful update of the database. In step 4428, the web tier may display a success dialog box indicating that the user account information has been updated.

[0543] Figure 17 A flowchart is shown detailing various exemplary steps that may be used to update a DERS within an organization or institution. In particular, Figure 17 In some embodiments, the user can be Figure 10200 of the drug library administrator. This can be done by accessing the DERS editor user interface. As described above, this can be accessed via an appropriate web browser that does not require client-side software. Then, in step 332, the user can navigate 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 can include the following steps similar to those shown and described with respect to Figures 16a and 16b. In step 334, the user can modify various permissions for a group, which can be one of the groups AD shown in Figure 16a. In step 336, the user can add a user to a previously created group. This can be done, for example, by adding a newly hired employee to a group. In step 338, the user can individually modify the permissions of the user to access the DERS editor. In some embodiments, this step may not be included. In some embodiments, this step may be included without steps 334 and 336. The former scenario may be most suitable for relatively large and / or complex institutions. The latter scenario may be well suited for small institutions or medical settings where the DERS editor may have only a small number of total users. After the user has finished updating various aspects of the DERS editor, the DERS editor service can save any changes to the database at step 339. The database can be Figure 4 The DERS editor service may notify affected users of any updates in step 340. This may be accomplished by automatically generating an email that is sent to the affected users.

[0544] Figure 18 The figure illustrates a flowchart detailing several exemplary steps that may be used to create or update an institution / organization master medication list. In some embodiments, Figure 18 The steps shown in the flowchart of FIG. 10 may be part of the medication list customization 210 described with respect to FIG. 10 . In step 350 , the user navigates to the medication list for the institution or organization on the DERS editor user interface. Then, in step 352 , the DERS editor service may display the medication list editor. The user may be a medication library administrator, such as Figure 10 00. In other embodiments, the user may be a pharmacist, or any user authorized with permission 0.04 of Table 3. After navigating to the list of medications for the institution or organization, the user may enter a medication or medications from the DERS editor service or may select a medication from a master list provided by the DERS editor service.

[0545] If the user chooses to import a list from the DERS editor service, in step 356, the user may be prompted by the DERS editor service to select a medication list to import. This step may include displaying a list of importable lists on a database stored by or associated with the DERS editor service. Then, in step 358, the user may enter the desired list. Then, in step 359, the DERS editor service may update the medication list for the institution / organization to include the entered entry. If the user wants to add more medications to the institution / organization medication list, the user may enter another medication list or may select medications from the master medication list accessed by the DERS editor service. If the user finishes updating or creating the institution / organization medication list, the user may proceed to step 366. Step 366 will be described later in this specification.

[0546] If the user does not enter a medication list or if the user has already entered a medication list and wants to add additional medications, the user can add the desired medications to the institution / organization medication list by proceeding to step 360. In step 360, the DERS editor service can prompt the user to select medications to add to the medication list, as shown in step 361. In some embodiments, these medications can be selected by the user from a master medication list provided by the DERS editor service. Then, in step 362, the DERS editor service can prompt the user to enter an alias or other name for the medication. In step 363, the user can provide the alias. In step 364, the DERS editor service can request the user to provide additional information for the added medication. In step 365, the user can provide any additional information. If, after completing step 365, the user wants to add additional medications to the institution / organization medication list, the user can determine whether they want to enter a medication list or select medications from the master list and proceed as described above.

[0547] When the user is finished adding medications to the medication list, the user may proceed to step 366. In step 366, the user may indicate that they are finished adding medications. The DERS editor service may then, in step 367, enable the user to save the created or updated medication list for the institution or organization. In step 368, the user may then save the created or updated medication list. This may cause the medication list to be saved on a database, such as a DERS database. The DERS editor service may then, in step 369, notify the appropriate users of the institution or organization that their medication list has been created or updated. For example, the DERS editor service may notify all users responsible for creating or maintaining care area medication lists that an institution / organization medication list has been created or updated.

[0548] Now refer to Figure 19, a flowchart detailing multiple exemplary steps that can be used to add a clinical consultation entry to a database is shown. A clinical consultation can provide information about medications to users of a medical device. This information can include medication instructions, information from a pharmacy prescription, contraindications, and the like. In different embodiments, a clinical consultation can include text, images or pictures, and / or electronic files, such as .pdf files, and the like. A clinical consultation can be a free text entry into which a user can enter anything they want. Some embodiments may include multiple clinical consultations. For example, some embodiments may include a short text clinical consultation and a full clinical consultation. The short text clinical consultation can be limited to a predetermined number of characters (e.g., the device gateway 40) to make it easy to display on a graphical user interface of the medical device.

[0549] These steps can be performed as follows Figure 10 as described in part 210 of the medication list customization. In step 370, the user navigates to the clinical consultation list. The user can then decide to import a list of clinical consultations from the DERS editor service or can add his or her own clinical consultations to the clinical consultation list. If the user wants to import a list of clinical consultations from the DERS editor service, in step 372, the user can import the list. If the user wants to add their own clinical consultations to the list, the user can proceed to step 374 and add those clinical consultations. The user can repeat step 374 as many times as desired until the user finishes adding clinical consultations to the clinical consultation list. In step 376, the user can log out and save the changes to the clinical consultation list for the institution or organization. The changes can be saved on the DERS database. In step 378, the DERS editor service can notify all relevant users that the clinical consultation list has been updated. In some embodiments, step 378 can include automatically sending an email to the relevant users to inform them of the change.

[0550] In some embodiments, an additional step may be included in which a user may upload files (e.g., images, documents, etc.) to the clinical advisory. In some embodiments, clinical advisories may not be added, modified, etc. at the clinical application layer. Instead, these advisories may be added to the medication record when these records are defined by the user. In some embodiments, a user may define clinical applications for a medication and various clinical applications and concentrations for the medication.

[0551] Figure 20 A flowchart detailing several exemplary steps that may be used to modify the general settings for an institution or organization is shown. The steps may be performed as a DERS setting 122 (e.g., see Figure 9) stage. In step 380, the user navigates to a list of common settings on the DERS editor user interface. As described above, this can be accessed via an appropriate web browser that does not require client-side software. In some embodiments, in step 381, the DERS editor service can enable the user to enter values ​​for various common settings. Then, in step 382, ​​the user can modify, enter, update, etc. any of the desired values ​​in the common settings. In step 384, the user can log out and save any changes made to the common settings. The changes can be saved on the DERS database. Then, in step 386, the DERS editor service can notify all appropriate users that the common settings have been changed. In a specific embodiment of the present disclosure, a non-limiting list of possible common settings is shown in the following table CQI Manager 4:

[0552] <![CDATA[ General Settings ]]> 0.01 Drug library name 0.02 DAL Release Notes / Description 0.03 DAL version number 0.04 DAL Approval Status 0.05 The time / date the DAL version was created 0.06 Institution / Organization Name 0.07 area 0.08 facility 0.09 language 0.10 Screen lock password 0.11 Date format 0.12 area 0.13 Decimal format 0.14 Syringe List

[0553] Figure 21 A flow chart detailing several exemplary steps that may be used to add a care group to a facility or organization is shown.As described above with respect to Figures 11a-11b, within a DAL file, an organization or facility may be divided into groups within subareas that may, for example, reflect departments within the organization or facility. Figure 21 The steps shown may be DERS setup 122 (see, for example, Figure 9 ) stage. In step 2370, the user navigates to the Care Group list on the DERS editor user interface. In step 2372, the user selects to add a new Care Group to the list. When adding a new Care Group to the Care Group list, the user may have multiple choices. In some embodiments, the user may start with a blank template or an almost blank template. Figure 21 In the flowchart of the illustrated embodiment, the user can also choose to copy the information for a pre-existing care group to expedite the process. If the user chooses to copy a pre-existing care group, the user proceeds to step 2374. In step 2374, the user specifies the pre-existing care group that the user wants to copy, and the care group is copied. Then, in step 2376, the user can change the care group type by modifying the care group type for that care group. In some embodiments, in step 2376, the user can also adjust the care group settings.

[0554] If the user chooses not to copy a pre-existing care group, or a pre-existing care group does not exist, the user can proceed to step 2378. In step 2378, the user specifies the type of new care group to be added to the list. This step can include selecting a care group from a list of possible care group types. A care group type can be a broad category that multiple care groups within an institution or organization may fit into. Exemplary care groups can include ICU, emergency, pediatric, neonatal, adult, step-down, surgical, psychiatric, etc.

[0555] The user can proceed from step 2376 or step 2378 to step 2380. In step 2380, the user can modify the name of the care group so that it matches the name of the care group used within the institution or organization. In step 2382, the user can specify the various users associated with the newly created care group. For example, in step 2382, the user can specify multiple clinicians who work on or are assigned to the care group. The user can also specify other individuals within the institution or organization who are responsible for reviewing or contributing to the new care group.

[0556] In step 2384, the user can define various care group parameters for the new care group. This may include modifying default values, filling in blank templates, modifying copied values, etc. In a specific embodiment of the present disclosure, a non-limiting list of possible care group parameters is shown in Table 5 below:

[0557] Nursing group parameters 0.01 Nursing team name 0.02 Nursing group type 0.03 Second review required 0.04 Second review required for high-risk drugs 0.05 Required operator identification 0.06 The speaker volume can be changed by operation 0.07 Default speaker volume 0.08 Default screen brightness 0.09 Automatically adjust screen brightness 0.10 Automatically lock the UI after a predetermined period of inactivity 0.11 Option to enter weight in pounds 0.12 Allows the operator to select a syringe that is not on the facility's syringe list 0.13 Second entry requesting patient weight 0.14 Request a second entry for the patient's BSA 0.15 Patients with high weight restrictions 0.16 Patient weight high soft limit 0.17 Patients with low hard weight limit 0.18 Patient weight low soft limit 0.19 Patients with high BSA hard limit 0.20 Patient BSA high soft limit 0.21 Patients with low BSA hard limit 0.22 Patient BSA low soft limit 0.23 High hard rate limit 0.24 High rate soft limit 0.25 Default KVO value 0.26 Can be changed by the operator KVO 0.27 Default downstream blocking sensitivity 0.28 Default upstream blocking sensitivity 0.29 Ability to change blocking sensitivity on device 0.30 Default air infusion limit 0.31 Ability to change air infusion limits on device

[0558] After specifying the care group parameters, the user can save the new values ​​in step 2386. The care group and parameter values ​​can be saved in the DERS editor database. Then, in step 2388, the user can indicate that the new care group is ready for review by the person responsible for reviewing care groups. Then, in step 2390, the DERS editor service can notify the appropriate users that the care group has been created and is ready for review. This can be done by automatically generating an email.

[0559] In some embodiments, similar steps are followed to add a care group to the DAL file. Although the screens used on the DERS Editor user interface may be different, the user can define similar information and parameters for the care area. In some embodiments, some of the care group parameters shown in Table DAL Manager 5 can be replaced or defined at the care area level. The parameters of the care group can act as parent parameters for the care area. For example, the care group parameters can be the default settings for the same parameters at the care area level. Additionally, when defining a care group, the user can create a list of medications that can be used within the care group. This can be done later similarly to the instructions regarding Figure 18 The steps shown and described are completed.

[0560] Figure 22 A flow chart detailing a number of exemplary steps that may be used to add a care area to a facility or organization is shown.As described above with respect to Figures 11a-11b, an organization or facility may be divided into sub-areas or groups reflecting, for example, departments of the organization or facility. Figure 22 The steps shown may be a DERS setup DERS editor 112 (see for example Figure 9) stage. In step 390, the user navigates to the list of care areas on the DERS editor user interface. In step 392, the user selects to add a new care area to the list. When adding a new care area to the care area list, the user may have multiple choices. In some embodiments, the user may start with a blank template or an almost blank template. Figure 12 In the flowchart of the illustrated embodiment, the user can choose to copy information for a pre-existing care area to expedite the process. If the user chooses to copy a pre-existing care area, the user proceeds to step 394. In step 394, the user specifies the pre-existing care area that the user wants to copy and copies the care area. Then, in step 398, the user can change the care area type by changing the care area type of the new care area. In some embodiments, in step 398, the user can also adjust the care area settings.

[0561] If the user chooses not to copy a pre-existing care area, or if there are no pre-existing care areas, the user may proceed to step 396. In step 396, the user specifies the type of new care area to be added to the list. This step may include selecting a care area from a list of possible care area types. In a specific embodiment of the present disclosure, a non-limiting list of possible care areas is shown in Table 6 below:

[0562]

[0563]

[0564]

[0565] From step 396 or step 398, the user may proceed to step 400. In step 400, the user may modify the name of the care area so that it matches the name used for that care area within the institution or organization. In step 401, the user may specify the care group (if any) to which the new care area belongs. In step 402, the user may specify the various users associated with the newly created care area. For example, the user may specify multiple clinicians who work on or are assigned to the care area. The user may also specify other individuals within the institution or organization who may be responsible for reviewing or contributing to the new care area.

[0566] At step 404, the user can define various care area parameters for the new care area. This can include modifying default values, filling in blank templates, modifying copied values, and so on. In some embodiments, parent parameter values, i.e., values ​​defined for the same parameter at the care group level, can automatically be used as default values ​​for child parameters at the care area level. In certain embodiments of the present disclosure, a non-limiting list of possible care area parameters is shown in Table 7 below:

[0567]

[0568]

[0569]

[0570] After specifying the care area parameters, the user can save the new values ​​at step 406. The care area and parameter values ​​can be saved in the DERS editor database. Then, at step 408, the user can indicate that the new care area is ready for review by the person responsible for reviewing the care area. Then, at step 410, the DERS editor service can notify the appropriate users that the care area has been created and is ready for review. This can be accomplished by automatically generating an email.

[0571] Now refer to Figure 23 , shows a flowchart detailing a number of exemplary steps that may be used in validating a care area. Similar steps are also well suited for validation of a care group. These steps may need to be performed by all designated reviewers before a DAL file containing the care area is released. In some embodiments, these steps may define one of many processes that need to be completed before a DAL file is released. These steps may be performed as follows: Figure 9 Part of the review 121 stage or in some embodiments, Figure 10 The per-care area verification sub-step 216, the per-care area review sub-step 222, the cross-care area review sub-step 224, and / or the care area review sub-step 226 may be performed. Figure 1 These steps can be performed by the nurse administrator 7, pharmacist 8, risk manager 6 and / or biomedical 19. Figure 10 The DERS editor user interface can be accessed through an appropriate internet browser. Figure 23 Steps shown.

[0572] In step 420, the reviewing user can navigate to a list of care areas. In some embodiments, the DERS editor can then request the reviewing user to select a care area from the list in step 421. In step 422, the reviewing user can select the care area they want to or are responsible for reviewing. In some embodiments, the reviewing user can specify only a portion of the entries, elements, parameters, etc. in the care area. In step 424, the reviewing user can review the elements of the care area.

[0573] In some embodiments, when a reviewing user is reviewing a care area, the reviewing user may be asked to enter comments for all entries, elements, or parameters for the care area. Figure 23In the exemplary flow chart, as the reviewing user is reviewing various parameters for a care group, the reviewing user is asked to approve an entry, element, parameter, etc. or enter a comment regarding the entry, element, parameter, etc. If the reviewing user is not concerned or has no issues with the element, the user can indicate verification of the element at step 425 .

[0574] If the reviewing user does not approve the entry, element, parameter, etc. for the care area, or has other comments / feedback / questions, the user can proceed from step 424 to step 426. In step 426, the reviewing user can enter comments, questions, or provide feedback about a specific entry, element, parameter, etc. for the care area. For a hypothetical example, if the parameter for the high hard limit for patient weight in the neonatal intensive care unit is specified as 70 kg, the reviewer can enter a comment "This limit seems too high, maybe a typographical error, add 0 to the entry, the value should be lower?" In addition, some comments in some embodiments may include change requests that can be accepted or rejected. Any comments, questions, or feedback can be made parameter-dependent so that other users or participants can view and, in some cases, act on the comments or feedback. In some embodiments, the reviewing user can include various attachments, links, pictures, CQI data, etc. in the comments.

[0575] Once the reviewing user has checked or commented on the entry, element, parameter, etc., the user may return to step 424 if there are additional entries, elements, parameters, etc. to review. If there is no additional content remaining in the care area requiring review, the reviewing user may have the option of providing general feedback about the care area. In step 428, the user may provide general feedback or comments about the care area as a whole. The comments, questions and / or feedback provided in step 428 may be tied to the care area so that other users may view and, in some cases, act on the comments or feedback. After the reviewing user has provided all of the general comments and feedback they wish to provide, in step 429, the reviewing user may indicate that they have completed their comments. The various comments, questions, feedback, etc. may be saved on the DERS editor database.

[0576] After indicating that the user has completed reviewing the care area, the DERS editor service may issue a notification at step 430 that the user has completed reviewing the care area. This notification may be sent to other users or participants and may be in the form of an automatically generated email message. This message may be sent, for example, to a drug library administrator, such as Figure 10 In some embodiments, it may be necessary for at least one participant or user to address all comments, questions, and feedback provided in steps 426 and 428 before publishing the DAL file containing the care area.

[0577] Figure 24A flowchart illustrating several exemplary steps that may be used to update a care area. Specifically, Figure 24 The exemplary embodiment in details the multiple steps that can be used to update the care area after the review. The review process can be related to Figure 23 The process described and shown in . Figure 24 The steps shown in the exemplary flow chart in FIG. 1 may be Figure 10 Part of the Editing and Revision substep in . Figure 24 The steps illustrated in FIG can be performed by a user, such as a drug library administrator. Figure 24 Similar steps can be used to update the care group.

[0578] In step 440, the user can navigate to the list of care areas on the DERS editor user interface. In some embodiments, the DERS editor user interface can be accessed via an appropriate web browser. In some embodiments, in step 441, the DERS editor service can enable the user to select a care area. In step 442, the user can select the care area they want to revise. In step 444, the user reviews comments, questions, or feedback about the new care area or parameters within the new care area. The user can take multiple actions for each comment, question, or feedback provided.

[0579] If the reviewing user asks a question about a care area or a parameter in a care area, the user may proceed to step 446. In step 446, the user may enter an answer to the question. The answer may then be made available for the initial reviewing user to view. In some embodiments, in step 446, after the user provides the answer, the DERS editor service may notify the reviewing user who asked the question that the answer is available. This notification may be sent as part of step 448. In some embodiments, the reviewing user may respond to the answer if necessary or may request an acknowledgment upon receipt of a satisfactory answer.

[0580] If the review user enters a comment, question, or feedback that is not readily understood, approves further discussion, or the like, the user can proceed to step 450. In step 450, the user can enter a question regarding the review user's initial input. The question can then be made available to the initial review user for review and response. In some embodiments, after the user enters the question in step 450, the DERS editor service can notify the review user that a comment, question, or feedback regarding the question has been entered. This notification is sent as part of step 452.

[0581] If the reviewing user input includes a comment, question, or feedback requesting a change to a parameter of the care area, the user can accept or reject the change request. If the user accepts the change, they proceed to step 454 and change the parameters of the care area in response to the change request. If the user wants to reject the change request provided by the reviewing user, 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, acceptance of the change request can automatically change the parameters for the care area.

[0582] If the review user input does not include a comment or feedback that requests a change, asks a question, or requires a response, the user may be asked to mark the comment or feedback as read at step 458 .

[0583] After resolving the comment, question, or feedback, the DERS editor service may update the DERS review status information in step 459. The user may then review additional comments, questions, and feedback until all comments, questions, and feedback from the reviewing user have been resolved. When all comments, questions, and feedback have been resolved, the user may proceed to step 460. In step 460, the user may indicate that they have finished updating the care area. In step 462, the updates are saved and the user logs out of the DERS editor.

[0584] At step 464, the DERS editor service has notified all relevant users that the care area has been updated and is ready for revalidation. In some embodiments, this notification may consist of an automatically generated email message. The revalidation process may be performed with the relevant Figure 23 Similar as described and shown.

[0585] Refer again Figure 25 , a flowchart detailing several exemplary steps that can be used to add a medication record or drug record to a particular care area. "Drug record" and "drug record" are used interchangeably herein. These medication records can define medications that can be used within a care area, as well as various restrictions, properties, etc. that apply to these medications. Figure 25 The exemplary steps shown in the flowchart may be performed as follows Figure 10 The drug selection and recording specification substep 214 is shown as part of the embodiment. In some embodiments, these embodiments can be performed by a drug library administrator, such as Figure 10 In some embodiments, the medicine record is added to the nursing area by the medicine library administrator 200 shown in FIG. In other embodiments, different individuals, such as pharmacists or other participants can be responsible for adding the medicine record to the nursing area. In some embodiments, similar steps can be used to add the medicine record to the nursing group.

[0586] In step 470, the user can navigate to the list of care areas on the DERS editor user interface. Then, in step 471, the user can select a care area to add a record. In some embodiments, it may be required to pre-define and verify parameters for a care area before adding a drug record to the care area. In these embodiments, this can be accomplished by performing a similar operation to the one described in the previous section. Figure 22-24 The steps shown and described enable the definition and verification of parameters.

[0587] When the user is ready to add a medication record to the care area, the user can decide to add a specific medication or can choose to add a non-specific medication. If the user chooses to add a specific medication, the user can copy the medication record from an existing group (step 474) or can define the medication to create a medication record for the care area (step 476). If the user chooses to copy the medication record, the user can proceed to step 474. In step 474, the user can copy the medication record for the desired medication from an existing care area. In some embodiments, this can include selecting a medication record from a list of medication records displayed on the DERS user interface. In some embodiments and situations, the user can copy medication records from different institutions. This is particularly true if the institution is part of an IDN, for example.

[0588] Copying a medication record may copy all rule sets and concentration records for that medication. In some embodiments, when copying a medication record to a new care area, the user may have the ability to elect to copy some or all rule sets and / or concentration records. After copying a medication record, the user may repeat step 474 for all multiple records or may perform step 476 to add additional medication records. If, after copying the medication record, no more medications are added to the care area, the user may proceed to step 486. Step 486 will be described later in the specification. In some embodiments, steps may be included to enable the user to make adjustments and improvements to the copied care area.

[0589] If the user wants to create a medication record rather than copying a record from another care area, step 476 may be performed. In this step, the user may define the name of the medication for which the medication record will be created. In some embodiments, the user may select the name of the medication from a master list of medications. These lists may be provided by the DERS editor service or may be compiled within an institution or organization. In certain embodiments of the present disclosure, a non-limiting list of possible medication record parameters is shown in Table 8 below:

[0590] <![CDATA[ Medication Record Parameters ]]> 0.01 Drug name 0.02 Synonyms / other names used for the drug 0.03 The name of the drug displayed on the medical device 0.04 Drug Class 0.05 Drug classification (e.g., AHFS classification) 0.06 List of incompatible medications 0.07 Record medication as a CQI consent 0.08 High-risk drugs 0.09 Add medicine series

[0591] After defining the drug name and various drug parameters for the medication record, the user is then asked to define one or more rule sets for each medication record. In some embodiments, each rule set can be provided for a specific clinical application of the drug or medication. Rule set and clinical application are used interchangeably herein. For example, a medication may have a rule set that governs how the medication is delivered when delivered as a weight-based infusion and another rule set that governs how the medication is delivered when delivered as an intermittent infusion. A non-limiting list of other possible clinical applications may include: non-weight-based infusions, body surface area (BSA)-based infusions, continuous infusions, and the like.

[0592] In some embodiments, such as Figure 25 As shown, the user may have the option of either copying a rule set for a medication from an existing medication record (step 478) or defining their own rule set for the medication (step 480). If the user chooses to copy a rule set, the user may proceed to step 478. In step 478, the user may select a rule set to copy from an existing medication record. This may include selecting the desired rule set from a list displayed on the DERS editor user interface. In some embodiments and situations, the user may be able to copy a rule set from a different organization. This is particularly true if the organization is part of an IDN, for example.

[0593] Copying a rule set may also copy all concentration records for the rule. In some embodiments, when copying a rule set, the user has the ability to decide to copy certain concentration records or all concentration records. After copying the rule set, the user may repeat step 478 for as many rule sets as desired, or may perform step 480 to add additional rule sets. If, after copying the rule set, there are no more medication records or rule sets to add to the care area, the user may proceed to step 486. Step 486 will be described later in the specification. Some embodiments may include a step where the user can edit or modify the copied rule set.

[0594] If the user wants to create a rule set for medication records rather than copying a pre-existing rule set, step 480 may be performed by the user. In this step, the user may create a rule set and define parameters for the rule set. In some embodiments, the user may be required to define different parameters depending on the type of rule set being created. In certain embodiments of the present disclosure, a non-limiting list of possible rule set parameters is shown in Table 9 below:

[0595]

[0596]

[0597]

[0598]

[0599]

[0600] After defining the rule sets and the parameters for the rule sets, the user may then be asked to define one or more concentration records for each rule set. Each concentration record may be created for each concentration of a drug to be used with a particular rule set. In some embodiments, such as Figure 25 As shown, the user may choose between copying the concentration record for the rule set for an existing medication record (step 482) or defining their own concentration record for the rule set (step 484).

[0601] If the user chooses to copy the concentration record, the user can proceed to step 482. In step 482, the user can select a copied concentration record from an existing rule set. After copying the concentration record, the user can repeat step 482 for as many concentration records as desired, or can perform step 484 to add additional concentration records. If, after copying the concentration record, no more medication records, rule sets, or concentration records are added to the care area, the user can proceed to step 486. Step 486 will be described later in the specification. In some embodiments, additional steps can be included to allow the user to modify or adjust the copied concentration record.

[0602] If the user wants to create a concentration record for a rule set rather than copying a pre-existing concentration record, the user can perform step 484. In this step, the user can create a concentration record and define parameters for the concentration record. In certain embodiments of the present disclosure, non-limiting examples of possible concentration record parameters are shown in Table 10 below:

[0603]

[0604]

[0605]

[0606]

[0607]

[0608] After completing step 484, the user can add additional concentration records to the rule set, add additional rule sets to the medication record, or add additional medication records to the care area. If, after completing step 484, there are no more medication records, rule sets, or concentration records to be added to the care area, the user can proceed to step 486. Step 486 will be described later in the specification. In some embodiments, the various parameters defined in Tables 8-10 can be defined at different levels of the DAL file than those shown. For example, in some embodiments, some values ​​defined in the rule set can be defined at the medication record level.

[0609] As described above, in some embodiments, a user may choose to add medication records for non-specified medications. These records may act as wildcards or semi-wildcards. That is, these medication records may define broad parameters for managing the use of multiple non-specified medications. These records may, for example, allow a user to run an infusion pump in a volume per duration mode that is not subject to any restrictions defined by the user in the DERS editor, etc. Medication records for non-specified medications may allow a caregiver to start treatment more quickly in an emergency. This may also help if it is necessary to use a medication that is not in the medication list for the care area (e.g., when using experimental or investigational medications). These medication records may also be used in unusual circumstances where the restrictions defined in DERS are not appropriate for the situation. For example, if a patient who is weighed and is severely overweight requires an infusion, the restrictions defined by the DERS editor may prohibit the administration of a clinically effective infusion. In this case, the user may use medication records for non-specified medications to bypass the restrictions and administer an infusion with the desired effect.

[0610] As described, these drug records can also be configured to be semi-wildcard. For example, a drug record for an unspecified drug can be configured so that a parameter is assigned to the class or subclass of drug that can be managed. The class of drug can include, but is not limited to, blood products, investigational drugs, IV fluids, medications, etc. This can also be used to provide greater flexibility when needed while imposing some of the protections that can be created in the DERS editor. In some embodiments, if a user selects a drug record for some or all unspecified drugs, the user can be required to use the drug record for the unspecified drug and enter text describing the drug being used and why it is being delivered.

[0611] When adding a medication record for a non-designated drug, the user can copy the non-designated drug from another care area (step 472) or can create a new non-designated drug (step 473). If the user decides to copy the medication record for the non-designated drug, the user can select and copy the required record by executing step 472. If the user wants to create a medication record for the non-designated drug, in step 473, the user can create the medication record and its various parameters. In some embodiments, the user can define any required parameters for the non-designated drug. These parameters may include some or all of the parameters included in Tables 7-9. This allows the user to adjust the medication record for the non-designated drug so that it is as wide or narrow as desired. After completing step 472 or step 473, the user wants to add another drug to the medication record list, which they can do as described above.

[0612] When the user has finished adding or creating the care area medication list, the user may proceed to step 486. In step 486, the user indicates that the care area medication list is ready for viewing by the appropriate reviewing user and logs out. In step 488, the DERS editor service may notify the appropriate reviewing user that the care area medication list is ready for review. This notification may be in the form of an automatically generated email from the DERS editor service. The medication list may be saved in the DERS database.

[0613] Figure 26 The figure illustrates a flowchart detailing several exemplary steps that may be used to review a medication list for a particular care area. Similar steps may be used to review a medication list for a care group. Figure 25 Following the steps described, create a medication list. Figure 26 The exemplary steps shown in the flowchart may be related to Figure 9 Part of the review 121 stage shown and described. Figure 26 The steps shown can be related to Figure 10 The illustrated and described portion of the per-care area validation sub-step 216, the per-care area review sub-step 222, the cross-care area review sub-step 224, and / or the care area review sub-step 226 may be performed by at least one reviewing user. Figure 26 The reviewer can be Figure 1 Nurse Administrator 7, Pharmacist 8, Risk Manager 6 and / or Biomedical 19. Reviewing users can be Figure 10 Resource clinician 202 , reviewing pharmacist 204 , pharmacy consultant 206 and / or clinical consultant 208 .

[0614] In step 490, the reviewing user can navigate to the care area list on the DERS editor user interface. Then, in step 492, the reviewing user can select the care areas and medication lists that they want to review. In step 494, the reviewing user can review the entries or parameters in the medication list. In some embodiments, the entries and parameters that the user needs to review can be displayed to the user in a task list, window, accessory, etc. on the DERS editor user interface. In some embodiments, the user may not need to navigate to the care area list to review the medication list. In some embodiments, the reviewing user can review the entries in the medication list via a medical device simulator on the DERS editor user interface. These medical device simulators can simulate how the medication list will view when used on a specific medical device. In some embodiments, the user can also navigate to a review screen or a drug screen to review the medication list.

[0615] After reviewing the entry, the reviewing user may enter comments or certify that they feel the entry is appropriate and do not request any changes. If the reviewing user decides to comment on the entry, the reviewing user may proceed to step 495 and provide any comments they wish to provide. If the reviewing user decides to certify the entry, the reviewing user may proceed to step 496 and indicate their certification for the entry. After completing step 495 or step 496 for the entry, the DERS editor service may update the review status of the care area and / or entry in step 498. The reviewing user may then return to step 494 if there are additional entries that require review. This may be repeated until all entries and parameters in the medication list have been reviewed.

[0616] If there are no additional entries or parameters in the medication list that require review, the reviewing user may proceed to step 499. In step 499, the DERS editor service may display a list of comments made by the user during their review. In step 500, the reviewing user may review, extend, or refine their comments. If the reviewing user has any general comments about the medication list or elements of the medication list, the reviewing user may enter those comments in step 502. If the reviewing user does not have any general comments about the medication list or elements in the medication list, or if the reviewing user has already entered all of these comments, in step 504, the reviewing user may indicate that they have completed their review. The reviewing user may then log out of the DERS editor in step 506. In step 508, the DERS editor service may then notify another user, such as a drug library administrator, that the reviewing user has completed their review of the medication list.

[0617] Now refer to Figure 27 , a flowchart detailing several exemplary steps that can be used to update a medication list. Figure 27The steps shown in can be performed after reviewing the medication list for a particular care area. Similar steps can be used to update the care group. Figure 26 Perform a medication list review following the steps detailed and shown in . Figure 27 The steps shown in the exemplary flow chart may be Figure 10 Part of the editing and revision sub-step 220. Figure 27 Described step can be performed by user, such as medicine storehouse administrator.In certain embodiments, one or more users can collaborate to update medicine list.For example, medicine storehouse administrator can work together with pharmacist to update medicine list.

[0618] At step 510, the user can navigate to the care area list on the DERS editor user interface. In some embodiments, the DERS editor user interface can be accessed via an appropriate web browser. Then, at step 512, the user can select the care area and the medication list they want to revise. In some embodiments, the user does not need to select a care area, but instead uses a review screen, medication screen, etc. on the DERS editor user interface to update the medication list. At step 514, the user reviews comments, questions, or feedback regarding the medication list or entries or parameters within the medication list. The user can take multiple actions for each comment, question, or feedback provided.

[0619] If the reviewing user asks a question about the medication list or a parameter in the medication list, the user can proceed to step 516. In step 516, the user can enter an answer to the question. The answer can then be made available for the initial reviewing user to view. In some embodiments, after the user provides the answer in step 516, the DERS editor service can notify the reviewing user who asked the question that the answer is available. The notification is sent as part of step 518. In some embodiments, the reviewing user can respond to the answer if necessary, or can request a reply upon receiving a satisfactory answer.

[0620] If the reviewing user enters a comment, question, or feedback that is not readily understood, approves further discussion, and the like, the user may proceed to step 520. In step 520, the user may enter a question regarding the reviewing user's initial input. The question may then be made available to the initial reviewing user to review and respond to. In some embodiments, after the user enters the question in step 520, the DERS editor service may notify the reviewing user that a comment, question, or feedback regarding the question has been entered. This notification is sent as part of step 522. In some embodiments, the user may enter an answer or question using the same fields. In these embodiments, the notification sent in step 518 or step 522 may simply state that a response has been proposed.

[0621] If the reviewing user input includes a comment, question, or feedback requesting a change to an entry or parameter of the medication list, the user can accept or reject the change request. If the user accepts the change, they can proceed to step 524 and change the change request to change the entry or parameter in the medication list. If the user desires to reject the change request provided by the reviewing user, 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 these embodiments, accepting the change request can automatically change the entry or parameter in the medication list.

[0622] If the review user input does not include a comment or feedback requesting a change, asking a question, or requesting a response, the user may be asked to mark the comment or feedback as read at step 528 .

[0623] If a comment, question, or feedback is resolved, the user can preview additional comments, questions, or feedback until all comments, questions, and feedback from reviewing users have been resolved. When all comments, questions, and feedback have been resolved, the user can proceed to step 530. At step 530, the user can indicate that they have finished updating the medication list. At step 532, the updates can be saved in the DERS database, and the user can then log out of the DERS editor.

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

[0625] Figure 28 A flow chart detailing several exemplary steps that may be used to recalibrate a medication list is shown. Figure 28 The exemplary steps illustrated in the flowchart of can be performed by at least one reviewer. Figure 1 Nurse Administrator 7, Pharmacist 8, Risk Manager 6 and / or Biomedical Technician 19. Reviewing users can be Figure 10 Resource clinician 202 , reviewing pharmacist 204 , pharmacy consultant 206 and / or clinical consultant 208 .

[0626] At step 540, the reviewing user may navigate to the list of care areas on the DERS editor user interface. Then, at step 542, the reviewing user may select the care area and medication list that they intend to review. In some embodiments, by navigating to the list of care areas, no review is required. In some embodiments, the user may review entries from, for example, a DERS user interface review screen, a task list plug-in, or a medication list screen. At step 543, a list of items requiring review may be displayed on the DERS editor user interface via the DERS editor service. In some embodiments, the user may apply a filter to the DERS editor user interface to cause the DERS editor service to generate and display such a list. At step 544, the reviewing user may review items or parameters that have been changed or annotated by selecting from the list. In some embodiments, the reviewing user may review items in the medication list via a medical device simulator on the DERS editor user interface. Such a medical device simulator may simulate what a medication list would look like when used on a particular medical device.

[0627] Some embodiments include Figure 28 As shown in , step 545 may be included in which the DERS editor service displays a review history for the item. The review history may provide the user with context as to why changes were made to the item. For example, the review history may include a list of comments, questions, responses, accepted or rejected change requests, and the like for the item. The review history may include the initial settings or values ​​for the item and any other historical settings or values ​​for the item. The values, comments, questions, responses, accepted / rejected change requests for the item may be stored in a database, such as a DERS database, when created, generated, and submitted.

[0628] After reviewing the item, the reviewing user may enter comments or confirm that they believe the item or parameter is appropriate and does not require any changes. If the reviewing user decides to comment on the item, the reviewing user may proceed to step 546 and provide any comments they wish to provide. If the reviewing user decides to verify the item, the reviewing user may proceed to step 547 and indicate their verification of the item. After completing step 546 or step 547 for the item, the DERS editor service may update the review status for the medication list in step 548. The reviewing user may then return to step 544 if there are additional items or parameters that require review. This may be repeated until all items and parameters in the medication list have been reviewed.

[0629] If there are no additional items or parameters in the medication list that require review, the reviewing user can proceed to step 550. At step 550, the reviewing user can indicate that they have completed the review. At step 552, the reviewing user can log out of the DERS editor. At step 554, the DERS editor service can notify another user, such as a drug library administrator, that the reviewing user has completed their review of the medication list. If there are any unresolved issues, questions, feedback, and / or comments, the user can re-update the medication list and then recheck the medication list. This can continue until all users agree and there are no issues with the medication list. In a similar manner to the following regarding Figure 27 After following the steps shown and described, re-update the list.

[0630] Figure 29 The figure illustrates a flowchart detailing several exemplary steps that may be used to submit a DAL file for approval. These steps may be performed after the DAL file has been created / updated and has gone through the various review and validation processes described above. In some embodiments, these steps may be performed after a trial of the DAL file has been implemented. The steps may be performed by a user or participant, such as a drug library administrator or other participant. Figure 29 The exemplary steps are shown in the flowchart of FIG.

[0631] In step 560, the user checks that all care areas, medication records, other items, etc. that have been created / updated in the DERS editor have been verified by the user responsible for verifying and reviewing them. Once the user has confirmed that all care areas, medication records, items, etc. have been verified, in step 562 the user can indicate that the DAL file that has been created / updated is ready for approval by the person responsible for approving the release of DAL files. In some embodiments, these can be agency or organizational heads. After the user completes step 562, in step 564, the DERS editor service can notify the individual responsible for approving the release of DAL files that the DAL file is ready for approval. Then, in step 566, the user can log out of the DERS editor service.

[0632] Based on the processes defined by various agencies or organizations, different individuals responsible for approving the release of DAL files can review and approve the created / updated DAL files. In some embodiments, these processes may include processes similar to the review and verification processes described above. Once the DAL file has been approved, it can be used in a manner similar to that described above. Figure 30 After the multiple steps shown in the exemplary flowchart of , the DAL file is in a released state. Figure 30As shown, a user, such as a drug library administrator, can receive notification from the DERS editor service that the created / updated DAL file has been approved (step 580). Once the user receives 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 individuals responsible for approving the DAL file have in fact approved the DAL file. In step 586, the user can indicate that the DAL file is ready to be released to various medical devices within the institution or organization.

[0633] Referring now to Figure 31a, a flow chart detailing a number of exemplary steps that may be used to deploy DAL files on various system components is shown. Figures 29-30 The process can be performed after the DAL file is approved and indicated as ready for release, and then the steps shown in Figure 31a are executed. The various components may include Figure 4 CQI server 109, Figure 4 The device gateway 99, and multiple medical devices such as Figure 1 The steps illustrated in FIG. 31a may be performed by multiple users or participants. In some specific embodiments, the steps may be performed by a user, such as a facility IT 18, Figure 1 Biomedical 19, or Figure 4 The biomedical device 102 implements the steps illustrated in FIG31a. The transmission of the DAL file may occur over a secure connection. Some embodiments may specifically utilize a secure socket layer (SSL) connection to transmit the DAL file.

[0634] The exemplary flowchart shown in Figure 31a begins with step 590, where the DERS editor service notifies the CQI user that the DAL file has been published and is ready to be deployed. In step 592, the CQI user receives the notification generated in step 590. Then, in step 594, the CQI user logs into the CQI application. The CQI application can be accessed by users who do not require client-side software. This can be achieved, for example, via an appropriate web browser. Then, in step 596, the CQI user can use the CQI application to deploy the DAL file on the CQI service. In some instances, the CQI user can be a biomedical user.

[0635] In step 598, the CQI application may notify the DERS editor service that the DAL file has been successfully deployed on the CQI service. Then, in step 600, the DERS editor service may notify the user that the DAL file is available for deployment to the device gateway. In step 602, the user receives a notification that the DAL is available for deployment on the device gateway. In some embodiments, the user receiving the notification may be a biomedical technician. Then, in step 604, the user may log in to the device gateway application. In step 606, the user may instruct the device gateway application to download the DAL to the device gateway. In step 608, the device gateway application may request the DAL file from the DERS editor service. In step 610, the DERS editor service may provide the DAL to the device gateway.

[0636] The user can choose to deploy the DAL on various medical devices in a variety of ways. In the exemplary embodiment shown in Figure 31a, the user can deploy the DAL using a device gateway or do it manually. If the user decides to deploy the DAL file using a device gateway, the DAL file can be remotely deployed to the medical device in step 612. The user can manually deploy the DAL file by proceeding to step 614. Manual deployment may be desired or necessary in many situations. For example, in the case of a disconnected environment, manual deployment may be necessary. In step 614, the user can log in to the DERS editor service. Then, in step 616, the user can use the DERS editor service to load the DAL onto a local storage device for manual deployment to the medical device. The local storage device can be a USB memory stick, an external or portable hard drive, etc. In step 618, the user can manually deploy the DAL file onto the medical device by connecting the local storage device to the medical device and downloading the DAL file from the local storage device to the medical device.

[0637] Figure 31b illustrates an exemplary flow chart detailing the multiple steps that can be used to package and stage resources for release to a facility gateway. In some embodiments, these resources can be DALs. In step 4700, a user can select the resources they want to release. Then, in step 4702, the resources are signed using an encryption algorithm. Then, in step 4704, the files are hashed. In some embodiments, additional packaging steps can be included. For example, in some embodiments, an encryption step can be included. The packaging steps used can depend on the type of file that will be generated.

[0638] In step 4706, a staging location for the hash can be determined. In some embodiments, the staging location can be a location on a database. Then, in step 4708, the signed hash is copied to the staging location. In step 4710, the initial signed hash file is saved in an archive location. In some embodiments, the archive location can be a database or other file system. In step 4712, a notification message is generated for the facility data exchange to be sent to each facility gateway that will be notified of the availability of the resource. The notification can include information such as the file type, the hash of the file, a unique identifier for the file, and an identifier for the facility gateway. In step 4714, the notification message can be attached to the facility data exchange. The notification message is then sent to the intended recipient facility gateway.

[0639] Figure 31c illustrates a flowchart detailing several exemplary steps that can be used to track the deployment of various resources. These resources can include DAL files or multiple other resources. In some embodiments, these steps can be performed on a user interface such as the DERS editor user interface. In step 4730, the user selects a specific resource whose deployment they want to track. The resource can be selected from a list of trackable resources stored in a memory associated with the device manager. In step 4732, the device manager in the managed environment can then query the database for the version of the selected resource at each organization. In some embodiments, only information about the organizations associated with the user can be queried in the database. Then, in step 4734, the device manager can display a list of organizations detailing the latest downloaded versions of the resource for each organization. If the user wants detailed information about the resource version deployment within an organization, in step 4736, the user can select the desired organization from the list. In step 4738, the device manager can query the database to determine how many versions of each resource are deployed at the selected organization. In step 4740, a list of versions and the number of versions deployed at the selected organization can be displayed.

[0640] Once created and deployed, it may be necessary or desirable to update the DAL file. During use, it may become apparent that some of the restrictions in the DAL file governing the delivery of certain medications are too restrictive. For example, if nurses in a particular care area find that they must frequently select medication records for non-specific medications to deliver a specific medication in a therapeutically effective manner, one or more nurses can request a change to the specific medication or care area restrictions. Additionally, changes to the DAL file may be necessary if hospital policy changes, new medications become available, and the like. Figure 32 The figure illustrates a flow chart detailing several exemplary steps that may be used to update an existing DAL file.

[0641] In step 620, the reviewing user can log into the DERS editor service and indicate that they would like to enter an update or change request for the current DAL. The reviewing user can then select the type of request they would like to submit. In step 622, the reviewing user can, for example, enter a general comment. The reviewing user can also choose to enter more specific comments. In some embodiments, the user can enter comments about any of the various layers of the DAL file. In step 624, the reviewing user can select a specific care area for which they would like to generate an update request. In some embodiments, additional steps (not shown) may be included to create an update request for a care group. In step 626, the reviewing user can enter comments about the care area, or if they would like to make a more specific request, the reviewing user can proceed to step 628. In step 626, the user can also enter an update request for any parameter values ​​defined for the care area.

[0642] In step 628, the reviewing user can select a specific medication record within the care area for which they want to enter an update request. If the reviewing user wants to enter a general update request regarding medication records, they can do so in step 630. The user can also submit an update request for any parameter value defined for the medication record in this step. If the reviewing user wants their update request to be more specific, the reviewing user can proceed to step 632. In step 632, the user can select a rule set for the medication record to submit the update request. If the reviewing user wishes to submit an update request for the rule set generally, the reviewing user can enter the update request in step 634. In step 634, the user can also submit an update request for any parameter defined at the rule set level. If the reviewing user wants to enter a more specific update request, the reviewing user can proceed to step 636. In step 636, the reviewing user can select a specific concentration record from the rule set to create and update the request. In step 638, the reviewing user can enter the update request for the concentration record. The update request can be entered into the update request field displayed on the user interface of the DERS editor.

[0643] Once the reviewing user has completed any of steps 622, 626, 630, 634, or 638, the reviewing user may proceed to step 640. At step 640, the reviewing user may submit the update request that they entered. The submitted update request may be saved on the DERS database. Then, at step 642, the DERS editor service may notify at least one other user that the update request has been submitted. For example, the DERS editor service may notify the drug library administrator that the update request has been submitted. The reviewing user may then, if necessary, add additional update requests for the current DAL file by returning to step 620.

[0644] In some embodiments, the reviewing user may select an element, item, parameter, etc. in a DAL file (e.g., a care area) before executing step 620. This may be accomplished by navigating to the desired DAL entry using the DERS editor user interface. After the user has navigated to the desired entry, in step 620, the user may indicate that they would like to enter an update request. This may cause an update request field to be displayed in which the user may enter the update request. The user may then enter the update request for the item and submit it in step 640.

[0645] Figure 33 The figure illustrates a flow chart detailing several exemplary steps that can be used to update an institution's / organization's medication list. This may be necessary when new medications become available or when new classes for existing medications become available. This may also be necessary if the institution / organization expands and adds care areas that use medications that would otherwise not be needed at the institution. In this way, experimental or investigational medications can also be added to the institution's / organization's medication list. Figure 33 The steps shown in can be performed by drug library administrator and / or pharmacist.In certain embodiments, other users can perform these steps.

[0646] In step 650, the user navigates to the institution / organization medication list on the DERS editor. Then, in step 652, the DERS editor service may display the institution / organization medication list to the user. The user may then choose to add the medication to the medication list by creating an entry for the new medication (step 656) or select the medication from the master medication list provided by the DERS editor service (step 654). This selection may be made by clicking a virtual button on the user interface, etc. If the user decides to select the medication from the master medication list, the user may proceed to step 654. In step 654, the user may select the medication from the master medication list. A search function may be included for this step, allowing the user to more quickly find the medication they want to add to the institution / organization medication list. If the user decides to enter the medication without using the master medication list, or cannot find the desired medication on the master medication list, the user may proceed to step 656. In step 656, the user may enter the new medication into the institution / organization medication list. In this step, the user may also define any parameters that may be associated with the new medication. Then, in step 657, the DERS editor service may add the new medication for the institution / organization to the DERS database. After the new medication is added to the institution / organization's medication list, at step 658, the DERS editor service may notify all users responsible for creating care group and care area medication lists that the institution / organization's medication list has been updated.

[0647] Figure 34 The figure illustrates a flow chart detailing several exemplary steps that may be used to update a clinical advisory list. Figure 34The exemplary steps shown in can be performed by a drug library administrator, pharmacist, or other user. In step 660, the user navigates to the clinical consultation list on the DERS editor. Then, in step 662, the DERS editor service can display the clinical consultation list of the institution / organization. Figure 34 In the exemplary embodiment shown, the user can update an existing list by adding a clinical consultation to the list or by modifying a clinical consultation on the current list. In step 664, the user can add a clinical consultation to the list. In step 666, the user can update a clinical consultation on the list.

[0648] After the update to the clinical consultation list has been created, the user can further update the list, if necessary, by returning to the clinical consultation list displayed in step 662. When the user is finished updating the institution / organization's clinical consultation list, the user can proceed to step 672. In step 672, the user can indicate that the clinical consultation list should be saved and log out of the DERS editor. Then, in step 674, the DERS editor service can save the updates to a database. The database can be a DERS editor database. In step 676, the DERS editor service can notify the user responsible for creating the care area medication list that the institution / organization's clinical consultation list has been updated.

[0649] In some embodiments, a user can update a clinical consultation without selecting or adding it to the displayed list of clinical consultations. Instead, the user can navigate to a specific entry (e.g., a clinical application) within the DAL file and add the clinical consultation for the specific entry. This can be done by modifying the clinical consultation parameters for the desired entry.

[0650] Referring now to FIG. DAL file 35 , a flow chart of a number of exemplary steps that may be used to update the general settings for an institution / organization is shown. In some embodiments, these steps may be performed by a drug library administrator. In step 680, a user may navigate to the general settings on the DERS editor. In step 682, the DERS editor service may display the general settings. In step 684, the user may update the general settings as needed. In step 686, the user may indicate that they have finished updating the general settings and that they would like to save them. Then, in step 687, the DERS editor service may save the general settings for the institution / organization in the DERS database. Then, in step 688, the DERS editor service may notify the appropriate users that the general settings have been changed.

[0651] Figure 36 A flowchart illustrating several exemplary steps that can be used to update a care area is shown. In some embodiments, a process similar to Figure 36The steps shown are to update the care group. In step 690, the user can navigate to the list of care areas. In step 692, the user can select the care area they want to update. The user then has the option of updating various aspects of the care area. The user can update the list or group of users who have administrative rights for a particular care area. This can be done in step 694. Among other things, administrative rights for a care area can allow a user to have editing capabilities for entries and parameters in a care area. The user also has the option of updating the list or group of users who are reviewing users for the care area. This can be done in step 696. The user can also modify a care area entry or parameter in step 698.

[0652] After making the update, if the user wants to make additional updates, the user can return to step 692 to make additional updates. If the user is finished making updates, the user can save the updated care area on the DERS database at step 700. At step 702, the DERS editor service can notify the appropriate users that the care area has been updated. If necessary, the DERS editor service can notify the appropriate users that the care area is ready for review. In some embodiments, the review and verification process for care area updates can be similar to that described above. Figure 23 and 24 The processes described are the same or similar.

[0653] Figure 37 A flowchart is shown detailing several exemplary steps that may be used to update medication records for a care area. Similar steps may be used to update medication records for a care group. These updates may occur in response to different update requests that may be submitted by a reviewing user. For example, in a similar manner to the one related to Figure 32 Submit an update request after following the steps shown and described. Additionally, updates can occur if new medications need to be added to the care area medication list. Medication records for the care area can also be updated if a DAL file is used and analysis of the CQI data for the medical device indicates that certain values ​​in one or more medication records in the DAL file may be inappropriate.

[0654] In step 710, the user can navigate to the care area list on the DERS editor. In some embodiments, the DERS editor service can then enable the user to select a care area from the displayed care area list in step 712. The user can then select the care area they want to update in step 714. In some embodiments, the user does not need to navigate to the care area list to update the medication record. For example, the user can navigate to the medication list or review screen on the DERS user interface, etc. to update the entry.

[0655] Users can update medication records for the nursing area in a variety of ways. Figure 37By executing step 716, the user can add medication records to the care area. Figure 25 After the various steps illustrated and described,...

Claims

1. A medical error reduction system, comprising: an editor computer including a processor configured to communicate with a display; as well as medical error reduction software configured to be executed by a server and accessible via the editor computer, the editor computer configured to create and revise a drug library for use in a medical device having a medical device processor and a medical device graphical user interface, the medical device graphical user interface configured to display a user interface that conveys information and that can be used to program its corresponding medical device, the drug library containing entries that guide programming by a user of the medical device, Wherein the medical error reduction software is configured to display a simulated medical device graphical user interface configured to mimic the behavior of a medical device graphical user interface for the medical device using the drug library.

2. A medical device for delivering a drug to a patient, comprising: a controller configured to control operation of a pumping mechanism that causes the drug to be delivered; monitor; a computer readable memory configured to store program code for a drug library, the drug library comprising a plurality of entries, the plurality of entries including at least one entry corresponding to a portion of a facility and, for each such entry, at least one drug entry, each of the at least one drug entry having parameters associated therewith, at least one drug entry in the drug library being associated not with a specific drug but with a broad drug category; as well as A processor is configured to display a graphical user interface on a display of the medical device, the graphical user interface used by a user to program the controller with the drug library.

3. A medical error reduction system, comprising: Drug library editing software configured to create and revise at least one drug library for use with a medical device and configured to provide privilege sets to users, the privilege sets being used to assign levels of software functionality to a plurality of users; an editor computer including a processor configured to communicate with a user interface; as well as Among them, the privilege implementation requests changes to the drug library.

4. A medical error reduction system, comprising: Drug library editing software configured to create and revise a drug library configured for a medical device; an editor computer including a processor configured to communicate with a user interface for editing the drug library; as well as The software implements the request to change the drug library by submitting an electronic change request.

5. A medical error reduction system, comprising: Drug library editing software configured to create and revise a drug library for a medical device; an editor computer comprising a processor configured to communicate with a user interface for editing the drug library; and Wherein, the drug library editing software realizes access to medical data.

6. A medical error reduction system, comprising: Drug library editing software configured to create and revise a drug library for use with a medical device; an editor computer comprising a processor configured to communicate with a user interface for editing the drug library; as well as Wherein, the drug library editing software is configured to display the medical data from the medical data database on the user interface.

7. The medical error reduction system according to claim 6, wherein: The drug library editing software is configured to filter the medical data using filter criteria.

8. A medical device comprising: processor; Graphical user interface; And wherein the processor is configured to generate at least one screen for display on the graphical user interface, at least one of the at least one screen includes one or more parameter values, and wherein the processor is further configured to visually change the font of at least one of the one or more parameter values ​​in response to a change in the one or more parameter values.

9. A medical device comprising: Graphical user interface; A processor is configured to generate at least one screen displayed on the graphical user interface, at least one of the at least one screen is a treatment-in-progress screen, and the treatment-in-progress screen includes a pressure indicator that indicates the pressure of the fluid in the infusion line.

10. A medical device comprising: Graphical user interface; a processor configured to generate at least one screen displayed on the graphical user interface; And wherein, at least one of the at least one screen is a treatment-in-progress screen displayed when the medical device is delivering treatment, the treatment-in-progress screen includes a drug indicator indicating a drug being delivered by the medical device, and the processor color codes at least a portion of the drug indicator displayed on the user interface using one of a plurality of colors dependent on a classification of a plurality of classifications assigned to the drug.

11. A medical device comprising: Graphical user interface; a processor configured to generate at least one screen displayed on the graphical user interface; a computer-readable memory storing a plurality of parameter values ​​associated with a therapy programmed into the medical device, at least one of the parameter values ​​being a value for a user-overrideable limit on a therapy parameter value, the user-overrideable limit on a therapy parameter value being overridable by one or more users via the graphical user interface; And wherein the processor causes a marker to be displayed adjacent to the treatment.

12. A medical device comprising: Graphical user interface; a processor configured to generate at least one screen displayed on the graphical user interface; a computer-readable memory storing a plurality of medications delivered by the medical device, the medications organized into one or more medication categories, each of the medications also being associated with one or more parameter values ​​related to the treatment programmable into the medical device; And wherein a user can use the graphical user interface to program the medical device to deliver therapy, at least one step in programming the medical device includes selecting a drug category that includes drugs to be delivered by the medical device.

13. A medical error reduction system, comprising: medical error reduction software configured to create and revise a drug library, the drug library being configured for use with a medical device, and providing a user with a privilege set arranged to assign a level of software functionality to the user, including altering the drug library; as well as An editor computer includes a processor configured to communicate with a display.

14. The medical error reduction system of claim 1, further comprising: Medical equipment.

15. A medical device for delivering a drug to a patient, comprising: a controller configured to control operation of a pumping mechanism that causes the drug to be delivered; monitor; a computer readable memory configured to store program code for a drug library having a plurality of entries, the plurality of entries including at least one entry corresponding to a portion of a facility, wherein for each such entry, the plurality of entries further includes at least one drug entry corresponding to the portion of the facility; as well as and a processor configured to display a graphical user interface on a display of the medical device, the graphical user interface being used by a user to program the controller using the drug library, wherein the user can select one of at least one drug entry corresponding to the portion of the facility to program delivery of a medication to a patient.

16. A medical error reduction system, comprising: Drug library editing software configured to create and revise drug libraries for medical devices and configured to provide a user with a privilege set configured to assign a level of software functionality configured to define the user's ability to alter the drug library; as well as An editor computer includes a processor configured to communicate with a user interface, wherein the editor computer is configured to access the drug library editing software to request changes to the drug library.

17. A medical error reduction system, comprising: drug library editing software configured to create and revise drug libraries for medical devices; An editor computer includes a processor configured to communicate with a user interface configured to edit the drug library, and the editor computer accesses the drug library editing software configured to enable a user to request changes to the drug library by submitting an electronic change request through the user interface.

18. A medical error reduction system, comprising: drug library editing software configured to create and revise drug libraries for medical devices; as well as An editor computer is configured to communicate with a drug library database and a medical data database, the editor computer includes a processor configured to communicate with a user interface, the user interface is configured to edit the drug library using the drug library editing software, wherein the drug library editing software enables access to medical data from the medical data database.

19. A medical device comprising: Graphical user interface, and A processor, wherein the processor is configured to generate at least one screen displayed on the graphical user interface, the at least one screen including at least one parameter value, and the processor is further configured to visually change the font of the at least one parameter value in response to a change in the magnitude of the at least one parameter value.

20. A medical error reduction system, comprising: medical error reduction software configured to create and revise drug libraries and provide a user with a privilege set for assigning a level of software functionality configured to define the user's ability to alter the at least one drug library; an editor computer including a processor configured to communicate with a display; as well as Wherein, the drug library is used in medical equipment.

21. A medical error reduction system, comprising: Drug library editing software configured to create and revise a plurality of drug libraries, each of the plurality of drug libraries being configured for use with at least one medical device; an editor computer comprising a processor configured to communicate with a user interface configured to edit the drug library; as well as The drug library editing software is configured to import entries in a first drug library among the multiple drug libraries into a second drug library among the multiple drug libraries.

22. A medical error reduction system, comprising: Drug library editing software configured to create and revise a drug library, the drug library comprising a plurality of entries, the drug library configured for use with a medical device; an editor computer comprising a processor configured to communicate with a user interface for editing the drug library; as well as Wherein, the plurality of items include clinical consultation.

23. A medical error reduction system, comprising: Drug library editing software configured to create and revise a drug library, the drug library comprising a plurality of entries, the drug library being used with a medical device; an editor computer comprising a processor configured to communicate with a user interface configured to edit the drug library; and Wherein, the drug library editing software is configured to receive comments and / or associate comments with one or more of the plurality of entries.

24. A medical error reduction system, comprising: Drug library editing software configured to create and revise a drug library, the drug library comprising a plurality of entries, the drug library configured for use with a medical device; an editor computer comprising a processor configured to communicate with a user interface configured to edit the drug library; as well as Wherein, the plurality of entries include flushing parameters.

25. A medical error reduction system, comprising: Drug library editing software configured to create and revise drug libraries; an editor computer comprising a processor configured to communicate with a user interface configured to edit the drug library; as well as Wherein, the drug library editing software is configured to display a user-customizable screen that provides the user with the information he needs at a glance.

26. A medical error reduction system, comprising: Drug library editing software configured to create and revise drug libraries; an editor computer comprising a processor configured to communicate with a user interface configured to edit the drug library; as well as Wherein, the software implements, on the user interface, comparing two or more items among the plurality of items.

27. A medical error reduction system, comprising: medical error reduction software configured to create and revise a drug library to generate an edited drug library based on the drug library, and to provide a user with a privilege set for assigning a level of software functionality defining the user's ability to alter the drug library; an editor computer including a processor configured to communicate with a display, the display configured to display the edited drug library and provide a review simulator to simulate a graphical user interface of a medical device using the edited drug library, the edited drug library not being in the medical device when being reviewed, in: Each drug library, when executed on said medical device, restricts the operation of the medical device, The drug library editing software is configured to access medical data by selecting a tab displayed on the editor computer, The review simulator is configured to simulate a plurality of medical device types in a plurality of care areas using the edited drug library, and The edited drug library is downloaded to the medical device only after being simulated by a corresponding medical device type of the plurality of medical device types in the review simulator.

28. The medical error reduction system of claim 27, wherein: The medical device types include at least two of the following: a syringe pump, a large volume pump, a peristaltic pump, and a patient-controlled analgesia machine, and combinations thereof.

29. A medical error reduction system, comprising: an editor computer comprising a processor configured to communicate with a display; and medical error reduction software configured to be accessible via the editor computer to create and revise a drug library to generate an edited drug library based on the drug library, wherein the drug library is configured to communicate information to program a medical device having a medical device processor and a medical device graphical user interface configured to display a user interface to program its corresponding medical device, in: the medical error reduction software being configured to display a simulated medical device graphical user interface, the simulated medical device graphical user interface being configured to mimic the behavior of a medical device graphical user interface of the medical device having the edited drug library of the drug library, The drug library editing software is configured to access medical data by selecting a tab displayed on the editor computer, The review simulator is configured to simulate a plurality of medical device types using the edited drug library, and The edited drug library is downloaded to the medical device only after being simulated by the corresponding medical device type in the review simulator.

30. The medical error reduction system of claim 29, wherein: The plurality of medical device types include at least two of the following: a syringe pump, a large volume pump, a peristaltic pump, and a patient-controlled analgesia machine, and combinations thereof.

31. A medical error reduction system, comprising: A medical device having drug library editing software configured to create and revise a drug library and to provide a user with a privilege set, the privilege set being used to assign a certain level of software functionality to the user; an editor computer comprising a processor configured to communicate with a user interface, and in: The software authorizes a set of users to request changes to the drug library, The drug library editing software is configured to access medical data by selecting a tab displayed on the editor computer, The review simulator is configured to simulate a plurality of medical device types using the edited drug library, and The edited drug library is downloaded to the medical device only after being simulated by the corresponding medical device type in the review simulator.

32. The medical error reduction system of claim 31, wherein: The plurality of medical device types include at least two of the following: a syringe pump, a large volume pump, a peristaltic pump, and a patient-controlled analgesia machine, and combinations thereof.

33. A medical error reduction system, comprising: A computer configured to provide a drug library editor to create and revise a drug library for execution on a medical device; an editor computer comprising a processor configured to communicate with a user interface configured to edit a drug library to generate an edited drug library based on the drug library; and in: The drug library authorizes a user to request a change to the drug library by submitting an electronic change request, The drug library editing software is configured to access medical data by selecting a tab displayed on the editor computer, The review simulator is configured to simulate a plurality of medical device types using the edited drug library, and The edited drug library is downloaded to the medical device only after being simulated by the corresponding medical device type in the review simulator.

34. The medical error reduction system of claim 33, wherein: The plurality of medical device types include at least two of the following: a syringe pump, a large volume pump, a peristaltic pump, and a patient-controlled analgesia machine, and combinations thereof.

35. A medical error reduction system, comprising: Drug library editing software configured to create and revise drug libraries for use with medical devices; an editor computer comprising a processor configured to communicate with a user interface for editing the drug library, in: The drug library editing software is configured to access the medical data by selecting a tab displayed on the editor computer.

36. A medical device comprising: a controller configured to control operation of a pumping mechanism that causes the drug to be delivered; processor; Graphical user interface; a computer readable memory configured to store program code for a drug library, the drug library comprising a plurality of entries, the plurality of entries including at least one entry corresponding to a portion of a facility and at least one drug entry for each such entry, each of the at least one drug entry having parameters associated therewith, at least one drug entry in the drug library being associated not with a specific drug but with a broad drug category, wherein the processor is configured to generate at least one screen for display in the graphical user interface, at least one of the at least one screen comprising one or more parameter values, and wherein the processor is further configured to visually change a font of at least one of the one or more parameter values ​​in response to a change in the one or more parameter values.

37. A medical error reduction system when used in a method of providing a drug library file for a medical device, comprising: an editor computer including a processor configured to communicate with a display; as well as medical error reduction software configured to be accessible via the editing computer for creating and revising a drug library configured for use in a medical device including a medical device processor and a medical device graphical user interface configured to display a user interface configured to communicate information and / or program its corresponding medical device, Wherein, the medical error reduction software is configured to display a simulated medical device graphical user interface, and the simulated medical device graphical user interface is configured to mimic the behavior of the medical device graphical user interface of the medical device using a selected drug library.

Images