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

Abstract

To provide a medical error reduction system and an information processing method, including a medical error reduction software used to create and revise at least one drug library used in a medical device.SOLUTION: A software of a medical error reduction system provides each of a plurality of sets of users with one of a plurality of sets of privileges. Each of the plurality of sets of privileges allocates a certain degree of a software function to one of the plurality of sets of users. The certain degree of the software function defines ability of a user to alter at least one drug library. The medical error reduction system comprises at least one server and at least one editor computer, at least one editor computer includes a processor in communication with each display, and at least one editor computer and at least one server communicate via a network in a client-server based model.SELECTED DRAWING: None

Description

[Technical field]

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

[0002] The present disclosure relates to patient care. More particularly, the present disclosure relates to electronic patient care systems and devices. [Background technology]

[0003] Patient care often involves administering fluids, such as medications, directly to a patient. This can be accomplished using gravity-feed tubing connected to a fluid container (e.g., an IV bag). Fluids or medications may also be administered by forced infusion. The administration of fluids or medications to a patient often requires interaction between many parties (e.g., physicians, nurses, pharmacists). Such interactions are prone to miscommunication, errors, or other occurrences that can result in an incorrect amount of fluid being administered to the patient. Summary of the Invention [Means for solving the problem]

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

[0005] According to one embodiment of the present disclosure, a medical error reduction system may include medical error reduction software for use in creating and revising at least one drug library. The software may be configured to provide one of a plurality of sets of privileges to each of a plurality of user sets. Each of the plurality of sets of privileges may be configured to allocate a degree of software functionality to one of the plurality of user sets. The degree of software functionality may be configured to define the ability of a user 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. Each of the at least one editor computers 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 over a network in a client / server model. Each of the at least one drug library may be usable with at least one medical device.

[0006] In some embodiments of the above system, the at least one drug library may each be organized into a hierarchy. In some embodiments, the hierarchy may include a plurality of care areas subordinate to at least one care group. In some embodiments, each level of the hierarchy may include a number of delivery parameters for at least one medical device. In some embodiments, each of the at least one drug library includes a plurality of entries, each corresponding to a particular medication. In some embodiments, the at least one drug library may include a number of parameters that inform the operation of the at least one medical device. In some embodiments, the drug library may include a plurality of programming limits for the at least one medical device. In some embodiments, the medical error reduction software may further be configured to provide quality improvement information to the user. In some embodiments, at least one of the plurality of privilege sets may allocate privileges to inspect the drug library to one of a plurality of user sets. In some embodiments, at least one of the plurality of privilege sets may allocate privileges to edit the drug library to one of a plurality of user sets. In some embodiments, at least one of the plurality of privilege sets may allocate privileges to edit or create privilege sets to one of a plurality of user sets. In some embodiments, at least one of the plurality of privilege sets can allocate user-added privileges to one of the plurality of user sets. In some embodiments, the plurality of privilege sets allocated to each of the plurality of user sets can enforce a collaborative process among the plurality of user sets to create and revise the at least one drug library.

[0007] According to an embodiment of the present disclosure, 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 in communication with a display. The at least one editor computer and the at least one server may be configured to communicate over a network in a client / server model. 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 via the at least one editor computer for use in creating and revising the at least one drug library. Each of the at least one drug library may be used with at least one medical device. Each of the at least one medical devices 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 and may be used to program the respective medical device. Each of the at least one drug library may include a plurality of entries that guide a user to program the at least one medical device. The medical error reduction software may be configured to display a simulated medical device graphical user interface. The simulated medical device graphical user interface may mimic the behavior of a medical device graphical user interface of a medical device using a drug library selected from the at least one drug library.

[0008] In some embodiments, the simulated medical device graphical user interface is context sensitive. In some embodiments, the medical error reduction software may include several privilege sets. The privilege sets may each be assigned to one of a plurality of user sets. Each of the several privilege sets may allocate a degree of software functionality to each of a plurality of user sets. In some embodiments, the simulated medical device graphical user interface may be a software function that may switch several privilege sets on or off. In some embodiments, each of the at least one drug library may be organized into a hierarchy. In some embodiments, the hierarchy may include several care areas subordinate to the at least one care group. In some embodiments, each level of the hierarchy may include several delivery parameters for the at least one medical device. In some embodiments, each of the at least one drug library may include several entries, each corresponding to a particular medication. In some embodiments, the at least one drug library may include several parameters that inform the operation of the at least one medical device. In some embodiments, the drug library may include several 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.

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

[0010] In some embodiments, a user can select one of the at least one drug entries in the drug library that is associated with a broad drug category rather than a specific drug to program delivery of the medication to a patient. In some embodiments, the at least one drug entry in the drug library that is associated with a broad drug category rather than a specific drug can be associated with at least one parameter that governs delivery of the medication. In some embodiments, the drug library can be created or modified using medical error reduction software. In some embodiments, the display can be a touch screen display. In some embodiments, at least one of the at least one drug entries in the drug library that is associated with a broad drug category rather than a specific drug can enable a user to program the medical device to deliver the medication in a volume per hour mode. In some embodiments, multiple entries can each be associated with at least one parameter. In some embodiments, at least one of the at least one parameter may be a drug delivery parameter.

[0011] According to one embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. Each of the at least one drug library may be usable with at least one medical device. The software may be configured to provide one of a plurality of sets of privileges to each of a plurality of user sets. Each of the plurality of sets of privileges may be configured to allocate a degree of software functionality to one of the plurality of 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 in communication with a user interface. The at least one editor computer and the at least one server may be configured to communicate over a network in a client / server model. At least one of the plurality of user sets may request to modify at least a portion of the at least one drug library using the software.

[0012] In some embodiments, at least one of the plurality of sets of privileges may be configured to allow a user to reject the implementation of the change. In some embodiments, at least one of the plurality of sets of privileges may be configured to allow a user to accept the implementation of the change. In some embodiments, at least one of the plurality of sets of privileges may be configured to allow a user to submit a question to the change. In some embodiments, at least one of the plurality of sets of privileges may be configured to allow a user to propose a revision of the change. In some embodiments, the server may be configured to execute medical error reduction software. In some embodiments, a degree of software functionality may be configured to define an ability for a user to modify the at least one drug library. In some embodiments, the at least one medical device may be an infusion pump.

[0013] According to one embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. Each of the at least one drug library may be usable with at least one medical device. The medical error reduction system may include at least one server configured to execute medical error reduction software. The medical error reduction system may include at least one editor computer. The at least one editor computer may each comprise a processor in communication 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 over a network. At least one of the one or more users may request changes to the at least one drug library by submitting an electronic change request.

[0014] In some embodiments, the at least one medical device may be an infusion pump. In some embodiments, the electronic change request can be linked to the medical data. In some embodiments, the medical data can be stored in an electronic database to provide context information. In some embodiments, the electronic database can be in a hosted environment. In some embodiments, the medical data can be generated from at least one medical device. In some embodiments, the medical data can be stored in an electronic database. In some embodiments, the medical data can be associated with one of at least one drug library used by the at least one medical device that generated the medical data. In some embodiments, the medical data can be displayed in the form of a table. In some embodiments, the medical data can be displayed in the form of a chart. In some embodiments, the medical data can be displayed in the form of a graph. In some embodiments, the medical data can be displayed in the form of a diagram. In some embodiments, the medical data can be displayed in the form of an infusion case. In some embodiments, a user can search for medical data using the drug library editing software. In some embodiments, a user can filter medical data using the drug library editing software. In some embodiments, the medical data can be displayed in a user selectable format. In some embodiments, a user can only access medical data that corresponds to a version of the at least one library in which editing is currently being performed. In some embodiments, each of the multiple entries can be associated with one or more delivery parameters. In some embodiments, at least one of the one or more users can accept the electronic change request. In some embodiments, at least one of the one or more users can respond to the electronic change request. In some embodiments, at least one of the one or more users can suggest modifications to the electronic change request. In some embodiments, at least one of the one or more users can reject the electronic change request.

[0015] According to one embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. Each of the at least one drug library may be usable with at least one medical device. The drug library editing software may be 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 database of medical data. The medical error reduction system may include at least one editor computer. The at least one editor computer may each comprise a processor in communication with a user interface. The user interface may be used by a user to edit the at least one drug library. At least the editor computer, the at least one drug library database, and the at least one database of medical data may be configured to communicate over a network. During editing of the at least one drug library, the user may access the medical data using the drug library editing software.

[0016] 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 may be stored in the host environment. In some embodiments, the medical data may be displayed in the form of charts. In some embodiments, the medical data may be displayed in the form of graphs. In some embodiments, the medical data may be displayed in the form of tables. In some embodiments, the medical data may be displayed in the form of diagrams. In some embodiments, the medical data may be displayed in the form of infusion cases. In some embodiments, the medical data may be displayed in a user selectable format. In some embodiments, the accessed medical data is searchable. In some embodiments, the accessed medical data may be filtered by applying a filter. In some embodiments, the filter may be a device type filter. In some embodiments, the filter may be a data category. In some embodiments, the filter may be treatment based 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 area based criteria. In some embodiments, the filter may be a drug criteria. In some embodiments, the drug criteria may be a drug identifier. In some embodiments, the drug criteria may be a drug type. In some embodiments, the at least one drug library database may be in the host environment. In some embodiments, the medical device may be an infusion pump.

[0017] According to an embodiment of the present disclosure, the medical error reduction system may include drug library editing software used in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. The at least one drug library may each be used with at least one medical device. The drug library editing software may be 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 database of medical data. The medical error reduction system may include at least one editor computer. The at least one editor computer may each include a processor in communication with a user interface. The user interface may be used by 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 database of medical data may be configured to communicate over a network. When creating or revising the at least one drug library, the drug library editing software may be configured to display medical data in the at least one database of medical data in the user interface and filter the medical data using a filter criterion.

[0018] In some embodiments, the at least one medical device may be an infusion pump. In some embodiments, at least one drug library database may be in the hosted environment. In some embodiments, at least one database of medical data may be in the hosted environment. In some embodiments, the filter criteria may be user selectable. In some embodiments, the filter criteria may be a type of medical device. In some embodiments, the filter criteria may be a category of data. 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 care 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 drug criterion may be a drug type. In some embodiments, the filter criteria may be applied by interaction with the medical data displayed in the user interface to display a subset of the medical data. In some embodiments, the filter criteria may be applied by interaction with the medical data displayed in the user interface to scrutinize the medical data. In some embodiments, the medical data may be displayed in the user interface in one or more of several formats specified by the user.

[0019] 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 may include one or more parameter values. The processor may be further configured to visually alter 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.

[0020] In some embodiments, the change is an order of magnitude change in the one or more parameter values. In some embodiments, the processor may be configured to visually alter the font by changing the size of the font. In some embodiments, the processor may be configured to visually alter 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 a user. In some embodiments, one of the one or more parameter values ​​may be a patient's weight. In some embodiments, one of the one or more parameter values ​​may be a patient's body surface area. In some embodiments, one of the one or more parameter values ​​may be a dosage 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 planned infusion volume. 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 ​​may be preprogrammed. In some embodiments, the processor may be configured to visually alter the font by decreasing the size of the parameter value.

[0021] 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 a pressure of a fluid in an infusion line.

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

[0023] 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 that is displayed when the medical device is performing a treatment. The treatment in progress screen may include a drug indicator that indicates a drug being delivered by the medical device. The processor may color code at least a portion of the drug indicator displayed on the user interface with one of a plurality of colors according to one of a plurality of classifications assigned to the drug.

[0024] In some embodiments, the graphical user interface may be a touch screen. In some embodiments, the processor may be in communication with a memory that stores a drug library for use with the medical device. In some embodiments, the drug library may hold color coding information for a portion of the drug indicator. In some embodiments, at least one of the at least one screen may be a program 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 may be a high risk classification. In some embodiments, at least one of the plurality of classifications may be a drug type. In some embodiments, at least one of the plurality of classifications may be a narcotic drug classification. In some embodiments, the drug indicator may include a name of the drug. In some embodiments, the drug indicator may include a non-text indicia. In some embodiments, the non-text indicia is the only portion of the drug indicator that is color coded.

[0025] 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 parameter values ​​associated with a therapy that may be programmed into the medical device. At least one of the parameter values ​​may be a value of a user-overridable limit value for a therapy parameter value. The user-overridable limit value for a therapy parameter value may be overridden by one or more users via the graphical user interface. The processor may display an indicator next to the therapy parameter value in response to the user-overridable limit value being overridden.

[0026] In some embodiments, the graphical user interface may be a touch screen. In some embodiments, at least one of the at least one screen may display a limit violation notification. In some embodiments, the limit violation notification may not display the value of the limit that can be overridden. In some embodiments, the limit violation notification may include an override option. In some embodiments, the user-overridable limit on the therapy parameter value may require both the first user and the second user to override the limit via the graphic user interface. In some embodiments, the plurality of parameter values ​​associated with the therapy that can be programmed into the medical device may be part of a drug library file stored in the computer readable memory. In some embodiments, the indicia may be non-textual indicia.

[0027] According to an embodiment of the present disclosure, the 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 capable of being delivered by the medical device. The medications may be organized according to one or more medication categories. Each of the medications 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 perform the treatment. At least one step in programming the medical device may include selecting a medication category that includes a medication to be delivered by the medical device.

[0028] In some embodiments, the graphical user interface may be a touch screen. In some embodiments, the plurality of medications and the one or more medication categories are part of a drug library file. In some embodiments, the medication categories are searchable via the graphical user interface. In some embodiments, the medication categories are filterable via the graphical user interface. In some embodiments, at least one of the one or more parameter values ​​may be a parameter limit value that is overridable by a user.

[0029] According to one embodiment of the present disclosure, a medical error reduction system may include medical error reduction software for use in creating and revising at least one drug library configured for use with at least one medical device. The software may be configured to provide one of a plurality of sets of privileges to each of a plurality of user sets. Each of the plurality of sets of privileges may be configured to allocate a degree of software functionality to one of the plurality of user sets. The degree of software functionality may be configured to define the ability of a user 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 having a processor in communication with a display. The at least one editor computer may be configured to communicate with the at least one server over a network in a client / server model.

[0030] According to an embodiment of the present disclosure, the medical error reduction system may include a medical device. The medical device may include a medical device processor. The medical device may include a medical device graphical user interface configured to allow a user to program the medical device. The medical error reduction system may include at least one server. The medical error reduction system may include at least one editor computer having a processor in communication with a display. The at least one editor computer may be configured to communicate with the at least one server over a network in 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 accessible via the at least one editor computer for use in creating and revising at least one drug library. The at least one drug library may be used with the at least one medical device and may include a plurality of entries that guide a user to program the at least one medical device. The medical error reduction software may be further configured to display a simulated medical device graphical user interface. The simulated medical device graphical user interface may mimic the behavior of a medical device graphical user interface of a medical device using one of the at least one drug libraries.

[0031] According to an embodiment of the present disclosure, a medical device for delivering a medication to a patient may include a controller configured to control operation of a pump mechanism to deliver the medication. 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 have a plurality of entries. The plurality of entries may include at least one entry corresponding to a portion of a facility. For each such 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 a display of the medical device. The graphical user interface may be used by a user to program the controller with a drug library, and the user may select one of the at least one drug entry corresponding to a portion of the facility to program delivery of the medication to a patient.

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

[0033] According to one embodiment of the present disclosure, a medical error reduction system may include drug library editing software for use in creating and revising at least one drug library for use with at least one medical device. The at least one drug library may include a plurality of entries. The software may be configured to provide at least one of a plurality of sets of privileges to each of a plurality of user sets. Each of the plurality of sets of privileges may be configured to allocate a degree of software functionality to one of the plurality of user sets. The degree of software functionality may be configured to define the ability of a user to modify 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 having a processor in communication with a user interface. The at least one editor computer may be configured to communicate with the at least one server over a network in a client / server model. At least one of the plurality of user sets may access the drug library editing software using the at least one editor computer to request changes to the at least one drug library.

[0034] In some embodiments, at least one of the sets of privileges may be further configured to enable a user to decline making the requested changes to the at least one drug library or to consent to making the requested changes to the at least one drug library.

[0035] According to an embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. The at least one drug library may be used for 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 having a processor in communication with a user interface. The user interface may 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 over a network in a client / server model such that the at least one editor computer has access to the drug library editing software. A user may request changes to the at least one drug library by submitting an electronic change request via the user interface.

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

[0037] According to an embodiment of the present disclosure, the medical error reduction system may include drug library editing software used in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. The at least one drug library may each be used for at least one medical device. The drug library editing software may be 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 database of medical data. The medical error reduction system may include at least one editor computer configured to communicate with the server, the at least one drug library database, and the at least one database of medical data over a network. The at least one editor computer may include a processor in communication with a user interface. The user interface may be used by a user to edit the at least one drug library using the at least one drug library editing software. During editing of the at least one drug library, the user may access medical data in the at least one database of medical data using the drug library editing software.

[0038] In some embodiments, during the editing of the at least one drug library, a user may use the drug library editing software to access medical data in the at least one database of medical data. In some embodiments, the medical data may be in the form of at least one of a chart, graph, plot, and diagram displayed in a user interface. In some embodiments, during the editing of the at least one drug library, a user may use the drug library editing software to display medical data in the at least one database of medical data in a user interface and filter the medical data such that only medical data of interest to the user is displayed in the user interface.

[0039] 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 at least one screen may include at least one parameter value. The processor may be further configured to visually vary a font of the at least one parameter value in response to a change in the number of digits of the at least one parameter value.

[0040] In some embodiments, the at least one screen can include a therapy in progress screen, the therapy in progress screen including a pressure indicator indicating a pressure of fluid in the infusion line. In some embodiments, the at least one screen can be a therapy in progress screen. The therapy in progress screen can include a drug indicator indicating a drug being delivered by the medical device. The processor can be further configured to color code the drug indicator displayed on the user interface in one of a plurality of colors. Each color of the plurality of colors can correspond to a drug classification. In some embodiments, the medical device can include a computer readable memory. The computer readable memory can store a plurality of parameter values ​​associated with a therapy that can be programmed into the medical device. At least one of the parameter values ​​can be a user-overridable limit value for the therapy parameter value. The user-overridable limit value for the therapy parameter value can be overridden by a user via the graphical user interface. The processor can be further configured to display an indicator next to the therapy parameter value in response to a user overriding the user-overridable limit value. In some embodiments, the computer readable memory can be configured to store a plurality of drugs that can be delivered by the medical device. Each medication may be organized into one or more medication categories. Each medication may be further 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 by at least selecting a medication category that includes the medication to be delivered by the medical device.

[0041] According to one embodiment of the present disclosure, the medical error reduction system may include medical error reduction software used in creating and revising at least one drug library. The software may be configured to provide a set of privileges to each of a plurality of users. The set of privileges may be configured to allocate a degree of software functionality to each of a plurality of users. The degree of software functionality may be configured to define the 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. Each of the at least one editor computers 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 over a network in a client / server model. Each of the at least one drug library may be usable with at least one medical device.

[0042] In some embodiments, each of the at least one drug library may be organized into a hierarchy. In some embodiments, the hierarchy may include multiple care areas subordinate to at least one care group. In some embodiments, each level of the hierarchy may include a number of delivery parameters for at least one medical device. In some embodiments, each of the at least one drug library may include a number of entries, each corresponding to a particular medication. In some embodiments, the at least one drug library may include a number of parameters that inform the operation of at least one medical device. In some embodiments, the drug library may include a number of programming limits for the at least one medical device. In some embodiments, the medical error reduction software may further be configured to provide quality improvement information to multiple users. In some embodiments, the set of privileges is configurable to allocate privileges to inspect the drug library. In some embodiments, the set of privileges is configurable to allocate privileges to edit the drug library. In some embodiments, the set of privileges is configurable to allocate edit or create privileges. In some embodiments, the set of privileges is configurable to allocate user-added privileges. In some embodiments, a set of privileges assigned to each of the multiple users may enforce a collaborative process among the multiple users to create and revise at least one drug library.

[0043] According to an embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising a number of drug libraries. Each of the number of drug libraries may include a plurality of entries. Each of the number of drug libraries may be used for at least one medical device. The medical error reduction system may include at least one editor computer. Each of the at least one editor computer may include a processor in communication with a user interface. The user interface may be used by one or more users to edit the at least one drug library. The drug library editing software may be configured to populate a second drug library of the number of drug libraries with entries of the plurality of entries of a first drug library of the number of drug libraries.

[0044] In some embodiments, the system may further comprise at least one server configured to execute the medical error reduction software. In some embodiments, the number of drug libraries may be stored in a drug library database. In some embodiments, the drug library database may be in a hosted environment. In some embodiments, one or more users may specify an entry from a first drug library in the number of drug libraries that they would like to populate in a second drug library in the number of drug libraries. In some embodiments, both the first drug library in the number of drug libraries and the second drug library in the number of drug libraries may belong to a subset of the drug libraries in the number of drug libraries. In some embodiments, the subset of the drug library may be associated with a set of permissions that allow one or more users to access the subset of the drug library. In some embodiments, the set of permissions does not allow another one or more users to access the subset of the drug library.

[0045] According to an embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. The at least one drug library may each be used for at least one medical device. The drug library editing software may be executed by a server. The medical error reduction system may include at least one drug library database that stores the at least one drug library. The medical error reduction system may include at least one editor computer. The at least one editor computer may each include a processor in communication with a user interface. The user interface may 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 may be configured to communicate over a network. The plurality of entries may include one or more clinical recommendations.

[0046] In some embodiments, the drug library database is in a hosted environment. In some embodiments, the one or more clinical advisories may be free text entries. In some embodiments, the one or more clinical advisories may include an image. In some embodiments, the one or more clinical advisories may include a document. In some embodiments, the one or more clinical advisories may be limited in length to between 0 and 100 characters. In some embodiments, each of the one or more clinical advisories may be associated with a short text clinical advisory. In some embodiments, the length of the short text clinical advisory may be limited to between 0 and 100 characters. In some embodiments, the short text clinical advisory may be displayed on at least one screen of a graphic user interface of the at least one medical device. In some embodiments, each of the one or more clinical advisories may be displayed on at least one screen of a graphic user interface of the at least one medical device. In some embodiments, each of the at least one clinical advisory may be associated with a drug entry in at least one drug library.

[0047] According to an embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. The at least one drug library may each be used for at least one medical device. The drug library editing software may be executed by a server. The medical error reduction system may include at least one drug library database that stores the at least one drug library. The medical error reduction system may include at least one editor computer. The at least one editor computer may each include a processor in communication with a user interface. The user interface may 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 may be configured to communicate over a network. The drug library editing software may be configured to allow a user to enter notes about one or more of the plurality of entries.

[0048] In some embodiments, the drug library database can be in a hosted environment. In some embodiments, the note can be a free text entry. In some embodiments, the note can include an image. In some embodiments, the note can include a document. In some embodiments, the drug library editing software can be configured to allow a user to enter notes for one or more subsets of the plurality of entries. In some embodiments, the drug library editing software can be configured to allow a user to enter notes for each of the plurality of entries. In some embodiments, each of a plurality of entries associated with a note may be depicted with a note indicator on a user interface, and in some embodiments, upon user interaction with the note indicator, the note may be displayed in the user interface.

[0049] According to one embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. Each of the at least one drug library may be used for at least one medical device. The drug library editing software may be 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. The at least one editor computer may each comprise a processor in communication with a user interface. The user interface may be usable 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 may be configured to communicate over a network. The plurality of entries may include cleaning parameters.

[0050] In some embodiments, the flush parameters may govern flushing of a fluid line associated with the at least one medical device. In some embodiments, the flush parameters may include default fluid delivery parameter values ​​to be used by the at least one medical device when flushing a fluid line associated with the medical device. In some embodiments, the flush parameters may include a scheduled volume of fluid to be delivered. In some embodiments, the flush parameters may include a flow rate of fluid delivery. In some embodiments, the flush parameters may include a time.

[0051] According to an embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. Each of the at least one drug library may be used for at least one medical device. The drug library editing software may be executed by a server. The medical error reduction system may include at least one drug library database that stores 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 computers may include a processor in communication with a user interface. The user interface may 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 may be configured to communicate over a network. The drug library editing software may be configured to display user customizable screens that provide the user with desired profile information.

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

[0053] According to an embodiment of the present disclosure, the medical error reduction system may include drug library editing software for use in creating and revising at least one drug library. The at least one drug library may include a plurality of entries. The at least one drug library may each be used for at least one medical device. The drug library editing software may be 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. The at least one editor computer may each include a processor in communication with a user interface. The user interface may 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 may be configured to communicate over a network. The user may compare two or more entries of the plurality of entries using the drug library editing software. The comparison may be displayed in the user interface.

[0054] In some embodiments, the comparison may be displayed in a table on the user interface. In some embodiments, the comparison may be a side-by-side comparison. In some embodiments, the differences between two or more entries being compared may be visually indicated on the user interface. In some embodiments, the comparison may include an option to show only the differences. In some embodiments, interacting with a show differences only option can toggle the comparison between showing only the differences between two or more of the plurality of entries and showing all information associated with two or more of the plurality of entries. In some embodiments, the comparison can include an edit option that can be used to open one of the two or more of the plurality of entries for editing.

[0055] According to an embodiment of the present disclosure, a method for generating a drug library file can include assigning one of a plurality of sets of privileges to each of a plurality of user sets. The plurality of sets of privileges can be configured to allocate a degree of software functionality within the drug library editing software. The degree of software functionality can be configured to define an ability of a user to modify at least one drug library. A method for generating a drug library file can include creating a drug library using at least one editor computer. The at least one editor computer can each include a processor in communication with a user interface. The user interface can be used by a user to edit at least one drug library using the drug library editing software. Creating a drug library can include appropriate users among the plurality of user sets, the appropriate users being defined by the plurality of sets of privileges, and can include specifying a master drug list for an institution, defining drug records for one or more portions of the institution, and validating the defined drug records. The method can include approving the drug library for release to at least one medical device within the institution.

[0056] In some embodiments, one of the sets of privileges can allocate editing privileges. In some embodiments, one of the sets of privileges can allocate review privileges. In some embodiments, the step of specifying a master medication list can include selecting a number of medications from a prescription database. In some embodiments, the step of defining medication records for one or more parts of the institution can include selecting a desired medication from a master medication list for each of the one or more parts of the institution. In some embodiments, the step of defining medication records for one or more parts of the institution can include defining a number of parameters for each of the desired medications. In some embodiments, the step of validating the defined medication records can include reviewing the defined medication records. In some embodiments, the step of validating the defined medication records can include editing and revising the defined medication records. In some embodiments, the step of generating the drug library file can further include performing a pilot build phase on the drug library file, in which the drug library file is tested on a test medical device. In some embodiments, the step of generating the drug library file can further include performing a pilot build phase on the drug library file, in which the drug library file is tested on a user interface of a simulated medical device. In some embodiments, verifying the defined medication record may include inspecting the defined medication record using a user interface of a simulated medical device.

[0057] According to one embodiment 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 can include approving the drug library file for publication to the at least one medical device. The method can include sending a notification to a user via an editor service of a drug error reduction system. The method can include downloading the drug library file to a device gateway. The method can include distributing the drug library file to the at least one medical device over a network through which the device gateway can communicate with the at least one medical device.

[0058] In some embodiments, the method may further include a step of a user instructing downloading of the drug library file to the device gateway. In some embodiments, the method may further include a step of selecting at least one medical device from a list of medical devices. In some embodiments, the method may further include a step of the device gateway periodically checking whether an update to the drug library file is available. In some embodiments, the method may further include a step of the at least one medical device verifying the validity of the drug library file. In some embodiments, the method may further include a step of sending a confirmation message from each of the at least one medical device to the device gateway if the validation of the drug library file is successful and updated.

[0059] These and other aspects will become more apparent from the following detailed description of various embodiments of the present disclosure, which is provided with reference to the drawings. [Brief description of the drawings]

[0060] [Figure 1] FIG. 1 is a block diagram of an electronic patient care system according to an embodiment of the present disclosure. [Diagram 2] FIG. 2 is a block diagram illustrating some aspects of the system of FIG. 1 in accordance with one embodiment of the present disclosure. [Diagram 3]FIG. 1 illustrates an aggregation of several facilities for communication according to one embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates a system for electronic patient care according to one embodiment of the present disclosure. [Diagram 5] FIG. 2 is a block diagram illustrating some aspects of electronic communication between a medical device and a device application according to one embodiment of the present disclosure. [Figure 6] 1 is a state diagram illustrating a method of programming an infusion device according to one embodiment of the present disclosure. [Figure 7] FIG. 5 illustrates a software program executable by a processor, the software program and processor configured to implement a publish / subscribe model for use in the facility gateway of FIG. 1 and the application and device gateways shown in FIGS. 2 and 4 in accordance with one embodiment of the present disclosure. [Figure 8] A diagram illustrating a software program executable by a processor, the software program and the processor being configured to implement a capabilities registration model according to one embodiment of the present disclosure. [Figure 9] FIG. 13 is a diagram illustrating a software program that can be executed by a processor, the software program and processor being configured to implement a drug safety method used to generate drug administration library files according to one embodiment of the present disclosure. [Figure 10] FIG. 1 is an exemplary conceptual diagram detailing possible roles, responsibilities, and privileges of various users and parties that may be involved in the creation of a Drug Administration Library File in accordance with an embodiment of the present disclosure. [Figure 11a] FIG. 1 is a diagram outlining an exemplary hierarchical organizational structure of a Drug Administration Library ("DAL") file in accordance with one embodiment of the present disclosure. [Figure 11b] FIG. 13 is a diagram outlining an exemplary hierarchical organizational structure of a Drug Administration Library file according to an embodiment of the present disclosure. [Figure 12]11 is a flowchart detailing several exemplary steps that may be part of the drug error reduction system setup phase of creating a drug administration library file in accordance with an embodiment of the present disclosure. [Figure 13] 1 is a flowchart detailing several exemplary steps that may be used to update a look-up table loaded into a database of a drug error reduction system in accordance with an embodiment of the present disclosure. [Figure 14] 1 is a flowchart illustrating some example steps that may be used to populate a hierarchy of institutions and organizations in a drug error reduction system database in accordance with an embodiment of the present disclosure. [Figure 15] 1 is a flow chart illustrating some exemplary steps that may be used to provide a subscriber with access to an editor for the drug error reduction system. [Figure 16a] 1 is a flowchart detailing several exemplary steps that may be used to set up various aspects of a drug error reduction system within an organization or institution in accordance with an embodiment of the present disclosure. [Figure 16b] 1 is a flowchart detailing several example steps that may be used to define users, the groups to which each user belongs, and various permissions and privileges for each user in connection with an editor of a drug error reduction system according to one embodiment of the present disclosure. [Figure 17] 1 is a flowchart detailing several exemplary steps that may be used to update various aspects of a drug error reduction system within an organization or institution in accordance with an embodiment of the present disclosure. [Figure 18] 1 is a flowchart detailing several exemplary steps that may be used to create or update an institution's / organization's master medication list in accordance with an embodiment of the present disclosure. [Figure 19]1 is a flowchart detailing several exemplary steps that may be used to add a clinical advisory entry to a database in accordance with one embodiment of the present disclosure. [Figure 20] 1 is a flowchart detailing several example steps that may be used to change general settings for an institution or organization in accordance with one embodiment of the present disclosure. [Figure 21] 11 is a flowchart detailing several exemplary steps that may be used to add a care group to a drug administration library file in accordance with an embodiment of the present disclosure. [Figure 22] 11 is a flowchart detailing several exemplary steps that may be used to add a care area to a medication administration library file in accordance with an embodiment of the present disclosure. [Figure 23] 1 is a flowchart detailing several exemplary steps that may be used in validating a care area in accordance with one embodiment of the present disclosure. [Figure 24] 1 is a flowchart detailing several example steps that may be used to update a care area in accordance with one embodiment of the present disclosure. [Diagram 25] 1 is a flowchart detailing several example steps that may be used to add a drug or medication record to a designated care area in accordance with an embodiment of the present disclosure. [Figure 26] 1 is a flowchart detailing several example steps that may be used to review a medication list for a particular care area in accordance with an embodiment of the present disclosure. [Figure 27] 1 is a flowchart detailing several exemplary steps that may be used to update a medication list in accordance with an embodiment of the present disclosure. [Figure 28] 1 is a flowchart detailing several exemplary steps that may be used to revalidate a medication list in accordance with an embodiment of the present disclosure. [Figure 29] 1 is a flowchart detailing several exemplary steps that may be used in submitting a Drug Administration Library file for approval in accordance with an embodiment of the present disclosure. [Diagram 30] 11 is a flowchart detailing several exemplary steps that may be used to prepare a drug administration library file for publishing in accordance with an embodiment of the present disclosure. [Figure 31a] 11 is a flowchart detailing several exemplary steps that may be used to deploy a drug administration library file to various system components in accordance with an embodiment of the present disclosure. [Figure 31b] 1 is an exemplary flowchart detailing several steps that may be used to package and stage resources for publication to a facility gateway in accordance with one embodiment of the present disclosure. [Figure 31c] 1 is a flowchart detailing several example steps that may be used to track the allocation of various resources in accordance with one embodiment of the present disclosure. [Diagram 32] 11 is a flowchart detailing several exemplary steps that may be used to update an existing drug administration library file in accordance with an embodiment of the present disclosure. [Diagram 33] 1 is a flowchart detailing several exemplary steps that may be used to update an institution's / organization's master medication list in accordance with an embodiment of the present disclosure. [Diagram 34] 11 is a flowchart detailing several exemplary steps that may be used to update a clinical recommendation list in accordance with an embodiment of the present disclosure. [Diagram 35] 1 is a flowchart detailing several example steps that may be used to update general settings for an institution / organization in accordance with one embodiment of the present disclosure. [Diagram 36]1 is a flowchart detailing several example steps that may be used to update a care area in accordance with one embodiment of the present disclosure. [Figure 37] 1 is a flowchart detailing several example steps that may be used to update a care area medication record in accordance with an embodiment of the present disclosure. [Figure 38] 11 is a flowchart detailing several exemplary steps that may be used to create and save a drug administration library report in accordance with an embodiment of the present disclosure. [Figure 39] 1 is a flowchart detailing several exemplary steps that may be used to generate a drug administration library difference report in accordance with an embodiment of the present disclosure. [Diagram 40] 1 is a flowchart detailing several exemplary steps that may be used to generate an intra-institutional drug administration library comparison report in accordance with an embodiment of the present disclosure. [Diagram 41] 1 is a flowchart detailing several exemplary steps that may be used to generate an inter-organizational drug administration library comparison report in accordance with an embodiment of the present disclosure. [Diagram 42] 1 is a flowchart detailing several exemplary steps that may be followed to generate a drug administration library history report in accordance with an embodiment of the present disclosure; [Diagram 43] 1 is a flowchart detailing several exemplary steps that may be used to log into an editor of a drug error reduction system in accordance with an embodiment of the present disclosure. [Diagram 44] 1 is an exemplary flow chart detailing several steps that may be used to change a password for a drug error reduction system editor service in accordance with an embodiment of the present disclosure. [Diagram 45]1 is a flowchart detailing several exemplary steps that may be used to recover a password for a Drug Error Reduction System Editor Service in accordance with an embodiment of the present disclosure. [Figure 46] 11 is a flowchart detailing several example steps that may be used to check drug library entries using a medical device programming simulator in accordance with an embodiment of the present disclosure. [Figure 47] 11 is a flowchart detailing several exemplary steps that may be used to compare records in a drug administration library file according to an embodiment of the present disclosure. [Figure 48] 11 is a flowchart detailing several exemplary steps that may be used to update a drug administration library file on a medical device in accordance with an embodiment of the present disclosure. [Figure 49] 11 is a flowchart detailing several example steps that may be used to update a DAL file on a medical device in accordance with an embodiment of the present disclosure. [Figure 50] 1 is a flowchart detailing several exemplary steps that may be used to configure a user interface for a drug error reduction system editor service or continuous quality improvement ("CQI") service according to one embodiment of the present disclosure. [Figure 51] 1 is a flowchart detailing several example steps that may be used to view and utilize continuous quality improvement data in accordance with one embodiment of the present disclosure. [Figure 52] 1 is a flowchart detailing several exemplary steps that may be used to display a desired continuous quality improvement report in a user interface according to an embodiment of the present disclosure. [Diagram 53]1 is a flowchart detailing several example steps that may be used to set up a continuous quality improvement report in accordance with an embodiment of the present disclosure. [Figure 54] 1 is a flowchart detailing several example steps that may be used to set up a continuous quality improvement report in accordance with an embodiment of the present disclosure. [Figure 55] 1 is a flowchart detailing several example steps that may be used to filter continuous quality improvement data using organization / institution hierarchy in accordance with an embodiment of the present disclosure. [Figure 56] 1 is a flowchart detailing several example steps that may be used to filter continuous quality improvement data using a date range or time frame in accordance with an embodiment of the present disclosure. [Figure 57] 1 is a flowchart detailing several example steps that may be used to filter continuous quality improvement data based on custom filtering criteria defined by a user in accordance with an embodiment of the present disclosure. [Figure 58] 1 is a flowchart detailing several example steps that may be used to modify the appearance of continuous quality improvement data, such as continuous quality improvement reports, in a user interface in accordance with an embodiment of the present disclosure. [Figure 59] 1 is a flowchart detailing several example steps that may be used to modify the time units of continuous quality improvement reports based on user input, in accordance with one embodiment of the present invention. [Figure 60] 1 is a flowchart detailing several example steps that may be used to hide a displayed panel or display a hidden panel in a continuous quality improvement report in accordance with one embodiment of the present invention. [Figure 61]1 is a flowchart detailing some example steps that may be used to switch between summary and detailed views within a continuous quality improvement report, according to one embodiment of the present invention. [Figure 62] 4 is a flowchart detailing some example steps that may be used to sort CQI data in a CQI report, in accordance with one embodiment of the present invention. [Figure 63] 1 is a flowchart detailing some example steps that may be used to switch between count and date views in a CQI report, according to one embodiment of the present invention. [Figure 64] 1 is a flowchart detailing several exemplary steps that a user may use to select a utility on a user interface that can perform one or more functions in accordance with one embodiment of the present disclosure. [Figure 65] 1 is a flowchart detailing several example steps that may be used to print a continuous quality improvement report in accordance with one embodiment of the present disclosure. [Figure 66] 1 is a flowchart detailing several example steps that may be used to download a continuous quality improvement report in accordance with an embodiment of the present disclosure. [Figure 67] 1 is a flowchart detailing several example steps that may be used to email a continuous quality improvement report in accordance with an embodiment of the present disclosure. [Figure 68] 1 is a flowchart detailing several example steps that may be used to export data from a continuous quality improvement report in accordance with an embodiment of the present disclosure. [Figure 69] 1 is a flowchart detailing several example steps that may be used to schedule the automatic generation and distribution of continuous quality improvement reports in accordance with an embodiment of the present disclosure. [Figure 70]1 is a flowchart illustrating some example steps that may be used to generate and distribute scheduled continuous quality improvement reports in accordance with an embodiment of the present disclosure. [Figure 71] 1 is a flowchart illustrating some example steps that may be used to generate an automated continuous quality improvement summary report in accordance with an embodiment of the present disclosure. [Figure 72] FIG. 13 illustrates an exemplary graphical user interface login screen that may be presented to a user when the user attempts to access a Drug Error Reduction System Editor service or a Continuous Quality Improvement service in accordance with an embodiment of the present disclosure. [Figure 73] FIG. 13 illustrates an exemplary graphical user interface login screen that may be presented to a user when the user attempts to access a Drug Error Reduction System Editor service or a Continuous Quality Improvement service in accordance with an embodiment of the present disclosure. [Figure 74] FIG. 1 illustrates an exemplary initialization screen that may be displayed on a user interface in accordance with an embodiment of the present disclosure. [Figure 75] FIG. 1 illustrates an exemplary initialization wizard screen according to an embodiment of the present disclosure. [Figure 76] FIG. 1 illustrates an exemplary initialization wizard screen according to an embodiment of the present disclosure. [Figure 77] FIG. 1 illustrates an exemplary initialization wizard screen according to an embodiment of the present disclosure. [Figure 78] FIG. 13 illustrates an exemplary embodiment of a “Welcome” screen that may be displayed in a user interface, such as a drug error reduction system editor service user interface, in accordance with an embodiment of the present disclosure. [Figure 79] FIG. 13 illustrates an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 80]FIG. 13 illustrates an exemplary care area screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 81] FIG. 1 illustrates an exemplary add care area screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 82] FIG. 1 illustrates an exemplary add care area screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 83] FIG. 1 illustrates an exemplary add care area screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 84] FIG. 1 illustrates an exemplary add care area screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 85] FIG. 1 illustrates an exemplary add care area screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 86] FIG. 1 illustrates an exemplary add care area screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 87] FIG. 13 illustrates an exemplary care area screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 88] FIG. 1 illustrates an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Figure 89]FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 90] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 91] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 92] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 93] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 94] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 95] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 96] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 97] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 98] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 99] FIG. 1 illustrates an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Figure 100] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 101] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 102] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 103] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 104] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 105] FIG. 1 illustrates an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 106] FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 107] FIG. 1 illustrates an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Figure 108] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Fig. 109] FIG. 1 illustrates an exemplary medication screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Figure 110] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 111] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 112] FIG. 1 illustrates an exemplary medical device simulator screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 113] FIG. 1 illustrates an exemplary medical device simulator screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 114] FIG. 1 illustrates an exemplary medical device simulator screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Figure 115] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Fig. 116] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 117] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 118] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 119] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 120] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 121] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 122] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 123] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 124] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Fig. 125] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Fig. 126] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 127] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 128] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Figure 129] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Fig. 130] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Fig. 131] FIG. 1 illustrates 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, in accordance with an embodiment of the present disclosure. [Fig. 132] FIG. 13 illustrates an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Fig. 133] FIG. 13 illustrates an example of a dashboard screen of a drug error reduction system editor with feedback items accessed according to one embodiment of the present disclosure. [Fig. 134]FIG. 13 illustrates an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Fig. 135] FIG. 13 illustrates an example of a dashboard screen of a drug error reduction system editor where a change request is being accessed in accordance with one embodiment of the present disclosure. [Fig. 136] FIG. 13 illustrates an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Fig. 137] FIG. 13 illustrates an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 138] FIG. 13 illustrates an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Figure 139] FIG. 13 illustrates an example of a dashboard screen of a drug error reduction system editor where a change request is being accessed in accordance with one embodiment of the present disclosure. [Fig. 140] FIG. 13 illustrates an example of a dashboard screen of a drug error reduction system editor where a change request is being accessed in accordance with one embodiment of the present disclosure. [Fig. 141] FIG. 13 illustrates an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Fig. 142] FIG. 13 illustrates an example of a Drug Error Reduction System Editor dashboard screen where proposed changes are accessed for review in accordance with an embodiment of the present disclosure. [Fig. 143] FIG. 13 illustrates an example of a Drug Error Reduction System Editor dashboard screen where proposed changes are accessed for review in accordance with an embodiment of the present disclosure. [Fig. 144] FIG. 13 illustrates an example of a dashboard screen for a drug error reduction system editor according to one embodiment of the present disclosure. [Fig. 145] FIG. 13 illustrates an example of a Drug Error Reduction System Editor dashboard screen where proposed changes are accessed for review in accordance with an embodiment of the present disclosure. [Fig. 146] FIG. 13 illustrates an example of a dashboard screen of a drug error reduction system editor in which a user is using a search utility according to one embodiment of the present disclosure. [Fig. 147] FIG. 13 illustrates an example of an inspection screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 148] FIG. 13 illustrates an example of an inspection screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Figure 149] FIG. 13 illustrates an example of an inspection screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 150] FIG. 13 illustrates an example of an inspection screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 151] FIG. 13 illustrates an example of an inspection screen that may be displayed on a user interface, such as a user interface of a medication error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 152] FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 153] FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 154] FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 155]FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 156] FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 157] FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 158] FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 159] FIG. 1 illustrates an exemplary drug library entry screen that may be displayed on a user interface, such as a drug error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 160] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 161] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 162] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 163] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 164] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 165] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 166] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 167] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 168] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 169] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 170] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 171] FIG. 1 illustrates an exemplary master medication list screen that may be displayed on a user interface, such as a medication error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 172] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 173] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 174] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 175] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 176] FIG. 1 illustrates an exemplary master medication list screen that may be displayed on a user interface, such as a medication error reduction system user interface, in accordance with an embodiment of the present disclosure. [Fig. 177] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 178] FIG. 1 illustrates an exemplary drug library screen that may be displayed on a user interface, such as a user interface of a drug error reduction system, in accordance with an embodiment of the present disclosure. [Fig. 179] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 180] FIG. 13 illustrates an exemplary prompt that may be displayed on a user interface, such as a user interface of a medication error reduction system, according to an embodiment of the present disclosure. [Fig. 181] FIG. 1 is a block diagram of an exemplary software architecture of an exemplary medical device according to one embodiment of the present disclosure. [Fig. 182]1 is a flowchart detailing several exemplary steps that may be used to attach a syringe to a medical device in preparation for administration of an infusion by the medical device, according to an embodiment of the present disclosure. [Fig. 183] 1 is a flowchart detailing several exemplary steps that may be used to prime an IV line of a medical device in accordance with an embodiment of the present disclosure. [Fig. 184] 1 is a flowchart detailing several exemplary steps that may be used to load an administration set into a medical device, such as a large volume pump, in accordance with an embodiment of the present disclosure. [Fig. 185] 1 is a flowchart detailing several example steps that may be used to select a care area, agent, clinical use, and concentration of a drug when programming an infusion in a medical device in accordance with one embodiment of the present disclosure. [Fig. 186] 1 is a flowchart detailing several exemplary steps that may be used to program an infusion in a medical device in accordance with an embodiment of the present disclosure. [Fig. 187] 1 is a flowchart detailing several example steps that may be used to determine whether a parameter entered at a medical device is outside of defined limits for that parameter in accordance with one embodiment of the present disclosure. [Fig. 188] 1 is a flowchart detailing several exemplary steps that may be used to perform a primary continuous infusion in accordance with an embodiment of the present disclosure. [Fig. 189] 1 is a flowchart detailing several exemplary steps that may be used to implement a bolus of medication in a medical device in accordance with an embodiment of the present disclosure. [Fig. 190] 1 is a flowchart detailing several exemplary steps that may be used to perform a secondary infusion in accordance with an embodiment of the present disclosure. [Fig. 191]1 is an exemplary flow chart detailing several steps that may be used to perform a multi-stage infusion in a medical device in accordance with an embodiment of the present disclosure. [Fig. 192] 1 is a flowchart detailing several exemplary steps that may be used to titrate a fluid being administered by a medical device, in accordance with an embodiment of the present disclosure. [Fig. 193] 1 is a flow chart detailing several exemplary steps that may be used when an infusion being administered by a medical device is nearing completion, in accordance with an embodiment of the present disclosure; [Fig. 194] 1 is a flow chart detailing several steps that may be used to detect and resolve an air-in-line condition in a medical device in accordance with one embodiment of the present disclosure. [Fig. 195] 1 is a flowchart detailing several example steps that may be used to detect and clear an occlusion in an infusion line associated with a medical device in accordance with an embodiment of the present disclosure. [Fig. 196] 13 is a flowchart detailing several steps that may be used to change a care area corresponding to a medical device during the course of treatment, according to one embodiment of the present disclosure. [Figure 197] 1 is a flowchart detailing several exemplary steps that may be used to stop an ongoing infusion in a medical device in accordance with an embodiment of the present disclosure. [Figure 198] 1 is a flowchart detailing several example steps that may be used when a battery in a medical device drops to a predetermined level, in accordance with one embodiment of the present disclosure. [Figure 199] 1 is a flowchart detailing several steps that may be used to lock and unlock a user interface of a medical device in accordance with one embodiment of the present disclosure. [Figure 200]1 is a flowchart detailing several example steps that may be used to power down or put a medical device to sleep in accordance with one embodiment of the present disclosure. [Figure 201] 1 is a flowchart detailing several steps that may be used to clean an IV line associated with a medical device in accordance with an embodiment of the present disclosure. [Fig. 202] 1 is a flow chart detailing several exemplary steps that may be used to attach a replacement syringe to a medical device during an infusion in accordance with an embodiment of the present disclosure. [Fig. 203] 1 is a flowchart detailing several exemplary steps that may be used to prepare a relay infusion using several medical devices, according to an embodiment of the present disclosure. [Fig. 204] 11 is a flowchart detailing several example steps that may be used when a medical device that is part of a relay infusion set is removed from a medical device rack in accordance with an embodiment of the present disclosure. [Fig. 205] 11 is a flowchart detailing several example steps that may be used when a medical device that is part of a relay infusion set is removed from a medical device rack in accordance with an embodiment of the present disclosure. [Fig. 206] FIG. 1 illustrates an exemplary startup screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 207] FIG. 1 illustrates an exemplary startup screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 208] FIG. 1 illustrates an exemplary startup screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 209]FIG. 1 illustrates an exemplary login screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 210] FIG. 1 illustrates an exemplary login screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 211] FIG. 1 illustrates an exemplary login screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 212] FIG. 1 illustrates an exemplary care group selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 213] FIG. 1 illustrates an exemplary care area selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 214] FIG. 1 illustrates an exemplary patient selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 215] FIG. 1 illustrates an exemplary medication selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 216] FIG. 1 illustrates an exemplary medication selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 217] FIG. 1 illustrates an exemplary medication selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 218] FIG. 1 illustrates an exemplary medication selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 219] FIG. 1 illustrates an exemplary medication selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 220] FIG. 1 illustrates an exemplary clinical use selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 221] FIG. 1 illustrates an exemplary clinical use selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 222] FIG. 1 illustrates an exemplary concentration selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 223] FIG. 1 illustrates an exemplary patient weight entry screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 224] FIG. 1 illustrates an exemplary patient weight entry screen that may be displayed on a user interface, such as a user interface of a medical device according to an embodiment of the present disclosure. [Fig. 225] FIG. 1 illustrates an exemplary patient weight entry screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 226] FIG. 13 illustrates an exemplary administration set loading screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 227] FIG. 13 illustrates an exemplary problem resolution screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 228]FIG. 1 illustrates an exemplary syringe loading screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 229] FIG. 1 illustrates an exemplary syringe selection screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 230] FIG. 13 illustrates an exemplary treatment program screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 231] FIG. 13 illustrates an exemplary treatment program screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 232] FIG. 13 illustrates an exemplary treatment program screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 232] FIG. 13 illustrates an exemplary treatment program screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 233] FIG. 13 illustrates an exemplary treatment program screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 234] FIG. 13 illustrates an exemplary treatment program screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 235] FIG. 13 illustrates an exemplary treatment program screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 236]FIG. 13 illustrates an example limit override screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 237] FIG. 13 illustrates an exemplary second user approval screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 238] FIG. 13 illustrates an exemplary treatment program screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 239] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 240] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 241] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 242] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 243] 1 illustrates an exemplary treatment in progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 244] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 245]FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 246] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 247] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 248] FIG. 13 illustrates an exemplary treatment discontinuation screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 249] FIG. 13 illustrates an exemplary alert screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 250] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 251] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 252] FIG. 13 illustrates an exemplary locked treatment in progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 253] FIG. 13 illustrates an exemplary treatment progress screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 254]FIG. 13 illustrates an exemplary treatment completion screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Figure 255] FIG. 13 illustrates an exemplary treatment completion screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 256] FIG. 1 illustrates an exemplary notification settings screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. [Fig. 257] FIG. 1 illustrates an exemplary treatment parameter screen that may be displayed on a user interface, such as a user interface of a medical device, in accordance with an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0062] The facility 10 may be a hospital, a clinic, a medical facility, an outpatient care center, an urgent care center, or any combination or group thereof. The facility 10 may include a facility gateway 21 through which various medical devices 26 may communicate with the facility IT applications / services 11 and / or cloud services 2. The facility 10 includes various medical devices 26 operated and used by nurses 9 on patients receiving care at the facility 10. The medical devices 26 may be infusion pumps, peristaltic pumps, syringe pumps, nephrology equipment, physiological parameter monitoring equipment, other patient care equipment, or any combination thereof.

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

[0064] The Med Technician PC Tool 20 may be used by the Med Technician 19 to update the software of the device 26. The Med Technician PC Tool 20 is a browser-based tool that allows the Med Technician User 19 to monitor the health of the medical device 26, view log files, track maintenance activities, and manage software / firmware installations. The Med Technician 19 may be a hospital employee (or contracted service) who installs, updates, and maintains the medical devices 26 (including infusion pumps) to ensure that the medical devices are in good working order. The Med Technician PC Tool 20 may interface with the device 26 via a physical data connection, such as a USB connection or a serial cable connection, to allow the Med Technician 19 to perform such services. The Med Technician 19 may also wirelessly update the device 26 using the Device Manager 24.

[0065] Devices 26 may communicate with facility IT applications / services 11 (via communications link 343) and / or cloud services 2 (via communications link 344) through facility gateway 21. Communications links 343 and 344 may use WiFi, Ethernet, TCP / IP, WiMax, fiber optic cable, or any other known communications technology.

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

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

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

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

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

[0071] An environment in which the device 26 does not maintain a wireless connection is referred to as a "standard environment," although it may still be connected to enterprise application components and external subsystems. In this particular embodiment, the device gateway 22 still performs all three roles for the enterprise application components and external subsystems, while the medical technician 19 (e.g., using the medical technician PC tool 26) is used for message exchange involving the device 26, and messages may be stored on an external media device (e.g., a memory stick).

[0072] Event subscribers, such as device applications 23, can refine the event stream and republish higher level events to the device gateway 22. Events republished by such applications include reportable biomed events ("RBEs"), described below. 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 medical server that subscribes to RBEs and stores them in a local database within the facility gateway 21.

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

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

[0075] Each medical device 26 may perform self-tests upon power-up and may publish an event containing the results to the device gateway 22. Also, because medical devices 26 may routinely operate for long intervals between reboots, the medical devices 26 may automatically schedule and perform self-tests at times that will not interfere with patient safety and / or treatment.

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

[0077] The facility gateway 21 also includes an equipment manager 24 that controls, manages, or monitors the equipment 26. For example, the equipment manager 24 may be used to update and / or download configuration files (e.g., DAL files) to one of the equipment 26. As previously described, the medical technician 19 may control software, firmware, or configuration file updates to the equipment 26. The equipment manager 24 may provide browser-based tools for the IT director and / or technician 18 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 may be managed by the facility's IT employees / contractors 18.

[0078] When a new version of the Medication Administration Library ("DAL") is released, a DAL file can be sent from the DAL Manager 5 to the Device Gateway 22 over a secure messaging link to notify medical technicians 19 that a new version is available. The notification specifies the device type, location of the DAL, documentation, release notes URL, installer URL, checksum, and installation dependencies. In some embodiments of the present disclosure, the Device Manager 24 can access the new DAL file, receive the DAL file from the Device Gateway 22, receive the DAL file directly from the DAL Manager 5, and / or use the DAL file to control updates to medical devices 26.

[0079] In certain embodiments, the medical technician 19 uses the release notes URL (e.g., via the device manager 24 web page and / or the medical technician PC tool 20) to access information about the upgrade, downloads and verifies the DAL file using the installer URL and checksum, and saves it to a location on the device gateway 22. The medical technician 19 then selects one or more of the medical devices 26 to which the new DAL file will be copied. The selected one or more of the medical devices 26 may then be notified (e.g., via the device gateway 22) that a new DAL file is available. The next time the medical devices (among the medical devices 26 selected for the update) are rebooted, the selected group of medical devices 26 installs the new DAL version (or cancels the installation if an error occurs) and notifies the device gateway 22 and / or device manager 24 of the results. Any of the procedures for updating a DAL file described herein may be used to update firmware, software, OS, or other configuration files of one of the medical devices 26.

[0080] The enterprise gateway 21 may also include an integration API 25 that allows the equipment 26, equipment applications 23, and / or equipment manager 24 to communicate with various databases of the enterprise IT applications 11, such as the patient information system 16, electronic medical records 17, computerized physician order entry 14, laboratory information system 15, real-time location service 12, and / or other databases or services 13. The integration API 25 allows components within the enterprise gateway 21 to interoperate with the enterprise IT applications / services 11. The enterprise gateway 21 may communicate with the enterprise 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 methodology or technology.

[0081] The facility IT applications / services 11 support the hospital's administrative functions (e.g., admission, discharge, transfer, coding, billing, collection, etc.). The unified API 25 insulates the differences between the applications 12-17 of the facility IT applications 11 from the applications 23-24, the device gateway 22, and / or the devices 26. For example, one of the devices 26 may request programming information from the device gateway 22 (or may push programming information to one of the devices 26). Patient IDs, pump IDs, medications, and flow rates may reside in one or more of the facility IT applications 11, and the unified API 25 provides a common format for communicating that information to the devices 26 regardless of the needs or requirements of the facility IT applications 11. This information may be collected by the unified API 25 querying each of the facility IT applications 11 to obtain data and providing that data to the devices 26 in a standardized format. The unified API 25 may be used with a variety of facility IT applications 12-17 having different formats, data standards, communication standards, encryption standards, etc., but provides a standard interface between the applications 22-24 and / or equipment 26.

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

[0083] A caregiver can use the UI to review programming of the medical devices among the devices 26. A clinician can identify medication locations and use individual medical device user interfaces of the medical devices 26 to review automatic programming parameters of the medical devices among the devices 26 and / or manually program the medical devices among the medical devices 26.

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

[0085] The cloud services 2 include a cloud hosted infusion safety manager 3 ("ISM"). Infusion safety manager may be used interchangeably herein with the term "hosted safety manager ("HSM"). The HSM 3 includes a continuous quality improvement ("CQI") manager 4 and a DAL manager 5. A risk manager 6, a nursing manager 7, and a pharmacist 8 can all review the CQI messages obtained by the CQI manager 4 to aid in the development and improvement of the DAL file via the DAL manager 5. The DAL file may then be downloaded to one or more of the devices 26. The DAL manager 5 may include or be associated with a medication error reduction system ("DERS") editor (e.g., DERS editor 112 of FIG. 4 described below).

[0086] Figure 2 is a block diagram illustrating some aspects of the system of Figure 1 in accordance with one embodiment of the present disclosure, i.e., Figure 2 illustrates some aspects of Figure 1 in greater detail.

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

[0088] A large volume pump ("LVP") application 44 is an application corresponding to the LVP 36. A syringe application 43 is an application corresponding to a syringe pump 38, and an other application 42 is an application corresponding to another device 39. The other application 42 and the other device 39 may correspond to any medical device.

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

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

[0091] In some embodiments, the applications 42, 43, 44 reformat raw events from each of the devices 36-39 (received via subscriptions to topics registered by the device gateway 40) into CQI messages. The applications 42, 43, 44 can register CQI topics to which the CQI listener 72 subscribes. The applications 42, 43, 44 publish CQI messages to those CQI topics, which are then received by the CQI listener 72. The CQI listener 72 then sends the CQI messages to the cloud service 28.

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

[0093] FIG. 3 shows a diagram 73 illustrating the aggregation of several facilities 76-80 for communication, according to one embodiment of the present disclosure. Each of the several facilities 76-80 may include a facility gateway 21 (see FIG. 2) for communicating with a cloud service, such as an infusion safety manager 74. In some embodiments, several facilities 76-80 are part of a group of facilities that share a common infusion safety manager 74 that is not accessible to other facilities that are not in the group of facilities 76-80. The group of facilities 76-80 in FIG. 3 communicate with the infusion safety manager via a communication link 344. Such a configuration may be used when the group of facilities 76-80 are grouped together into a larger organization, such as an integrated delivery network (IDN) 75.

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

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

[0096] The cloud service 83 includes databases 104, 105, 106, 113, a firewall 103, a CQI receiver 108, a CQI server 109, a CQI UI 110, and a DERS editor 112. Pharmacists and clinicians 111 can interface with the DERS editor 112 and / or the CQI UI 110. Safety staff 107 can interface with 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 may be accessed from the same browser-based interface.

[0097] The HIS 84 supports the hospital's administrative functions (e.g., admission, discharge, transfer, coding, billing, collection). The EMR 85 tracks the patient's medical history (encounters, tests, diagnoses, procedures, etc.) in the health care facility. The CPOE 86 is the system used by physicians to order laboratory tests, prescription drugs, medical images, and other clinical procedures. The PIS 97 is the departmental system used by pharmacists to receive, review, track, and fill prescription drug orders. The LIS 88 is the departmental system used by laboratory technicians to receive and process orders for clinical specimens (e.g., tissue, blood, urine, etc.). The hospital integration engine 89 provides message translation capabilities that allow the information systems 84-88 to interoperate with each other and with external systems. Most of these engines can support various dialects of HL7. The integration engine is located in the device gateway 99 and can interoperate with the HIS, EMR, and PIS through the hospital integration engine 89. The device gateway 99 provides a message routing engine that supports both a publish / subscribe mechanism and a point-to-point routing mechanism. The device gateway 99 also provides name resolution and capability registration functions.

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

[0099] Each infusion device of the device 101 may be used to control the delivery of a particular infusion (e.g., hydration, nutrients, blood, or medication in liquid form) to a particular patient. Dosage adjustments in the form of loading or bolus doses, or dose titration, may be considered separate infusion phases of a single parent infusion. A collection of infusions or infusion events for the same patient as part of the same treatment may be considered an "infusion story" and recorded in the CQI server 109.

[0100] An infusion can be organized into a preparation phase, a programming phase, and a delivery phase. In the preparation phase, the clinician identifies the infusion fluid, the patient, and the pump, and connects tubing from the infusion fluid to the pump and from the pump to the patient, which can be recorded in the CQI server 109. In the programming phase, the clinician enters dosage parameters into the pump, which uses the installed DAL version to verify the parameters (which can also be recorded in the CQI server 109). In the delivery phase, the pump delivers the specified amount of infusion fluid at the programmed rate.

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

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

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

[0104] In some embodiments, portions of the CQI messages can be used for auto-documentation, auto-programming, and billing functions. In yet some other embodiments, the CQI messages can be used for auto-documentation from the medical device 101 to the EMR 85 and / or auto-programming of the medical device 101 from an eMAR system (e.g., part of the HIS 84). The CQI messages can include drug safety events and latency information.

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

[0106] The CQI receiver 108, CQI server 109, and CQI UI 110 may be provided within a hosted environment 83 (i.e., cloud services). To reduce inconsistencies between user queries and CQI data updates, master / slave database replication (database 105 as master and 106 as slave) may be used in the hosted environment 83. The CQI server 109 may post-process CQI events into reportable summaries before storing them in the database 105 to reduce response times to top-level queries and submission requests. The CQI UI 110 may provide a set of standard reports (compliance, limit violations, escalation safety, events by stage, and events by priority). The CQI server 109 may support a query API used by the DERS editor 112 and the CQI UI 110 for more detailed summaries and to drill down into specific CQI messages.

[0107] The CQI server 109 provides analysis and query services to the user using the CQI UI 110. The CQI server 109 can provide the user of the CQI UI 110 with a summary table of aggregated and updated CQI messages (at configurable intervals). The purpose of this summary table is to reduce response times for top-level CQI queries. This summary can include statistical measures of: (1) programming mode used, such as infusions using DERS limits vs. infusions using wildcards; (2) violations of recommended and absolute limits; (3) titration safety information, such as titration up / down settings and dose limit violations; (4) reportable clinical events by priority (e.g., RCE 149 in FIG. 5, discussed below); and / or (5) reportable clinical events by infusion phase (e.g., RCE 149 in FIG. 5, discussed below). Each of these summaries can produce subtotals corresponding to the following data views: (1) organization name, (2) agency name (e.g., facility name), (3) care area, (4) time of day, and / or (5) week.

[0108] The web service query API allows the CQI UI 110 and / or the DERS editor 112 to select (1) aggregates per data view above filtered by specified selectors, (2) RCE details per infusion, and / or (3) actual programming, limits, and infusion statistics per patient (i.e., infusion cases). In some specific embodiments, the DERS editor 112 and / or any of the systems of the hosted services 83 can be based on a J2EE compliant application server. The databases 104, 105, 106, and 113 can use a database management server.

[0109] Once the J2EE and database management servers are installed and configured, the DERS database 113 can be initialized with the following shared database tables: (1) lookup tables such as units of measurement and modes of administration, (2) access control tables for administrative users, roles, privileges, and permissions, (3) DERS medication list, (4) National Database of Nursing Quality Indicators (NDNQI) nursing area list, (5) agency 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 (each with or without attributes).

[0110] In one embodiment, the DERS editor 112 and / or the DERS database 113 may run in one application server and database environment for multiple institutions 82. In yet another embodiment, each institution 82 may be hosted in its own virtual environment (e.g., cloud service 2).

[0111] The CQI UI 110 and / or DERS Editor 112, in some particular embodiments, may support an HTTP / Javascript interface to generate CQI reports and perform interactive drill-down operations for a user running a web browser.

[0112] 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 of the CQI messages it receives at a given rate and / or if the buffers of the CQI receiver 108 are full, the CQI messages may be temporarily stored in the database 104 and, when the CQI receiver is less loaded, the messages may be retrieved from the CQI receiver 108 and stored in the database 105. The database 105 may be replicated by the database 106. The database 106 may be accessed by a user via the CQI server 109 using either the CQI user interface 110 and / or the DERS editor 112.

[0113] The records in the CQI databases 105 , 106 depend on the DERS editor 112 . The records may include (1) lookup tables such as units of measurement and mode of administration, (2) access control tables for administrative users, roles, privileges, and permissions, (3) DERS medication lists, (4) NDNQI nursing area lists, and / or (5) institution attributes.

[0114] These references are preferably consistent since they depend on the version of the DERS editor database 113. One option is to share these tables between the databases 113, 105, 106. This option is convenient, but increases the deployment coupling between the two databases, 113 and 105, 106. Alternatively, the coupling can be reduced by maintaining read-only copies of the tables inside the CQI databases 105, 106 and taking steps to update the tables when they are modified in the DERS editor 112.

[0115] The access control for the CQI databases 105, 106 may be structurally similar to the DERS database 113 but may differ in content. Some users may be defined in the CQI server 109 but not in the DERS editor 112. For 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.

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

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

[0118] The Clinical Status Manager 91 is an intermediary between the Device Gateway 99 and the Integration Engine 89, coordinating asynchronous workflows involving several parties and components.

[0119] Pharmacists and selected clinicians 111 define the institution's drug limits using a DERS editor 112 and create a DAL file 114 (which may be in XML format, for example). Drug limits may be defined using a well-defined, carefully managed, and well-documented process, with controlled publication procedures. Drug limits may be specified using the DERS editor 112 in the DAL manager 5. The facility 82 can use a common reference model for drugs, care areas, administration modes, etc. to facilitate subsequent inter-agency comparisons. The DERS editor 112 can run in the host environment 83 so that users can access it using a web browser. In some embodiments, no client-side software is required to run the DERS editor 112, other than a sufficient browser. The DERS editor 112 can provide drug limits and default values ​​organized by care area, drug, clinical use, drug concentration, etc. The DERS editor 112 can support a query interface with the CQI server 109 to aggregate search and analysis of CQI insights to improve the next DAL version.

[0120] In some embodiments, a prescription database 7002 may also be included. The prescription database 7002 may include a master list of medications and drugs that may be included in the various DAL files 114. The prescription database 7002 may interface with the DERS editor 112 and the CQI server. The DERS editor 112 may retrieve data from the prescription database 7002 when creating a DAL file 114, thereby helping to ensure consistency of data between the various DAL files and facilitating comparison of multiple DAL files 114.

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

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

[0123] The event 146 is, for example, an event as shown in Table 1 below.

[0124] [Table 1] TIFF2024109862000002.tif234155 TIFF2024109862000003.tif192149Table 1

[0125] Items labeled 1, 2, 3, 4, 5, 6, 7, 8, and 9 in Table 1 are pump event categories. When the medical device 145 is not connected to the device gateway 147, these events are stored in a buffer in the local memory of the medical device 145. When connected (and upon reconnection), the 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, the events may be copied to a portable storage medium and manually published to the device gateway 147. As described above, the device gateway 147 may function as (or include) a publish / subscribe engine configured to send pump events to interested subscribers.

[0126] Referring again to FIG. 1, pump events can be sent to the CQI manager 4 that relate to equipment events for the equipment 26. Those events can be used to monitor an entire fleet of medical equipment 26 across multiple facilities 10. For example, the equipment hardware status set 9.71 can be converted into a CQI message that is communicated to the CQI manager 4. A user can log into the CQI manager 4 to schedule maintenance events, order new parts based on the data, provide predictive or preventive maintenance, and / or order new parts for preventive or predictive reasons. A user can use deterministic heuristics to decide what to order, when to order, and / or when to order pieces of equipment 26 at various facilities 10 for maintenance. The CQI manager 4 can be used to manage the supply chain of parts for the equipment fleet 26 and can provide real-time information on the status of the equipment fleet 26. For example, the equipment hardware status set can include battery information such as current at full charge, indicating the health of the internal battery. If the battery health drops below a predetermined threshold for all or a subset of devices 26 in some facility 10, the CQI manager 4 can automatically order new batteries. Additionally or alternatively, the CQI manager 4 can automatically schedule battery replacement for identified devices 26.

[0127] 5, a device application 151 (e.g., a pump application configured to operate with a pump) may run on the gateway 147 (or, in some embodiments, may be different hardware and / or software). The device application 151 subscribes to events published by the medical device 145.

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

[0129] In some embodiments of the present disclosure, the device application 151 is deployed to 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 the pump topic 150. When a message becomes available, the device gateway 147 application server can launch the device application 151 in a worker thread.

[0130] The Equipment Application 151 is a stateful component and maintains one instance of a Pump Handler 153 for each pump 145 deployed at the institution. The Pump Dispatcher 152 maintains a lookup table of the Pump Handlers 153 using the pump 145 sequence number as a unique key.

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

[0132] The Pump FSM 156 is the top-level state machine that handles events that do not belong to any infusion. The Program FSM 157 is a child state machine that is started when an infusion programming context is started and is responsible for handling infusion programming events. The Delivery FSM 158 is a child state machine that is started when an infusion run begins and is responsible for handling operational events during the infusion. Separate Programming FSM 157 and Delivery FSM 158 can be used because a secondary infusion (including load, bolus, or titration) may be programmed while a primary infusion is in progress.

[0133] An operational model of a medical device 145, such as the pump FSM 156, can be used to construct reportable clinical events (RCEs) 149 or to construct reportable medical events (RBEs) 148. For example, the pump FSM 156 can track the pump 145 as it completes one infusion and resumes another that was suspended, track the programming of one infusion while another is running, and / or track two or more high priority operational alarms that may occur at one time. That is, the pump FSM 156 can include nested state models.

[0134] Each pump handler 153 may also maintain several context objects that hold programming and delivery context information. Such context objects are generated as medical events (to track pump utilization) upon completion and are retained for retrieval if the pump application 151 needs to be restarted. Context objects may include infusion state, infusion mode, and infusion interval. Infusion state contains programming / delivery state data for primary and secondary infusions. Infusion mode contains programming / delivery state data for a particular dose / rate (e.g., load, bolus, and / or titration). Infusion interval contains delivery state (e.g., pump running, stopped, alarms present, etc.) over the duration of operation within an infusion mode. Upon processing the pump event 146, the respective FSM 156, 157, or 158 transitions to a new state, creates, updates, or deletes a context object, and outputs a reportable event (CQI message), such as a reportable medical event 148 or a reportable clinical event 149. A list of reportable clinical events in a particular embodiment of the present disclosure is provided in Table 2 below.

[0135] [Table 2] TIFF2024109862000005.tif187154 TIFF2024109862000006.tif140152Table 2

[0136] Referring to Fig. 4, the CQI listener 93 of Fig. 4 can run in each facility 82 and can connect to the device gateway (99 of Fig. 4 or 147 of Fig. 5) and subscribe to the CQI RCE 149 or the CQI RBE 148. The CQI listener 93 of Fig. 4 can establish a secure private connection with the CQI receiver 108 (see Fig. 4) in the host environment 83. This connection can be a physical connection (always connected) or a logical connection (temporarily connected when a message is sent).

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

[0138] The CQI receiver 108 executes within the host environment within the host environment 83. The CQI receiver 108 listens for and accepts requests for a secure network connection 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 guarantee message persistence, and therefore writes each RCE 149 to the database 105 upon receipt. The CQI receiver 108 can (1) store each received message (CQI message) in a local permanent queue (for buffering), (2) add each CQI message from the head of the queue to the end of a table in the CQI event database, (3) notify the CQI listener 93 that sent the message of the reception of the message, and (4) remove the CQI message from the local queue (since it is in the CQI event database 105 and is secure).

[0139] As described above, the CQI event database 105 is implemented using master / slave replication; that is, database 105 is the master and database 106 is the slave. With this approach, in some specific embodiments, there are two copies of the CQI event database with the same schema. As insert, update, and delete transactions are applied to the master database 105, a database management system (DBMS) in the database 105 writes the changes to a journal and can send unacknowledged changes to the slave database 106.

[0140] Each CQI message (e.g., RCE) can belong to a particular organization. This organization reference must match the organization that operates the medical device (e.g., medical device 101 in FIG. 4 or medical device 145 in FIG. 5) and published the Drug Administration Library (DAL) located on that device. As a result, the CQI databases 105, 106 may require a list of organizations that are consistent with the DERS database 113.

[0141] 6 is a state diagram illustrating a method 161 of programming an infusion device (e.g., in device 16 of FIG. 1) according to one embodiment of the present disclosure. Method 161 begins with a user who may interface with the device's UI.

[0142] Infusion programming begins at what is illustrated in the diagram as the state labeled "START." State 162 is when basic mode programming is used (e.g., when a DERS compliance exception device is used). When programming is performed using a DERS compliance exception device, the method transitions to state 165 where programming of the drug is complete.

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

[0144] If an absolute limit is detected, the method transitions from state 166 to state 167 which requires a state transition back to state 166 and does not allow the clinician to override the DERS violation.

[0145] The infusion method 161 can be canceled during a number of states. In the basic mode programming state 162, the clinician can cancel the infusion before programming is complete. In the DERS programming state 166, the clinician can cancel the infusion before programming is complete. In state 167, the clinician can cancel the infusion if a violation of the DERS recommended or absolute limits is detected.

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

[0147] Once the infusion is complete, the pump sends an infusion completion message via the Device Gateway to the Clinical Server, which ties the completion event to the prescription record. The Clinical Server can then format an IHE Automated Documentation message and send it to one of the facility IT applications 11 (see Figure 1), for example, to record in the Electronic Medical Administration Record ("eMar"), to update the patient's Electronic Medical Record (EMR) 17, and / or to update the hospital billing system to record that the medication was successfully infused.

[0148] FIG. 7 is a diagram illustrating a publish / subscribe model 168 used by the facility gateway 21 of FIG. 1, the applications 41, 42, 43, 44 of FIG. 2 or FIG. 4, and the device gateway 40 according to one embodiment of the present disclosure.

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

[0150] A publisher among (publishers 171) can register one or more topics 170. Each topic 170 can be a unique topic. One or more subscribers 172 can subscribe to one or more of the topics 170 to receive events therefrom. When a publisher 171 posts an event to a unique topic among the topics 170 (e.g., "topic 1"), all subscribers who are subscribed to the topic 170 will receive the event, and subscribers who are not subscribed to the topic 170 will not receive the event. Subscribers 172 who are subscribed to other topics among the topics 170 (e.g., topic 2) but not to the topic 170 will not receive the event sent corresponding to only the topic 170.

[0151] Topics 170, in some embodiments, can provide a level of indirection and allow publishers 171 and subscribers 172 to be anonymous. Publish / Subscribe engine 169 can make the communication one-way and asynchronous (e.g., "fire and forget" type communication). Publish / Subscribe engine 169 can provide durable message delivery on both sides. A durable topic in topics 170 can ensure that messages are not lost even if publish / subscribe engine 169 fails. A durable subscription used for subscriber 172 can ensure that messages are not missed when subscriber 172 is not running.

[0152] The publish / subscribe engine 169 may be part of the device gateway 22, part of any other software in the facility gateway 21, or a stand-alone application of Figure 1. The publish / subscribe engine 169 may be part of the device gateway 40, applications 41-44, or a stand-alone application of Figure 2. The publish / subscribe engine 169 may be part of the device gateway 99, applications 94, 96, 97 of Figure 4, or a stand-alone application of Figure 4.

[0153] Figure 8 illustrates a capability registration model 173 according to one embodiment of the present disclosure. Providers 176 register their capabilities 175 in a capability registry 174. Capabilities 175 can include two aspects: interfaces and attributes. Interfaces are a list of request / response pairs and notifications (in both directions). Attributes are service level agreement parameters that specify constraints on the quality of delivery (e.g. response times, error rates and recovery policies, costs, etc.).

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

[0155] 9 illustrates a drug safety method 115 used to generate a DAL file, according to one embodiment of the present disclosure. Method 115 may be used in system 1 of FIG. 1, system 27 of FIG. 2, system 81 of FIG. 4, or any other electronic patient care system. Method 115 is only one of many methods that may be used to generate a DAL file, and may vary depending on the embodiment.

[0156] Stakeholders such as pharmacies, clinical care areas, etc. (e.g., users selected from 6, 7, 8, 9, 18, and 19 in FIG. 1, or 102, 107, and 111 in FIG. 4) can be selected to help generate and define DAL file 35 (see FIG. 2), which contains drug administration safety rules that can take into account drug type, clinical care group, clinical care area, mode (e.g., volume-based, flow-based, or weight-based, administration policy (loading, bolus, ramp, etc.), concentration, etc.

[0157] Method 115 includes acts 116 and 117. Act 116 includes sub-acts 118-125, and act 117 includes sub-acts 126-127. Act 116 generates a DAL file, and act 117 monitors usage of the DAL file to aid in notifying updates to DAL file 35 (see FIG. 2).

[0158] Act 122 sets up a DAL file, e.g., an initial DAL file or a template DAL file with no field entries. Act 123 receives changes to the DAL file according to input from one of the selected users (e.g., via the DERS editor 112 of FIG. 4). Act 121 inspects the DAL file, e.g., by running a medical device simulator via the DERS editor 112 of FIG. 4. After review in act 121, the trial DAL file may be published (electronically) in act 120. The trial DAL file is approved in act 118, although adjustments may be made to the DAL after the trial is complete. Act 118 may be accomplished via clicking an "Approve" button in a web browser to approve the use of the referenced file (e.g., referenced by version number, creation date, etc.).

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

[0160] During operation, medical devices generate CQI events (i.e., CQI messages) that can include information about when a normal infusion was administered, when an infusion bypassed a DERS test, when a recommended limit was exceeded and overridden, and / or when a recommended or absolute limit was exceeded and therapy was reprogrammed, etc.

[0161] The CQI events are sent to the CQI server in act 126, which collects and stores them. Safety personnel can maintain reports summarizing those events, providing a drill-down capability to find opportunities to improve procedures in act 124. Similarly, pharmacists and clinicians can query the CQI database in act 124 to find opportunities to improve the drug record the next time the DAL file is published. That is, the CQI messages are analyzed or reviewed in act 124. Changes can be made to the DAL file and a new version of the DAL file can be created in act 123. The new DAL file can then be reviewed, piloted, and published as described above.

[0162] In some embodiments, creating a DAL file using a DERS editor, such as the DERS editor 112 of FIG. 4, is a collaborative process involving several individuals or participants. All of the people or participants involved in the creation of the DAL file can contribute to the creation of the DAL file by accessing the DERS editor and interacting with the DERS editor's user interface. In some embodiments, no client-side software is required to access the DERS editor other than a sufficient web browser. In some embodiments, the DERS editor's user interface can be accessed through an application such as a tablet computer. Any of the people or participants involved in the creation of the DAL file can access the DERS editor and contribute to the DAL file using a computer with internet capability, a tablet computer, a smart phone, or the like.

[0163] Each individual or party involved in the construction of the DAL file can have certain roles, responsibilities, and / or privileges assigned. Such roles can be assigned using an Access Control List (ACL) and / or a Role Based Access Control (RBAC) model. The roles and responsibilities can be accomplished as part of the methodology that can be used to generate the DAL file. The roles, responsibilities, privileges, etc. can be assigned to structure a collaborative process. They can also be assigned to encourage as much input and oversight into the DAL file generation as possible. This can ensure that the DAL file created in the collaborative process is well-crafted, reducing drug errors as much as possible. The various roles and privileges of the users can be stored in a user database (not shown) hosted within the host environment. In some embodiments, the various roles and privileges may instead be stored in a DERS database.

[0164] The DERS editor also allows users to provide spontaneous contributions, feedback, requests, comments, annotations, questions, etc., which can be used to build or improve the DAL file. If, during piloting, simulation, or daily use of the DAL file, the user discovers an issue, concern, potential improvement, etc., the user can submit a change request to address it. Such requests can be tied to CQI data or specific CQI reports to provide context to the reviewer.

[0165] CQI data can be easily accessed when contributing to a DAL file, possibly with varying degrees of access depending on the user or party. This information can be presented in the DERS editor user interface in an easy to understand form. In some embodiments, at least a portion of this data may be presented in the form of graphs, charts, or other visual aids. A user may also use the DERS editor to filter out unnecessary CQI data, thereby presenting the user with a more concise data set that focuses on the data of interest. The availability of this CQI data may be utilized by individuals or interested parties to help inform decisions regarding changes to various items, etc. This data may also be used to evaluate the appropriateness of various entries in the DAL file.

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

[0167] An exemplary diagram illustrating possible roles, responsibilities, and privileges of individuals and parties involved in collaboratively creating a DAL file is shown in FIG. 10. This exemplary diagram is one of many possible examples and may be configured differently in alternative embodiments. For example, some parties / parties may be combined or not included. Roles and responsibilities may also differ. As shown, roles, responsibilities, and privileges may be assigned to encourage thoughtful creation of a DAL file that minimizes the likelihood of possible drug errors. In this exemplary embodiment, publication of a DAL file requires multiple reviews of the entries and multiple consensuses.

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

[0169] The drug library manager 200 may be one or more individuals, such as a physician, a caregiver, a pharmacist, etc. In some embodiments, the drug library manager 200 may be, for example, a pharmacist 8 as shown in FIG. 1 or a safety staff member 107 as shown in FIG. 4. The drug library manager 200 may be given administrator capabilities within the DERS editor. That is, the drug library manager 200 may have editing privileges, which gives the ability to modify most, if not all, of the modifiable entries and ultimately oversee the proposed DAL file modifications. The drug library manager 200 may have privileges to access most, if not all, of the functionality of the DERS editor. The drug library manager 200 may also be required to approve the finalized DAL file before it is released for use on various medical devices.

[0170] The resource clinicians 202, in some embodiments, are one or more individuals such as physicians, nurses, directors of nursing, etc. In some embodiments, the resource clinicians 202 are directors of nursing 7 and / or nurses 9 of FIG. 1. In some embodiments, the resource clinicians 202 are pharmacies and clinicians of FIG. 4. The resource clinicians 202 may have the ability to inspect, comment, annotate, suggest changes, etc., via the DERS editor in the DAL file. The resource clinicians 202 may be divided into several subgroups. For example, the resource clinicians 202, in some embodiments, may be divided into care area groups.

[0171] The review pharmacist 204, in some embodiments, is one or more individuals, such as a pharmacist. In some embodiments, the review pharmacist 204 is pharmacist 8 of Figure 1. The review pharmacist 204 can review all of the entries in the DAL file via the DERS editor to see if any entries may require revision. The review pharmacist 204 can also have the ability to comment, annotate, and request changes to various entries in the DAL file.

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

[0173] The clinical consultant 208, in some embodiments, is one or more individuals, such as a physician, a nurse, a director of nursing, a director of risk management, or other appropriate staff. In some embodiments, the clinical consultant 208 is the director of nursing 7, the nurse 9, the medical technician 19, and / or the director of risk management 6 of FIG. 1. The clinical consultant 208, in some embodiments, is the safety staff 107 of FIG. 4. The clinical consultant 208 may be involved in performing pilot creation of the DAL file. The clinical consultant 208 may have the ability to inspect, comment, annotate, etc., the entries in the DAL file or portions of the entries in the DAL file.

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

[0175] In various embodiments, the roles, responsibilities, and privileges assigned to each party may differ, for example, in some embodiments, a greater number of parties may be required to approve the DAL file before it is released for use on various medical devices. Different parties may be assigned greater or lesser degrees of software functionality.

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

[0177] In the example of FIG. 10, the care area drug records step 212 may include a substep 214 of selecting drugs and designating records by the drug library administrator 200. This substep may include selecting the various drugs identified in step 210 for inclusion in a particular subdivision or care area / group of the institution. For example, a hospital may select a subset of the drugs defined in step 210 as drugs to be used in the hospital's intensive care units. The various drugs selected for each care group may then modify those drug records to suit the needs of each care area within that care group. For example, in this step, drugs for a particular care area may have various clinical uses, concentrations, limitations, etc. designated. 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.

[0178] Once the drug selection and record assignment substep 214 of the care area drug records step 212 is completed, a validation by care area substep 216 can be performed by at least one resource clinician 202, in which the selected drugs and their records are reviewed and verified by care area. In a hospital, one or more nurses or physicians responsible for or working in a particular care area can be the resource clinicians 202 performing this substep for that care area. In this substep, the resource clinicians 202 can provide feedback on the various drug selections and records by care area.

[0179] In the review step 218, the drug selections and records made in the care area drug records step 212 are reviewed to ensure they are appropriate and correct. In the example of FIG. 10, in the edit and revise substep 220, the drug library manager 200 edits and modifies records that may require such action. This may include addressing any feedback or requests generated by the resource clinicians 202 in the care area drug records step 212. It may also include addressing any feedback, concerns, requests, etc. from other parties involved in the review step 218.

[0180] In the review step 218, a substep of review 222 by care area can be performed by at least one resource clinician 202. In this substep, the selected drugs and their records are reviewed by care area. In a hospital, one or more nurses or doctors responsible for or working in a particular care area can be the resource clinicians 202 performing this substep for that care area. In this substep, the resource clinicians 202 can provide feedback or requests for changes to the various drug selections and records by care area.

[0181] Additionally, the sub-steps of review between care areas 224 and review between care groups 226 may be performed by the review pharmacist 204 and the pharmacy consultant 206, respectively. In the review between care areas sub-step 224, the drugs selected for each care area and their records may be reviewed by the review pharmacist 204 and feedback may be generated indicating any concerns, suggestions, requests, etc. In the sub-step of review between care areas 224, the drugs selected for each care area and their records may be reviewed by the review pharmacist 204 and feedback may be generated indicating any concerns, suggestions, requests, etc. In the sub-step of review between care groups 226, the pharmacy consultant 206 may review the drug list, drug records, and feedback indicating any concerns, suggestions, requests, etc. There may be multiple pharmacy consultants 206, each of whom is assigned to a particular care group. In some examples, the pharmacy consultant 206 may also review other records. For example, in some instances, the pharmacy consultant 206 may also review the records for all medications within the institution that are considered high risk if delivered incorrectly.

[0182] In the pilot creation step 228, all parties shown in FIG. 10 (and possibly others not shown in FIG. 10) participate in the pilot creation of the new DAL file generated through steps 210, 212, and 218. In the pilot creation step 228, the various parties may use a pump simulator in the DERS UI to inspect or review all entries for each care area. In some embodiments, a mock DAL file may be created and sent to the test medical device. The DAL file may be inspected and reviewed by the various parties in the test medical device UI. Feedback generated by the various parties involved in the pilot creation step 228 may be addressed and any necessary changes may be made to the DAL file.

[0183] To complete the DAL file, the DAL file may need to go through an approval step 230, where various parties can approve the DAL file and therefore make it available to medical devices within the institution. In the example of FIG. 10, the drug library administrator 200 and resource clinician 202 are required to approve the DAL file. Depending on the implementation, more or fewer parties may be required to approve the DAL file before it is made available. After the approval step 230, the DAL file can be made available for use within the institution.

[0184] In various embodiments, a DAL file may be organized hierarchically. That is, a DAL file may contain multiple superior and subordinate or parent and child entries that specify settings for the DAL file. The entries may be organized in various hierarchies. As you move down the hierarchy, the entries in the DAL file may become more specific. For example, a parent entry may broadly define parameters, restrictions, etc., and a child entry may further narrow or refine those parameters, restrictions, etc.

[0185] FIG. 11a illustrates an example hierarchical organization of a DAL file. As shown, the example hierarchical organization illustrated in FIG. 11a resembles an institution / organization hierarchy. In some embodiments, the hierarchical organization of a DAL file may differ. For example, some DAL files may not include the nursing group and / or organizational hierarchy illustrated in FIG. 11a. This may be especially true for DAL files used in small, independent institutions.

[0186] As shown, the top of an exemplary hierarchy for a DAL file may be the organization 2350 for which the DAL file is used. Below the organization 2350 may be constituent institutions 2352 that make up the organization 2350. In some DAL files, the institution 2352 may be the top of the DAL file hierarchy. This may be the case, for example, when the DAL file is created in an institution 2352 that is not part of the organization 2350.

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

[0188] At various levels of the hierarchy, several parameters may be defined. Defining such parameters may be the process by which the DAL file is created. Such parameters may include, but are not limited to, various operational settings, data format settings, acceptable input ranges or values ​​for data in a medical device, treatment or medical device guardrails or limits, etc. Examples of some settings that may be defined in a DAL file are described throughout this specification. Other settings may also be included in some embodiments. In some instances, values ​​defined at higher levels in the hierarchy may serve as parent values ​​for other values ​​defined at lower levels in the hierarchy.

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

[0190] As another example, a care group 2354 may have several drugs associated with it. The drug records 2358 corresponding to drugs defined at the care area 2356 level in that care group 2354 may specify the clinical use and concentration of that particular drug appropriate for that particular care area 2356. As an example, in a care group 2354 consisting of five care areas 2356 that use similar drugs, a user may simply add those common drugs at the care group 2354 level, rather than adding them once for each care area 2356 in the care group 2354. Adding a drug to the care group 2354 may result in the drug being added to the care areas 2356 in that care group. Also, in some embodiments, a user may define some or all parameters for each common drug at the care group 2354 level. Those parameters may then be inherited by each care area 2356 in the care group 2354 as default values ​​for the respective child parameters. Such an arrangement may facilitate the creation and improvement of DAL files, as well as increase ease of use and efficiency.

[0191] Additionally, in some embodiments, some levels of the exemplary DAL file hierarchy may be divided into several sub-levels. For example, a drug record 2358 may be divided into a general drug setting, a clinical use setting, and a specific concentration setting for that drug. Each of these sub-levels may further have its own hierarchical structure.

[0192] FIG. 11b illustrates another exemplary embodiment 4500 of a DAL file hierarchy. As shown, the DAL file hierarchy 4500 illustrated in FIG. 11b includes several additional hierarchies compared to the hierarchy illustrated in FIG. 11a. Other embodiments may include different hierarchies or a different number of hierarchies. A user may be able to define various parameter values ​​for creating the DAL file at each level illustrated. In some embodiments, the same or related parameter values ​​may be defined at multiple levels of the hierarchy. In such cases, a value defined at a higher level of the DAL file hierarchy 4500 may act as a parent value for the same or related values ​​at a lower level of the DAL file hierarchy 4500. It should also be noted that there may be multiple components at each level of the DAL file hierarchy that make up the higher levels of the DAL file hierarchy 4500. For example, referring again to FIG. 11a, multiple nursing groups 2354 may make up an institution 2352.

[0193] As shown in Figure 11b, the top level of the DAL file hierarchy 4500 is the IDN or organization 2350. The next level down is the region 4502. This level may be included in cases where an IDN includes several institutions spread across a large geographic area. In other embodiments, this level of the hierarchy may be used to create groupings of similar institutions (e.g., urgent care centers, clinics, etc.).

[0194] 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 may be done at a higher level of the DAL file hierarchy 4500. They may be defined by creating a master medication list for an institution and then partitioning it into categories. The user can also define parameters for medications and categories 4506. 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.

[0195] A user may define various parameters at 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 act as a parent setting for any medication records 2358 defined in the care group 2354. The parameter settings for a care group 2354 may also act as a parent setting for any care area 2356 entries in the care group 2354. Additionally, medication records 2358 and associated parameters defined in a care group 2354 may be automatically included in the care areas 2356 in the care group 2354.

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

[0197] As shown, the medication record 2358 is divided into several sub-levels. In the exemplary embodiment of FIG. 11b, the medication record 2358 includes a sub-level of medication 4508, which is the highest in its internal hierarchy. The user can populate this sub-level of the hierarchy by selecting a medication name from the master medication list. This can be any parent value defined for that medication in the master medication list or medication category list. The user may also be able to define other parameters at the medication 4508 sub-level. Any value defined at the medication 4508 sub-level can serve as a parent value for the clinical use 4510 sub-level. The user may define various parameters at the clinical use 4510 sub-level. These values ​​can serve as parent values ​​for the concentration 4512 sub-level. The user may also be able to define various parameters at the concentration 4512 sub-level.

[0198] 12-71 show some exemplary flow charts detailing some aspects of the use of the DERS editor. These flow charts and the steps shown in those flow charts are merely exemplary. In other embodiments, the use of the DERS editor may differ from that shown and described in FIG. 12-71. 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 recognized that some of the flow charts shown in the figures only detail one example of many possible ways to achieve the same result. Many embodiments may include multiple alternative workflows that may be employed to achieve the same end result. For the sake of brevity, not all alternative workflows contemplated within the scope of this disclosure are shown in the figures. The flow charts shown and described in FIG. 12-71 may be associated with various screens shown and described in FIG. 72-181.

[0199] FIG. 12 shows a flowchart detailing some exemplary steps that may be part of the DERS setup 122 (see, e.g., FIG. 9) phase of DAL file creation. The steps detailed in the flowchart of FIG. 12 may be performed prior to using the DERS editor at a medical institution. At step 240, a user may log into a DERS hosting environment. The user may be part of the host IT of the host environment 83 of FIG. 4. In some embodiments, the user is an administrator of the DERS editor service. At step 242, a user may log into a DERS database of the DERS hosting environment. The DERS database is, in some embodiments, the DERS database 113 shown in FIG. 4. At step 244, a user may run a database loading script on the DERS database. This loading script may load DERS reference tables into the DERS database. The loading script may load DERS reference tables that are used for all institutions and organizations that use the DERS editor service. The lookup tables can be loaded into the database for drugs, drug aliases, substitute drugs, drug incompatibilities, care area type, role, unit of measure, comment type, approval / validation status, various attributes, etc. At step 246, the database loading script can be verified by the user for accuracy. At step 248, the user can load an instance of the institutional DERS for testing. At step 249, this instance can be used by the user to verify the lookup tables loaded into the DERS database for accuracy. The steps detailed in the flowchart of FIG. 12 can be performed by a user with direct or remote access to the DERS host environment.

[0200] FIG. 13 shows a flow chart detailing some exemplary steps that can be used to update the lookup table loaded into the DERS database. In some embodiments, the lookup table can be the lookup table described with respect to FIG. 12. In step 250, a user logs into the DERS hosting environment. The user can be part of the host IT of the host environment 83 of FIG. 4. In some embodiments, the user is an administrator of the DERS editor service. In step 252, the user can log into a DERS database in the DERS hosting environment. The DERS database is, in some embodiments, the DERS database 113 shown in FIG. 4. In step 254, the user can run a database update script on the DERS database. This update script can update the DERS lookup table in the DERS database. This update script can update the DERS lookup table used by all institutions or organizations that use the DERS editor service. In step 256, the user can verify that the database update script is correct. In step 258, the user can load an instance of the testing institution DERS. In step 259, the user can use this instance to check whether the lookup table updated in the DERS database is correct. The steps detailed in the flowchart of FIG. 13 may be performed by a user with direct or remote access to the DERS host environment.

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

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

[0203] FIG. 15 shows a flow chart illustrating some exemplary steps that may be used in providing a subscribing institution access to the DERS editor. At step 280, an institution or organization may sign an agreement with a provider of the DERS editor service to register with the DERS service. At step 282, the DERS editor service may be configured to accommodate the new institution or organization. In some embodiments, this may involve setting up a database and application server for the new institution or organization. In some other embodiments, a new data set may be created in an existing database for the new institution or organization. This step may be performed by host IT, which corresponds to the host environment in which the DERS editor service database, server, etc. reside. In some embodiments, step 282 may involve performing the steps detailed in FIG. 14.

[0204] In step 284, DERS editor service personnel (e.g., host IT of host environment 83 of FIG. 4) may create a user account for the institutional or organizational user. In some embodiments, the user is a drug library administrator, such as drug library administrator 200 shown in FIG. 10. Access information for that user account may also be provided to the institutional or organizational user in this step. In step 286, the institutional or organizational user may log into the DERS editor. In some embodiments, the institutional user may also be required to change their password in step 286. The institutional user may then be provided with training by DERS editor service personnel in step 288, allowing the institutional user to access the DERS editor.

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

[0206] At step 304, the value of group permission for group A is changed. At step 306, the value of group permission for group B is changed. At step 308, the value of group permission for group C is changed. At step 310, the value of group permission for group D is changed. Groups A-D may represent various categories of agency employees that may exist. For example, one of groups A-D may be a pharmacist group, another may be a medical technician group, another may be a nursing director group, and a final group may be a safety officer group. In various embodiments, there may be other groups corresponding to other categories of agency or organization employees. Groups may be user defined in some embodiments. In some embodiments, groups may be predefined and have a default set of group permissions provided by the DERS editor service. Some embodiments may not include groups and may allocate permissions based on a particular user. Some groups may also include subgroups (not shown). The assignable permissions allow a user to customize groups or subgroups to best suit the needs and / or current structure of their agency / organization.

[0207] A list of possible permissions in a particular embodiment of the present disclosure is shown in Table 3 below.

[0208] [Table 3] TIFF2024109862000008.tif62149

[0209] Continuing with reference to FIG. 16a, at step 312 the user may also choose to create a new user. This may involve defining a username and temporary password for the new user. It may also involve providing an email address for the new user. The user may then proceed to any of steps 314, 316, 318, and 320. If the user selected an existing user at step 313, the user may also choose to proceed from there to any of steps 314, 316, 318, and 320. At step 314 the user may assign the newly created user or an existing user to group A. At step 316 the user may assign the newly created user or an existing user to group B. At step 318 the user may assign the newly created user or an existing user to group C. At step 320 the user may assign the newly created user or an existing user to group D. In some embodiments the user may assign the newly created user or an existing user to more than one group. Some embodiments may include additional steps (not shown) in which the user may further assign the newly created user or an existing user to other groups or subgroups.

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

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

[0212] In step 4404, the user may indicate that they wish to add a new user. In step 4406, the web tier corresponding to the DERS editor may then render an add user page. In step 4408, the user may then add various user metadata for the new user. Once the various user metadata for the new user has been added, in step 4410, the web tier may create user credentials for the new user. In step 4412, the new user data may be inserted into a database, which may be, for example, the DERS editor database 113 of FIG. 4 or a user database in a hosted environment.

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

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

[0215] Figure 18 shows a flowchart detailing several exemplary steps that may be used to create or update an institution's / organization's master medication list. In some embodiments, the steps shown in the flowchart of Figure 18 may be part of customizing the medication list 210 described in connection with Figure 10. At step 350, the user navigates to the institution's or organization's medication list on the DERS editor user interface. The DERS editor service may then display a drug list editor at step 352. The user may be a drug library administrator, such as, for example, drug library administrator 200 of FIG. 10. In other embodiments, the user may be a pharmacist or a user that has been granted permission 0.04 of Table 3. Upon proceeding to the institution's or organization's drug list, the user may import a drug list from the DERS editor service or may select one or more drugs from a master list provided by the DERS editor service.

[0216] If the user selects to import a list from the DERS editor service, the DERS editor service may prompt the user to select a medication list to import, at step 356. This step may involve displaying a list of available lists stored in the DERS editor service or a database associated with the DERS editor service. At step 358, the user may import the desired list. The DERS editor service may then update the institution's / organization's medication list to include the imported entries, at step 359. If the user wishes to add more medications to the institution's / organization's medication list, the user may import another medication list or select medications from a master medication list accessed via the DERS editor service. Once the user has finished updating or creating the institution's / organization's medication list, the user may proceed to step 366, which is described later in this specification.

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

[0218] Once 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 prompt the user to save the created or updated medication list for the institution or organization in step 367. The user may then save the created or updated medication list in step 368, which may then be saved to a database, such as a DERS database. The DERS editor service may then notify appropriate users at the institution or organization that a medication list has been created or updated in step 369. For example, the DERS editor service may notify all users responsible for creating or maintaining medication lists for care areas that a medication list for the institution / organization has been created or updated.

[0219] Referring now to FIG. 19, a flow chart is shown detailing some exemplary steps that may be used in adding a clinical advisory entry to the database. A clinical advisory may provide information about a medication to a medical device user. This information may include administration guidelines, information from a prescription, contraindications, etc. In various embodiments, a clinical advisory may include text, images or graphics, and / or electronic files such as PDFs. A clinical advisory may be a free text entry that allows a user to enter whatever content they desire. Some embodiments may include several types of clinical advisories. For example, some embodiments may include short text clinical advisories and detailed clinical advisories. Short text clinical advisories may be limited to a predetermined number of characters (e.g., 40 characters) to facilitate display in a medical device graphic user interface.

[0220] These steps may be performed as part of customizing the medication list 210 described in connection with FIG. 10. In step 370, the user navigates to a clinical advisory list. The user may then decide to either retrieve a clinical advisory list from the DERS editor service or add their own clinical advisory to the clinical advisory list. If the user decides to retrieve a list of clinical advisories from the DERS editor service, the list may be retrieved in step 372. If the user decides to add their own clinical advisory to the list, the user may proceed to step 374 and add the clinical advisory. The user may repeat step 374 as many times as necessary until they are finished adding clinical advisories to the clinical advisory list. In step 376, the user may log out and save the changes to the institution's or organization's clinical advisory list. The changes may be saved to the DERS database. In step 378, the DERS editor service may notify all relevant users that the clinical advisory list has been updated. Step 378 may, in some embodiments, include automatically sending an email to the relevant users to notify them of the changes.

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

[0222] FIG. 20 shows a flow chart detailing some exemplary steps that may be used to change the general settings of an institution or organization. These steps may be performed as part of the DERS setup 122 (see, e.g., FIG. 9) phase. At step 380, the user navigates to a list of general settings on the DERS editor user interface. As noted above, the list may be accessed via a suitable web browser and no client-side software is required. In some embodiments, at step 381, the DERS editor service may prompt the user to enter values ​​for various general settings. Then, at step 382, ​​the user may change, enter, update, etc., the desired values ​​of the general settings. At step 384, the user may log out and save the changes made to the general settings. The changes may be saved to the DERS database. Then, at step 386, the DERS editor service may notify all applicable users that the general settings have been changed. A non-limiting list of possible general settings in certain embodiments of the present disclosure is provided in Table 4 below.

[0223] [Table 4]

[0224] FIG. 21 shows a flow chart detailing some exemplary steps that may be used in adding a care group to an institution or organization. As described in detail above in connection with FIGS. 11a-11b, within the DAL file, an organization or institution may be divided into several sub-areas or groups that reflect, for example, departments within the organization or institution. The steps shown in FIG. 21 may be part of the DERS setup 122 (see, for example, FIG. 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 several options. In some embodiments, the user may start with a blank or near blank template. In the flow chart of the embodiment shown in FIG. 21, the user may also select to copy information about an existing care group to expedite the process. If the user selects to copy an existing care group, the user proceeds to step 2374. In step 2374, the user specifies the existing care group they want to copy and copies the care group. Then, in step 2376, the user can change the care group type by changing the care group type to the new care group type. In some embodiments, the user can also adjust the care group settings in step 2376.

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

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

[0227] At step 2384, the user may define various care group parameters for the new care group. This may involve changing default values, filling in empty templates, modifying copied values, etc. A non-limiting list of possible care group parameters in certain embodiments of the present disclosure is provided in Table 5 below.

[0228] [Table 5]

[0229] Once the care group parameters have been specified, the user may save the new values ​​in step 2386. The care group and parameter values ​​may be saved in the DERS editor database. The user may then, in step 2388, notify the new care group that it is ready for review by those responsible for reviewing the care group. The DERS editor service may then, in step 2390, notify the appropriate users that the care group has been created and is ready for review. This may be done with an automatically generated email.

[0230] In some embodiments, similar steps may be followed to add, for example, a care area to a DAL file. Although the screens used in the DERS editor user interface may differ, the user may define similar information and parameters for the care area. In some embodiments, some of the care group parameters shown in Table 5 may be defined at the care area level instead or may also be defined at the care area level. The care group parameters may act as parent parameters for the care area. For example, the care group parameters may be default settings for the same parameters at the care area level. Additionally, when defining a care group, the user may create a list of medications that may be used within the care group. This may be accomplished by following steps similar to those shown and described in connection with FIG. 18.

[0231] FIG. 22 shows a flowchart detailing some exemplary steps that may be used in adding a care area to an institution or organization. As described above in connection with FIGS. 11a-11b, an organization or institution may be divided into several subareas or groups that reflect, for example, departments within the organization or institution. The steps shown in FIG. 22 may be part of the DERS setup 122 (see, for example, FIG. 9) stage. In step 390, the user navigates to a care area list 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 several options. In some embodiments, the user may start with a blank or near blank template. In the flowchart of the embodiment shown in FIG. 22, the user may also select to copy information about an existing care area to expedite the process. If the user selects to copy an existing care area, the user may proceed to step 394. In step 394, the user specifies the existing care area that they want to copy and copies the care area. The user may then change the care area type by changing the care area type to the new care area type in step 398. In some embodiments, the user may also adjust the care area settings in step 398.

[0232] If the user chooses not to copy an existing care area or if there is no existing care area, 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 the care area from a list of possible care area types. A non-limiting list of possible care areas in certain embodiments of the present disclosure is shown in Table 6 below.

[0233] [Table 6] TIFF2024109862000012.tif176150

[0234] The user may proceed to step 400 from step 396 or step 398. In step 400, the user may change the name of the care area to match 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 will belong. In step 402, the user may specify various users to be associated with the newly created care area. For example, the user may specify several clinicians who work in or are responsible for the care area. The user may also specify other individuals within the institution or organization who may be responsible for overseeing or contributing to the new care area.

[0235] At step 404, the user can define various care area parameters for the new care area. This can involve changing default values, filling empty templates, changing copied values, etc. In some embodiments, parent parameter values, i.e. values ​​defined for the same parameter at the care group level, can be automatically used as default values ​​for child parameters at the care area level. A non-limiting list of possible care area parameters in certain embodiments of the present disclosure is provided in Table 7 below.

[0236] [Table 7] TIFF2024109862000014.tif130150

[0237] Once the care area parameters are specified, the user may save the new values ​​in step 406. The care area and parameter values ​​may be saved in the DERS editor database. The user may then, in step 408, notify the new care area that it is ready for inspection by those responsible for inspecting the care area. The DERS editor service may then, in step 410, notify the appropriate users that the care area has been created and is ready for inspection. This may be done via an automatically generated email.

[0238] 23, a flow chart is shown detailing some exemplary steps that may be used in validating a care area. Similar steps may be appropriate for validating a care group. These steps may need to be performed by all designated reviewers before a DAL file containing that care area can be published. In some embodiments, these steps may define one of many processes that must be completed before a DAL file is published. These steps may be performed in some embodiments as part of the Review 121 stage of FIG. 9, or the Validate by Care Area substep 216, Review by Care Area substep 222, Review between Care Areas substep 224, and / or Review by Care Area substep 226 of FIG. 10. The steps shown in FIG. 23 may be performed by one or more parties. For example, the steps may be performed by the Director of Nursing 7, Pharmacist 8, Director of Risk Management 6, and / or Medical Technician 19 of FIG. 1. These steps may be performed by the Resource Clinician 202, Review Pharmacist 204, Pharmacy Consultant 206, and / or Clinical Consultant 208 of FIG. 10. The steps shown in Figure 23 can be completed in the DERS editor user interface, which can be accessed through a suitable internet browser.

[0239] At step 420, the reviewing user may navigate to a care area list. In some embodiments, the DERS editor may then prompt the reviewing user to select a care area from a list at step 421. At step 422, the reviewing user may select a care area that they would like to review or are responsible for reviewing. In some embodiments, the reviewing user may be responsible for reviewing all items, elements, parameters, etc. of a care area. In some embodiments, the reviewing user may be responsible for only a portion of the items, elements, parameters, etc. of a care area. At step 424, the reviewing user may review elements of the care area.

[0240] In some embodiments, the reviewing user may be required to enter comments for all items, elements, or parameters in a care area when reviewing the care area. In the exemplary flow chart shown in Figure 23, as the reviewing user reviews various parameters of a care group, the reviewing user is required to approve or enter comments for the items, elements, parameters, etc. If the reviewing user does not have concerns or questions regarding an element, at step 425 the user may indicate that the element has been verified.

[0241] If the reviewing user does not approve of the item, element, parameter, etc. for the care area or has other comments / feedback / questions, the user may proceed from step 424 to step 426. In step 426, the reviewing user may enter a comment, question, or provide feedback regarding a particular item, element, parameter, etc. for the care area. As a hypothetical example, if the parameter for the upper absolute limit for patient weight in the neonatal intensive care unit is specified as 70 kg, the reviewer may enter the comment "This limit seems very high. Perhaps there was a typo that added a zero to the entry. Maybe it should be lowered?" In some embodiments, some comments may also include requests for changes that may be granted or denied. Any comments, questions, or feedback may be attached to the parameter so that other users or parties can view and potentially act on the comments and feedback. In some embodiments, the reviewing user may include various attachments, links, photos, CQI data, etc. in the comment.

[0242] Once the reviewing user has verified or commented on the items, elements, parameters, etc., the user may return to step 424 if there are more items, elements, parameters, etc. to review. If nothing remains in the care area requiring review, the reviewing user may choose to provide general feedback about the care area. In step 428, the user may provide general feedback or comments about the entire care area. The comments, questions, and / or feedback provided in step 428 may be tied to the care area so that other users may view and potentially act on the comments and feedback. Once the reviewing user has provided all the general comments and feedback they wish to provide, the reviewing user may indicate completion of the review in step 429. The various comments, questions, feedback, etc. may be saved in the DERS editor database.

[0243] Once the user indicates that they are done reviewing the care area, the DERS editor service may send a notification in step 430 that the user is done reviewing the care area. This notification may be sent to other users or parties and may take the form of an automatically generated email message. The message may be sent to a drug library administrator, such as, for example, drug library administrator 200 shown in FIG. 10. In some embodiments, the DAL file containing the care area may not be made public until at least one party or user has responded to all comments, questions, and feedback provided in steps 426 and 428.

[0244] FIG. 24 illustrates a flow chart detailing several exemplary steps that may be used to update a care area. Specifically, the exemplary flow chart of FIG. 24 details several steps that may be used to update a care area after it has been reviewed. The review process may be similar to the process described and illustrated in connection with FIG. 23. The steps illustrated in the exemplary flow chart of FIG. 24 may be part of the edit and revise sub-step 220 illustrated in FIG. 10. The steps illustrated in FIG. 24 may be performed by a user, such as a drug library administrator. Steps similar to FIG. 24 may also be used to update a care group.

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

[0246] If the reviewing user has a question regarding a care area or a parameter within the care area, the user may proceed to step 446. At step 446, the user may enter an answer to the question. This answer may then be made available to the original reviewing user. In some embodiments, after the user provides an answer at step 446, the DERS editor service may notify the reviewing user who asked the question that their answer is now available. This notification may be sent as part of step 448. In some embodiments, the reviewing user may be able to respond to the answer if necessary, or may need to communicate that a satisfactory answer has been provided.

[0247] If the reviewer has entered comments, questions, or feedback that are not easily understood or that should be further discussed, the user may proceed to step 450. At step 450, the user may enter a question regarding the reviewer's original entry, which may then be made available for the original reviewer to view and respond to. In some embodiments, after the user enters a question at step 450, the DERS editor service may notify the reviewer that a question has been entered regarding the reviewer's comment, question, or feedback. This notification may be sent as part of step 452.

[0248] If the reviewing user has entered comments, questions, or feedback that includes a request to change a parameter of the care area, the user may accept or reject the change request. If the change is accepted, the user may proceed to step 454 and modify the parameter of the care area according to the change request. If the user decides to reject the change request submitted by the reviewing user, the user may reject the request at step 456. In some embodiments, the user may accept or reject the change request by interfacing with one or more virtual buttons included as part of the change request on the DERS editor user interface. In such embodiments, accepting the change request may automatically modify the parameter in question for the care area.

[0249] If the reviewing user enters a comment or feedback that does not include a request for change, does not raise a question, and does not require a response, the user may be prompted to mark the comment or feedback as "read" in step 458.

[0250] Once the comment, question, or feedback has been addressed, the DERS editor service may update the DERS review status information in step 459. The user may then review other comments, questions, and feedback until all comments, questions, and feedback from the reviewing user have been addressed. Once all comments, questions, and feedback have been addressed, the user may proceed to step 460. In step 460, the user may indicate that they are finished updating the care area. The updates may be saved, after which the user may log out of the DERS editor in step 462.

[0251] At step 464, the DERS editor service can notify all interested users that the care area has been updated and is ready for revalidation. This notification can consist of an automatically generated email message in some embodiments. The revalidation process can be similar to the process described and illustrated in connection with FIG.

[0252] Referring now to FIG. 25, a flow chart is shown detailing several exemplary steps that may be used to add a drug record or medication record to a specified care area. The terms "drug record" and "medication record" are used interchangeably herein. These drug records may define the medications that may be used within a care area and various restrictions, characteristics, etc. that may apply to the medication. The exemplary steps shown in the flow chart of FIG. 25 may be performed as part of the drug selection and record specification sub-step 214 shown in FIG. 10. In some embodiments, the steps of FIG. 25 may be performed by a drug library administrator, such as the drug library administrator 200 shown in FIG. 10. In other embodiments, another party, such as a pharmacist or other party, may be responsible for adding drug records to a care area. In some embodiments, similar steps may be used to add drug records to a care group.

[0253] At step 470, a user may navigate to a list of care areas on the DERS editor user interface. Then, at step 471, the user may select a care area to which to add a drug record. In some embodiments, parameters for a care area may need to be predefined and validated before a drug record can be added to that care area. In such embodiments, parameter definition and validation may be accomplished by performing steps similar to those shown and described in connection with FIGS. 22-24.

[0254] Once the user is ready to add a drug record to the care area, the user may decide to add a specific drug or may choose to add an unspecified drug. If the user chooses to add a specific drug, the user may copy a medication record from an existing group (step 474) or define the medication and create a medication record for the care area (step 476). If the user chooses to copy a medication record, the user may proceed to step 474. At step 474, the user may copy a medication record for the desired medication from an existing care area. In some embodiments, this may involve selecting the medication record from a list of medication records displayed in the DERS user interface. In some embodiments and circumstances, the user may be able to copy medication records from a different institution. This may be the case, particularly if the institution is part of an IDN, for example.

[0255] Copying a medication record may copy all of the rule sets and concentration records corresponding to that medication. In some embodiments, the user may choose not to copy some or all of the rule sets and / or concentration records when copying a medication record to a new care area. After copying a medication record, the user may repeat step 474 for as many records as desired or perform step 476 to add additional medication records. After copying a medication record, if there are no more medications to add to the care area, the user may proceed to step 486, which is described later in this specification. In some embodiments, a step may be included that allows the user to make adjustments and changes to the copied care area.

[0256] Step 476 can be performed if the user wishes to create a medication record without copying a record from another care area. This step allows the user to define the name of the medication for which the medication record is being created. In some embodiments, the user can select the name of the medication from a master list of medications. Such a list may be provided by a DERS editor service or may be created within the institution or organization. A non-limiting list of possible medication record parameters for certain embodiments of the present disclosure is provided in Table 8 below.

[0257] [Table 8]

[0258] After defining the medication record with the medication name and various medication parameters, the user may be required to define one or more rule sets for each medication record. Each rule set may be provided in some embodiments corresponding to a particular clinical use of the drug or medication. Rule set and clinical use are used interchangeably herein. A medication may, for example, have a rule set that governs how it should be delivered when delivered as a weight-based infusion and another rule set that governs how it should be delivered when delivered as an intermittent infusion. A non-limiting list of other possible clinical uses may include non-weight-based infusion, body surface area (BSA)-based infusion, continuous infusion, etc.

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

[0260] When copying a set of rules, all concentration records corresponding to that set of rules may also be copied. In some embodiments, the user may choose not to copy certain concentration records or all concentration records when copying a set of rules. After copying a set of rules, the user may repeat step 478 for as many sets of rules as desired or perform step 480 to add additional sets of rules. If, after copying a set of rules, there are no more medication records or sets of rules to add to the care area, the user may proceed to step 486. Step 486 is described later in this specification. Some embodiments may include a step that allows a user to edit or modify the copied set of rules.

[0261] Step 480 can be performed by the user if the user wishes to create a rule set for the medication record without copying an existing rule set. This step allows the user to create a rule set and define parameters for the rule set. In some embodiments, depending on the type of rule set being created, the user may be required to define different parameters. A non-limiting list of possible rule set parameters for certain embodiments of the present disclosure is provided in Table 9 below.

[0262] [Table 9] TIFF2024109862000017.tif156148 TIFF2024109862000018.tif135155 TIFF2024109862000019.tif130155

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

[0264] If the user selects to copy a concentration record, the user may proceed to step 482. In step 482, the user may select a concentration record to copy from an existing rule set. After copying a concentration record, the user may repeat step 482 for as many concentration records as needed or perform step 484 to add additional concentration records. After copying a concentration record, if there are no more medication records, rule sets, or concentration records to add to the care area, the user may proceed to step 486, which is described later in this specification. In some embodiments, additional steps may be included that allow the user to modify or adjust the copied concentration record.

[0265] Step 484 can be performed by the user if the user wishes to create a concentration record for a rule set without copying an existing concentration record. This step allows the user to create a concentration record and define the parameters for that concentration record. A non-limiting list of possible concentration record parameters in certain embodiments of the present disclosure is shown in Table 10 below.

[0266] [Table 10] TIFF2024109862000021.tif156148 TIFF2024109862000022.tif135155 TIFF2024109862000023.tif135161

[0267] Upon completing step 484, the user may add more concentration records to a rule set, more rule sets to a medication record, or more medication records to a care area. After completing step 484, if there are no more medication records, rule sets, or concentration records to add to the care area, the user may proceed to step 486, which is described later in this specification. In some embodiments, the various parameters defined in Tables 8-10 may be defined at a different hierarchical level of the DAL file than the levels shown here. For example, some of the values ​​defined at the rule set level may be defined at the medication record level in some embodiments.

[0268] As mentioned above, in some embodiments, the user may also choose to add medication records for non-specified medications. Such records may function as wildcards or quasi-wildcards. That is, such medication records may define broad parameters governing the use of any number of non-specified medications. Such records may, for example, allow the user to run an infusion pump in volume per duration mode without being constrained by any limits, etc., defined by the user in the DERS editor. Medication records for non-specified medications may allow caregivers to initiate treatment more quickly in emergency situations. They may also be useful when a medication needs to be used that is not on the medication list for a care area (e.g., when using experimental or investigational medications). Such medication records may be useful in special cases where the limits defined in the DERS may not be appropriate for the situation. For example, if an extremely overweight patient requires an infusion, the limits defined via the DERS editor may not allow for a clinically effective infusion to be administered. In that case, the user may use medication records for non-specified medications to circumvent the limits to administer an infusion that may have the desired effect.

[0269] As noted above, such medication records may also be configured as quasi-wildcards. For example, medication records for unspecified medications may be configured to be given a parameter that may define the category or subcategory of the medication. Drug categories may include, but are not limited to, blood products, investigational medications, IV fluids, medications, etc. This may be useful to provide more flexibility when needed while still applying some of the safeguards that may be created in the DERS editor. In some embodiments, when a user selects medication records for some or all of the unspecified medications, the user may be prompted to enter text explaining the medication to be used and the reason for using the medication record corresponding to the unspecified medication to deliver the medication.

[0270] When adding a medication record for a non-specified medication, the user can either copy a non-specified medication from another care area (step 472) or create a new non-specified medication (step 473). If the user decides to copy a medication record for a non-specified medication, the user can select and copy the desired record by performing step 472. If the user wants to create a medication record for a non-specified medication, the user can create the medication record and its various parameters in step 473. In some embodiments, the user may be able to define desired parameters for the non-specified medication. Such parameters may include some or all of the parameters contained in Tables 7-9. The user can then tailor the medication record for the non-specified medication to be as broad or narrow as desired. If the user wants to add more medications to the care area list after completing step 472 or step 473, they can do so as described above.

[0271] Once the user is finished adding to or creating the care area medication list, the user may proceed to step 486. At step 486, the user acknowledges that the care area medication list is now available for review by the appropriate review user and logs out. At step 488, the DERS editor service may notify the appropriate review user that the care area medication list is now available 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 to the DERS database.

[0272] FIG. 26 illustrates a flow chart detailing some exemplary steps that may be used in reviewing a medication list for a particular care area. Similar steps may also be used to review a medication list for a care group. A medication list may be created by following similar steps as described in FIG. 25. The exemplary steps illustrated in the flow chart of FIG. 26 may be part of the review 121 stage illustrated and described in connection with FIG. 9. The steps illustrated in FIG. 26 may be part of the verify by care area substep 216, the review by care area substep 222, the review between care areas substep 224, and / or the review of care areas substep 226 illustrated and described in connection with FIG. 10. The exemplary steps illustrated in the flow chart of FIG. 26 may be performed by at least one reviewing user. The reviewing user may be, for example, the nursing director 7, the pharmacist 8, the risk manager 6, and / or the medical technician 19 of FIG. 1. The reviewing user may be, for example, the resource clinician 202, the reviewing pharmacist 204, the pharmacy consultant 206, and / or the clinical consultant 208 of FIG. 10.

[0273] At step 490, the reviewing user may navigate to a care area list on the DERS editor user interface. Then, at step 492, the reviewing user may select a care area with a medication list to review. At step 494, the reviewing user may review an item or parameter in the medication list. In some embodiments, the items and parameters that the user is asked to review may be displayed to the user on the DERS editor user interface as a work list, window, widget, etc. In some embodiments, the user may not need to navigate to a care area list to review the medication list. In some embodiments, the reviewing user may review the medication list items via a medical device simulator on the DERS editor user interface. Such a medical device simulator may simulate what a medication list looks like when used with a particular medical device. The user may navigate to a review screen or a drug screen in some embodiments to review the medication list.

[0274] Once an item has been reviewed, the reviewing user may enter comments or verify that the item appears to be correct and does not require any changes. If the reviewing user decides to comment on the item, the reviewing user may proceed to step 495 and provide any comments of their choice. If the reviewing user decides to review the item, the reviewing user may proceed to step 496 and indicate that the item has been reviewed. Upon completing step 495 or step 496 for an item, the DERS editor service may update the review status of that care area and / or item on the DERS database in step 498. The reviewing user may then return to step 494 if there are more items that need to be reviewed. This may be repeated until all items and parameters on the medication list have been reviewed.

[0275] Once there are no more items or parameters in the medication list that need to be reviewed, 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 review. In step 500, the reviewing user may review, supplement, or refine the comments that he or she made. If the reviewing user has any general comments regarding the medication list or medication list elements, the reviewing user may enter such comments in step 502. If the reviewing user does not have any general comments regarding the medication list or medication list elements, or has already entered all such comments, the reviewing user may indicate that the review is complete in step 504. The reviewing user may then log out of the DERS editor in step 506. In step 508, the DERS editor service may notify another user, such as a drug library administrator, that the reviewing user has completed reviewing the medication list.

[0276] Referring now to FIG. 27, a flow chart is shown detailing several exemplary steps that may be used to update a medication list. The steps shown in FIG. 27 may be performed after reviewing the medication list for a particular care area. Similar steps may also be used to update a care group. Reviewing the medication list may be performed utilizing the steps detailed in FIG. 26. The steps shown in the exemplary flow chart of FIG. 27 may be part of the editing and revising sub-step 220 shown in FIG. 10. The steps shown in FIG. 27 may be performed by a user, such as a drug library administrator. In some embodiments, one or more users may collaborate to update the medication list. For example, a drug library administrator may work with a pharmacist to update the medication list.

[0277] At step 510, the user may navigate to a care area list on the DERS editor user interface, which in some embodiments may be accessed via a suitable web browser. The user may then select a care area with a medication list that the user wishes to revise at step 512. In some embodiments, the user may update the medication list using a review screen, a medication screen, etc., of the DERS editor user interface without having to select a care area. At step 514, the user reviews comments, questions, or feedback regarding the medication list or items or parameters in the medication list. The user may take several actions on each comment, question, or feedback provided.

[0278] If the reviewing user has a question about the medication list or a parameter in the medication list, the user may proceed to step 516. At step 516, the user may enter an answer to the question, which may then be made available to the original reviewing user. In some embodiments, after the user provides an answer at step 516, the DERS editor service may notify the reviewing user who asked the question that the answer is now available. This notification may be sent as part of step 518. In some embodiments, the reviewing user may be able to respond to the answer if desired, or may be requested to indicate that a satisfactory answer has been provided.

[0279] If the reviewer has entered a comment, question, or feedback that is not easily understood or that should be further discussed, the user may proceed to step 520. In step 520, the user may enter a question regarding the reviewer's original entry, which may then be made available for the original reviewer to see and respond to. In some embodiments, after the user enters the question in step 520, the DERS editor service may notify the reviewer that a question regarding the reviewer's comment, question, or feedback has been entered. This notification may be sent as part of step 522. In some embodiments, the user may enter a response or question using the same field. In such embodiments, the notification sent in step 518 or step 522 may simply be an indication that a response has been submitted.

[0280] If the reviewing user enters a comment, question, or feedback that includes a request to change an item or parameter of the medication list, the user may either accept or reject the change request. If the user accepts the change, the user may proceed to step 524 and modify the medication list item or parameter according to the change request. If the user decides to reject the change request made by the reviewing user, the user may reject the request at step 526. In some embodiments, the user may accept or reject the change request by interfacing with one or more virtual buttons included as part of the change request on the DERS editor user interface. In such embodiments, accepting the change request may automatically modify the item or parameter of the medication list.

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

[0282] Once a comment, question, or feedback has been addressed, the user may review other comments, questions, and feedback until all comments, questions, and feedback from the reviewing user have been addressed. Once all comments, questions, and feedback have been addressed, the user may proceed to step 530. At step 530, the user may indicate that they are finished updating the medication list. The updates may be saved to the DERS database, after which at step 532 the user may log out of the DERS editor.

[0283] At step 534, the DERS editor service may notify all affected users that the medication list has been updated and is ready for revalidation. This notification may consist of an automatically generated email message in some embodiments. Notification may be sent to all reviewing users who originally reviewed the medication list. The revalidation process may be similar to the process described and illustrated in connection with FIG. 26. In some embodiments, the revalidation process may be similar to the process detailed in FIG. 28.

[0284] Figure 28 shows a flowchart detailing several exemplary steps that may be used to review a medication list. The exemplary steps shown in the flowchart of Figure 28 may be performed by at least one reviewing user. The reviewing user may be, for example, the nursing director 7, the pharmacist 8, the risk manager 6, and / or the medical technician 19 of Figure 1. The reviewing user may be, for example, the resource clinician 202, the reviewing pharmacist 204, the pharmacy consultant 206, and / or the clinical consultant 208 of Figure 10.

[0285] At step 540, the reviewing user may navigate to a care area list on the DERS editor user interface. Then, at step 542, the reviewing user may select a care area with a medication list to review. In some embodiments, the review does not have to be performed by navigating to a care area list. In some embodiments, the user may review entries from, for example, a review screen, a work list widget, or a drug list screen of the DERS user interface. At step 543, a list of items requiring review may be displayed by the DERS editor service on the DERS editor user interface. In some embodiments, the user may apply a filter on 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 modified or have comments by selecting them from the list. In some embodiments, the reviewing user may review medication list items 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 with a particular medical device.

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

[0287] After reviewing an item, the reviewing user may enter a comment or verify that the item or parameter appears to be correct 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 desired comments. If the reviewing user decides to verify the item, the reviewing user may proceed to step 547 and indicate that the item has been verified. Upon completing step 546 or step 547 for an item, the DERS editor service may update the review status for that medication list in step 548. The reviewing user may then return to step 544 if there are more items or parameters that require review. This may be repeated until all items and parameters for the medication list have been reviewed.

[0288] Once there are no more items or parameters in the medication list that require review, the reviewing user may proceed to step 550. At step 550, the reviewing user may indicate that the review is complete. Then, at step 552, the reviewing user may log out of the DERS editor. At step 554, the DERS editor service may notify another user, such as a drug library administrator, that the reviewing user has completed reviewing the medication list. If there are still issues, questions, feedback, and / or comments that have not been resolved, the user may update the subject medication list again and revalidate the medication list. This may be done until all users agree with the medication list and no questions remain regarding the medication list. The list may be updated again by following steps similar to those illustrated and described in connection with FIG. 27.

[0289] FIG. 29 illustrates a flowchart detailing several exemplary steps that may be used in submitting a DAL file for approval. These steps may be performed after the DAL file has been created / updated and has undergone various review and validation processes as described above. In some embodiments, these steps may be performed after a trial run of the DAL file has been performed. The exemplary steps illustrated in the flowchart of FIG. 29 may be performed by a user or party, such as a drug library administrator or other party.

[0290] At step 560, the user verifies that all care areas, drug records, other items, etc. created / updated in the DERS editor have been verified by the user responsible for verifying and reviewing them. Once all care areas, drug records, other items, etc. have been verified, the user may notify at step 562 that the created / updated DAL file is ready for approval by a party responsible for approving the DAL file for release, which in some embodiments may be an official at the institution or organization. Once the user has completed step 562, the DERS editor service may notify at step 564 a party responsible for approving the DAL file for release that the DAL file is ready for approval. The user may then log out of the DERS editor service at step 566.

[0291] Based on procedures defined by various institutions or organizations, various individuals responsible for approving DAL files for release may review and approve the created / updated DAL file. In some embodiments, such procedures may include procedures similar to the review and validation process described above. Once the DAL file is approved, the DAL file may be put into a state for release by following several steps as illustrated in the exemplary flow chart of FIG. 30. As illustrated in FIG. 30, a user, such as a drug library administrator, may 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 may proceed to step 582 and log into the DERS editor service. Then, in step 584, the user may verify that all individuals responsible for approving the DAL file have indeed approved the DAL file. In step 586, the user may be notified that the DAL file is now ready for release to various medical devices within the institution or organization.

[0292] Referring now to FIG. 31a, a flow chart is shown detailing some exemplary steps that may be used to place the DAL file on various system components. The steps shown in FIG. 31a may be performed after the DAL file has been approved and signaled as ready for release through a process similar to that described in connection with FIGS. 29-30. The various components include, among others, the CQI server 109 of FIG. 4, the device gateway 99 of FIG. 4, and any number of medical devices, such as the device 26 of FIG. 1. The steps shown in FIG. 31a may be performed by any number of users or parties. In some particular embodiments, the steps shown in FIG. 31a may be performed by a user, such as the facility IT 18 of FIG. 1, the medical technician 19, or the medical technician 102 of FIG. 4. The transmission of the DAL file may be performed over a secure connection. In some embodiments, the DAL file may be transmitted utilizing a secure socket layer (SSL) connection, among others.

[0293] The exemplary flow chart shown in FIG. 31a begins at step 590 with the DERS editor service notifying the CQI user that the DAL file has been published and is ready to be deployed. At step 592, the CQI user receives the notification generated at step 590. The CQI user can then log on to the CQI application at step 594. The CQI application can be accessed by the user without the need for client-side software. This can be accomplished, for example, via a suitable web browser. The CQI user can then use the CQI application to deploy the DAL file to the CQI service at step 596. In some instances, the CQI user is a medical technician.

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

[0295] A user may choose to deploy the DAL to various medical devices in several ways. In the exemplary embodiment shown in FIG. 31a, the user may deploy the DAL using the device gateway or manually. If the user decides to deploy the DAL file using the device gateway, the DAL file may be deployed remotely to the medical device at step 612. The user may manually deploy the DAL file by proceeding to step 614. Manual deployment may be desirable or necessary in some situations. For example, manual deployment may be necessary in a disconnected environment. At step 614, the user may log into the DERS editor service. The user may then use the DERS editor service to load the DAL to a local storage device at step 616 for manual deployment to the medical device. The local storage device may be a USB memory stick, an external or portable hard drive, etc. At step 618, the user may manually deploy the DAL file to 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.

[0296] FIG. 31b shows an exemplary flow chart detailing several steps that may be used to package and stage a resource for publication to a facility gateway. Such a resource is a DAL in some embodiments. At step 4700, a user may select a resource they wish to publish. The resource may then be signed at step 4702 using a cryptographic algorithm. At step 4704, a hash of the file may be taken. In some embodiments, additional packing steps may be included. For example, in some embodiments, a compression step may also be included. In some embodiments, an encryption step may be included. The packing step used depends on the type of file being published.

[0297] In step 4706, a stage location for the hash may be determined, which in some embodiments is a location on a database. The signed hash may then be copied to the stage location in step 4708. The original signed hash file may then be saved to an archive location in step 4710. This archive location, in some embodiments, is a database or other file system. At step 4712, a notification message may be generated to a facility data exchange that is sent to each facility gateway that is to be notified of the resource availability. The notification may include information such as the type of file, a hash of the file, a unique identifier for the file, and an identifier for the facility gateway. At step 4714, the notification message may be posted to the facility data exchange. The notification message may then be sent to the intended recipient facility gateways.

[0298] FIG. 31c shows a flow chart detailing some exemplary steps that may be used to track the disposition of various resources. Such resources include DAL files and any number of other resources. These steps may be performed on a user interface, which in some embodiments is a DERS editor user interface. In step 4730, the user selects a particular resource for which they wish to track the disposition. The resource may be selected from a list of trackable resources stored in memory associated with the device manager. In step 4732, the device manager of the hosted environment may then query the database for versions of the selected resource at each institution. In some embodiments, the database may only be able to query information for the institution with which the user is associated. In step 4734, the device manager may then display a list of institutions detailing the last version of the resource that was downloaded at each institution. If the user wishes to know more information about the disposition of resource versions at an institution, the user may select the desired institution from the list in step 4736. In step 4738, the device manager may query the database to determine how many of each resource version have been deployed at the selected institution. In step 4740, a list of the versions deployed at the selected institution and the quantity of the versions may be displayed.

[0299] Once created and deployed, it may become necessary or desirable to update the DAL file. During use, it may become apparent that some of the DAL file's limit constraints, particularly those governing the delivery of certain medications, are too restrictive. For example, if nurses in a care area find that they frequently have to select medication records for unspecified medications in order to deliver a particular medication in a therapeutically effective manner, one or more nurses may be able to request changes to the limits for a particular medication or care area. Changes to the DAL file may also be required when hospital policy changes are made, new medications come onto the market, and the like. FIG. 32 shows a flowchart detailing some exemplary steps that may be used to update an existing DAL file.

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

[0301] At step 628, the reviewing user may select a particular medication record in the care area for which an update request is to be entered. If the reviewing user wishes to enter a general update request for a medication record, they may do so at step 630. The user may also make an update request for parameter values ​​defined in the medication record at this step. If the reviewing user wishes to be more specific with the update request, they may proceed to step 632. At step 632, the user may select a rule set for the medication record for which the update request is to be submitted. If the reviewing user wishes to make an update request for a rule set in general, they may enter an update request at step 634. The user may also submit an update request for parameters defined at the rule set level at step 634. If the reviewing user wishes to enter a more specific update request, they may proceed to step 636. At step 636, the reviewing user may select a particular concentration record from the rule set for which an update request is to be created. At step 638, the reviewing user may enter an update request for that concentration record. The update request may be entered into an update request field displayed in the DERS editor user interface.

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

[0303] In some embodiments, the user performing the review may select an element, item, parameter, etc. (e.g., a care area) in the DAL file prior to performing step 620. This may be done by navigating to the desired DAL entry using the DERS editor user interface. Once the user has navigated to the desired entry, the user may indicate that they wish to enter an update request in step 620. This may cause an update request field to be displayed in which the user may enter the update request. The user may then enter and submit an update request for that item in step 640.

[0304] FIG. 33 illustrates a flow chart detailing several exemplary steps that may be used to update an institution's / organization's drug list. This may be necessary as new drugs come onto the market or generic versions of existing drugs become available. It may also be necessary if an institution / organization expands and adds care areas that use drugs that were not previously required for the institution. Updating a drug list may also add experimental or investigational drugs to an institution's / organization's drug list. The steps illustrated in FIG. 33 may be performed by a drug library administrator and / or a pharmacist. In some embodiments, these steps may also be performed by other users.

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

[0306] Figure 34 shows a flow chart detailing several exemplary steps that may be used to update a clinical advisory list. The exemplary steps shown in Figure 34 may be performed by a drug library administrator, a pharmacist, or other user. In step 660, a user navigates to a clinical advisory list on a DERS editor. In step 662, the DERS editor service may then display the institution's / organization's clinical advisory list. In the exemplary embodiment shown in Figure 34, a user may update an existing list by adding clinical advisories to the list or by modifying clinical advisories currently in the list. In step 664, a user may add clinical advisories to the list. In step 666, a user may update clinical advisories in the list.

[0307] Once an update to the clinical advisory list has been made, the user may make further updates to the list, if desired, by returning to the clinical advisory list displayed in step 662. Once the user is finished updating the institution / organization's clinical advisory list, the user may proceed to step 672. In step 672, the user may indicate that the clinical advisory list should be saved and log out of the DERS editor. The DERS editor service may then save the updates to a database in step 674. The database may be the DERS editor database. In step 676, the DERS editor service may notify the user responsible for creating the medication list for the care area that the institution / organization's clinical advisory list has been updated.

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

[0309] Referring now to FIG. 35, a flow chart is shown detailing several exemplary steps that may be used to update the institution / organization general settings. These steps may be performed by a drug library administrator in some embodiments. At step 680, the user may navigate to the general settings on the DERS editor. The DERS editor service may then display the general settings at step 682. At step 684, the user may update the general settings as needed. At step 686, the user may indicate that they are done updating the general settings and wish to save. At step 687, the DERS editor service may save the institution / organization general settings in the DERS editor database. At step 688, the DERS editor service may notify the appropriate user that the general settings have been changed.

[0310] FIG. 36 shows a flow chart detailing some exemplary steps that may be used to update a care area. In some embodiments, care groups may also be updated using steps similar to those shown in FIG. 36. In step 690, a user may navigate to a list of care areas. In step 692, the user selects a care area that the user would like to update. The user may then be able to select to update certain aspects of that care area. The user may update the list or group of users that have administrative permissions for a particular care area. This may be done in step 694. In particular, administrative permissions for a care area may give the user the ability to edit the entries and parameters of that care area. The user may also choose to update the list or group of users that are reviewing users for that care area. This may be done in step 696. The user may also change the entries or parameters of the care area in step 698.

[0311] Once updates are made, the user may return to step 692 to make further updates if desired. When the user is finished with the updates, the updated care area may be saved to the DERS database in step 700. The DERS editor service may then notify the appropriate user that the care area has been updated in step 702. If desired, the DERS editor service may notify the appropriate user that the care area is ready for review. In some embodiments, the review and validation process for updating a care area may be the same or similar to the process described above with respect to Figures 23 and 24.

[0312] FIG. 37 illustrates a flow chart 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. Such updates may be made in response to various update requests submitted by reviewing users. An update request may be submitted, for example, by following steps similar to those illustrated and described with respect to FIG. 32. Such updates may also be made when a new medication needs to be added to a medication list for a care area. Medication records for a care area may also be updated when analysis of medical device CQI data using the DAL file indicates that a value for one or more medication records in the DAL file may not be appropriate.

[0313] At step 710, the user may navigate to a care area list on the DERS editor. The DERS editor service, in some embodiments, may then prompt the user to select a care area from a list of displayed care areas at step 712. The user may then select the care area they wish to update at step 714. In some embodiments, the user does not need to navigate to a care area list to update a medication record. For example, the user may navigate to a drug list, or review screen, etc. on the DERS user interface and update the entry.

[0314] A user may be able to update a medication record for a care area in a number of ways. In FIG. 37, a user may add a medication record to a care area by performing step 716. Step 716 may be performed by following a number of steps, such as those illustrated and described in connection with FIG. 25. A user may also update a medication record for a care area. To do so, an existing medication record for the care area may be selected in step 718. The user may then modify the medication record, the set of rules for the medication record, and / or the concentration record for the medication record in step 720.

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

Claims

1. configured to create, review, and / or edit a drug library; establishing a set of privileges for allocating a certain degree of software functionality with respect to said drug library; A medical error reduction system comprising medical error reduction software.

2. further comprising a server configured to execute said software; The system of claim 1 .

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

4. the drug library configured for use with a medical device; The system of claim 1 .

5. said degree of software functionality configured to define a capability to modify said drug library; The system of claim 1 .

6. The drug library is organized into a hierarchy; The system of claim 1 .

7. The hierarchy includes care areas subordinate to care groups; The system of claim 6.

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

9. the drug library comprising entries corresponding to medications; The system of claim 1 .

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

11. the drug library includes programming limits for medical devices; The system of claim 1 .

12. the software configured to provide quality improvement information; The system of claim 1 .

13. The set of privileges allows for creating, reviewing, and / or editing a drug library; The system of claim 1 .

14. The set of privileges allows for creating, inspecting, and / or editing privilege sets; The system of claim 1 .

15. The set of privileges allows adding and / or removing users; The system of claim 1 .

16. The set of privileges enforces collaborative creation and / or editing of the drug library; The system of claim 1 .

17. an editor computer including a processor configured to communicate with the display and / or user interface over the network in a client / server model; the editor computer and the server are configured to communicate over a network in a client / server model; The system of claim 2.

18. said set of privileges enabling requests for changes to said drug library; The system of claim 1 .

19. said set of privileges allows for approving and / or denying the implementation of requests for changes to said drug library; 20. The system of claim 18.

20. The set of privileges allows for submitting questions regarding the changes; 20. The system of claim 18.

21. said set of privileges allows for proposing revisions to said changes; 20. The system of claim 18.

22. The medical device includes an infusion pump; The system of claim 4.

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

24. Creating a drug library; Designating a Master Drug List; Defining a medication record; verifying said medication record; and configuring a set of privileges to enable authorizing the medication record for release to a medical device; A method for generating a drug library.

25. The specifying includes selecting the medication from a prescription database; 25. The method of claim 24.

26. said defining includes selecting a drug from said master drug list; 25. The method of claim 24.

27. said defining includes defining parameters of said agent; 27. The method of claim 26.

28. said verifying including reviewing said medication record; 25. The method of claim 24.

29. said verifying including editing and / or revising said medication record; 25. The method of claim 24.

30. The verifying includes reviewing the medication record with a user interface of a simulated medical device; 25. The method of claim 24.

31. generating a drug library file, the drug library file including performing a test generation step of the drug library file including testing the drug library file on a test medical device; 25. The method of claim 24.

32. creating a drug library file, the drug library file including testing the drug library on a simulated medical device user interface; 25. The method of claim 24.

33. The software is configured to enable navigation and / or selection from a list of care areas; The system of claim 1 .

34. The privileges are configured to enable navigation and / or selection from a list of care areas; The system of claim 1 .

35. The privileges are configured to be dependent on a care area; The system of claim 1 .

36. The software is configured to limit operation of the medical device; The system of claim 1 .

37. The limiting comprises limiting one or more of an acceptable input range, a treatment regimen, and a medical device limit; 37. The system of claim 36.

38. The privileges are configured to limit operation of the medical device; The system of claim 1 .

39. The limiting comprises limiting one or more of an acceptable input range, a treatment method, and a medical device limit; 39. The system of claim 38.

40. The software is configured to display, enter, and / or edit comments associated with records in the drug library; The system of claim 1 .

41. The privileges are configured to enable viewing, entering, and / or editing comments associated with records in the drug library; The system of claim 1 .

42. The software is configured to inform a user of the creation, review, and / or editing; The system of claim 1 .

43. The privileges are configured to allow a user to be informed of the creation, inspection, and / or editing; The system of claim 1 .

Images