COMPUTER-IMPLEMENTED METHOD, SYSTEM, AND APPARATUS FOR ELECTRONIC PATIENT CARE - Patent application

Abstract

A medical error reduction system and medical device that reduce the occurrence of errors in medical care are provided. [Solution] System 1 includes facility IT applications / services 11, a facility 10, and cloud services 2. The facility 10, which may be a hospital, clinic, medical facility, outpatient care center, urgent care center, or a combination or group thereof, has a facility gateway 21, through which various medical devices 26 communicate with the facility IT applications / services and / or cloud services. The facility gateway may be implemented in equipment in a patient's home and used by a healthcare facility or infrastructure such as a hospital. The cloud services include an Infusion Safety Manager (ISM) 3 hosted in the cloud. The facility IT applications / services support hospital administrative functions (e.g., admissions, discharges, transfers, coding, billing, collections, etc.).

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. Provisional Patent Application No. 61 / 740,474, filed December 21, 2012. No., name of invention "System, Method, and Apparatus for Communicating Data" (Attorney No. J80, which is incorporated herein by reference in its entirety. is incorporated into. This application is a joint venture of U.S. Patent Application Serial No. 13 / 723,253, filed December 21, 2012. , Title of invention: "System, Method, and Apparatus for Electronic Patient Care", currently US Patent Application Publication No. 2013-0191413 (A 1) (Attorney Docket No. J85), which is a continuation-in-part of U.S. patent application Ser. No. 13 / 723 ,253 claims priority to and the benefit of: U.S. Provisional Patent Application No. 61 / 578,649, filed December 21, 2011, Inventor Name: "System, Method, and Apparatus for Infusing Fluid" (Representative Reference Number J02 ), U.S. Provisional Patent Application No. 61 / 578,658, filed December 21, 2011, Inventor Name of the company: "System, Method, and Apparatus for Estimating Liquid Delivery" (Agent J04), U.S. Provisional Patent Application No. 61 / 578,674, filed December 21, 2011, Inventor Name of "System, Method, and Apparatus for Dispensing Oral Medications" (Agent Serial number J05), No. 61 / 651,322, filed May 24, 2012, of the invention Name: "System, Method, and Apparatus for Electronic Patient Care" (proxy reference number) No. J46), and U.S. Provisional Patent Application No. 61 / 679,117, filed August 3, 2012, entitled "Invention of the Invention" System, Method, and Apparatus for Monitoring, Regulating, or Controlling Flu No. 6,399,633, filed on Dec. 13, 2003, and entitled "Attorney Docket No. J30," each of which is incorporated herein by reference in its entirety. is incorporated into. U.S. Patent Application No. 13 / 723,253 was filed on December 21, 2011. Patent application No. 13 / 333,574, entitled "System, Method, and Apparatus for "Electronic Patient Care," now a U.S. patent application published on July 19, 2012. No. US-2012-0185267(A1), (Attorney Docket No. I97), and PCT Application No. PCT / US11 / 66588, filed December 21, 2011; Title of invention: "System, Method, and Apparatus for Electronic Patient Care" (Attorney This application is a continuation-in-part of US Pat. No. 6,393,313, filed on May 13, 2003, and US Pat. No. 6,393,313, both of which are incorporated herein by reference in their entirety. Be absorbed. U.S. Patent Application No. 13 / 333,574 was filed on January 21, 2011. Patent application No. 13 / 011,543, entitled "Electronic Patient Monitoring System" ”, now U.S. Patent Application Publication No. US-2011-013666, published December 22, 2011. No. 313789(A1) (Attorney Docket No. I52), a continuation-in-part of U.S. patent application No. 13 / 011,543 is a provisional patent application filed on January 22, 2010. / 297,544, invention title: Electronic Order Intermediation System for a Medical This application claims priority to USPTO International, Inc. (Attorney Docket No. H53), both of which are incorporated by reference. all of which are incorporated herein by reference. This application is a joint venture of U.S. Patent Application Serial No. 13 / 723,239, filed December 21, 2012. , Title of invention: "System, Method, and Apparatus for Electronic Patient Care", currently No. US-2013-029733, published November 7, 2013 0(A1) (Attorney Docket No. J77), which is a continuation-in-part of Claim priority and benefit. No. 61 / 578,649, filed December 21, 2011, of the present invention. Name: “System, Method, and Apparatus for Infusing Fluid” (proxy reference number J02) , U.S. Provisional Patent Application No. 61 / 578,658, filed December 21, 2011, Inventor Name of the company: "System, Method, and Apparatus for Estimating Liquid Delivery" (Agent J04), U.S. Provisional Patent Application No. 61 / 578,674, filed December 21, 2011, Inventor Name of "System, Method, and Apparatus for Dispensing Oral Medications" (Agent Serial number J05), No. 61 / 651,322, filed May 24, 2012, of the invention Name: “System, Method, and Apparatus for Electronic Patient Care” (proxy reference number) No. J46), and U.S. Provisional Patent Application No. 61 / 679,117, filed August 3, 2012, entitled "Invention of the Invention" ``System, Method, and Apparatus for Monitoring, Regulating, or Controlling Flu No. 6,313,635, filed on Dec. 13, 2003, and entitled "Digital Flow," Attorney Docket No. J30, each of which is incorporated herein by reference in its entirety. Can be enjoyed. U.S. Patent Application Serial No. 13 / 723,239 claims priority to and the benefit of: It is also a continuation-in-part application. U.S. Patent Application No. 13 / 011,543, filed January 21, 2011, entitled "Invention of the Invention" Titled "Electronic Patient Monitoring System," it is currently being released on December 22, 2011. No. US-2011-0313789(A1) (Attorney Docket No. I 52), and U.S. Patent Application No. 13 / 011,543 was filed on January 1, 2010. U.S. Provisional Patent Application No. 61 / 297,544, filed on the 22nd of this month, entitled "Electron Order Intermediation System for a Medical Facility" (Representative Reference Number H53) No. 13 / , filed December 21, 2011, which claims priority to No. 333,574, entitled "System, Method, and Apparatus for Electronic Patie nt Care,” now U.S. Patent Application Publication No. US-2012, published July 19, 2012. No. 2-0185267(A1) (Attorney Reference No. I97), and PCT Application No. PCT / US11 / 66588, filed December 21, 2011; The name of the invention is "System, Method, and Apparatus for Electronic Patient Care" and is currently International Patent Application Publication No. WO2013 / 095459 published on September 12, 2013 No. 60 / 339,933, filed on Oct. 13, 2003. Each application is incorporated herein by reference in its entirety. This application is a joint venture of U.S. Patent Application Serial No. 13 / 723,242, filed December 21, 2012. , Title of invention: "System, Method, and Apparatus for Electronic Patient Care", currently No. US-2013-03177, published November 28, 2013 53(A1) (Attorney Docket No. J78), and is a continuation-in-part of U.S. Patent Application Serial No. 13 / No. 723,242 is, No. 61 / 651,322, filed May 24, 2012, of the invention Name: "System, Method, and Apparatus for Electronic Patient Care" (proxy reference number) No. J46, which is incorporated herein by reference in its entirety. To be incorporated. This application is a continuation of U.S. patent application Ser. No. 13 / 900,655, filed May 23, 2013. The name of the invention is "System, Method, and Apparatus for Electronic Patient Care" and is currently U.S. Patent Application Publication No. US-2013-031783 published November 28, 2013 7(A1) (Attorney Docket No. K66), and is a continuation-in-part of U.S. Patent Application Serial No. 13 / No. 900,655 is a U.S. Provisional Patent Application No. 61 / 651, filed May 24, 2012. ,322, invention title "System, Method, and Apparatus for Electronic Patient Carrier This application claims priority to and the benefit of (Attorney Docket No. J46), both of which are incorporated by reference. All are incorporated herein by reference. U.S. Patent Application Serial No. 13 / 900,655 claims priority to and the benefit of: It is also a continuation-in-part application. U.S. Patent Application No. 13 / 480,444, filed May 24, 2012, entitled "Invention of the Invention" Titled "Blood Treatment Systems and Methods", currently published on February 14, 2013. US Patent Application Publication No. US-2013-0037485(A1) (Attorney Docket No. J4 3), and PCT Application No. PCT / US12 / 00257, filed May 24, 2012, The original name was "Blood Treatment Systems and Methods", and is currently on November 29, 2012. Published International Patent Application No. WO / 2012 / 161744 (Attorney Docket No. J43 WO). This application is a joint venture with PCT Application No. PCT / US13 / 4235, filed May 23, 2013. No. 0, invention name "System, Method, and Apparatus for Electronic Patient Care" This is a continuation-in-part of the PCT application No. PCT / US13 / No. 42350 is a U.S. Provisional Patent Application No. 61 / 651,3 filed May 24, 2012. No. 22, Title of invention: "System, Method, and Apparatus for Electronic Patient Care" (Attorney Docket No. J46), both of which are incorporated herein by reference in their entirety. all of which are incorporated herein by reference. PCT Application No. PCT / US13 / 42350 claims priority to and the benefit of: It is also a continuation-in-part application that extends the scope of the present invention. U.S. Patent Application No. 13 / 480,444, filed May 24, 2012, entitled "Invention of the Invention" Titled "Blood Treatment Systems and Methods", currently published on February 14, 2013. US Patent Application Publication No. US-2013-0037485(A1) (Attorney Docket No. J4 3), and PCT Application No. PCT / US12 / 00257, filed May 24, 2012, The original name was "Blood Treatment Systems and Methods", and is currently on November 29, 2012. Published International Patent Application Publication No. WO / 2012 / 161744 (Attorney Docket No. J4 3WO). This application may also relate to one or more of the following patent applications, all filed on December 21, 2012: No. 60 / 639,333, filed on Oct. 13, 2007, and all of which applications are incorporated herein by reference in their entirety. . Regular application for "System, Method, and Apparatus for Clamping" (Attorney serial number J47 ), No. 13 / 723,238, Regular application for "System, Method, and Apparatus for Dispensing Oral Medications" ( Agent docket number J74), No. 13 / 723,235, PCT application for "System, Method, and Apparatus for Dispensing Oral Medications" (Agent docket number J74WO), No. PCT / US12 / 71131, Regular application for "System, Method, and Apparatus for Estimating Liquid Delivery" (substitute) Rijin reference number J75), No. 13 / 724,568, Regular application for "System, Method, and Apparatus for Infusing Fluid" (Attorney Serial Number J76), No. 13 / 725,790, PCT application for "System, Method, and Apparatus for Infusing Fluid" (agent serial no. No. J76WO), No. PCT / US12 / 71490, “System, Method, and Apparatus for Monitoring, Regulating, or Controlling Flu id Flow” regular application (attorney docket number J79), No. 13 / 723,244; “System, Method, and Apparatus for Monitoring, Regulating, or Controlling Flu id Flow” PCT application (Attorney Docket No. J79WO), No. PCT / US12 / 7114 No. 2, Regular application for "System, Method, and Apparatus for Estimating Liquid Delivery" (substitute) J81), No. 13 / 723,251, and PCT application for "System, Method, and Apparatus for Estimating Liquid Delivery" ( Agent docket number J81WO), No. PCT / US12 / 71112. This application may also be related to one or more of the following patent applications: All are incorporated herein by reference in their entirety. U.S. Provisional Patent Application No. 61 / 738,447, filed December 18, 2012, Inventor System, Method, and Apparatus for Detecting Air in a Fluid Line Using Ac tive Rectification” (proxy reference number J32), U.S. Patent Application No. 13 / 840,339, filed March 15, 2013, entitled "Invention of the Invention" ``Apparatus for Infusing Fluid'' (proxy docket number K14), PCT Application No. PCT / US13 / 32445, filed March 15, 2013, Ming's name "Apparatus for Infusing Fluid" (agent reference number K14WO), U.S. Patent Application No. 13 / 833,432, filed March 15, 2013, entitled "Invention of the Invention" ``Syringe Pump and Related Method'' (proxy docket number K21), U.S. Patent Application No. 13 / 836,497, filed March 15, 2013, entitled "Invention of the Invention" ``System and Apparatus for Electronic Patient Care'' (proxy docket number K22), U.S. Patent Application No. 13 / 833,712, filed March 15, 2013, entitled "Invention of the Invention" ``System, Method, and Apparatus for Clamping'' (Representative docket number K23), U.S. Patent Application No. 13 / 834,030, filed March 15, 2013, entitled "Invention of the Invention" ``System, Method, and Apparatus for Monitoring, Regulating, or Controlling Flu id Flow" (representative serial number K28), No. 61 / 860,398, filed July 31, 2013, of the present invention. Name: “System, Method, and Apparatus for Bubble Detection in a Fluid Line Using a Split-Ring Resonator” (proxy reference number J31), No. 61 / 900,431, filed November 6, 2013, of the present invention. Name “System, Method, and Apparatus for Monitoring, Regulating, or Controlling F luid Flow" (agent serial number K52), U.S. Provisional Patent Application No. 61 / 894,801, filed October 23, 2013, Inventor Name: "Syringe Pump and Related Method" (Representative Reference Number K88) U.S. Provisional Patent Application No. 61 / 843,574, filed July 8, 2013, entitled "Invention of the Invention" ``System, Method, and Apparatus for Clamping'' (proxy docket number K75), U.S. Patent Application No. 13 / 971,258, filed August 20, 2013, entitled "Invention of the Invention" ``Electronic Patient Monitoring System'' (proxy reference number K84), U.S. Provisional Patent Application No. 61 / 904,123, filed November 14, 2013, Inventor Name: "Syringe Pump and Related Method" (Representative Reference Number L33), No. 14 / 101,848, filed December 10, 2013, of the present invention. Name: “System, Method, and Apparatus for Detecting Air in a Fluid Line Using Acti ve Rectification” (proxy reference number L05), The "System, Method, and Apparatus for Communicating" application was filed on December 20, 2013. "Atting Data" U.S. patent application (Attorney Docket No. L49); The "System, Method, and Apparatus for Communicating" application was filed on December 20, 2013. PCT application for "Patenting Data" (Attorney Reference Number L49WO), "Computer-Implemented Method, System, and A" filed on December 20, 2013 U.S. patent application for "paratus for Electronic Patient Care" (Attorney Docket No. K50); The "System, Method, and Apparatus for Electronic US patent application for "Patient Care" (Attorney Docket No. L52), and The "System, Method, and Apparatus for Electronic PCT application for "Patient Care" (Attorney Reference Number L52WO).

[0002] The present disclosure relates to patient care. More particularly, the present disclosure relates to an electronic patient care system and and the equipment. [Background technology]

[0003] Patient care often involves administering liquids, such as medications, directly to the patient. This can be accomplished using a gravity-fed tube connected to a container (e.g., an IV bag). Fluids and medications may also be given by forced infusion. often requires the interaction of many stakeholders (e.g., doctors, nurses, pharmacists). Such interactions can lead to miscommunication, mistakes, or resulting in an incorrect amount of fluid being administered to the patient. This is likely to lead to other events that will be 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 The medical device manufacturer has at least one drug license configured for use in at least one medical device. This includes medical error reduction software used in creating and revising patient libraries. The software is configured to provide a set of privileges to a set of users. The set of privileges may be Allocate a certain amount of software functionality to a set of users, and is configured to define an ability for a user to modify at least one drug library. The medical error reduction system includes at least one server and at least one editor. The editor computer communicates with the server via the network. The display includes a processor in communication with the display.

[0005] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. This may include medical error reduction software used in creating and revising patient libraries. The software may provide one of multiple sets of privileges to each of multiple sets of users. Each of the multiple sets of privileges may be configured to duplicate a certain degree of software functionality. A certain degree of software functionality may be configured to allocate the The capability is configured to define an ability for a user to modify at least one drug library. The medical error reduction system may include at least one server. The error reduction system may include at least one editor computer. At least one editor computer each has a processor in communication with the display. At least one editor computer and at least one The server is configured to communicate over the network in a client / server model. Each of the at least one drug library may include a drug library for use with at least one medical device. It is possible.

[0006] In some embodiments of the above system, the at least one drug library is each organized into a hierarchy. In some embodiments, the hierarchy may be created under at least one care group. In some embodiments, each level of the hierarchy may include a number of care areas. It may include some delivery parameters for at least one medical device. In an embodiment, each of the at least one drug library is a library of drugs, each library being directed to a particular pharmaceutical agent. In some embodiments, at least one drug library includes a plurality of entries corresponding to the , which may include some parameters that inform the operation of at least one medical device. In some embodiments, the drug library includes multiple profiles for at least one medical device. In some embodiments, the medical error reduction software may include a programming limit. The software may be further configured to provide quality improvement information to the user. In this case, at least one of the multiple privilege sets grants a drug license to one of the multiple user sets. In some embodiments, multiple sets of privileges may be assigned to inspect the libraries. At least one of the users in the user set has the privilege to edit the drug library. In some embodiments, at least one of the sets of privileges may be assigned You can assign the privilege to edit or create privilege sets to one of several user sets. In some embodiments, at least one of the multiple sets of privileges may be set for multiple users. A user may be assigned additional privileges to one of the sets. A set of privileges assigned to each of the user sets is used to access at least one drug label. Enforce a collaborative process between multiple sets of users to create and revise libraries It is possible.

[0007] According to one embodiment of the present disclosure, a medical error reduction system includes at least one server. The medical error reduction system includes at least one editor computer. Each of the at least one editor computer may include a display and At least one editor computer may have a processor in communication with the at least one editor computer. The data and at least one server communicate over a network in a client / server model. The medical error reduction system may be configured to communicate with at least one server. The medical error reduction software may include software configured to be executed by the The medical error reduction software will: To be used, it must be accessible via at least one editor computer. Each of the at least one drug library may be used with at least one medical device. Each of the at least one medical device may include a medical device processor and a user interface. A medical device graphical user interface configured to display a The user interface may include a user interface that can convey information, Each medical device can be programmed with at least one drug. Each object library guides a user to program at least one medical device. It can contain multiple entries. The medical error reduction software uses simulated medical devices. The simulated medical device may be configured to display a graphical user interface. The therapeutic device graphical user interface must be able to read and write data from at least one drug library. Graphical user interface for medical devices using selected drug libraries It is possible to mimic the behavior of a given interface.

[0008] In some embodiments, the simulated medical device graphical user interface In some embodiments, the medical error reduction software is context-aware. Each privilege set can be assigned to one of multiple user sets. Each of several privilege sets can grant a certain degree of software functionality to multiple users. In some embodiments, a simulated medical device graph may be assigned to each of the sets. The physical user interface allows you to turn on or off some sets of privileges. In some embodiments, the at least one Each of the at least one drug library may be organized into a hierarchy. A tier can include multiple care areas subordinate to at least one care group. In some embodiments, each level of the hierarchy includes several In some embodiments, the delivery parameters of at least one drug line may be included. Each library can contain multiple entries, each corresponding to a particular drug. In some embodiments, the at least one drug library is In some embodiments, the drug may include a number of parameters that inform the operation of the drug. The library shall contain multiple programming limits for at least one medical device. In some embodiments, the medical error reduction software further comprises: It may be configured to provide it to the user.

[0009] According to another embodiment of the present disclosure, a medical device for delivering a medicine to a patient includes: The medical device may include a controller configured to control operation of a pump mechanism for causing the medical device to The medical device may include a display. The medical device may include a program for the drug library. The method may include a computer readable memory configured to store a program code. A drug library can contain multiple entries. Multiple entries can be used to identify Each such entry may include at least one entry corresponding to a portion of the There may be at least one drug entry for each of the at least one drug entries. Each parameter may be associated with at least one drug entry in the drug library. may be associated with a broad drug category rather than with a specific drug. The medical device shall display a graphical user interface on the display of the medical device. The system may include a processor configured to: The interface allows the user to program the controller with the drug library. It can be used.

[0010] In some embodiments, the user may select from broad drug categories rather than being associated with a specific drug. Select at least one drug entry in the drug library associated with the drug. In some embodiments, the delivery of a medication to a patient can be programmed using a specific In the drug library, the drugs are associated with broad drug categories rather than with specific drugs. At least one drug entry includes at least one parameter governing the delivery of the drug. In some embodiments, the drug library may be associated with medical error reduction software. In some embodiments, the display may be created or modified using software. In some embodiments, the display may be a touch screen display. At least one drug in the drug library is associated with a broad drug category rather than a single drug At least one of the drug entries may be used to allow the user to administer the drug in a quantity per hour mode. In some implementations, the medical device may be programmed to deliver a drug. In an embodiment, each of the multiple entries may be associated with at least one parameter. In some embodiments, at least one of the at least one parameter is a drug delivery parameter. It can be a parameter.

[0011] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used with at least one medical device. The software may be configured to provide one of multiple sets of privileges to each of multiple sets of users. Each of the multiple privilege sets may provide a certain degree of software functionality to multiple users. The medical error reduction system may be configured to allocate one of the sets of The medical error reduction system may include at least one server. At least one editor computer may be included in each Each of the devices may include a processor in communication with the user interface. At least one editor computer and at least one server are The multiple user sessions may be configured to communicate over the network in a multi-user model. At least one of the participants will use the software to identify a small number of drugs in at least one drug library. may request that at least a portion of the

[0012] In some embodiments, at least one of the sets of privileges allows a user to make changes. In some embodiments, the system may be configured to allow multiple privileges to be set. At least one of the sets is configured to allow a user to accept the implementation of the changes. In some embodiments, at least one of the sets of privileges may be changed by the user. In some embodiments, the system may be configured to allow users to submit questions to the At least one of the sets of privileges allows the user to propose revisions of changes. In some embodiments, the server may be configured to In some embodiments, certain software functions may be configured to 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, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used with at least one medical device. The medical error reduction system includes a medical error reduction system configured to execute medical error reduction software. The medical error reduction system may include at least one server. At least one editor computer. Each of the sensors can include a processor in communication with a user interface. The user interface allows one user to edit at least one drug library. or multiple users. At least one editor computer and the at least one server may be configured to communicate over a network. At least one of the person or users at least changes the content of the document by submitting an electronic change request. Any one may request changes to the drug library.

[0014] In some embodiments, the at least one medical device may be an infusion pump. In some embodiments, the electronic change request may be linked to medical data. In some embodiments, the medical data is stored in an electronic database to provide contextual information. In some embodiments, the electronic database can be in a hosted environment. In some embodiments, the medical data may be generated from at least one medical device. In some embodiments, the medical data may be stored in an electronic database. The medical data is used by at least one medical device that generated the medical data. In some embodiments, the drug library may be associated with one of at least one drug library. The medical data may be displayed in the form of a table. In some embodiments, the medical data may be displayed in the form of a chart. In some embodiments, the medical data may be displayed in the form of a graph. In some embodiments, the medical data may be displayed in graphical form. In some embodiments, the medical data may be displayed in the form of an infusion case. can search medical data using drug library editing software. In this embodiment, the user uses the drug library editing software to filter the medical data. In some embodiments, the medical data may be filtered based on user selection. In some embodiments, the user may view the currently edited content in a format that is A medical data library that corresponds to a version of at least one of the libraries In some embodiments, each of the multiple entries can access only one In some embodiments, the fluid delivery parameter may be associated with one or more of the delivery parameters. At least one of the users can accept the electronic change request. In an embodiment, at least one of the one or more users responds to the change request electronically. In some embodiments, at least one of the one or more users may In some embodiments, one or more At least one of the plurality of users may reject the electronic change request.

[0015] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used with at least one medical device. The drug library compilation software may be executed by a server. The system may include at least one drug library database. The reduction system may include at least one database of medical data. The error reduction system may include at least one editor computer. At least one editor computer is in communication with the user interface. The user interface may include at least one processor. It can be used by the user to edit the drug library. a computer, at least one drug library database, and at least Another medical data database is configured to communicate over a network. During the editing of at least one drug library, the user Medical data can be accessed using the device.

[0016] In some embodiments, the medical data is stored in at least one medical data database. In some embodiments, the at least one database of medical data may include 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 a graph. In some embodiments, the medical data may be displayed in the form of a table. In some embodiments, the medical data may be displayed in graphical form. In some embodiments, the medical data may be displayed in a user selectable format. In some embodiments, the medical data accessed may be displayed in a searchable format. In some embodiments, the medical data accessed may be filtered. In some embodiments, the filter may be based on the type of device. In some embodiments, the filter may be a category of data. 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 can be a drug-based criterion. In some embodiments, the drug criterion may be a drug identifier. In some embodiments, the drug criteria may be a type of drug. At least one drug library database can be in the hosted environment. In some embodiments, the medical device may be an infusion pump.

[0017] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used with at least one medical device. The object library editing software may be executed by the server. The system may include at least one drug library database. The reduction system may include at least one database of medical data. The error reduction system may include at least one editor computer. At least one editor computer is in communication with the user interface. The user interface may include a processor for selecting at least one drug. At least one of the objects may be used by the user to edit the object library. An editor computer, at least one drug library database, and a small number of At least one database of medical data is configured to communicate over a network. When creating or revising at least one drug library, a drug library editor may The collection software provides users with medical data from at least one medical data database. Display in the interface and filter medical data using filter criteria It may be configured as follows.

[0018] In some embodiments, the at least one medical device may be an infusion pump. In some embodiments, at least one drug library database is present in the hosted environment. In some embodiments, at least one database of medical data may be hosted. In some embodiments, the filter criteria can 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 treatment-based criteria. In some embodiments, the filter criteria may be a medical device identifier. In some embodiments, the filter criteria can be a caregiver identifier. , care area based criteria. In some embodiments, the filter criteria include: In some embodiments, the drug criteria may be an identifier for the drug. In some embodiments, the drug criteria may be a type of drug. In an embodiment, filtering is performed by interacting with medical data displayed in a user interface. Filter criteria can be applied to display a subset of the medical data. In this mode, the user can filter the medical data by interacting with it. Criteria can be applied to scrutinize the medical data. The data is provided to the user interface in one or more of several formats specified by the user. It can be displayed on the face.

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

[0020] In some embodiments, the change is an order of magnitude change in one or more parameter values. In some embodiments, the processor modifies the font by changing its size. In some embodiments, the processor may be configured to visually change the color of the font. In some embodiments, the font may be visually altered by changing In a , at least one of the one or more parameter values ​​must be specified by the user. In some embodiments, one of the one or more parameter values ​​is a patient's weight. In some embodiments, one of the one or more parameter values ​​may be a In some embodiments, one of the one or more parameter values ​​may be a body surface area. In some embodiments, one or more parameters may be a dosage value. One of the values ​​may be a time value. In some embodiments, one or more parameters One of the data values ​​can be the amount of fluid to be infused. In some embodiments, one or more One of the parameter values ​​may be an infusion rate value. In some embodiments, one of the parameter values ​​may be a concentration value of a pharmaceutical agent. At least one or more parameter values ​​may be preprogrammed. In an embodiment, the processor reduces the size of the parameter values ​​to reduce the font. It may be configured to visually vary.

[0021] According to one embodiment of the present disclosure, the medical device includes a graphical user interface The medical device may include a processor. The processor may include a graphics Generate at least one screen for display in the physical user interface. At least one of the at least one screen may be a treatment in progress screen. The treatment in progress screen displays a pressure indicator that shows the fluid pressure in the infusion line. The data may include

[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 sections. The indicator is configured to indicate different pressures by filling different numbers of intervals. In some embodiments, the pressure indicator may vary by filling the bar by different amounts. In some embodiments, a graphical user interface may be configured to display different pressures. The interface can be a touch screen.

[0023] According to one embodiment of the present disclosure, the medical device includes a graphical user interface The medical device may include a processor. The processor may include a graphics Generate at least one screen for display in the physical user interface. At least one of the at least one screen may be configured to display a medical device performing a treatment. The treatment in progress screen can be displayed while the treatment is being performed. A drug indicator may be included to indicate a drug being delivered by the medical device. The processor may then notify the user of the classification of the drug according to one of several classifications assigned to the drug. At least a portion of the drug indicator displayed in the interface is colored in multiple colors. One can color code it.

[0024] In some embodiments, the graphical user interface may be a touch screen. In some embodiments, the processor may include a drug library for use with the medical device. In some embodiments, the drug library may be in communication with a memory having stored therein. can hold color-coding information for a portion of a drug indicator. In an embodiment, at least one of the at least one screens includes a display of a medical device to be delivered by the medical device. In some embodiments, the program screen may be a screen where a drug is specified. At least one of the classifications can be a high risk classification. At least one of the classifications can be a type of drug. At least one of the number categories can be a category of anesthetic agents. The medication indicator may include a name of the medication. In some embodiments, the product indicator may include a non-text indicator. The cyst label is the only part of the drug indicator that is color coded.

[0025] According to one embodiment of the present disclosure, the medical device includes a graphical user interface The medical device may include a processor. The processor may include a graphics Generate at least one screen for display in the physical user interface. The medical device may be configured to include a computer readable memory. The computer readable memory contains treatment-related information that can be programmed into the medical device. A plurality of associated parameter values ​​may be stored, at least one of the parameter values ​​being The value of the limit on the treatment parameter value may be overridden by the user. User-overridable limits on therapy parameter values ​​are Overridden by one or more users via a physical user interface The processor has user-overridable limits. An indicator may be displayed next to the treatment parameter value in response to being overridden. do.

[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 be in violation of a limit. In some embodiments, the notification of a limit violation may be displayed as an override. In some embodiments, the value of the limit that can be idiom may not be displayed. The notification of a value violation may include an override option. The user-overridable limits on the therapy parameter values ​​are set by a first user Both the first user and the second user can set the limit values ​​via the graphic user interface. In some embodiments, the medical device may require a pre-override. A plurality of parameter values ​​related to the therapy that can be programmed are provided on a computer readable memory. The drug library file may be part of a drug library file stored in the active memory. In some embodiments, the sign may be a non-text sign.

[0027] According to one embodiment of the present disclosure, the medical device includes a graphical user interface. The medical device may include a processor. The processor may include a graph. It is recommended that you generate at least one screen for display in the physical user interface. The medical device may be configured to include a computer readable memory. The computer readable memory stores a plurality of pharmaceutical agents capable of being delivered by the medical device. The medicines can be organized according to one or more medicine categories. Each medicine further has associated therapeutic functions that can be programmed into a medical device. The user can then graphically select one or more parameter values. Use the user interface to program the medical device to perform the treatment At least one step in programming the medical device may This may include selecting a drug category that includes the drug to be delivered.

[0028] In some embodiments, the graphical user interface may be a touch screen. In some embodiments, multiple pharmaceutical agents and one or more pharmaceutical categories may be used. is part of a drug library file. In some embodiments, the drug category is In some embodiments, the information is searchable via a graphical user interface. , Drug categories filtered through a graphical user interface In some embodiments, at least one of the one or more parameter values ​​is: It can be a parameter limit that can be overridden by the user.

[0029] According to one embodiment of the present disclosure, a medical error reduction system includes at least one medical device. In creating and revising at least one drug library configured for use in The software may include software for reducing medical errors used in The system may be configured to provide one of the sets of rights to each of a plurality of user sets. Each set of privileges assigns a certain degree of software functionality to one of several sets of users. A certain degree of software functionality may be provided by the user, who may then assign at least one The medical error reduction system may be configured to define the ability to modify the drug library of the The system may include at least one server. The medical error reduction system may include a disk. At least one editor computer with a processor in communication with the play At least one editor computer may be a client / server The system may be configured to communicate with at least one server over a network in a stomach.

[0030] According to one embodiment of the present disclosure, a medical error reduction system can include a medical device. The medical device may include a medical device processor. A medical device graphical user interface configured to enable a user to program the device. The medical error reduction system may include at least one sub-system. The medical error reduction system may include a processor in communication with the display. At least one editor computer having a processor. A single editor computer is networked in a client / server model. The medical error reduction system may be configured to communicate with at least one server via the The program will provide at least one It is run by one server and accessed through at least one editor computer. The medical error reduction software may include software configured to provide access to at least one Each drug library is used by at least one medical device and has at least one user. It may contain multiple entries that guide the programming of one medical device. The error reduction software also uses simulated medical device graphical user interfaces. The simulated medical device graphical user interface may be configured to display a The interface uses at least one drug library to identify medical device groups. It is possible to mimic the behavior of a graphical user interface.

[0031] According to one embodiment of the present disclosure, a medical device for delivering a medicine to a patient includes: The medical device may include a controller configured to control operation of a pump mechanism. The medical device may include a display. The medical device may include a program for the drug library. a computer readable memory configured to store program code. The drug library can have multiple entries. , may include at least one entry corresponding to a portion of the facility. For each entry, the multiple entries further include at least one drug The medical device may include a graphical user interface on the medical device display. The device may further include a processor configured to display a user interface. A graphical user interface controls the controller using the drug library. The user can then program the corresponding Select one of at least one drug entries to program the delivery of the medication to the patient. It is possible.

[0032] In some embodiments, at least one drug entry has associated therewith In some embodiments, the drug library further comprises a specific At least one drug associated with a broad drug category rather than with a specific drug In some embodiments, the user may include a medication entry associated with a particular medication. At least one drug in the drug library associated with a broad drug category rather than being assigned to a specific drug You can select one of three drug entries to program the delivery of medication to a patient. do.

[0033] According to one embodiment of the present disclosure, a medical error reduction system includes at least one medical device. Drugs used in creating and revising at least one drug library for use in At least one drug library can be included in the drug library editing software. It may contain multiple entries. Software may use at least one of multiple privilege sets. A set of privileges may be configured to provide one to each of a plurality of user sets. Each system allocates a certain amount of software functionality to one of several sets of users. A degree of software functionality may be provided to the user to allow the user to select at least one drug library. The medical error reduction system may be configured to define an ability to modify the drug library. at least one server configured to execute the library editing software; The medical error reduction system is in communication with a user interface. At least one editor computer having a processor. At least one editor computer is networked in a client / server model. The plurality of user sessions may be configured to communicate with at least one server via a At least one of the participants will use at least one editor computer to create a drug live Access to library editing software to make changes to at least one drug library can be requested.

[0034] In some embodiments, at least one of the sets of privileges further comprises a user having less Deny the implementation of the requested changes to at least one drug library, or and a drug library configured to allow the drug library to be approved for implementation. It is okay to do so.

[0035] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. A drug library can be used for at least one medical device. The error reduction system includes a small number of devices configured to run drug library editing software. The medical error reduction system may include at least one server. At least one editor computer having a processor in communication with the interface. The user interface may include at least one drug library. At least one editor control can be used by the user to edit the The computer includes at least one editor computer running drug library editing software. A small number of servers are connected to the network in a client / server model to allow access to the software. The user may be configured to communicate with at least one server. Change requests can be made to at least one drug library by submitting an electronic change request via the You may request a change to your account.

[0036] In some embodiments, the electronic change request is linked to the medical data in the electronic database. It is possible for the system to provide contextual information.

[0037] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used for at least one medical device. The object library editing software can be executed by a server. The drug 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 includes a server, at least one drug library database, and at least one database of medical data over a network. At least one editor computer configured to: The editor computer is the program that communicates with the user interface. The user interface may include a processor for displaying at least one drug license. A user is required to edit at least one drug library using the drug library editing software. The user may use the drug library during editing of at least one drug library. The user will create at least one medical data database using the drug library editing software. This allows access to medical data stored on the database.

[0038] In some embodiments, during editing of at least one drug library, a user may Use library editing software to identify medical records in at least one medical data database. In some embodiments, the medical data may be accessed by the user. At least one of the following charts, graphs, plots, and diagrams displayed in the interface: In some embodiments, at least one of the drug libraries may be in one form. During editing, the user must create at least one medical The medical data in the database is displayed in a user interface, and the user can Organize medical data so that only the medical data of interest is displayed in the user interface Can be filtered.

[0039] According to one embodiment of the present disclosure, the medical device includes a graphical user interface. The medical device may include a processor. The processor may include a graphics Generate at least one screen for display in the physical user interface. The at least one screen may include at least one parameter value. The processor may further be responsive to a change in the order of magnitude of the at least one parameter value. In accordance with the present invention, the font of at least one parameter value may be visually changed.

[0040] In some embodiments, the at least one screen may include a treatment in progress screen, The treatment progress screen includes a pressure indicator that shows the pressure of the fluid in the infusion line. In embodiments, at least one of the screens may be a treatment progress screen. The screen inside includes a drug indicator that shows the drug being delivered by the medical device. The processor may further include a medication index that is displayed on the user interface. The indicator may be configured to be color coded in one of a plurality of colors, each color representing a medical In some embodiments, the medical device may be computer readable. The medical device may include a computer readable memory. A plurality of parameter values ​​related to the treatment that can be programmed can be stored. At least one of the parameter values ​​is overridden by the user for the treatment parameter value. This can be a user-overridden limit on the value of a therapy parameter. Rideable limits can be set by the user via a graphical user interface. The processor can also be overridden by the user. Displaying indicators next to therapy parameter values ​​in response to user overrides of modifiable limits In some embodiments, the computer readable memory The medical device is configured to store a plurality of medicines that can be delivered by the medical device. Each drug may be organized into one or more drug categories. to one or more parameter values ​​related to a therapy that can be programmed into a medical device; The user may further use a graphical user interface to At least select the drug category that contains the drug to be delivered by the medical device. , the medical device can be programmed.

[0041] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. This may include medical error reduction software used in creating and revising patient libraries. The software may be configured to provide a set of privileges to each of multiple users. A set of privileges is used to allocate a degree of software functionality to each of multiple users. A degree of software functionality may be provided to allow a user to acquire at least one drug license. The medical error reduction system may be configured to define the ability to modify the library. The medical error reduction system may include at least one server. At least one editor computer. Each of the display devices may include a processor in communication with the display. One editor computer and at least one server are in a client / server configuration. The at least one drug may be configured to communicate over a network in a drug model. Each library can be used 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 includes a plurality of nurses subordinate to at least one care group. In some embodiments, each level of the hierarchy may include at least one In some embodiments, the fluid delivery parameters for the medical device may include: Each of the at least one drug library includes a plurality of drug libraries, each of which corresponds to a particular drug. In some embodiments, at least one drug library may include , which may include some parameters that inform the operation of at least one medical device. In some embodiments, the drug library includes multiple profiles for at least one medical device. In some embodiments, the medical error reduction software may include a programming limit. The software may be further configured to provide quality improvement information to a plurality of users. In this form, a set of privileges is configurable to allocate privileges to inspect the drug library. In some embodiments, the set of privileges allocates privileges to edit the drug library. In some embodiments, the set of privileges can be set to include edit or create privileges. In some embodiments, the set of privileges can be configured to allocate user-added privileges. In some embodiments, the rights can be allocated to each of a number of users. The set of privileges granted to the user must be duplicated to create and revise at least one drug library. It is possible to enforce a collaborative process between multiple users.

[0043] According to one embodiment of the present disclosure, the medical error reduction system includes a number of drug libraries. Includes drug library editing software used in creating and revising Some drug libraries may each contain multiple entries. Each library can be used for at least one medical device. The system may include at least one editor computer. Each of the four editor computers is a process in communication with the user interface. The user interface may include at least one drug live It can be used by one or more users to edit the drug library. The library editing software creates a copy of the first drug library among several drug libraries. A number of entries are added to a second drug library among several drug libraries. The signal may be configured to be inserted into the signal processing unit.

[0044] In some embodiments, the system is further configured to execute medical error reduction software. In some embodiments, the system may include at least one server configured to: Some drug libraries may be stored in a drug library database. In an embodiment, the drug library database may be in a hosted environment. In an embodiment, one or more users may select a first drug library from among several drug libraries. library to be imported into a second drug library. In some embodiments, a drug entry can be specified from multiple entries. A first drug library in the substance library and a second drug library in some drug library Both the substance library and the drug library are a subset of the drug library. In some embodiments, a subset of a drug library can belong to one or A set of permissions that allows multiple users to access a subset of the drug library. In some embodiments, a set of permissions can be associated with one or more other Do not allow users to access a subset of the drug library.

[0045] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used for at least one medical device. The object library editing software may be executed by the server. The system includes at least one drug library storing at least one drug library. The medical error reduction system may include at least one editor. Each of the at least one editor computer may include The user interface may include a processor in communication with the user interface. The interface allows the user to edit at least one drug library. At least one editor computer and at least one The two drug library databases are configured to communicate over a network. Multiple entries may contain one or more clinical advisories.

[0046] In some embodiments, the drug library database is in a hosted environment. In the form, one or more clinical recommendations can 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 recommendations may include a document. may limit the length of one or more clinical recommendations to between 0 and 100 characters. In some embodiments, each of the one or more clinical advisories relates to a short text clinical advisory. In some embodiments, the short text clinical advisory may be 0 to 1 character long. In some embodiments, short text clinical recommendations may be limited to between 0 and 10 characters. At least one image of the graphic user interface of at least one medical device In some embodiments, each of the one or more clinical advisories may be displayed on a screen. At least one image of the graphic user interface of at least one medical device In some embodiments, each of the at least one clinical advisory may be displayed on a screen. Each of the drug entries may be associated with a drug entry in at least one drug library.

[0047] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used for at least one medical device. The object library editing software may be executed by the server. The system includes at least one drug library storing at least one drug library. The medical error reduction system may include at least one editor. Each of the at least one editor computer may include The user interface may include a processor in communication with the user interface. The interface allows the user to edit at least one drug library. At least one editor computer and at least one The drug library database may be configured to communicate over a network. The drug library editing software allows the user to edit one or more of the multiple entries. The device may be configured to allow all notes to be entered.

[0048] In some embodiments, the drug library database can be in a hosted environment. In some embodiments, the note may be a free text entry. In embodiments, the note may include an image. In some embodiments, the note may include a document. In some embodiments, the drug library editing software may include Allows you to enter notes about one or more subsets of entries In some embodiments, the drug library editing software may be configured to It may be configured to allow notes to be entered for each of a number of entries. In some embodiments, each of a plurality of entries associated with a note is In some embodiments, the note indicator may be displayed on the face. When the user interacts with the indicator, the note is displayed in the user interface. Good too.

[0049] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used with at least one medical device. The drug library compilation software may be executed by a server. The system stores at least one drug library. The medical error reduction system includes at least one ed At least one editor computer may be included in each Each of the devices may include a processor in communication with the user interface. The interface allows the user to edit at least one drug library. At least one editor computer and at least one The drug library database may be configured to communicate over a network. Multiple entries may contain cleaning parameters.

[0050] In some embodiments, the cleaning parameters are associated with at least one medical device. In some embodiments, the cleaning parameters can govern the cleaning of the fluid lines. When at least one medical device flushes a fluid line associated with the medical device, In some embodiments, the default delivery parameter values ​​to be used by the In some embodiments, the wash parameters can include a planned volume of fluid delivered. In some embodiments, the meter may include a flow rate of the delivered fluid. It can include.

[0051] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used for at least one medical device. The object library editing software may be executed by the server. The system includes at least one drug library storing at least one drug library. The medical error reduction system may include at least one editor. Each of the at least one editor computer may include The user interface may include a processor in communication with the user interface. The interface allows the user to edit at least one drug library. At least one editor computer and at least one The drug library database may be configured to communicate over a network. The drug library editing software provides the user with the desired profile information. The device may be configured to display a customizable screen that allows users to customize the device settings.

[0052] In some embodiments, a user customizable screen may include one or more windows. In some embodiments, the user may select a user-customized You can select one or more widgets to include on a customizable screen. In an embodiment, 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 a In some embodiments, one or more widgets may be One of the widgets may be a quick link widget. One of the one or more widgets may be a change request widget. In an embodiment, one of the one or more widgets is a feedback widget. In some embodiments, one of the one or more widgets may be a medical In some embodiments, one or more widgets may be One of the widgets may be a change inspection widget. Or one of the multiple widgets may be an admin comment widget. In some embodiments, a user may select one or more widgets from a list of permitted widgets. In some embodiments, a user may be provided with a medical error reduction solution. Users are assigned specific roles within the software and the list of allowed widgets is specific to that role. In some embodiments, the system further comprises a user database. In some embodiments, a user customizable display may be provided. Once a face is customized it is stored in a user database and associated with the user In some embodiments, the user customizable screen may include some You can choose from a range of customised screen configurations that can be loaded.

[0053] According to one embodiment of the present disclosure, a medical error reduction system includes at least one drug license. may include drug library editing software used in creating and revising drug libraries. At least one drug library may contain multiple entries. Each drug library can be used for at least one medical device. The object library editing software may be executed by the server. The system includes at least one drug library storing at least one drug library. The medical error reduction system may include at least one editor. Each of the at least one editor computer may include The user interface may include a processor in communication with the user interface. The interface allows the user to edit at least one drug library. At least one editor computer and at least one The drug library database may be configured to communicate over a network. The user may use the drug library editing software to edit two or more of the multiple entries. The comparison may be displayed in the user interface. stomach.

[0054] In some embodiments, the comparison may be displayed in a table in a user interface. In some embodiments, the comparison may be a side-by-side comparison. The differences between two or more entries being compared are visually indicated in the user interface. In some embodiments, the comparison may include an option to show only the differences. In some embodiments, interacting with the option to show only the differences will result in two of several entries being displayed. Only the differences between one or more entries are displayed, and two or more of the entries are displayed. You can toggle between a state where all information associated with the entry is displayed and a state where all information associated with the entry is displayed. In some embodiments, the comparison is to one of two or more entries of the plurality of entries. may contain an edit option which can be used to open the

[0055] According to one embodiment of the present disclosure, a method for generating a drug library file includes: The method may include assigning one of the sets of rights to each of a plurality of user sets. Multiple privilege sets are implemented within the drug library editing software to provide a degree of software A certain degree of software functionality may be allocated to the user. The drug library may be configured to define the ability to modify at least one drug library. The method for generating a library file requires the use of at least one editor computer. The method may include creating a drug library by using at least one editor. The computers each include a processor in communication with a user interface. The user interface is based on the drug library editing software. can be used by a user to edit at least one drug library Creating a drug library includes appropriate users among multiple user sets, Appropriate users are defined by a set of privileges and are assigned to the institution's Master Drug List. and defining a medication record for one or more portions of the institution. and verifying the defined medication record. approving the drug library for release to at least one medical device within the country; It can include.

[0056] In some embodiments, one of a plurality of privilege sets may allocate editing privileges. In some embodiments, one of a plurality of privilege sets allocates the privilege to perform the check. In some embodiments, the step of specifying the master medication list comprises In some embodiments, the method may include selecting a number of drugs from a base. The step of defining a medication record for one or more parts of the institution includes: or for each of the plurality of portions, selecting a desired medication from a master medication list. In some embodiments, a drug list for one or more parts of an institution may be included. The step of defining the code includes the step of defining several parameters for each desired drug. In some embodiments, the step of verifying the defined medication record may include: In some embodiments, the step of checking the medication record may include checking the medication record. In this example, the step of validating the defined medication record is the step of editing and In some embodiments, the drug library file may include a step of updating and revising the drug library file. The drug library file is then tested on a medical device for testing. The method may further include performing a pilot generation step on the drug library file. In some embodiments, the step of generating a drug library file comprises A pilot experiment in which the library files were examined on a simulated medical device user interface. The method may further include performing a synthesis step on the drug library file. In an embodiment, the step of verifying the defined medication record includes verifying the medication record using a simulated medical device user interface. using a user interface to review the defined medication records. It is possible.

[0057] According to one embodiment of the present disclosure, a drug library file is stored in at least one medical device. The method can include creating a drug library file. The method further comprises accepting a drug library file for publishing to at least one medical device. The method may include a step of verifying that the drug error reduction system is The method may include sending a notification to the user via the drug service. This may include downloading the object library file to the device gateway. The method further comprises the step of: the device gateway being capable of communicating with at least one medical device. Distributing the drug library file to at least one medical device via a network The method may include the step of:

[0058] In some embodiments, the method further comprises downloading the drug library file to a device gateway. The method may further include a step of instructing the user to download the image. In one embodiment, the method includes the step of selecting at least one medical device from a list of medical devices. In some embodiments, the method further comprises: The method further includes periodically checking whether there are updates to the drug library file. In some embodiments, the method includes providing at least one medical device that is a drug label. The method may further include verifying the validity of the library file. In the above manner, the validity of the drug library file is verified and updated successfully. transmit a confirmation message from each of at least one medical device to the device gateway when The method may further include the step of:

[0059] These and other aspects are described in detail below with reference to the various embodiments of the present disclosure, A more detailed explanation will make it clearer. [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 an 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] 13 is a flow chart 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 exposure to a facility gateway in accordance with one embodiment of the present disclosure. [Fig. 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] 11 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. [Diagram 46] 11 is a flowchart detailing several exemplary 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] 1 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, according to 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 user interface of a drug error reduction system, 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. [Fig. 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. [Fig. 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. [Fig. 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 user interface of a drug error reduction system, 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 user interface of a drug error reduction system, 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 user interface of a drug error reduction system, 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 user interface of a drug error reduction system, 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 user interface of a drug error reduction system, 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 user interface of a drug error reduction system, 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 user interface of a drug error reduction system, 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 user interface of a drug error reduction system, 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 in accordance with 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 an 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 example 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. [Figure 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. 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] FIG. 1 shows a block diagram of an electronic patient care system 1 according to one embodiment of the present disclosure. System 1 is composed of facility IT applications / services 11, facility 10, and cloud Includes Do Service 2.

[0062] Facility 10 may be a hospital, clinic, medical facility, outpatient care center, emergency care center, or or any combination or group thereof. The facility 10 includes a facility gateway 21. Various medical devices 26 can be connected to facility IT applications / services 11 and / or or a cloud service 2. The facility 10 is capable of communicating with a patient receiving care at the facility 10. The medical equipment includes various medical devices 26 that are operated and used by nurses 9 on patients. The device 26 is an infusion pump, a peristaltic pump, a syringe pump, an apparatus for nephrology, an apparatus for physiological parameters, Such as meter monitoring equipment, other patient care equipment, or some combination thereof.

[0063] The facility gateway 21 may be hosted, reside in the cloud, or managed by a service provider. of service providers and / or facility IT 18 personnel maintained for the facility 10 by Controlled and maintained in combination with and / or virtual or physical environments In some embodiments, the facility gateway 21 may be implemented within a patient The facility gateway 21 can be implemented in a device in a hospital, nursing group, or other facility. Group, Integrated Delivery Network (“IDN”), Integrated Services Group or Diagnostics Group Used by a clinic, group of clinics, central clinic, or other health care facility or infrastructure It is possible.

[0064] The medical technician PC tool 20 is used by the medical technician 19 to update the software of the device 26. The medical technician PC tool 20 allows the medical technician user 19 to update the medical device 2 6. Monitor the health of your software / files, view log files, track maintenance activities, A browser-based tool for managing firmware installations. The surgeon 19 is a hospital employee (or a contracted service) who is responsible for the medical equipment 26 (infusion pumps) Install, update, and maintain medical equipment (including medical devices) to ensure that medical equipment is in good working order The Medical Technician PC Tool 20 can be connected via USB or serial cable. The medical technician 19 interfaces with the device 26 via a physical data connection The medical technician 19 can provide the above-mentioned services. The device 26 may also be updated wirelessly using the mobile device 24 .

[0065] The equipment 26 communicates with the facility IT application / service 11 via the facility gateway 21. (via communications link 343) and / or cloud service 2 (via communications link 344 The communication links 343 and 344 may be WiFi, Et hernet, TCP / IP, WiMax, fiber optic cable, or any other Any known communication technology may be used.

[0066] The device 26 establishes communication with the device gateway 22 (e.g., via registration). This allows communication with the facility gateway 21. computer, virtual machine, hardware device, software device, hosted device, The device may be running software, etc., or some combination thereof. The gateway 22 may be software executable by the facility gateway 21. The devices 26 can communicate with the device gateway 22 using web services. In some particular embodiments, only the medical devices 26 can communicate with the device gateway 22 (and Therefore, the device gateway 22 starts communication with the facility gateway 21. A messaging system that supports both publish / subscribe and point-to-point routing mechanisms. The device gateway 22 may include a name resolution and routing engine. It can also provide resolution and capability registration functions. You can use object-relational mapping in the Gateway 22. (e.g. using an Object-Relational Mapping (ORM) engine) Additionally or alternatively, the device manager 24 may provide name resolution and / or A registration feature may also be provided.

[0067] In some embodiments of the present disclosure, one of the devices 26 is a tablet computer. tablet device, PDA, smartphone, laptop computer, or The monitoring client is a computer with a touch screen. The client has a monitoring client application in the device application 23. This allows the caregiver to communicate with other devices in the device 26. receiving status information from a medical device among the devices 26 using the client; Of these, 26 devices receive CQI messages from medical devices, and 26 devices can report from medical devices. The ability to receive Reportable Medical Events (RBEs) or Reportable Clinical Events (RCEs) Programming the medical device among the devices 26 or communicating in other ways with the medical device among the devices 26 It can be believed.

[0068] The communication link 343 between the device 26 and the facility gateway 21 may include WiFi, EtherNet / IP, or the like. net, TCP / IP, WiMax, fiber optic cable, or any other known In some embodiments of the present disclosure, the device 26 may use a communication technology such as cellular 3 communicates with the facility gateway 21 through a cellular connection (e.g., communication link 343 is a cellular connection). For example, one or more of the devices 26 may be installed in a patient's home, in a clinic, or in an outdoor facility. (e.g. tent facilities), emergency locations, other locations, or any combination thereof. It can be done.

[0069] The device gateway 22 can provide: (1) component registration and and license management (e.g., using Device Manager 24); (2) device firmware Software, Drug Management Library, Corporate Application Software, and Infrastructure software (e.g. operating system release, application server Installable Components, such as the An installation storage location for receiving, retaining, and tracking new versions of the or (3) between applications within the facility gateway 21 and external subsystems ( For example, a message routing service (e.g., a message delivery service to and from a cloud service 2) Capability.

[0070] The medical device 26 maintains an active network connection with the device gateway 22. The deployment environment in which the wireless network (IE This can be achieved using IEEE 802.11b / g / n), as mentioned above. Thus, in other embodiments, the network connection may be implemented using other technologies, such as cellular technologies. It is also possible.

[0071] An environment in which the device 26 does not maintain a wireless connection is called a "standard environment." It can still connect to application components and external subsystems. In this particular embodiment, the device gateway 22 also serves as the enterprise application controller. It performs all three roles for the components and external subsystems while For message exchange related to the medical technician 19 (e.g., using the medical technician PC tool 26) ) to store messages on an external media device (e.g. a memory stick) It is possible.

[0072] Event subscribers, such as device applications, can access the event stream with high accuracy. Therefore, higher level events can be republished to the device gateway 22. A reportable biomed event (RBE) that explains the RBE is included in the events republished by applications such as In some embodiments, the administrator may report the request to cloud service 2 as a The application running on the facility gateway 21 subscribes to the RBE and transmits the RBE to the facility gateway. The medical server stores the information in a local database within gateway 21.

[0073] The medical technician 19 uses his or her browser to access the device manager 24 and the device 26 A device status report can be requested for one of the devices in the device manager 24. I access the database on the medical server and send it to medical technicians 19 via a browser. You can instruct it to generate an HTML / JS page for display.

[0074] In some embodiments, new ones of the medical devices 26 may be used with the device gateway 22. Before being allowed to be used, the medical technician19 must identify the new device using its serial number. The device must be registered. This is done using asymmetric key (public / private key pair) cryptography. This can be done as part of the manufacturing process. When one of the devices 26 is registered with the device gateway 22, the medical technician 19 can Configure wireless protocol and encryption settings. One of 26 medical devices is a device gate. When registered with Way22, the device is registered with the following information: model, options, and hardware, firmware. The device will update its own initial settings, including the firmware and device control software version, to the The device manager 24 may then report the device status to the gateway 22 for storage. When a device is removed from the list of authorized devices in the device gateway 22, the medical technician 19 may de-register the device.

[0075] Each medical device 26 may perform a self-test upon start-up and may include an event to the device gateway 22. Additionally, the medical device 26 may routinely publish This may cause a long interval between restarts, so The device 26 may automatically schedule self-tests at times that will not interfere with patient safety and / or treatment. It can be executed as follows.

[0076] The facility gateway 21 transmits data using a publish / subscribe data connection (described below). Each device application includes a device application 23 capable of communicating data. 23 may correspond to a particular type and / or model of device 26. The application receives, filters, and analyzes raw events to provide higher quality results. By retransmitting standard interpretations, medical devices26 can be given software intelligence. Each type of medical device (out of 26 medical devices) can be classified into 23 device applications. ) may have a corresponding device application.

[0077] The facility gateway 21 also includes an equipment manager 24 that controls, manages, or monitors equipment 26. For example, using the Instrument Manager 24 to import configuration files (e.g., DAL files) The update and / or download may be performed on one of the devices 26. Thus, a medical technician 19 may modify the software, firmware, or configuration files of the device 26. The device manager 24 can control the updating of the device files to assist in the delivery of patient care. The health of the hardware, software, and network resources used to Provide a browser-based tool for IT managers and / or technicians to monitor the That is, the facility gateway 21 can provide the facility IT employees / contractors 18.

[0078] When a new version of the Drug Administration Library ("DAL") is released, A secure messaging link from DAL Manager 5 to Device Gateway 22 Send the AL file to inform medical technicians that a new version is available. This notification will include information about the type of equipment, the location of the DAL, and documentation. , release notes URL, installer URL, checksum, and installation In some embodiments of the present disclosure, the instrument manager 24 specifies dependencies between the new DA L file and receives DAL files from the device gateway 22 and receive DAL files directly from DAL Manager 5 and / or The update of the medical device 26 is controlled using the

[0079] In certain embodiments, the medical technician 19 may provide a URL for the release notes (e.g., via the Netja24 web page and / or Medical Technician PC Tool 20 Access information about the upgrade, installer URL and checksum Download and validate the DAL file using and then install it on the device gateway 22 The medical technician 19 then saves the new DAL file to a storage location. Then, one or more of the medical devices 26 are selected from the medical devices 26. A new DAL file is received (for example, via the device gateway 22) in one or more (26 Medical Devices Selected for Update) The next time the medical device is restarted, the selected group of medical devices 26 will be Install the AL version (cancel the installation if an error occurs), The result is notified to the device gateway 22 and / or the device manager 24. Use any of the procedures for updating the DAL file described in Firmware, software, operating system, or other configuration files of one of the medical devices can be updated.

[0080] The facility gateway 21 may also include an integration API 25, which interfaces with the devices 26, device applications, and application 23, and / or device manager 24, in conjunction with the patient information system 16, electronic Medical Records 17, Computerized Physician Order Entry 14, Laboratory Information Systems 15, real-time location services 12, and / or other databases or It communicates with various databases of facility IT applications 11 such as service 13. The integration API 25 enables components within the facility gateway 21 to communicate with the facility IT applications. The facility gateway 21 enables interoperation with the application / service 11. can communicate with the facility IT application 11 via a communication link 341, Communication Link 341 includes wireless links, wired links, TCP / IP links, and Internet A data link, software communication link, hardware communication link, or other communication method Or it may include technology.

[0081] Facility IT applications / services 11 are for hospital management functions (e.g., admission, discharge, transfer, The integrated API25 supports the facility IT applications. The differences between applications 12-17 in application 11, applications 23-24, and device games 22 and / or equipment 26. For example, if one of the equipment 26 is can request programming information from gateway 22 (or (The information can be pushed to one of the devices 26.) Patient ID, pump ID, medication, and The data and flow can be placed in one or more of the facility IT applications 11, and the integrated AP I25 is designed to provide a solution to facility IT applications11 regardless of their requirements or requirements. This information provides a common format for communicating the integrated A The PI 25 queries each of the facility IT applications 11 to obtain data, and The integrated AP can be collected by providing the data to the device 26 in a standardized format. I25 is a system that supports a variety of facility IT applications with different formats, data standards, communication standards, encryption standards, etc. Applications 12 to 17 may be used, but applications 22 to 24 and and / or device 26.

[0082] The integrated API 25 facilitates automated programming of one or more of the devices 26. The prescription may be sent from one of the servers of the IT application 14. 5 can receive the prescription, reformat it and send it to the device gateway 22 The facility gateway 21 may include a clinical server that reports prescription events. Write to permanent cache. Clinical Server initiates automated programming workflow. This workflow is performed by selecting the medical device that corresponds to the target patient from among the medical devices26. The device is identified and a command message is sent to each of the medical devices 26 instructing them to load the prescription. Each of the medical devices 26 may then notify the sender that it has received the prescription. The display will display a notification. The clinician will identify the location of the medication bag and the individual medical devices. For example, a barcode reader can be used to verify that the drug and patient are correct. Then, each medical device26 can verify that the medication matches the prescription and ensure that the clinician administers it. Each medical device 26 can start the clinical server via the device gateway. Complete the automation programming workflow by sending messages to

[0083] Caregivers can use the UI to review the programming of medical devices in the device 26. The clinician can identify the location of the medication and use the individual medical device user interfaces of the medical device26. Use the interface to determine the parameters for automatic programming of medical devices among the 26 devices. and / or be able to manually program the medical device among the medical devices 26. .

[0084] PIS16 allows pharmacist8 to receive, review, track, and fill prescription drug orders. The EMR17 system is a departmental system used to manage patients in a health care facility. CPOE14 tracks a patient's medical history (encounters, tests, diagnoses, procedures, etc.). Used by nurses to order lab tests, prescribe medications, medical images, and other clinical procedures The LIS15 is a system that allows laboratory technicians to analyze clinical specimens (e.g. tissue, blood, urine, etc.). ) is a department system used to receive and process orders. , track the location and status of equipment 26. Others 13 are used for patient care. It can be any other database.

[0085] Cloud Services 2 is a cloud-hosted Infusion Safety Manager 3 ("ISM"). The infusion safety manager is referred to herein by the term "hosted safety manager ( HSM3 is a continuous quality improvement (CQI) program. The "I" manager 4 and the DAL manager 5 are included. Risk management manager 6, nursing manager 7, and Pharmacist 8, who checks the CQI messages retrieved by CQI Manager 4. This can help you develop and improve your DAL files via DAL Manager 5. The AL file can then be downloaded to one or more of the devices 26. AL Manager 5 uses a Drug Error Reduction System ("DERS") editor (e.g., The DERS editor 112 shown in FIG. 4 may include or be associated with the DERS editor 112.

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

[0087] The device gateway 40, device manager 41, and integration API 65 all correspond to the facility gateway of FIG. Part of Toway 21. Large Volume Pump Applications 44, Syringe Pumps Application 43 and other applications 42 are all part of the equipment application in Figure 1. The device manager 41 with associated database 45 is part of the system 23. may be the device manager 24 of FIG.

[0088] Large Volume Pump ("LVP") Application 44 is a companion application to the LVP 36. The syringe application 43 is an application corresponding to the syringe pump 38. The other application 42 is an application corresponding to another device 39. The other applications 42 and other devices 39 may correspond to any medical device. It is possible.

[0089] The device gateway 40 provides publish / subscribe data connections 58-64. Options 42, 43, and 44 also provide publish / subscribe data connections 49-57. The messaging pattern is implemented by the device gateway 40 and / or the application However, other embodiments may be possible. In , different messaging patterns can be used for communication.

[0090] The CQI listener 72 receives various data feeds from the applications 42, 43, and 44. The CQI manager 29 then subscribes to the CQI message and reports the CQI message to the CQI manager 29. This can be stored in the database 30. The CQI listener 72 can 9–57 and / or 58–64 report unprocessed results and / or those results The format can be set.

[0091] In some embodiments, the applications 42, 43, and 44 are connected to the devices 36-39, respectively. raw events from the device gateway (via a subscription to the topic registered by the device gateway 40) The application converts the format of the received CQI message into a CQI message. 42, 43, and 44 register CQI topics to be subscribed to by the CQI listener 72. Applications 42, 43, and 44 can add CQI messages to their CQI topics. The CQI message is then published by the CQI listener 72, which receives the CQI message. The listener 72 sends a CQI message to the cloud service 28 .

[0092] In a particular embodiment, a single GUI interface 33 is used to access the database 30. The CQI messages in the 36, 37, 38, and 39 can be seen on the other hand. It is possible to create a DAL file 35 that is used for software updates 34 and device updates. can be sent to the gateway 40 to update medical devices 36, 37, 38, and 39. Cut.

[0093] FIG. 3 illustrates an aggregation of several facilities 76-80 for communication, according to one embodiment of the present disclosure. FIG. 73 is shown to explain the procedure. Each of the facilities 76-80 has an infusion safety manager 74, etc. and a facility gateway 21 (see FIG. 2) for communicating with the cloud services of the In some embodiments, some of the facilities 76-80 are not in the group of facilities 76-80. One of a group of facilities that share a common fluid safety manager 74 that is not accessible to other facilities The group of facilities 76-80 of FIG. 3 communicate with the Infusion Safety Manager via communication link 344. Such a configuration would allow a group of facilities 76-80 to be integrated into an integrated delivery network. This can be used to create a larger organization such as IDN75.

[0094] FIG. 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, a cloud service 83, and Includes.

[0095] Hospital network 82 includes hospital information network 84, EMR 85, CPOE 86, P IS87, LIS88, Integration Engine89, Integration Capability Components90, Clinical State Manager JA91, Database92, 95, 98, Medical Application94, CQI Listener9 3. Pump Application 96, Syringe Application 97, Instrument Gateway In some embodiments, the system includes a firewall 99, a firewall 100, and a medical device 101. The systems 84-88 may be external to the hospital network 82. teams may be able to use medical applications 94.

[0096] Cloud services 83, databases 104, 105, 106, 113, fire A wall 103, a CQI receiving unit 108, a CQI server 109, a CQI UI 110, and Pharmacists and clinicians 111 are the DERS editors 112. 2 and / or CQI UI 110. The staff 107 interfaces with the CQI UI 110 and / or the DERS editor 112. The DERS Editor 112 and / or the CQI UI 11 0 may be a browser-based interface. The DERS Editor 112 and the CQI UI 110 are both browser-based and run on the same interface. It may be accessed from the interface.

[0097] HIS84 manages hospital management functions (e.g. admission, discharge, transfer, coding, billing, collection) EMR85 supports the recording of patients' medical history (encounters, examinations, diagnoses, CPOE86 allows physicians to track lab tests, prescribed medications, medical images, and other PIS97 is a system used by pharmacists to order prescriptions for clinical procedures. A departmental system used to receive, review, track, and fill medication orders. LIS88 is a system in which a laboratory technician receives an order for a clinical specimen (e.g., tissue, blood, urine, etc.). The hospital integration engine 89 is a department system used to receive and process information. Message transformation that allows systems 84-88 to interact with each other and with external systems. Most of these engines are capable of handling various dialects of HL7. The integration engine is located in the device gateway 99 and communicates with the hospital through the hospital integration engine 89. It can interoperate with HIS, EMR, and PIS. The device gateway 99 is Message routing, supporting both publish / subscribe and point-to-point routing mechanisms - Provides the engine. Device Gateway 99 also provides name resolution and capability registration functions. do.

[0098] Medications, nutrients, and hydration in liquid form via intravenous (IV), subcutaneous, or other routes Various devices 101, such as an infusion device that delivers fluid to a patient, are used in the treatment of the patient. Application 96 and Syringe Application 97 receive the unprocessed event, Filtering, analyzing, and resubmitting higher level interpretations to medical devices1 It is an application that gives software intelligence to the 101. Medical devices are classified into corresponding device applications, e.g. application 96-97 It can have one of the following:

[0099] Each infusion device of the device 101 is used to deliver a particular infusion fluid (e.g., in liquid form) to a particular patient. It is possible to control the delivery of fluids (hydration, nutrition, blood, or medication) at various loading levels. Dosage adjustments in the form of dose escalation or dose titration are considered separate infusion steps of a single parent infusion. Infusions or infusion events for the same patient as part of the same treatment can be The collection is considered as an “infusion story” and can be recorded in the CQI server 109. do.

[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, the patient, and the pump, and transfers the fluid from the infusion to the pump and the pump. The tubes can be connected from the pool to the patient and recorded in the CQI server 109. During the programming phase, the clinician enters the dosage parameters into the pump, and the pump Check the parameters using the updated DAL version (also CQI server 109 During the delivery phase, the pump delivers the specified volume of fluid to the patient as programmed. The liquid is delivered at the controlled speed.

[0101] Each medical device 101 may be configured to detect an alarm condition (i.e., a pump is not delivering fluid), and It can detect warning and advisory conditions that have serious safety consequences. Each medical device 101 may or may not have a secure connection with the device gateway 99. Each medical device may attempt to establish a secure network connection. The 101 records programming, delivery status, and exception events for each infusion. and providing them to the device gateway 99 as a CQI message. Each medical device 101 can report these events to the device gate 108. The device gateway 99 communicates the data to the device gateway 99 (directly or indirectly), In some embodiments, one of the medical devices 101 may be a device gateway. If the medical device is unable to establish or maintain a valid connection with the The medical technician 102 uses the medical application 94 to store the data in an internal buffer. Copy the saved events to a portable medium (e.g. memory stick) without using the In some embodiments, the medical device includes a USB cable coupled to the The event is recorded via a medical application 94 running on a personal computer. can be downloaded.

[0102] The medical application 94 allows a medical technician user 102 to monitor the health status of a medical device 101. Monitor, view log files, track maintenance activities, and update software / firmware. Provides a browser-based tool for managing your software installation. files, maintenance logs, and software / firmware installation and upgrades. Upgrade tracking data may be stored in database 95.

[0103] The device gateway 99 is a room-wide gateway that connects all devices 101 associated with a particular patient. In another embodiment, the device gateway 99 may be a facility gateway. In yet another embodiment, the device is a software application that can be executed on the device. Gateway 99 is software that runs on in-hospital equipment (e.g., a small computer). The Device Gateway 99 acts as a message router, service registry, and / or the Pump Use Authority Registry. Equipment Application 96-9 7. Register the message type and publish the message to the gateway device 99 One of the medical devices 101 (see other 37 in FIG. 2) (e.g., a PCA respiratory monitor) ) can be used to detect the presence of a medical device 101 that includes a sensor that can be plugged into the Data can be published via the Way device 99. Device application 96-9 7 can function as an "information refinery." Each device application 96-97 The gateway device 9 transmits messages from specific types of in-hospital equipment among the medical equipment 101. Each device application 96-97 subscribes to the device through the device gateway 99. C included in the event stream received from one or more of the medical devices 101 as needed. QI information, clinical information, and medical information can be combined. The device applications 96-97 transmit the higher level events to the device gateway 99. , or republish to other subscribers, such as CQI listeners 93.

[0104] In some embodiments, part of the CQI message is auto-documentation, auto-provisioning, This can be used for programming and billing functions. Now, automated documentation from Medical Device 101 to EMR85 and / or e Automatic programming of medical devices 101 from the MAR system (e.g. part of HIS84) CQI messages can be used for drug safety monitoring. Event and wait time information may be included.

[0105] CQI Listener 93 subscribes to events related to continuous quality improvement in drug safety, The CQI listener 93 ensures that they are transmitted to the host environment. The database 9 is used to periodically transmit the CQI to the CQI receiver 108 (through the call 103). Events can be stored in 8.

[0106] The CQI receiver 108, the CQI server 109, and the CQI UI 110 are in a host environment. 83 (i.e. cloud services). User queries and CQ In order to reduce data update inconsistencies, master / slave database replication (database replication) The database 105 is the master and 106 is the slave) is used in the host environment 83. The CQI server 109 can measure the response time to the top-level query and the presentation request. To shorten this time, the CQI events are post-processed into a (reportable) summary form, It can be stored in the database 105. The CQI UI 110 is based on a set of standards reporting (compliance, limit violations, escalation safety, stage events, and The CQI server 109 can provide more detailed DERS Editor 112 and It can support the query API used in the CQI UI 110.

[0107] The CQI server 109 uses the CQI UI 110 to provide analysis and query services. The CQI server 109 provides the user of the CQI UI 110 with a CQI message. It can provide a summary table (at configurable intervals) that aggregates and updates messages. The purpose of the table is to improve response times for top-level CQI queries. The following statistical indicators were used: (1) DERS limits for infusions and wildcards; (2) the programming mode used, including the infusion used, and the recommended and absolute limits; (3) Titration safety information, such as violations of titration up / down settings and dose limits; (4) Reportable clinical events by priority (e.g., RCE149 in Figure 5 below) ), and / or (5) reportable clinical events by infusion phase (e.g., as described below). These summaries can include the following: The data views, i.e. (1) organization name, (2) institution name (e.g., facility name), (3) nursing Subtotals can be calculated for area, (4), time, and / or (5) week.

[0108] By using the Web Service Query API, CQI UI110 and / or or DERS Editor 112, (1) the above filtered by the specified selector (2) RCE details by infusion; and / or (3) patient actual programming, restrictions, and infusion statistics (i.e. infusion cases) by patient, In certain embodiments, the DERS editor 112 and / or Any system or hosted service 83 can be a J2EE compliant application. The databases 104, 105, 106, and 113 can be based on a database server. A database management server can be used.

[0109] Once the J2EE and database management servers are installed and configured, the following shared Initialize the DERS database 113 by importing the database tables. (1) Reference tables for units of measurement, administration modes, etc.; (2) Administrative users, roles, privileges, and access control table for authorizations; (3) DERS drug list; (4) nursing supplies (5) Nursing Area List of the National Database of Quality Indicators (NDNQI), and (6) Attributes of Institutions and / or (6) the database tables required for the DERS Editor 112. Use the editor 112 to add or edit organizations, add or edit regions, and and / or add or edit access controls (if they are accompanied by attributes) (In some cases, it may not be accompanied by

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

[0111] The CQI UI 110 and / or the DERS editor 112 may be implemented in some specific embodiments. generates CQI reports and provides interactive Supports HTTP / Javascript interface for in-depth investigation actions It is possible.

[0112] The CQI message is received by the CQI receiver 108, which then The CQI message received by the CQI receiving unit 108 is stored in the database 105. If all of the received data cannot be processed at a predetermined speed and / or if the CQI receiving unit 108 has a buffer If the buffer is full, the CQI message is temporarily stored in the database 104 and When the load on the CQI receiver becomes lighter, the message is retrieved from the CQI receiver 108. , can be stored in database 105. Database 105 is database 10 6. The database 106 may include a CQI user interface 110 and / or DERS editor 112. It can be accessed by users via 09.

[0113] The records in the CQI databases 105 , 106 depend on the DERS editor 112 . The records include (1) a lookup table of units of measurement, modes of administration, etc.; (2) administrative users, roles, and privileges; , and an access control table for authorization, (3) the DERS drug list, (4) the ND (5) agency attributes, including a list of nursing areas in the NQI;

[0114] These references are DERS Editor Database 113 version dependent, Consistency is preferred. One option is to have consistency between databases 113, 105, and 106. This option is convenient, but it is not possible to share these tables between the two databases. The coupling between the base 113 and the bases 105 and 106 is increased. Maintaining read-only copies of those tables inside the QI databases 105, 106 and performs a procedure to update the table when the table is changed in the DERS editor 112. This can reduce the coupling.

[0115] The access control for the CQI databases 105 and 106 is structurally the same as that for the DERS database. The CQI server 109 has several users. It can be defined in the user but not in the DERS editor 112. For each user, permissions may be different (e.g. some CQI data may be read In some embodiments, the users and their permissions and access are managed by the The credentials can be stored in a user database 7000. can be placed in the host environment.

[0116] Certain database tables (e.g., reportable clinical events and statistical summaries) are CQI database 105, 106, and CQI database 105, 1 It can be built when 06 is created.

[0117] The CQI UI 110 and / or the DERS editor 112 each include a CQI server 10 9 (and thus the data in database 106), as well as the DERS Using the data obtained from the editor 112 (and therefore the database 113) The DAL file 114 can be generated using the

[0118] The Clinical State Manager 91 is the intermediary between the Device Gateway 99 and the Integration Engine 89. It coordinates asynchronous workflows involving several parties and components.

[0119] Pharmacists and selected clinicians111 used the DERS editor112 to review the institution's drug Define the limits and create a DAL file 114 (which can be in XML format, for example) Drug limits are set through a clearly defined, carefully controlled and well-documented process. Drugs can be defined using controlled release procedures. The limit values ​​can be specified using the DERS editor 112 of the DAL manager 5. The facility 82 uses common reference models for drugs, care areas, administration modes, etc. This can facilitate subsequent inter-agency comparisons. It must be run in a hosted environment 83 so that users can access it using a web browser. In some embodiments, the DERS editor 112 can be used without the need for a full browser. No client-side software is required to run DERS Editor 11. 2 is a database of drug limits and data organized by care area, drug, clinical use, drug concentration, etc. The DERS editor 112 can provide a default value. To improve the next DAL version by supporting the following query interface: It can aggregate search and analysis of CQI insights for:

[0120] In some embodiments, a prescription database 7002 may also be included. The database 7002 contains information about drugs and medications that may be included in various DAL files 114. The prescription database 7002 may include a master list. 112 and CQI server. 12 retrieves data from the prescription database 7002 when creating the DAL file 114. This ensures data consistency between the various DAL files. This can help facilitate comparison of multiple DAL files 114.

[0121] FIG. 5 illustrates a medical device 145 (e.g., an infusion pump) and a device app according to one embodiment of the present disclosure. 10 illustrates some aspects of communication between the application 151 (e.g., a pump application). 5. A pump 145 will now be described with reference to FIG. However, any other medical device may be used in place of or in conjunction with the pump 145. It is contemplated to create a vent 146 .

[0122] Block diagram 144 illustrates how events 146 (e.g., pump events) can be routed to the device gateway. A medical device 145 (e.g., an infusion pump) is shown communicating with the device 147. Pump Event 146 is a CQI message, or the basis of a CQI message, or a medical device. Other data include raw data from the pump 145. Pump events 146 are the events that These are operational parameters, fluid delivery parameters, and / or other operational events. In certain embodiments, the pump event 146 may be generated using a Web Services (“WS”) address. Using the Simple Object Access Protocol ("SOAP"), which uses the In some embodiments, the event 146 may be a full HTTP (or Representational State Transfer (REST) ​​can be implemented using the HTTPS protocol. Communication is performed using the IEEE 802.3ad version of the protocol.

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

[0124] [Table 1] TIFF0007617068000002.tif234155 TIFF0007617068000003.tif192150Table 1

[0125] Items labeled 1, 2, 3, 4, 5, 6, 7, 8, and 9 in Table 1 are pump events. When the medical devices 145 are not connected to the device gateway 147, The events are stored in a buffer in the local memory of the medical device 145. When the connection is terminated (and reconnected), those events are handled over a secure protocol, e.g. SSL. , SSH, symmetric key encryption, and / or asymmetric key encryption to the device gateway Published on 147th January 2014. Alternatively, these events may be copied onto a portable storage medium and manually As described above, the device gateway 147 may A publish / subscribe engine configured to pump events to interested subscribers; It may function as (or contain)

[0126] Referring again to FIG. 1, the pump event is a CQ related to the equipment event of equipment 26. These events can be used to send information to multiple facilities 10. For example, the entire fleet of medical devices 26 can be monitored across the entire fleet of medical devices 26. The status set 9.71 can be converted into a CQI message and then sent to the CQI manager. The user logs into the CQI manager 4 to plan a maintenance event. order new parts based on data and provide predictive or preventative maintenance and / or order new parts for preventative or predictive reasons. The user uses deterministic heuristics to decide what to order, when to order, and and / or determine when to call in some of the equipment 26 at various facilities 10 for maintenance. The CQI Manager 4 can be used to manage the supply chain of parts for the equipment group 26. It can be used to provide real-time information on the status of the equipment26. For example, a set of device hardware statuses can indicate the health of the internal battery. The battery information may include, for example, the battery current when fully charged, which indicates the battery status. For all or a subset of devices 26, the battery health status falls below a predetermined threshold. When the battery is replaced, the CQI Manager 4 can automatically order a new battery. Alternatively, the CQI manager 4 may request a battery replacement for the identified device 26. Can be scheduled automatically.

[0127] Referring again to FIG. 5, an equipment application 151 (e.g., to operate with a pump) The Gateway 147 can run a pump application (configured as follows): (Some implementations may use different hardware and / or software.) The device application 151 receives events published by the medical device 145. Subscribe now

[0128] The Pump application 151 processes the raw event stream to produce higher 149 refinement of clinical event streams into standard clinical events, e.g., reportable clinical events, The events are stored in a cloud-hosted database (e.g., database 30 in Figure 2) for storage. This may be reported to the service's server.

[0129] In some embodiments of the present disclosure, the device application 151 is message-driven. Deployed to a J2EE application server as a Multi-Database Bean ("MDB"). MDB The Java Message Service (JMS) topic, e.g. PumpTopic150 It is a stateless component that subscribes to messages and notifies the device when a message becomes available. The application server of Gateway 147 is running the device application in a worker thread. The application 151 can be started.

[0130] The device application 151 is a stateful component that is deployed in the institution. It maintains one instance of the pump handler 153 for each pump 145 that is created. The pump dispatcher 152 uses the pump 145 sequence number as a unique key to The call handler 153 holds a reference table of the call handler 153.

[0131] The Pump MDB uses the application server's naming service to name the Pump application. The pump MDB sends the pump 145 serial number to the The header is obtained by using the pump dispatcher 152 and the pump handler 153. Find the appropriate pump handler from the list. If an individual pump handler 153 is busy, If the message is not being processed (for example, if another message is being processed, or if the message is in a different thread), the pump MDB , and queues the message to the pump dispatcher 152 (which (Ensuring that messages are processed in order). Individual pump handlers 153 are used. If not, the pump MDB will handle the event in an individual pump handler 153. Each pump handler 153 maintains a set of finite state machines (“FSMs”), The FSMs include the pump FSM156, the program FSM157, and the delivery FSM158. The NI PXI Express 8038 processes a subset of relevant pump events (see Table 1 above), including:

[0132] The Pump FSM156 is the top-level state machine that handles events that do not belong to any infusion. Program FSM157 is started when the infusion programming context is started. It is a child state machine that is started and is responsible for handling infusion programming events. M158 is a child state machine that is started when the infusion begins and controls the actions taken during the infusion. Responsible for handling events. A secondary infusion (including loading, bolus, or titration) can be started while a primary infusion is in progress. Since the FSM157 and FSM158 may be programmed separately, Liquid FSM158 can be used.

[0133] A medical device 145 operating model, e.g., a pump FSM 156, is used to generate reportable clinical Construct Events (RCE)149 or Reportable Medical Events (RBE)14 8. For example, the pump FSM156 can complete one infusion and then interrupt Tracking the pump 145 when restarting another infusion that was running Track the programming of one infusion in between and / or multiple infusions that may occur at once. The Pump FSM can track two or more high priority operational alarms. 6 can contain nested state models.

[0134] Each pump handler 153 maintains programming and pumping context information. You can also maintain several context objects that The test object is recorded as a medical event (to track pump utilization) upon completion. The pump application 151 is generated and can be recovered if it needs to be restarted. The context object holds information about the infusion state, infusion mode, and infusion interval. The infusion status may include programming / adjusting for primary and secondary infusions. Contains infusion status data. Infusion modes are specific doses / rates (e.g. loading, bolus, and / or titration) programming / delivery status data. Infusion status (e.g. pump running, stopped, alarm on) over the duration of operation within one infusion mode When pump event 146 is processed, the respective FSMs 156 and 157 or 158 transitions to a new state and creates, updates, or was deleted and replaced with reportable events such as Reportable Medical Event 148 and Reportable Clinical Event 149. In certain embodiments of the present disclosure, the reportable event (CQI message) is output. A list of possible clinical events is provided in Table 2 below.

[0135] [Table 2] TIFF0007617068000005.tif187154 TIFF0007617068000006.tif140152Table 2

[0136] Referring to FIG. 4, the CQI listener 93 of FIG. 4 may be implemented within each facility 82. The CQI RCE 149 or 147 in Figure 5 connects to the CQI gateway (Figure 4 or Figure 5). The CQI listener 93 in FIG. A private communication that protects security is established between the CQI receiving unit 108 (see FIG. 4) in the boundary 83. This connection is a physical connection (always connected) that can be established using the It may be a logical connection (a temporary connection when a message is sent).

[0137] The device gateway 147 sends the RCE 149 or the RBE 148 to the CQI listener 93. The CQI listener 93 can determine the persistence of messages (i.e., network congestion). This ensures that messages are not lost during transmission due to interruptions or disconnections. As a result, the CQI listener 93 (1) stores each message to be sent in a local permanent queue. (2) store each RCE149 and / or (3) transmits the RBE 148 to the CQI receiving unit 108; and / or The message may be removed after receiving an acknowledgment from the

[0138] The CQI receiver 108 executes within the host environment 83. 108 waits for a request for a secure network connection from one or more CQI listeners 93. The CQI receiver 108 receives and accepts the RCE1 from each connected CQI listener 93. 49. The CQI receiver 108 can guarantee the persistence of the message. Therefore, upon receiving each RCE 149, the CQI receiver 108 writes the RCE 149 to the database 105. (1) Each received message (CQI message) is stored in a local constant (for buffering purposes). (2) store each CQI message in a permanent queue from the head of the queue as a CQI event (3) The CQI that is the sender of the message is added to the end of the table in the database. (4) notify the listener 93 of the receipt of the message, and (5) retrieve the CQI message from the local queue. (Because it is in the CQI event database 105 and is safe) Cut.

[0139] As mentioned above, the CQI event database 105 uses master / slave replication. That is, database 105 is the master and database 1 06 is the slave. Using this method, in some specific embodiments, There are two copies of the CQI event database with the master database. When the insert, update, and delete transactions are applied to 105, database 10 The database management system (DBMS) in the 5 writes the changes to a journal and The changes in knowledge can be sent to the slave database 106 .

[0140] Each CQI message (e.g., an RCE) can belong to a particular organization. Reference is made to a medical device (e.g., medical device 101 in FIG. 4 or medical device 145 in FIG. 5) that is in operation. and the Drug Administration Library (DAL) located on the device does not match the institution that published it. As a result, the CQI databases 105 and 106 are based on the DERS database. The ILO may require a list of institutions consistent with Rule 113.

[0141] FIG. 6 illustrates a programming method for an infusion device (e.g., in device 16 of FIG. 1) according to one embodiment of the present disclosure. 1 is a state diagram illustrating a method 161 of Start with a user who is available to take the

[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., DERS controller). (When DERS Compliance Exception Equipment is Used) Once programmed, the method transitions to state 165 where the drug is programmed. Ming is complete.

[0143] State 166 uses DERS-based protection and dose parameters are programmed into the device. If no limit violation is detected, the process transitions to state 165. If a limit violation is detected, the method 161 transitions to state 167. In the case of a recommended limit, the clinician (1) causes the method to proceed to state 165 by overriding the recommended limit, 2) Program the infusion attributes without changing the infusion content, if no new violations are found Proceed to State 165 and, if new violations are found, to State 167; or (3) Infusion. Change the content of the medication (e.g., change the medication, care area, clinical use, and / or concentration) ) may cause the method 161 to resume from state 166.

[0144] If an absolute limit is detected, the method transitions from state 166 to state 167. requires a state transition back to state 166 and allows clinicians to override the DERS violation. No riding is allowed.

[0145] The infusion method 161 can be canceled during a number of conditions. Programming state 162 allows the clinician to cancel the infusion before programming is complete. In DERS programming state 166, the clinician can The infusion may be cancelled before the infusion begins. If a violation of the limit is detected, the clinician can cancel the infusion.

[0146] In state 165, the medical device displays a "Start Infusion" button, and the caregiver presses the button to The medical device transitions to state 163 and the infusion begins. There may be a pause button on the interface that pauses the device when pressed. This transitions the device to state 164. In state 164, the user interface There may be a continue button which, when pressed, returns the device to state 163 and ends the treatment. Continue. A fatal error (a predefined set of errors) causes status 163 and / or 164 If so, the method 161 transitions to an end state.

[0147] When the infusion is complete, the pump sends an infusion complete message to the clinical support via the Device Gateway. The Clinical Server then sends the completion event to the prescription record. , formatting IHE Automated Documentation messages, e.g., Electronic Healthcare Management To update the patient’s electronic medical record (EMR)17 for recording in the record (“eMar”) and / or update hospital billing systems to document successful infusion of medication For example, the request may be sent to one of the facility IT applications 11 (see FIG. 1 ).

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

[0149] In this model, a publisher 171 distributes one or more topics 170 to a publish / subscribe engine. Topic 1: Use a publish / subscribe engine that allows users to subscribe to the Once a topic 170 is registered, one or more subscribers 172 can subscribe to that topic 170. In some particular embodiments, the subscriber 172 may provide a guarantee for the topic 170. A user can subscribe to a topic using a subscription. One of the publishers 171 is related to topic 170. When you post a related event, all subscribers to that topic will receives data from the publish / subscribe engine 169 .

[0150] A publisher in (Publisher 171) may register one or more Topics 170. Each topic 170 may be a unique topic. A subscriber 172 subscribes to one or more of the topics 170 to receive events therefrom. The publisher 171 may select a specific topic from the topics 170 (e.g., "First When you post an event to the topic "Topic 170", the first topic in the topic list is purchased. All subscribers who are reading the first topic in topic 170 will receive the event. Subscribers who are not subscribed to the topic will not receive the event. A subscription that subscribes to a topic (for example, a second topic) but does not subscribe to the first topic Participant 172 does not receive a send event that corresponds only to the first topic.

[0151] Topics 170 may, in some embodiments, provide a level of indirection; Publishers 171 and subscribers 172 can be anonymous. Publish / Subscribe Engine 169 allows communication to be one-way and asynchronous (e.g. "fire and forget"). The publish / subscribe engine 169 provides two-way, durable message delivery. Topic 170 permanent topics can be provided by the Publish / Subscribe engine. This ensures that messages are not lost even if the subscriber 169 fails. A persistent subscription used by the subscriber 172 will not miss messages when the subscriber 172 is not running. You can be assured that this will not happen.

[0152] The publish / subscribe engine 169 is part of the device gateway 22 and is included in the facility gateway 21. It can be part of any other software or a standalone application of Figure 1. The publish / subscribe engine 169 may be part of the device gateway 40 or part of the application 40. 1 to 44, or as a standalone application as shown in Figure 2. The application 169 is a part of the device gateway 99 in FIG. It may be part of, or a stand-alone application of FIG.

[0153] FIG. 8 illustrates a capability registration model 173 according to one embodiment of the present disclosure. The capability 175 is registered in the capability registry 174. The capability 175 is made up of interfaces and attributes. The interface can include two aspects of functionality: request / response pairs and notifications ( The attributes are service level attributes that specify limitations on the quality of delivery. The agreed parameters are (e.g. response time, error rate and recovery policy, cost, etc.).

[0154] An initiator 177 communicates with a capability registry 174 to discover capabilities 175 and bind to the capabilities 175. The initiator 177 then requests information from the provider 176 and receives a response. The capability registry 174 is part of the device gateway 22, Any other piece of software within the gateway 21 or a standalone application of FIG. The capability registry 174 may be part of the device gateway 40, The application can be one of the applications 41 to 44, or a standalone application as shown in FIG. The power registry 174 is part of the device gateway 99 of FIG. 6, 97, or as a standalone application of FIG. The trawler 174, in some specific embodiments, assists the publish / subscribe engine 169, and can be a substitute for the publish / subscribe engine 169.

[0155] FIG. 9 illustrates a drug list used to generate a DAL file in accordance with one embodiment of the present disclosure. A safety method 115 is shown. The method 115 is implemented in the system 1 of FIG. 1, the system 27 of FIG. 4, System 81, or any other electronic patient care system. Method 115 lists the many methods that can be used to generate a DAL file. This is just one example. It may vary depending on the embodiment.

[0156] Those involved in pharmacies, clinical nursing areas, etc. (e.g., 6, 7, 8, 9, 18, and 19 in Figure 1 ; or the user selected from 102, 107, and 111 in FIG. 4) is selected, and the DA It can help to generate and define the L file 35 (see Figure 2), and the DAL file 35 Drug type, clinical care group, clinical care area, mode (e.g., volume-based, flow-based) Consider the following: dose, weight-based, administration method (loading, bolus, ramp, etc.), concentration, etc. This includes any safety regulations for drug administration that may be taken into consideration.

[0157] Method 115 includes operations 116 and 117. Operation 116 includes operation 118 as a suboperation. 125 to 126, and operation 117 includes operations 126 to 127 as suboperations. Generate the DAL file and monitor its usage in act 117 to This helps to notify users of updates to Rule 35 (see Figure 2).

[0158] Operation 122 creates a DAL file, e.g., an initial DAL file with no field entries. In action 123, the selected Receives changes to the DAL file according to input from one of the users specified in In operation 121, for example, via the DERS editor 112 of FIG. Inspect the DAL file by running the medical device simulator through 12. After the inspection in step 121, the trial DAL file is published (electronically) in step 120. In action 118, the trial DAL file is approved. However, the trial version is not finalized. Operation 118 is a process for checking the "approval" of the web browser. Click the "Browse" button to browse the referenced file (e.g. by version number, creation date, etc.). This can be achieved through approving the use of the

[0159] In operation 119, the DAL file is published and sent to the medical device. In operation 125, the CQI The server retrieves reference data (i.e. drugs, care areas, administration modes, etc.) from the DAL file. Once the DAL is published, files containing drug records are shared between the hospital and the CQI environment. After the release of action 119, the medical technicians upload the DAL file to each device. In operation 126, the medical device may receive the CQI event. The CQI event transmitted in operation 126 is transmitted to the DAL The file may be generated during treatment performed by the device.

[0160] During operation, medical devices generate CQI events (i.e., CQI messages). I messages indicate when routine infusions were performed, when infusions omitted DERS testing, When recommended limits are exceeded or overridden, and / or when recommended limits or can contain information about whether absolute limits have been exceeded and whether treatment has been reprogrammed. Cut.

[0161] The CQI events are sent to the CQI server in operation 126, where they are collected and recorded. The safety officer maintains a report summarizing those events and, in action 124, Similarly, in operation 124, the drug may be further refined to provide in-depth investigation capabilities to identify opportunities to improve the drug. When pharmacists and clinicians query the CQI database, the next time the DAL file is published In this way, an opportunity to improve the drug record can be found. The message is analyzed or inspected. In action 123, the DAL file is modified to create a new You can create a new version of the DAL file and then use the new DAL files can be inspected, tested, and published.

[0162] In some embodiments, a DERS editor such as DERS editor 112 of FIG. Creating a DAL file using a Access the DERS Editor and use the DERS Editor user interface. By interacting with the DAL service, all persons or parties involved in the creation of the DAL file are In some embodiments, the DERS editor can be used to create the L file. No client-side software is required for access other than a simple web browser. In some embodiments, the DERS editor user interface includes a tab. It can be accessed through applications such as the DAL File. Any individual or party involved in the creation of the file must have a computer with Internet capability, a Access the DERS editor using a tablet computer, smartphone, etc. You can contribute DAL files.

[0163] Each individual or party involved in constructing the DAL file must have a specific role, responsibility, and Such roles can be determined by access control lists ( Assigned using ACLs and / or Role-Based Access Control (RBAC) models Roles and responsibilities are part of the methods you can use to generate the DAL file. Assign roles, responsibilities, privileges, etc. and structure the collaborative process. By assigning them, you can provide input and supervision for the generation of the DAL file. This will increase the number of DAs created in the collaborative process. This ensures that the L file is well-written and minimizes drug errors. The various roles and privileges of users are managed by the user device hosted within the hosting environment. In some embodiments, the number of entries may be stored in a database (not shown). Species roles and privileges may be stored in a DERS database.

[0164] The DERS Editor allows users to provide voluntary contributions, feedback, requests, comments, notes, It also allows you to provide explanations, questions, etc. and use them to build the DAL file, You can create a DAL file or improve the DAL file. If you notice any problems, concerns, or potential improvements during the application or daily use of the If so, the user may submit a change request to address it. Can be linked to CQI data or specific CQI reports to provide context to reviewers can.

[0165] CQI data can be easily accessed when contributing to a DAL file, if Some information is accessible to different users or stakeholders to different degrees. The data can be presented in an easily understandable form in the user interface of the DERS editor. In some embodiments, at least a portion of this data is presented as a graph, chart, or other visual representation. The user can use the DERS editor to remove unnecessary CQIs. You can also filter out data, allowing you to get a more concise view that focuses on the data you care about. The data set can be presented to users. The availability of this CQI data can be made available to individuals or can be used by stakeholders to help inform decisions about changes to various items. This data can also be used to evaluate the appropriateness of various entries in the DAL file. can.

[0166] Additionally, creation and modification of DAL files via the DERS editor is fully traceable Each entry or change made in the DERS editor can be Link it to a unique user login or ID associated with an individual or party Each item that can be modified in the DERS editor can be A stored history record of past comments, annotations, changes, requirements, parameter values, etc. Can be associated.

[0167] Possible roles and responsibilities of individuals and parties involved in collaboratively creating the DAL file An exemplary diagram showing the privileges and privileges is shown in FIG. 10. This exemplary diagram shows many possible This is just one example, and alternative embodiments may have different configurations. It is possible to combine or not include any of the following actors / stakeholders. Roles and responsibilities may also be different. As shown in the figure, roles, responsibilities, and privileges can be assigned to mitigate potential medication errors. This can encourage the creation of thoughtful DAL files that minimize the likelihood of In this exemplary embodiment, publishing a DAL file involves multiple inspections of entries and multiple users. The agreement of the parties is required.

[0168] Each party may use a DERS editor, such as the DERS editor 112 shown in FIG. In some embodiments, various parties may contribute to the AL file. Through the DERS editor user interface, which can be navigated in a browser The DERS editor can be accessed by typing: Other embodiments may include additional parties or may include fewer parties than shown. In some embodiments, some parties may be a single individual, while in other embodiments, some parties may be multiple individuals. In some embodiments, the at least one group of two different individuals. Parties may in fact be the same individual or party performing different roles. The parties shown include a drug library manager 200, a resource clinician 202, and an inspection pharmacist 20 4, pharmacy consultant 206, and clinical consultant 208. In an embodiment, the parties are administrators or editing users (Drug Library Administrator 200). and the users who perform the inspection (resource clinician 202, inspection pharmacist 204, dispensing consultant 206 and clinical consultants 208).

[0169] The drug library manager 200 may be one or more individuals, such as a physician, caregiver, or pharmacist. In some embodiments, the drug library manager 200 may be, for example, a pharmacist as shown in FIG. 8 and the safety staff 107 shown in FIG. 4. The drug library manager 200 includes Can be given administrator capabilities within the ERS editor, i.e. managing drug libraries A person 200 may have editing privileges, which allows him to edit all of the entries that he can change. This gives you the ability to make at least the majority of changes to the DAL file and ultimately oversee the proposed changes. The drug library administrator 200 may use the full range of functions of the DERS editor, but not all of them. The drug library manager 200 can access the majority of the drugs. Approve the finalized DAL file before it is released for use in the medical device There may be cases where you are asked to do so.

[0170] The resource clinician 202, in some embodiments, may be one or more of a physician, nurse, head of nursing, etc. In some embodiments, the resource clinician 202 is a person or persons responsible for care in FIG. In some embodiments, the resource clinician 202 may be a physician 7 and / or a nurse 9. 4 pharmacy and clinician. Resource Clinician 202, through the DERS editor, Ability to inspect AL files, comment, annotate, suggest changes, etc. The resource clinicians 202 can be divided into several subgroups: For example, resource clinicians 202 may, in some embodiments, be divided into care area groups. It is possible.

[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 FIG. Check all entries in the DAL file via the DERS editor and see if they may need revision. The inspection pharmacist 204 can check for any entries that may be related to the DAL. You also have the ability to comment, annotate, and request changes to various entries in a file. Cut.

[0172] The pharmacy consultant 206, in some embodiments, may be one or more individuals, such as a pharmacist. In some embodiments, the pharmacy consultant 206 is the pharmacist 8 of FIG. Consultant 206 can edit one of the entries in the DAL file via the DERS editor. or multiple parts may be reviewed. The pharmacy consultant 206 may review any parts that require revision. You can check for possible entries in the DAL file and There will also be the ability to comment, annotate and request changes to species entries.

[0173] The clinical consultant 208 may, in some embodiments, be a physician, a nurse, a nursing officer, a psychiatrist, In some embodiments, the individual may be one or more individuals, such as a network administrator, a security officer, or other appropriate personnel. The clinical consultant 208 is the head of nursing 7, the nurse 9, the medical technician 19, and the and / or a risk manager 6. The clinical consultant 208 may, in some embodiments, , the safety staff 107 in FIG. 4. The clinical consultant 208 Clinical consultants 208 may be involved in conducting pilot studies. Inspect, comment, or note a file entry or part of a DAL file entry. It has the ability to add explanations, etc.

[0174] As shown in FIG. 10, first, the DERS is set up in DERS setup operation 122. In this operation, various parties can be identified and assigned user IDs, This gives those parties different degrees of DERS functionality. So, let's divide the environment in which the DAL files are used into several different sub-environments or groups. This can be done according to the organizational hierarchy of the environment. For example, Divide one hospital into its constituent nursing groups (ICU, ER, NICU, oncology, etc.) It is possible.

[0175] In various embodiments, the roles, responsibilities, and privileges assigned to each party may differ. For example, in some embodiments, the DAL may be used in a variety of medical devices prior to release for use in the device. A greater number of parties may be required to approve a file. Various parties may be assigned greater or lesser degrees of software functionality. can.

[0176] One or more DERS medications are then selected in a medication list customization step 210. A list can be set up. As shown in the example conceptual diagram, a drug library The administrator 200 of the system may be the only party with the privilege required to do this. In some embodiments, this step may be performed by, for example, a pharmacist. In step 210 of the store customization, the DAL is used in one or more facilities. All available drugs can be collected in one list. If there are different names or synonyms for the drug, they should be defined and linked to the respective drug. Other information can be defined for each drug. The complete medication list created in step 210 will be used in subsequent steps to ensure consistency In some embodiments, the complete medication list can be stored in a master - Select a drug from the list or a drug provided by the DERS Editor Service In some embodiments, a complete medication list can be created by selecting The system selects various medications from a master list of medications stored in a prescription database within the host environment. It can be created by selecting

[0177] In the example of FIG. 10, the care area drug record step 212 The administrator 200 may perform substep 214 of selecting a drug and assigning a record. This sub-step identifies the specific subdivisions or nursing areas / groups of the agency that will be included. For example, the hospital may select the various medications identified in step 210. Now, consider the subset of drugs defined in step 210 as being used in the intensive care unit of a hospital. The drugs selected for each nursing group can be: Modify those drug records to meet the needs of each nursing area within that nursing group. For example, in this step, drugs for a particular care area can be It may have specifications for use, concentrations, limitations, etc. In some embodiments, this step , in addition to or together with the drug library manager 200 , which may be performed by one or more pharmacists.

[0178] Nursing Area Drug Record Step 212 Drug Selection and Record Assignment Sub-Steps Once 214 is completed, the verification sub-step 216 for each care area is performed by at least one This substep can be performed by the source clinician 202. and their records are reviewed and verified by nursing area. One or more nurses or doctors who are in charge of or work in a particular nursing area may be a resource clinician 202 to perform this sub-step for that care area. In this substep, the resource clinician 202 may select various medications by care area. Feedback on selections and recordings can be provided.

[0179] Inspection step 218 checks the nursing area medication record for medications taken in step 212. Check the selections and records to ensure they are appropriate and correct. In the example in Figure 10 In the editing and revising sub-step 220, the drug library manager 200 Edit and change records that may require action. This includes the Nursing Area Drug Records. The feedback and requirements generated by the resource clinician 202 in the code step 212 Also, other parties involved in the review step 218 may be involved in the review step 218. This can also include addressing any feedback, concerns, requests, etc. .

[0180] In the inspection step 218, at least one person performs the substep of the inspection 222 for each nursing area. This substep can be performed by the selected resource clinician 202. Medications and their records are reviewed by nursing area. In hospitals, certain nursing areas One or more nurses or physicians who are responsible for a particular area of ​​care or who work in that area can be a resource clinician 202 performing this sub-step for the care area of In this substep, the resource clinician 202 selects various medications and and provide feedback or request changes to records.

[0181] Also, the sub-steps of the Inspection Between Nursing Areas 224 and the Inspection of Nursing Groups 226 The steps can be performed by the inspection pharmacist 204 and the dispensing consultant 206, respectively. In the cross-care area inspection substep 224, the selected medications and Those records are reviewed by the reviewing pharmacist 204 and any concerns, suggestions, requests, etc. are addressed. A feedback can be generated to indicate the result of the nursing group inspection 226. In this program, pharmacy consultants 206 review the drug lists, drug records, and Pharmacy consultants can review feedback indicating concerns, suggestions, requests, etc. There may be multiple staff members, each of whom is assigned to a specific nursing group. In some instances, the pharmacy consultant 206 may also review other records. For example, in some instances, the pharmacy consultant 206 may be aware of the risks associated with incorrectly delivered medication. Records of all drugs within the institution that are considered high can also be reviewed.

[0182] In the trial creation step 228, all the parties (and potentially 10 ) through steps 210, 212, and 218. In the test creation step 228, Various parties use the pump simulator in the DERS UI to test all the equipment in each care area. In some embodiments, a temporary DAL file can be created by The DAL file can then be sent to the test medical device. The UI of the device can be inspected and checked by various parties. The feedback generated by the various parties involved will be addressed and any necessary changes will be made. You can make changes to the DAL file if you want.

[0183] To complete the DAL file, the DAL file must go through approval step 230. In this step, the various parties approve the DAL file and Therefore, it can be made publicly available to medical devices within the institution. In the example of Figure 10, The DAL file must be approved by the resource administrator 200 and the resource clinician 202. Depending on the implementation, parties may be required to approve the DAL file before it is published. There may be more or less. After the approval step 230, the DAL file The files can be made public for use within the institution.

[0184] In various embodiments, the DAL file can be organized hierarchically. The L file contains multiple top and bottom entries that specify settings for the DAL file. The entries can contain multiple entries or parent entries and child entries. As you go down the hierarchy, the entries in the DAL file become more specific. For example, a parent entry can broadly define parameters, restrictions, etc., and a child entry can Entries can be further refined or narrowed down by their parameters and restrictions. do.

[0185] Figure 11a shows an example of a hierarchical structure of a DAL file. As shown, the hierarchy shown in Figure 11a An example of a hierarchical structure resembles an institution / organization hierarchy. In some embodiments, the hierarchy of the DAL file The hierarchical structure may vary. For example, some DAL files may contain the nursing group Some do not include groups and / or organizational hierarchies. This is particularly true for small, independent institutions. This may be the case for DAL files used in.

[0186] As shown, the top level of the example hierarchy for a DAL file is the group in which the DAL file is used. Under the organization 2350, there are constituent mechanisms that make up the organization 2350. Depending on the DAL file, the authority 2352 can be placed in the DAL file. This may be the top of a file hierarchy. This applies to cases where a DAL file is created in 352.

[0187] Each institution 2352 can be divided into several nursing groups 2354. Each care group 2354 may include several care areas 2356. 2354 is an organizational category to which some care areas 2356 may belong. For example, several ICU-type nursing areas 2356 (e.g., neonatal, pediatric, adult, medical, Grouping ICUs (surgery, cardiac, neurology, trauma, burn, etc.) into ICU nursing groups 235 4. Each care area 2356 may have associated therewith The drug or medication record 2358 may include several unique drug or medication records 2358 that have been selected.

[0188] At various levels of the hierarchy, several parameters can be defined. The parameter definition can be the process by which the DAL file is created. The parameters are not limited to, but include, various operation settings, data format settings, medical device settings, etc. Acceptable input ranges or values ​​of data in devices, treatment and medical device safety measures (guardrai l) and restrictions. There are several settings that can be defined in the DAL file. Certain examples are described throughout this specification. Other settings may also be included in some embodiments. In some cases, values ​​defined at a higher level in the hierarchy may be overridden by values ​​defined at a lower level in the hierarchy. It can act as a parent value for other values ​​that are added.

[0189] In some embodiments, the same parameter may be defined at multiple levels of the hierarchy. In such an embodiment, when a user specifies a parameter value at a lower level in the hierarchy, the child parameter The meter value (defined at a lower hierarchical level) is always the same as the value defined for the parent parameter ( The user can choose to use the default values ​​defined at a higher hierarchy level. In some embodiments, the user can change the value to a more restrictive value. For example, a user may be able to set an absolute upper limit for the patient's weight. Let us define the value at the level of the nursing group. The same parameters can also serve as default settings in the nursing area. If the group includes a care area for pediatric patients, the user may want to set a high absolute patient weight limit. They may want to be more restrictive and may be permitted to do so. Such parameter value inheritance makes it easier to create and improve DAL files, This can improve ease of use and efficiency.

[0190] As another example, care group 2354 may have several medications associated with it. The nursing group 2354 can be assigned to a nursing area 2356 level. The medication record 2358 corresponding to the medication is associated with that particular medication appropriate for that particular care area 2356. The clinical use and concentration of a particular drug may be specified. In the nursing group 2354 consisting of five nursing areas 2356 used by Instead of adding it once for each nursing area 2356 in the loop 2354, Simply add the drugs you want to use to the level of Nursing Group 2354. Adding a drug to will result in adding that drug to nursing area 2356 for that nursing group. In some embodiments, the user may also select a care group 2354 level. You can define some or all of the parameters for each common drug in the group. The parameters are then calculated for each child in each care area 2356 in the care group 2354. This may be inherited as the default value for the parameter. This makes it easier to create and improve files while increasing ease of use and efficiency.

[0191] Also, in some embodiments, some levels of the exemplary DAL file hierarchy may be For example, a drug record 2358 can be divided into a general drug setting These can be divided into settings for clinical use and settings for specific concentrations of the drug. Each lower level can then have its own hierarchical structure.

[0192] FIG. 11b illustrates another exemplary embodiment of a DAL file hierarchy 4500. As shown: The DAL file hierarchy 4500 shown in FIG. 11b has several differences compared to the hierarchy shown in FIG. Other embodiments may include different levels or a different number of levels. The user must create a DAL file for each level shown in the diagram. Various parameter values ​​may be defined. In some embodiments, the same parameter A meter value or associated parameter value can be defined at multiple levels of the hierarchy. In such cases, values ​​defined at higher levels in the DAL file hierarchy 4500 are Serve as a parent value for the same or related values ​​at lower levels in the file hierarchy 4500 The DAL file hierarchy consists of the higher levels of the 4500. Note also that there may be multiple components at each level of 11a, multiple nursing groups 2354 may constitute one organization 2352. can be done.

[0193] As shown in FIG. 11b, the top level of the DAL file hierarchy 4500 is the IDN or organization 23 50. The next level down is Region 4502. This level is where the IDN is This may be included in cases involving several institutions spread across a geographic region. Use this level of hierarchy to group similar institutions (e.g., emergency care centers, clinics, etc.) You can create groups of:

[0194] The next level in the DAL file hierarchy 4500 is shared. The user is at level 23 of the institution. 52, various settings can be defined. The user also defines general settings 4504. The user may also define drugs and drug categories 4506 at this level. In some embodiments, this can be done at a higher level in the DAL file hierarchy 4500. They may be done in separate batches, with a master drug list for one institution and then , which can be defined by dividing it into several categories. Parameters for drugs and category 4506 can also be defined. DAL File Hierarchy Any value defined at this share level in the 4500 will be added to the DAL file hierarchy 4500. This can act as a parent setting for the protection group 2354 level.

[0195] The user can enter various parameters at the nursing group 2354 level in the DAL file hierarchy 4500. A user can define one or more defining the medication records 2358 and parameters of those medication records 2358; The various parameters defined in the nursing group 2354 can be It can act as a parent configuration for any medication records 2358 defined in The parameter settings for the nursing group 2354 are It can also act as a parent preference for 356 entries. It can also be used for nursing groups. The medication record 2358 defined in 2354 and its associated parameters are The care area 2356 in the group 2354 may be automatically included.

[0196] The user can enter various parameters into the nursing area 2356 level of the DAL file hierarchy 4500. A user may define one or more medication records per care area 2356. Codes 2358 and parameters of those medication records 2358 can be defined. The various parameters defined in the nursing area 2356 are Can act as a parent setting for any medication record 2358.

[0197] As shown, the medication records 2358 are divided into several sub-levels. In the exemplary embodiment of b, the medication record 2358 includes a sublevel of medication 4508, The lower level of the master drug list is the highest level in the internal hierarchy. You can select drug names to fill in the lower levels of this hierarchy. This is done by Any parent value defined for the drug in the Drug Category List or Drug Category List The user can define further parameters at the drug 4508 sublevel. Any value defined at the lower level of a drug 4508 may be used in clinical use 4510 The user can use the Clinical Use Various parameters can be defined at the level below 0. Their values ​​are expressed in terms of cardinality 451. It can act as a parent value for the next level down. It may also be possible to define various parameters at a lower level.

[0198] 12-71 are several diagrams illustrating in detail some aspects of the use of the DERS editor. Exemplary flow charts are shown. The steps shown are merely exemplary. In other embodiments, the use of a DERS editor Usage may differ from that shown and described in Figures 12 to 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. Some of the flow charts shown in the figures are illustrative of the many possible ways of achieving the same result. It should also be appreciated that this is merely an example in detail; many embodiments may achieve the same end result. The present invention includes several alternative workflows that can be adopted to achieve the above-mentioned object. For the sake of brevity, not all alternative workflows contemplated within the scope of this disclosure are illustrated in the figures. The flowcharts shown and described in Figs. 12 to 71 are not , may be relevant to the various screens being described.

[0199] Figure 12 shows the DERS setup 122 (see Figure 9 for example) stage of creating a DAL file. 1 is a flowchart detailing some example steps that may be part of a The steps detailed in the flow chart of FIG. 12 are performed to This can be done before using the editor. The user can log in to the host IT environment of the host environment 83 in FIG. In some embodiments, a user may be part of a DERS editor service. In step 242, the user is the administrator of the DERS database in the DERS host environment. The DERS database, in some embodiments, is shown in FIG. 1 shows the DERS database 113. In step 244, the user You can run a database loading script based on this. The loading script allows you to load the DERS reference tables into the DERS database. The loading script is available to all institutions that use the DERS Editor Service. You can load DERS reference tables used by your organization. Reference tables include drugs, medications, and Alternative names for items, alternative drugs, drug incompatibilities, types of care areas, roles, units of measurement, comments The type, approval / validation status, various attributes, etc. can be loaded into the database. In step 246, the database loading script was verified by the user to be correct. In step 248, the user selects an instance of the testing institution's DERS. In step 249, the user can use this instance to ,The lookup tables loaded into the DERS database can be ,checked for correctness. The steps detailed in the flowchart in Figure 12 are performed by directly accessing the DERS host environment. This can be done by the administrator or by a user with remote access.

[0200] Figure 13 shows the procedure used to update the lookup table loaded into the DERS database. A flowchart detailing some exemplary steps that may be taken in some implementations is shown. In an embodiment, the lookup table may be the lookup table described with respect to FIG. At time 0, the user logs into the DERS hosting environment. The user is In some embodiments, the user may be part of the DERS environment. In step 252, the user is the administrator of the DERS host environment. You can log in to the DERS database. The DERS database is In the embodiment, this is the DERS database 113 shown in FIG. You can run a database update script on the DERS database. The new script can update the DERS lookup table in the DERS database. The update script must be used by any institution or organization that uses the DERS Editor service. In step 256, the database update may be performed by updating the DERS lookup table used. The user can verify that the script is correct. In step 258, the user A laboratory DERS instance can be loaded. This instance is then loaded in step 259. The user uses the instance to check whether the reference table updated in the DERS database is correct. The steps detailed in the flowchart of FIG. By users with direct or remote access to the RS host environment. It can be done.

[0201] Figure 14 can be used to establish a hierarchy of institutions and organizations in the DERS database. A flow chart showing some exemplary steps is shown in the flow chart of FIG. The various steps are described in the DERS setup 122 for creating a DAL file (see for example Figure 9). In step 260, the organizational structure of the institution or organization may be determined as part of the In the simplest case, a single entity with its own DAL and no parent organization is created. In other cases, an organization may contain several different agencies, All of the agencies use the same DAL. In some cases, an organization may use several different DALs. DER includes an authority that can use at least two different DAL files. If the database is used by an organization, include a field for the organization name. The name can be used for data comparison within the organization and can be used for Certification from agencies within the organization. It can be included in the QI message.

[0202] Step 262 creates the loading / update scripts for the organization schema. In step 264, the user logs into the DERS host environment. , may be part of the host IT of the host environment 83 of FIG. The user is an administrator of the DERS editor service. You can log into the DERS database in the RS host environment. DERS data In some embodiments, the base is the DERS database 113 shown in FIG. In step 268, the user is prompted to run a database update script against the DERS database. The update script can update one or more A new database can be created. In step 270, a database update script In step 272, the user can verify that the script is correct. It is possible to load an instance of the DERS for use by the user. Use to verify that the updated organization schema in the DERS database is correct. The steps detailed in the flowchart of FIG. 14 may be implemented in a DERS host environment. This can be done by users with direct or remote access. .

[0203] Figure 15 can be used to grant subscribing institutions access to the DERS editor. 2 shows a flow chart illustrating some exemplary steps. In step 280, an institution or To allow organizations to register for DERS services with DERS editor service providers In step 282, the contract for the new institution or organization can be signed. In some embodiments, this can be configured to Set up a database and application server for a new institution or organization. In some other embodiments, this may involve setting up a new institution or organization. In some cases, new data sets may be created in existing databases for the organization. The database and server of the DERS Editor Service are hosted in the host environment. This can be done by the corresponding host IT. In some embodiments, step 282 is , which may involve performing the steps detailed in FIG.

[0204] In step 284, a DERS editor service employee (e.g., host environment 83 in FIG. 4) The host IT) can create user accounts for users of the institution or organization In some embodiments, the user may be a user such as a drug library manager 200 shown in FIG. The access information for that user account is also included in this step. In step 286, the institution or organization may provide the user with the information. In some embodiments, users of the organization can log into the DERS editor. The institution's user may also be required to change their password in step 286. Step 288 provides training to institutional users by DERS Editor Services staff. This allows users at the institution to access the DERS editor. do.

[0205] There are several tools that can be used to set up various aspects of DERS within an organization or institution. A flow chart detailing exemplary steps of is shown in FIG. Using the exemplary steps shown in the flowchart of 16a, the users, Groups can be defined, as well as various permissions and privileges for each user. The steps shown can be part of the DERS setup 122 phase (see, for example, FIG. 9). In step 300, a user can log into the DERS editor. The user, in some embodiments, is the drug library manager 200 of FIG. This can be done by accessing the DERS editor user interface: As mentioned above, the user interface is accessible via a suitable web browser. Step 3: In step 02, the user enters the user editor on the DERS editor user interface. The user can then proceed through steps 304, 306, 308, and 310. Either can be done.

[0206] In step 304, the value of group permission for group A is changed. In step 306, Change the value of group permission for group B. In step 308, change the group permission for group C. In step 310, the value of group permission for group D is changed. Groups A through D can represent the various categories of agency employees that may exist. For example, Groups One group of groups A to D was assigned to the pharmacist group, another to the medical technician group, and another to the The nursing manager group and the last group can be the safety officer group. In some embodiments, there may be other groups corresponding to other categories of agency or organization employees. Groups may be user-defined in some embodiments. In the form, groups are predefined and provided by the DERS Editor Service. In some embodiments, a group may have a default set of group permissions. In some cases, the group does not include the user, but assigns permissions based on a specific user. Some contain subgroups (not shown). Users may select groups that best suit the needs and / or current structure of their institution / organization. You can customize groups or subgroups.

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

[0208] [Table 3] TIFF0007617068000008.tif62149

[0209] Continuing to refer to FIG. 16a, in step 312 the user also selects to create a new user. This allows you to define a username and a temporary password for the new user. This may involve providing an email address for the new user. The user may then select any of steps 314, 316, 318, and 320. If the user selects an existing user in step 313, the user can also From here, choose to proceed to either steps 314, 316, 318, or 320. In step 314, the user may create a new user or an existing user. In step 316, the user can assign the newly created A new or existing user can be assigned to group B. Step 318 Now, the user can assign newly created or existing users to group C. In step 320, the user can create a new user or an existing user. In some embodiments, the user can assign the newly created A created or existing user can be assigned to more than one group. In an embodiment, a user may assign a newly created user or an existing user to another group. including additional steps (not shown) that can be assigned to groups or subgroups. Good too.

[0210] Step 321 tells the DERS Editor Service to save the changes to the database. In some embodiments, the database may be the DERS database 113 of FIG. In other embodiments, the database may be, for example, a user database in a hosted environment. In step 322a, the DERS editor service notifies the appropriate For example, when a new user account is created, If so, the new user may be notified. In this state, an automatically generated email message is sent to the new user. This message will be displayed when the DERS editor is installed in a suitable web browser. In an embodiment where the DERS editor is accessible via This message provides account information and It may contain instructions detailing how to use the DERS editor. It may also contain the word and access information for the newly created user. Alternatively, This information may be manually provided to new users.

[0211] Figure 16b shows the users, the groups to which each user belongs, and the various permissions and A flow chart detailing some example steps that can be used to define the The exemplary flow chart shown in FIG. 16b is a web browser based Here are some steps that can be used for the DERS Editor service. On the 4400, a user logged in to the DERS editor and used the user editor. In step 4402, a web browser corresponding to the DERS editor is The hierarchy can then render the user editor page, and the user can create a new You can choose to add a new user or update / delete an existing user.

[0212] In step 4404, the user may indicate that they would like to add a new user. Then, in step 4406, the web tier corresponding to the DERS editor is added to the user-added page. Then, in step 4408, the user is prompted to create a new user. You can add various user metadata about the new user. Once the user metadata is added, in step 4410 the web tier registers the new user In step 4412, the new user data This database can be inserted into the DERS database shown in Figure 4. The database may be a data server database 113, or a user database within a hosted environment.

[0213] When new user data is added to the database, or when the user When the user indicates that they wish to update an existing user, in step 4416 the web tier updates the user. In step 4418, the requested user's privileges and information can be retrieved. A query record set can then be constructed and sent to the web tier. In step 4420, the web tier retrieves the user editor instance for the selected user. In step 4422, the user may select a desired interface. You may make edits to the content and submit any changes you may have made. This includes, but is not limited to, changing group assignments, changing privileges, deleting users, and changing user responsibilities. In step 4424, the web tier may In step 4426, the edited user data is The information may be written or stored in a database. A success notification is sent to the web tier to inform it that the database update was successful. In step 4428, the Web tier displays a dialog box indicating success. to let you know that your account information has been updated.

[0214] Figure 17 shows a table of functions that can be used to update various aspects of a DERS within an organization or institution. 1 shows a flowchart detailing some exemplary steps that can be performed. Using the exemplary steps illustrated in the flowchart of FIG. 17, the users, You can update the groups and various permissions and privileges for each user. Step 3 At 30, a user may log into the DERS editor. The user is the drug library manager 200 of FIG. 10. This is the user of the DERS editor. This can be done by accessing the user interface. The user interface can be accessed via a suitable web browser. , no client-side software is required. Then, in step 332, the user You can go to the user editor on the S Editor user interface. The user can then perform any of steps 334, 336, and / or 338. Performing these steps is shown and described in conjunction with Figures 16a and 16b. In step 334, the user The user changes various permissions for a group, for example, one of groups A to D shown in FIG. 16a. In step 336, the user can add the user to a previously created group. You can do this, for example, to add a newly hired employee to a group. In step 338, the user is granted access to the DERS editor. In some embodiments, this step can be performed by changing the permissions of users who have In some embodiments, this step may be included, but This does not include steps 334 and 336, which are for relatively large and / or complex institutions. The latter may be more appropriate for smaller institutions or those with a small total number of DERS editor users. Once the user has finished updating various aspects of the DERS editor, Then, in step 339, the DERS Editor Service updates the database with the changes that were made. This database may be the database 113 in FIG. In this embodiment, the database is a user database. The service can notify affected users of updates. This is done by automatically generating This can be achieved by sending an email to the target users.

[0215] Figure 18 may be used to create or update an institution's / organization's master drug list. A flowchart detailing some exemplary steps that may be taken in some implementations is shown. In an embodiment, the steps illustrated in the flow chart of FIG. 18 are carried out in accordance with the method described in connection with FIG. This may be part of customizing the list 210. In step 350, the user Proceed to the institution's or organization's medication list on the DERS editor user interface. Then, in step 352, the DERS editor service displays the medication list editor. The user may, for example, use a drug library manager 200 of FIG. In other embodiments, the user is a pharmacist or a user with permission 0. 04. When navigating to the institution or organization's drug list, the user is Import a drug list from the RS Editor Service or import a drug list from the DERS Editor Service. You can select one or more drugs from the master list provided by the do.

[0216] If the user chooses to import the list from the DERS Editor service, On step 356, the DERS Editor Service prompts the user to select the medication list to be imported. This step can be done by the DERS Editor Service or the DERS Editor. A list of available lists stored in a database associated with the service. In step 358, the user selects the desired list. Then, in step 359, the DERS editor service The user can update the institution / organization's drug list to include the added entry. If the user wishes to add more drugs to the institution / organization's drug list, the user must create another drug list. Master Drug List accessed through the DERS Editor service or Allows users to update or create an institution / organization's drug list. Once this is complete, the user can proceed to step 366. This will be explained later in the specification.

[0217] If the user does not import a drug list, or if the user imports and adds a drug list If the user wishes to add a specific medication, the user may proceed to step 360, The desired medication may be added to the institution's / organization's medication list. The RS Editor Service selects the drug to add to the drug list as shown in step 361. Such drugs may, in some embodiments, be: Selected by the user from the master drug list provided by the DERS Editor Service Then, in step 362, the DERS editor service The user may be prompted to enter an alternate or other name for the agent. The user may provide an alias. In step 364, the DERS editor service may prompt the user to provide additional information about the added medication. In step 365, the user may provide additional information, if any. If the user wants to add other drugs to the institution / organization's drug list after completing step 365 The user decides whether to import a medication list or select medications from a master list. , one can proceed as above.

[0218] Once the user is finished adding medications to the medication list, the user may proceed to step 366. At step 366, the user can indicate that they are done adding the medication. Then, in step 367, the DERS Editor Service processes the created or updated feature. The user may be prompted to save a list of medications for the institution or organization. At step 368, the user may save the created or updated medication list. This allows the medication list to be stored in a database such as the DERS database. Then, in step 369, the DERS Editor Service contacts the applicable user of the institution or organization. The DE can notify the user that a medication list has been created or updated. RS Editor Services is the sole responsibility of any person responsible for creating or maintaining a medication list for a care area. All users should be notified that an institution / organization drug list has been created or updated. can.

[0219] Referring now to FIG. 19, the following table shows the steps for adding a Clinical Advisory entry to the database: A flowchart is shown detailing some exemplary steps that can be performed. Clinical advisories can provide information about medications to users of medical devices. The information may include dosing guidelines, information from the prescription, contraindications, etc. In this case, the clinical advice may be presented in the form of text, images or graphics, and / or electronic format such as PDF. The clinical recommendation can include any desired content. Free text entry may be possible. Depending on the embodiment, several types For example, in some embodiments, a short text clinical recommendation may be included. The clinical advice may contain a short text message and a detailed clinical recommendation. For example, limit the text size to 40 characters to facilitate graphic user interfaces for medical devices. It can be made visible.

[0220] These steps are part of the Customize Medication List 210 step described in connection with FIG. At step 370, the user navigates to a clinical recommendation list; and Users can import clinical recommendation lists from the DERS Editor Service or create their own clinical recommendations. The user can decide whether to add the recommendation to the Clinical Recommendations list. If you decide to import the data from the DERS Editor Service, you can do so in step 372. If the user decides to add their own clinical recommendations to the list, If so, the user may proceed to step 374 and add a clinical recommendation. Repeat step 374 as many times as necessary until you have added clinical recommendations to the warning list. In step 376, the user logs out and can access the clinical advisory list of the institution or organization. Changes can be saved to the DERS database. In step 378, the DERS editor service notifies all relevant users The bed recommendation list may be updated. The form includes automatically sending emails to affected users to notify them of the changes. Good too.

[0221] In some embodiments, a user may upload files (e.g., images, documents, etc.) to a clinical advisory. In some embodiments, a clinical recommendation may be included. The FDA cannot add to or modify any of these recommendations at the clinical level. can be added to a medication record if the medication record is defined by the user. In some embodiments, the user can view the clinical uses of the drug, as well as various clinical uses of the drug. and concentration can be defined.

[0222] Figure 20 shows some examples of settings that can be used to change the general settings of an institution or organization. A flowchart detailing the key steps of the DERS is presented. This can be done as part of the setup 122 (see, e.g., FIG. 9) step. 380, the user can select the General Settings list on the DERS editor user interface. As mentioned above, the list can be accessed via a suitable web browser. In some embodiments, step 381 may include a The DERS Editor service prompts the user to enter values ​​for various general settings. Then, in step 382, ​​the user may be prompted to change or enter desired values ​​for the general settings. In step 384, the user logs out and returns to the general settings. The changes made can be saved. The changes can be saved to the DERS database. Then, in step 386, the DERS editor service In certain embodiments of the present disclosure, the user may be notified that a general setting has been changed. A non-limiting list of possible general settings is given in Table 4 below.

[0223] [Table 4]

[0224] Figure 21 shows some of the options that can be used to add a nursing group to an institution or organization. 11a to 11b are flowcharts illustrating some exemplary steps in detail. As explained in detail in relation to b., within the DAL file, organizations or institutions can be identified as e.g. into a number of sub-areas or groups reflecting divisions within an organization or institution The steps shown in FIG. 21 are implemented as a DERS setup 122 (see, e.g., FIG. 9). In step 2370, the user enters the user ID of the DERS editor. In step 2372, the user proceeds to the nursing group list on the user interface. Select to add a new nursing group to the list. When adding a new care group, the user may have several options. In this embodiment, the user starts with a blank or nearly blank template. In the flow chart of the embodiment shown in FIG. 21, the user can select an existing care group. You may also choose to copy information about the group to expedite the process. If the user selects to copy an existing care group, the user proceeds to step 237 Continue with step 4. In step 2374, the user specifies an existing nursing group that they wish to copy, and Then, in step 2376, the user copies the care group. Change the type of the nursing group by changing the type to a new nursing group type In some embodiments, the user may set up a care group in step 2376. It can also be adjusted.

[0225] If the user chooses not to copy an existing care group, or if the user chooses not to copy an existing care group, If no loop exists, the user may proceed to step 2378. At 78, the user specifies the type of new care group to be added to the list. The steps may include selecting a care group from a list of possible care group types. A nursing group type may represent multiple nursing areas within an institution or organization. Can be a broad category. Examples of nursing 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 selects the nursing care group that is used within the institution or organization. Users can change the name of the care group to match the name displayed in the status bar. In step 2382, specify the various users that will be associated with the newly created nursing group. For example, the user may select in step 2382 that he or she works in the nursing group, and The user can specify several clinicians who will be responsible for that nursing group. May be responsible for reviewing old nursing groups or contributing to new nursing groups. The person in charge may also designate other individuals within the institution or organization that is responsible for the designation.

[0227] In step 2384, the user selects various care group settings for the new care group. You can define parameters, which change the default values ​​or use the empty template. This may involve filling in the blanks, modifying the copied values, etc. A non-limiting list of possible nursing group parameters is given in Table 5 below.

[0228] [Table 5]

[0229] Once the care group parameters are specified, step 2386 allows the user to save the new values. Nursing groups and parameter values ​​can be stored in the DERS Editor database. The user can then save the new care group in step 2388. The group is now available for inspection by the person responsible for inspecting the nursing group. Then, in step 2390, the DERS editor service Notify appropriate users that a nursing group has been created and is available for inspection. This can be done via an automatically generated email.

[0230] In some embodiments, similar steps may be followed to add, for example, a care area to the DAL file. You can add the images used in the DERS editor user interface. Although the aspects may be different, users can provide similar information and parameters for the care area. In some embodiments, one of the care group parameters shown in Table 5 can be defined. Departments may instead be defined at the nursing area level or may also be defined at the nursing area level. The parameters for the nursing group act as parent parameters for the nursing area. For example, a parameter for a nursing group can be modeled after the same parameter at the nursing area level. The user can also define care groups. A list of medications that may be used within the nursing group when This can be accomplished by following steps similar to those shown and described in connection with FIG. This can be achieved by:

[0231] FIG. 22 illustrates some exemplary care areas that can be used to add care areas to an institution or organization. A flow chart is shown which explains the steps in detail. As explained, you may wish to separate an organization or institution into groups, for example to reflect a division within that organization or institution. The steps shown in FIG. 22 can be divided into several sub-areas or groups. This can be part of the setup 122 (see, for example, FIG. 9) step of the RS. In step 390, the user can select a care area on the DERS editor user interface. Go to List. In step 392, the user can add a new care area to the list. When adding a new care area to the care area list, the user can In some embodiments, the user may have the option to select a blank template or The method can start with a nearly empty template. The portal allows users to copy information about existing care areas to speed up the process. If the user chooses to copy an existing care area, If so, the user may proceed to step 394. In step 394, the user Select an existing nursing area that you want to copy and then click on step 3. At 98, the user updates the care area by changing the care area type to the new care area type. In some embodiments, the user may change the type of the protection area. You can also adjust the care area settings with

[0232] If the user chooses not to copy an existing care area or if the existing care area If no such file exists, the user may proceed to step 396. The user specifies the type of new care area to be added to the list. This step This may include selecting a care area from a list of possible care area types. A non-limiting list of possible care areas in certain embodiments of the disclosure is provided in Table 6 below.

[0233] [Table 6] TIFF0007617068000012.tif177150

[0234] The user can proceed to step 400 from step 396 or step 398. At step 400, the user enters the name and contact details used for that care area within the institution or organization. The care area name can be changed to match. In step 401, the user You can then specify the nursing group (if any) to which the new nursing area will belong. In step 402, the user selects various users to be associated with the newly created care area. For example, a user may work in that care area or may be a A user can specify several clinicians who will be responsible for the care of a new care area. Within the agency or organization that may be responsible for reviewing or contributing to new nursing areas Other individuals may also be designated.

[0235] In step 404, the user defines various care area parameters for the new care area. This allows you to change the default values, fill in empty templates, In some embodiments, the parent parameter value , i.e. values ​​defined for the same parameter at the nursing group level are can be automatically used as the default value for child parameters at the level of A non-limiting list of possible care area parameters in a particular embodiment is given in Table 7 below. show.

[0236] [Table 7] TIFF0007617068000014.tif130150

[0237] Once the care area parameters are specified, the user may save the new values ​​in step 406. Nursing areas and parameter values ​​are stored in the DERS Editor database. Then, in step 408, the user can select whether the new care area is The person responsible for inspecting the protected area must notify the area that it is ready for inspection. Then, in step 410, the DERS editor service may The relevant users can be notified that the equipment has been installed and is available for inspection. This can be done via an automatically generated email.

[0238] Referring now to FIG. 23, there are several examples that may be used in validating a care area. A flow chart detailing exemplary steps of the nursing care method is shown. It may be appropriate to validate the group. To open the system, these steps must be performed by all designated inspectors. In some embodiments, these steps are performed before the DAL file is published. These steps can define one of many processes that must be completed. In some embodiments, the step of inspection 121 of FIG. 9 or the step of verification by care area of ​​FIG. Sub-step 216, sub-step 222 of inspection by nursing area, inspection between nursing areas As part of sub-step 224 and / or sub-step 226 of the nursing area inspection The steps shown in FIG. 23 may be performed by one or more parties. For example, the steps are as shown in Figure 1: nursing manager 7, pharmacist 8, risk management manager 6, and / or a medical technician 19. These steps are shown in FIG. Resource clinicians 202, inspection pharmacists 204, dispensing consultants 206, and / or The steps shown in FIG. The DERS editor user interface is accessible through any Internet browser. can be completed in one go.

[0239] At step 420, the reviewing user may proceed to a care area list. In this embodiment, the DERS editor then selects a care area from the list in step 421. In step 422, the user performing the inspection may be prompted to select The user can select the care area they wish to inspect or are responsible for inspecting. In some embodiments, the reviewing user may review all items, elements, and In some embodiments, the user who performs the inspection may be responsible for checking the A user may be responsible for only a portion of the items, elements, parameters, etc. of a nursing area. At step 424, a reviewing user may review elements of the care area.

[0240] In some embodiments, the inspecting user may select the care area's You may be asked to enter a comment for any item, element, or parameter. In the exemplary flow chart shown in FIG. 23, a user who performs an inspection When reviewing a type of parameter, the reviewing user must approve the item, element, parameter, etc. or you are prompted to enter a comment about the item, element, parameter, etc. If the reviewing user does not have any concerns or questions regarding the element, then in step 425 the user The user can then indicate that they have verified the element.

[0241] If the user performing the inspection does not approve the items, elements, parameters, etc. for the nursing area If the user has any comments / feedback / questions, the user may continue to step 424. The user may proceed to step 426. In step 426, the user may Enter your comments or questions about a specific item, element, parameter, etc. in the feed As a hypothetical example, a neonatal intensive care unit may provide a weight limit for patients. If the parameter for the absolute limit was specified as 70 kg, the inspector would have to say, "This limit is very That seems high. Perhaps there was a typo that added a zero to the input. You can also enter comments such as "This value should be lowered." In some embodiments, some comments may include requests for changes, which may be granted. If you have any comments, questions, or feedback, Bind it to a parameter so that it can be viewed by other users or parties, and possibly It is possible to encourage comments and feedback. In some embodiments, a user inspecting the document may include various attachments, links, photos, CQI data, etc. Comments can include other information such as:

[0242] When the inspector validates or comments on an item, element, parameter, etc., If there are more items, elements, parameters, etc. to check, the user returns to step 424 If there is nothing left in the nursing area that needs inspection, then an inspection is performed. The user chooses to provide general feedback about the care area In step 428, the user may enter general feedback about the entire care area. Comments provided in step 428 may be provided as feedback or comments. Any questions and / or feedback can be linked to the care area and viewed by other users. and possibly engage with comments and feedback. Any general comments and feedback that the reviewer wishes to provide can be provided here. Once all of the information has been provided, the user performing the check may indicate in step 429 that the check is complete. Any comments, questions, feedback, etc. can be submitted to the DERS Editor database. The data can be stored in the database.

[0243] When the user indicates that they are done inspecting the care area, in step 430, the DERS system The diary service sends a notification that the user has finished inspecting the nursing area. This notification can be sent to other users or parties and can be generated automatically. This message may take the form of an e-mail message. The drug library manager can then send the drug to a drug library administrator such as drug library manager 200 shown in FIG. In some embodiments, at least one party or user may We will not disclose your information until we have responded to all comments, questions, and feedback provided in the notice. In some cases, it may not be possible to publish a DAL file that contains a protected area.

[0244] FIG. 24 illustrates some exemplary steps that can be used to update a care area. 24 shows a flowchart for explaining the step of the method in detail. The report includes several items that can be used to update the nursing area after inspection. The inspection process is similar to the process described and illustrated in relation to FIG. The steps shown in the exemplary flow chart of FIG. This may be part of the editing and revision sub-step 220 shown in FIG. The popping can be done by a user, such as a drug library manager. Steps can also be used to update care groups.

[0245] In step 440, the user selects a nursing You can now go to the Area List. The DERS Editor user interface has In some embodiments, the information may be accessed through a suitable web browser. In some embodiments, in step 441, the DERS editor service selects a care area. In step 442, the user may be prompted to select the nursing item that they wish to revise. In step 444, the user may select Any comments, questions or feedback you have about the new care area parameters Users may choose to review each comment, question, or feedback provided. Countermeasures can be taken.

[0246] The user who performed the inspection asked a question about the care area or a parameter within the care area. If so, the user may proceed to step 446. At step 446, the user The user can then enter answers to the questions. These answers will then be In some embodiments, the user may respond in step 446. After providing the information, the DERS Editor Service will respond to the user who made the inquiry. This notification is part of step 448. In some embodiments, the user who performed the review may send the review as a part of the review. You need to be able to respond to the answer or to communicate that you have received a satisfactory answer. There are cases like this.

[0247] The reviewer has comments or questions that are not easily understood or require further discussion. If so, the user may proceed to step 450. In step 450, the user enters a question about the user's first input that was verified. This question can then be viewed and answered by the first user. In some embodiments, the user may enter a question at step 450. After submission, the DERS Editor Service will review the submission and respond to any comments, questions, or requests from users. can notify the reviewer that a feedback question has been entered. This notification can be sent as part of step 452.

[0248] Comments, questions, and requests from the reviewing user, including requests to change parameters of the care area , or if feedback has been entered, the user can either accept the change request or If the changes are acceptable, the user proceeds to step 454 and accepts the change request. The parameters of the care area can be changed accordingly. If the user decides to reject the change request submitted by In some embodiments, the user may decline to One or more virtual buttons and interface elements that are included as part of the change request on the interface. You can accept or reject the change request by taking a In such an embodiment, accepting the change request automatically updates that parameter for that care area. can be changed dynamically.

[0249] The reviewer made a comment that did not include a change request, raised a question, or required a response. If the user has entered any comments or feedback, the user may enter the comments or feedback in step 458. You may be asked to mark your feedback as "read."

[0250] When addressing comments, questions, or feedback, DERS Editorial Services will In step 459, the DERS inspection status information can be updated. Users are responsible for ensuring that all comments, questions, and feedback from users who review the software is addressed. Other comments, questions, and feedback may be reviewed until the comment is 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 can be saved and the user can then proceed to step 462. You can now log out of the ERS editor.

[0251] In step 464, the DERS Editor Service updates the nursing area and This notification can be sent to all users who are interested in the system. The notification may, in some embodiments, consist of an automatically generated email message. The revalidation process may be similar to the process described and illustrated in connection with FIG. This can be done.

[0252] 25, the drug or medication record is then added to the designated care area. The following detailed description of some exemplary steps that can be used to add A flow chart is shown. The terms "drug record" and "medication record" are synonymous herein. These drug records are used to identify drugs that can be used within a single care area. It is possible to define a drug and various restrictions, characteristics, etc. that may be applicable to that drug. The exemplary steps shown in the flow chart are based on the drug selection and record designation shown in FIG. This can be done as part of step 214 of FIG. The pool is run by a drug library administrator, such as drug library administrator 200 shown in FIG. In other embodiments, another party, such as a pharmacist or other party, may be present in the care area. In some embodiments, a similar step may be taken to add a drug record. can be used to add a drug record to a care group.

[0253] In step 470, the user inputs a nursing item on the user interface of the DERS editor. The user may then proceed to the list of medications in the drug record at step 471. In some embodiments, the care area may include a Unless all parameters are predefined and validated, the care area will not have a drug record. In such an embodiment, the definition of the parameter The verification involves steps similar to those shown and described in relation to Figures 22-24. This can be achieved by:

[0254] Once a user is able to add a drug record to a care area, the user can select a specific drug You can decide to add a specific drug or choose to add an unspecified drug. If you choose to add a specific drug, the user can select it from the drug record from the existing group. Copy the medication (step 474) or define the medication to include in the medication record for the care area. A user may then create a new medication record (step 476). If so, the user may proceed to step 474. In step 474, the user The medication record for the desired medication can be copied from an existing care area. In this state, this is the list of medication records displayed in the DERS user interface. In some embodiments and situations, the selection may involve selecting a medication record from Users may also be able to copy medication records from different institutions. This is especially true for e.g. This may be the case if the institution is part of an IDN.

[0255] Copying a drug record copies the rule set and concentration records that correspond to that drug. In some embodiments, the user can copy the medication record to a new When copying to a care area, some or all of the rule sets and / or concentration records may be After copying a medication record, the user can choose not to copy everything. repeat step 474 for as many records as needed, or perform step 476. You can then add more medication records to the same If there are no more medications to add to this care area, the user may proceed to step 486. Step 486 is described later in this specification. In some embodiments, Include steps that allow users to make adjustments and changes to the copied care area. Good too.

[0256] Step 476 allows the user to create a medication record without copying the record from another care area. This step allows the user to create a medication record. In some embodiments, the user can define the name of the drug to be displayed. The name of the drug can be selected from a list of prescribers. Such lists are This disclosure may be provided by a third-party service or may be generated within an institution or organization. The following table provides a non-limiting list of possible medication record parameters in a specific embodiment of the present invention: Shown in Figure 8.

[0257] [Table 8]

[0258] After defining the drug name and various drug parameters in the drug record, the user can You may be required to define a set of one or more rules in your code. Each rule In some embodiments, the set of Rule set and clinical use are used interchangeably herein. For example, a set of rules governs how fluid is delivered as a weight-based infusion and an intermittent infusion. The fluid may have a different set of rules that govern how it should be delivered when it is delivered as an infusion. A non-exhaustive list of other possible clinical uses include non-weight-based fluid infusions, body surface area (BS) This may include infusion based on A), continuous infusion, etc.

[0259] In some embodiments, such as the embodiment shown in FIG. 25, a user may select a medication from an existing medication record. Copy the set of rules for the drug (step 478) or define your own set of rules for the drug. The user can choose to copy a set of rules (step 480). If so, the user may proceed to step 478. The user can select a set of rules to copy from an existing medication record. This is done by selecting the desired rule from the list displayed in the DERS editor user interface. In some embodiments and situations, the user may select a set of In some cases, it may be possible to copy a set of rules from a different institution. This is especially true if an institution, e.g. This may be the case if it is part of a DN.

[0260] When you copy a rule set, all concentration records that correspond to that rule set are also copied. In some embodiments, when copying a set of rules, the user may You can choose not to copy certain concentration records or all concentration records. After copying a set of rules, the user can repeat the steps for as many sets of rules as required. Repeat 478 or perform step 480 to add additional sets of rules. After you copy the rule set, you can add it to the medication records that you want to add to that care area. Alternatively, if there are no more sets of rules, the user may proceed to step 486 . Step 486 is described later in this specification. The method may include a step in which the user can edit or modify the copied set of rules.

[0261] Step 480 allows the user to add a set of rules to the medication record without copying an existing set of rules. This can be done by the user if they want to create a set. In this step, the user You can create a set of rules and define parameters for that set of rules. In an embodiment, depending on the type of rule set being created, the user may define different parameters. A possible set of rules for a particular embodiment of the present disclosure is A non-limiting list of test parameters is provided in Table 9 below.

[0262] [Table 9] TIFF0007617068000017.tif156149 TIFF0007617068000018.tif135155 TIFF0007617068000019.tif130155

[0263] Once you define the rule sets and the rule set parameters, the user can A user may be required to define one or more concentration records for a A rule can be created for each drug concentration used for a particular set of rules. In some embodiments, such as the embodiment shown in FIG. 1, a user may select a set of rules for an existing medication record. 4. Copy the corresponding concentration record (step 482) to the rule set or In step 484, the user may choose to define a concentration record for the analyte.

[0264] If the user chooses to copy the concentration record, the user proceeds to step 482. In step 482, the user selects a cardinality to copy from an existing set of rules. After copying the concentration record, the user can select the required concentration Repeat step 482 for as many records as there are records, or perform step 484 to select additional records. After copying the concentration record, you can add the concentration record to the nursing area. If there are no more drug records, rule sets, or concentration records to add to the The user can proceed to step 486, which is described later in this specification. In some embodiments, the user may modify or adjust the copied concentration record. The method may include additional steps that allow

[0265] Step 484 allows the user to add a concentration record to the set of rules without copying an existing concentration record. This can be done by the user if they want to create a record. You can create a concentration record and define the parameters for that concentration record. The following is a non-limiting list of possible concentration record parameters in certain embodiments of the disclosure: The results are shown in Table 10.

[0266] [Table 10] TIFF0007617068000021.tif156149 TIFF0007617068000022.tif135155 TIFF0007617068000023.tif135161

[0267] Upon completing step 484, the user adds additional concentration records to the set of rules. or add more sets of rules to the medication record, or add more medication records to the care area. After completing step 484, you can add a code to that care area. If there are no more matching drug records, rule sets, or concentration records, the user Step 486 may then be continued, as described later in this specification. In some embodiments, the various parameters defined in Tables 8-10 are They can be defined at a different level of the DAL file hierarchy than the rule level. For example, Some of the values ​​defined at the set level may, in some embodiments, be defined at the medication record level. It can be defined as:

[0268] As mentioned above, in some embodiments, the user may enter a medication record for unspecified medications. You can also choose to add a record with a wildcard or quasi- Such a medication record can act as a wildcard. It is possible to define broad parameters governing the use of any number of unspecified drugs. With such a record, for example, the user can Allows the infusion pump to operate in volume per duration mode without being constrained by any defined limits. Using a medication record for a non-specified medication can result in an emergency In some situations, caregivers can initiate treatment more quickly. This may be useful when a drug not on the full list needs to be used (e.g., experimental). Such medication records are used in accordance with the DERS definition. This may be useful in special cases where the limits provided may not be appropriate for the situation. For example, Extremely overweight patients who require fluid infusions are defined via the DERS editor. The set limit may not allow for a clinically effective infusion. In this case, the user By using medication records for non-specified medications, the limit can be avoided. Fluids can be administered that may have the desired effect.

[0269] As mentioned above, such medication records can also be configured as semi-wildcards. For example, a drug record for an unspecified drug may not specify a drug category or subcategory. It can be set up so that the parameters that can be defined are given. These may include, but are not limited to, blood products, investigational drugs, IV fluids, medications, etc. This is possible while applying some of the safeguards that can be created in the DERS editor. , which may be useful to provide more flexibility when needed. When the user selects a drug record for some or all of the unspecified drugs, The user can then select the medication to be used and the medication records corresponding to the medication not specified. The user may be prompted to enter text explaining the reason for the drug delivery.

[0270] When adding a medication record for a non-specified medication, the user must select Copy an unspecified medication (step 472) or create a new unspecified medication. A medication record can be created for medications not specified by the user (step 473). If the user decides to copy the data, the user selects the desired data by performing step 472. The user can select and copy the drug code. If the user wants to create a medication record, the user must enter a medication record and its various parameters in step 473. In some embodiments, the user may create a desired medication for a non-specified medication. Such parameters may be defined in accordance with the parameters in Tables 7 to 9. It may contain some or all of the parameters, allowing the user to The medication record for the non-specified medication can be adjusted to be either narrower or wider. After completing step 472 or step 473, the user can add additional If additional medication is desired, it can be added as described above.

[0271] When a user finishes adding to or creating a medication list for a care area, the user completes the step At step 486, the user may proceed to step 486. The corresponding inspection user is notified that the device is ready for inspection and is logged out. Step 488 allows the DERS Editor Service to review medication lists in nursing areas. The relevant inspection user can be notified that the DE This may be in the form of an automatically generated email from the RS Editor service. The medication list can be stored in the DERS database.

[0272] Figure 26 can be used to review the medication list for a particular care area. 1 shows a flowchart outlining in detail some exemplary steps involved in the You can also use the to check the medication list for a nursing group. The medication list is shown in Figure 25. It can be created by following steps similar to those described in FIG. The exemplary steps shown in the flowchart are the same as those shown and described in connection with FIG. The steps shown in FIG. 26 may be part of the steps shown and described in relation to FIG. The verification sub-steps for each nursing area 216 and the inspection sub-steps for each nursing area 222, an inter-care area inspection substep 224, and / or a care area inspection substep This may be part of step 226. The group can be conducted by at least one reviewing user. For example, the nursing manager 7, pharmacist 8, risk manager 6, and / or medical technician in Figure 1 The user who performs the inspection is, for example, the resource clinician 202 in FIG. 204, pharmacy consultant 206, and / or clinical consultant 208. .

[0273] In step 490, the user performing the inspection selects the DERS editor user interface The user can then proceed to the nursing area list at step 492. The user can select the care area with the medication list to review. At step 494, the reviewing user is prompted to review an item or parameter in the medication list. In some embodiments, the items and parameters that the user is asked to check include: The ERS Editor user interface consists of a work list, windows, widgets, and In some embodiments, the user may view a list of medications, such as a medication list. In some embodiments, you may not need to go to the nursing area list to check. The user performing the inspection can select the medical device stain on the user interface of the DERS editor. Through the medical device simulator, the user can check the items on the medication list. The regulator mimics what a medication list will look like when used with a particular medical device. In some embodiments, the user may navigate to a review screen or a medication screen to view the medication list. The strike can be inspected.

[0274] When reviewing an item, the reviewing user can enter a comment or decide whether the item is appropriate. The user can verify that the information is correct and that no changes are necessary. If the reviewing user decides to comment on the item, the reviewing user proceeds to step 495 and selects the item. If the reviewing user decides to verify the item, The reviewing user can proceed to step 496 and indicate that the item has been verified. Once you have completed step 495 or step 496 for an item, In 498, the DERS Editor Service will provide the DERS database with information on its nursing areas and You can then update the inspection status of the item(s) that need to be inspected. If there are more items to be reviewed, the reviewing user may return to step 494. This can be repeated until all items and parameters on the medication list have been checked.

[0275] When there are no more items or parameters to be checked in the medication list, the check is The user may proceed to step 499. In step 499, the DERS editor The Service may display a list of comments made by Users during the review. In step 500, the reviewing user can review, supplement, or The reviewing user may then select a medication list or medication list element. If there are general comments about the The user performing the review can enter If there are no general comments for the If so, in step 504, the user performing the review can indicate that the review is complete. Then, in step 506, the reviewing user logs out of the DERS editor. In step 508, the DERS editor service may Notify another user, such as a medical administrator, that the reviewing user has completed reviewing the medication list. It is possible.

[0276] Referring now to FIG. 27, several examples of medications that can be used to update a medication list are shown in FIG. A flow chart is shown detailing some exemplary steps. The drug list for a particular care area must be reviewed before the drug list can be reviewed. Similar steps can also be used to update the nursing group. This can be done using the steps detailed in FIG. The steps shown in the step are part of the Editing and Revision sub-step 220 shown in FIG. 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 create a medication list. For example, a drug library manager can work with a pharmacist to update the drug list. You can update the account.

[0277] In step 510, the user selects a nursing You can now go to the Area List. The DERS Editor user interface has In some embodiments, it may be accessed via a suitable web browser. Next, in step 512, the user selects the care area with the medication list that he or she wishes to revise. In some embodiments, the user does not need to select a care area and can access the DERS Update the medication list using the Editor user interface's Inspect screen, Drug screen, etc. In step 514, the user can select a medication list or an item in the medication list. Check for comments, questions, or feedback regarding the items or parameters. The user may take some action on each comment, question, or feedback provided. It is possible.

[0278] The user who performed the review may ask a question about the drug list or a parameter in the drug list. If so, the user may proceed to step 516. At step 516, the user The user can then enter the answer to the question. The answer will be displayed to the first user. In some embodiments, the user may turn back at step 516. After providing an answer, the DERS Editor Service will respond to the user who asked the question. The notification can be sent in step 518. In some embodiments, the reviewing user may send the review as part of the review. If you have any questions, please feel free to contact us. Sometimes it may be required.

[0279] The reviewer has comments or questions that are not easily understood or require further discussion. If so, the user may proceed to step 520. In step 520, the user enters a question about the user's first input that was reviewed. This question can then be seen and answered by the first user to check. In some embodiments, the user may enter a question in step 520. The DERS Editor Service then reviews the documents and responds to any comments, questions, or comments submitted by users who have reviewed them. Inform the reviewer that a review or feedback question has been entered. This notification may be sent as part of step 522. In the , the user can enter an answer or a question using the same field. In such an embodiment, the notification sent in step 518 or step 522 may simply be It may be something to inform the examiner that an answer has been submitted.

[0280] The user who performed the review wrote a comment containing a request to change an item or parameter in the medication list. If the user enters comments, questions, or feedback, the user must accept the change request. If the user accepts the changes, the process proceeds to step 524, where the user can accept or reject the changes. The items or parameters of the drug list can be changed according to the user's request. If the user decides to reject the change request, the user must continue with step 5. In some embodiments, the user may decline the request at 26. One or more temporary changes that are included as part of a change request on the user interface of the You can accept or reject a change request by interfacing with the button In such an embodiment, accepting the change request may result in the item in question being deleted from the medication list. or the parameters can be changed automatically.

[0281] The reviewer may submit comments that do not include a change request, raise a question, or require a response. If the user has entered a comment or feedback, the user may You may be asked to mark feedback as "read."

[0282] When you address a comment, question, or feedback, you acknowledge that you have Other comments will be posted until all comments, questions, and feedback from have been addressed. All comments, questions, and feedback can be reviewed. Once the feedback has 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 DERS database can then be saved to the user's DERS database in step 532. You can log out of the editor.

[0283] In step 534, the DERS Editor Service determines whether the medication list has been updated and can be revalidated. This notification can be sent to all interested users who are in a state where a In some embodiments, this may consist of an automatically generated email message. Notifications shall be sent to all Reviewing Users who first reviewed that medication list. The revalidation process may be similar to the process described and illustrated in connection with FIG. In some embodiments, the revalidation process may be a process as shown in detail in FIG. The process may be similar to that described above.

[0284] FIG. 28 illustrates some exemplary scripts that can be used to review a medication list. 28 shows a flowchart detailing the steps of the exemplary The steps may be performed by at least one reviewing user. The user may be, for example, the nursing manager 7, the pharmacist 8, the risk manager 6, and / or The user who performs the inspection may be, for example, a resource clinician 202 in FIG. Pharmacist 204, Pharmacy Consultant 206, and / or Clinical Consultant 208 It is.

[0285] In step 540, the user performing the inspection selects the DERS editor user interface. The user can then navigate to the care area list on the screen. The user can select the care area with the medication list to review. In an embodiment, the inspection does not have to be done by going to the care area list. In an embodiment, the user may, for example, inspect a screen of the DERS user interface, Entries can be inspected from the List Widget, or from the Drug List screen. In step 543, the list of items requiring inspection will be compiled by the DERS Editor Service. and displayed in the DERS editor user interface. The user can apply filters in the DERS editor user interface to The ERS Editor Service can generate and display such a list. In step 544, the reviewing user selects items or can be inspected by selecting the parameter from a list. The user who performs the inspection can enter the medical device system information on the DERS editor user interface. You can check the items on the medication list through the simulator. The simulator simulates how a medication list will look when used with a specific medical device. It can be rationed.

[0286] In some embodiments, including the embodiment shown in FIG. 28, the DERS editor service A step 545 of displaying an inspection history may be included, where the inspection history indicates whether any changes have been made to the item. For example, an inspection history can provide the user with context about why an item was This includes a list of comments, questions, responses, accepted and rejected change requests, etc. The inspection history shows the original setting or value of the item, as well as other past settings of the item. or value. Values ​​for items, comments, questions, responses, accepted / received Once a rejected change request is created, generated, and submitted, it is automatically added to the DERS database, etc. It can be stored in a database.

[0287] After reviewing an item, the reviewing user can enter comments or You can verify that the data appears to be correct and that no changes are necessary. If the user decides to comment on the item, the reviewing user proceeds to step 546 You can then go ahead and provide any comments you like. If so, the inspecting user proceeds to step 547 to acknowledge that the item has been verified. You can complete step 546 or step 547 for one item. In step 548, the DERS Editor Service checks the medication list for a review status. Then, if there are more items or parameters that need checking, If so, the reviewing user may return to step 544. This can be repeated until all items and parameters have been checked.

[0288] When there are no more items or parameters in the medication list that require checking, the check will The user who wishes to check may proceed to step 550. In step 550, the user who wishes to check may Then, in step 552, the user who performed the inspection can be notified that the inspection is completed. The user may then log out of the DERS editor. The Editor Service notifies the user that they have completed reviewing the drug list. You can notify another user, such as a library administrator, of any problems that have not yet been resolved. If you have any questions, feedback, and / or comments, please contact the The user can update the list again and revalidate the medication list. This is to ensure that all users have The medication list can be continued until the patient agrees to the medication list and has no further questions regarding the medication list. 27. can be renewed.

[0289] Figure 29 shows some examples that can be used when submitting a DAL file for approval. 1 shows a flowchart detailing exemplary steps of the method for The DAL file is created / updated as above, and after various inspection and verification processes, In some embodiments, these steps include a test run of the DAL file. The exemplary steps shown in the flow chart of FIG. This may be done by a user or a party, such as an object library administrator or other party.

[0290] In step 560, the user selects all the care areas created / updated in the DERS editor. A, drug records, and other items are verified by the user who is responsible for verifying and checking them. Verify that all nursing areas, medication records, other items, etc. have been verified. If the user confirms that the DAL file has been created or updated, then in step 562 the user The file is available for approval by the person responsible for approving DAL file releases. The person responsible for approval may, in some embodiments, be an agency or organization. When the user completes step 562, the DERS editor service In step 564, the person responsible for approving the release of the DAL file is notified of the DAL file release. Then, in step 566, The user can log out of the DERS Editor service.

[0291] DAL files are accepted for publication based on procedures defined by various agencies or organizations. Various individuals responsible for reviewing and approving the DAL files that are created / updated should review and approve them. In some embodiments, such a procedure can be implemented using the inspection and validation process described above. Once the DAL file is approved, it will be saved in the By following several steps as shown in the exemplary flow chart in FIG. As shown in FIG. 30, the drug library manager, etc. Users of DER will receive a notification that the created / updated DAL file has been approved. The DAL file can be received from the S Editor service (step 580). Once the user receives notification that they have been approved, they proceed to step 582, The user can then log into the DERS Editor Service. Then, in step 584, You represent and warrant that all persons responsible for approving the DAL File have actually approved the DAL File. In step 586, the user can verify that the DAL file is functional. It can notify various medical devices within the organization or department that the data is ready to be made available.

[0292] Now referring to Figure 31a, the DAL files are deployed to various system components. FIG. 1 is a flow diagram detailing some exemplary steps that may be used to place The steps shown in FIG. 31a are the same as those described in connection with FIGS. 29-30. The DAL file was approved through a process similar to that of the .DAL file, and is now available for public release. The various components include, in particular, the CQI 4, the device gateway 99 of FIG. 4, and any number of medical devices, such as the device 26 of FIG. The steps shown in FIG. 31a may be performed by any number of users or parties. In some specific embodiments, the steps shown in FIG. 31a may be implemented using the facility IT 18, medical technician 19, or medical technician 102 of FIG. The transmission of the DAL file can be done over a secure connection. In some embodiments, this is done specifically using a Secure Sockets Layer (SSL) connection. You may send the DAL file.

[0293] The exemplary flow chart shown in FIG. 31a begins at step 590, where a DERS editor The service notifies CQI users that the DAL files are published and ready to be deployed. In step 592, the CQI user receives the notification generated in step 590. Then, in step 594, the CQI user logs on to the CQI application. The CQI application requires no client-side software. , which can be accessed by the user via a suitable web browser, for example. Then, in step 596, the CQI user You can use the dalfile option to place the dalfile in the CQI service. In this case, the CQI users are medical technicians.

[0294] In step 598, the CQI application transmits the DAL file to the CQI service. The DERS Editor Service can then be notified that the deployment was successful. In step 600, the DERS Editor service sends the DAL file to the device gateway. In step 602, the user is notified that the device is ready for deployment. receives notification that the DAL is ready to be deployed to the device gateway. In the present embodiment, the user receiving this notification is a medical technician. The user can then log into the device gateway application. Step 60 In step 6, the user instructs the device gateway to download the DAL to the device gateway. In step 608, the device gateway application Applications can request DAL files from the DERS Editor Service. In step 610, the DERS editor service provides the DAL to the device gateway. It is possible.

[0295] Users can choose to deploy the DAL on various medical devices in several ways. In the exemplary embodiment shown in FIG. 31a, a user can use a device gateway to L can be placed or placed manually. The user can use the device gateway to If you decide to place the DAL file in the The user can then proceed to step 614 to remotely deploy the device to the medical device. You can manually deploy the DAL files. Manual deployment is desirable in some situations. For example, manual deployment may be required in a disconnected environment. In step 614, the user may log into the DERS editor service. Then, in step 616, the user may manually select the D You can use the ERS Editor Service to load the DAL into a local storage device. Local storage devices can be USB memory sticks, external or portable hard drives. In step 618, the user connects a local storage device to the medical device. Then, download the DAL file from the local storage device to the medical device. You can manually place the DAL file on a medical device.

[0296] Figure 31b shows the process for packaging and staging resources for publication to the facility gateway. FIG. 1 is an exemplary flowchart detailing several steps that can be used to In some embodiments, such a resource is a DAL. The user can select the resources that he or she wants to publish. Then, in step 4702, The resource may be signed using a cryptographic algorithm. In some embodiments, an additional packing step is performed. For example, in some embodiments, a compression step may also be included. In some embodiments, an encryption step may be included. The steps depend on the type of file being published.

[0297] In step 4706, the location of the hash stage can be determined. In some embodiments, the location is a location on a database. Then, the signed hash can be copied to a stage location. Then, step 4 At 710, the original signed hash file may be saved to an archive location. This archive location may in some embodiments be a database or other file system. In step 4712, a notification of resource availability is sent to each facility gateway to be notified. It can generate notification messages that are sent to the facility data exchange. , the type of file, the hash of the file, the unique identifier of the file, and the facility gateway. In step 4714, the notification message is sent. This notification message can then be posted to the data exchange of interest. The facility gateway may then transmit the request to the facility gateway on the other side.

[0298] Figure 31c shows some examples of resources that can be used to track allocation. A flowchart detailing typical steps is presented. Such resources include DA L file and any number of other resources. This is done on the user interface of the DERS editor. In step 4730, the user selects the particular resource for which they wish to track allocation. This resource is a traceable resource stored in memory associated with the Equipment Manager. A list of resources can then be selected from the host environment in step 4732. The equipment manager queries the database for versions of selected resources at each institution. In some embodiments, the database may include a user's associated institution. Then, in step 4734, the device manager , displays a list of institutions detailing the last version of the resource downloaded by each institution. Users can then view detailed information about the placement of the resource version at their institution. If the user wishes to know more about the organization, he or she can select the desired organization from the list in step 4736. In step 4738, the device manager queries the database to determine the device You can determine how many versions of each resource are deployed in the same relationship. In step 4740, a list of versions deployed to the selected institution and the quantity of versions can be displayed.

[0299] DAL files, once created and deployed, may need to be updated, and It may be desirable to update the D It may turn out that some of the limit constraints in the AL file are too strict. For example: A nurse in a nursing area may be assigned to administer a specific drug in a therapeutically effective manner. If nurses find themselves frequently having to select medication records for drugs that are not available, may be able to request changes to limits for a particular drug or care area. Also, when hospital policies change or new drugs come on the market, You may need to make some changes to your DAL file. Figure 32 shows an existing DAL file. 1 is a flow diagram detailing some exemplary steps that may be used to update Chart shown.

[0300] In step 620, the user who is to carry out the inspection logs on to the DERS editor service and You can then indicate that you would like to enter an update or change request for the current DAL. Step 6: The reviewer can then select the type of request they wish to submit. At 22, the user performing the review can enter, for example, general comments. A user may also choose to enter more specific comments. allows the user to enter comments for any of the various hierarchical levels of the DAL file. In step 624, the reviewing user may select the particular nursing event for which they wish to make an update request. In some embodiments, an update request can be made to a care group. The user may include additional steps (not shown) to create a Enter general comments about the care area on page 626 or enter more specific comments. If the user wishes to make a request, he or she may proceed to step 628. In step 626, the user Requests for updates to parameter values ​​defined in a care area may also be entered.

[0301] In step 628, the reviewing user selects the A specific medication record can be selected. The user performing the review can If the user wishes to enter a general update request, they may do so in step 630. In this step, the user may also request updates to parameter values ​​defined in the medication record. If the inspecting user wishes to be more specific in his update request, he proceeds to step 632. In step 632, the user may select the rule ...

Claims

1. A medical error reduction system, comprising: drug library editing software for use in creating and revising at least one drug library, said at least one drug library including a plurality of entries, each of said at least one drug library being used with at least one medical device, said drug library editing software being executed by a server; at least one drug library database; at least one database of medical data; at least one editor computer, each comprising a processor in communication with a user interface, the user interface being used by a user to edit the at least one drug library, the at least editor computers, the at least one drug library database, and the at least one database of medical data being configured to communicate over a network; The drug library editing software is adapted to display and filter the medical data. Medical error reduction system.

2. said medical data being stored in said at least one medical data database; The system of claim 1 .

3. said at least one database of medical data is stored in a hosted environment; The system of claim 2.

4. The medical data is displayed in the form of a chart. The system of claim 1 .

5. The medical data is displayed in the form of a graph. The system of claim 1 .

6. The medical data is displayed in the form of a table. The system of claim 1 .

7. The medical data is displayed in the form of a diagram; The system of claim 1 .

8. The medical data is displayed in the form of an infusion case. The system of claim 1 .

9. the medical data is displayed in a user selectable format; The system of claim 1 .

10. The medical data is searchable. The system of claim 1 .

11. The medical data can be filtered by applying a filter. The system of claim 1 .

12. the filter is an equipment type filter; The system of claim 11.

13. The filter is a category of data. The system of claim 11.

14. The filter is a treatment-based criterion. The system of claim 11.

15. the filter being a medical device identifier; The system of claim 11.

16. the filter being a caregiver identifier; The system of claim 11.

17. The filter is an area-based criterion. The system of claim 11.

18. The filter is a drug standard. The system of claim 11.

19. The drug criteria is a drug identifier.

20. The system of claim 18.

20. The drug criteria is a type of drug; 20. The system of claim 18.

21. said at least one drug library database being in a hosted environment; The system of claim 1 .

22. The medical device is an infusion pump. The system of claim 1 .

23. A medical error reduction system, comprising: drug library editing software for use in creating and revising at least one drug library, said at least one drug library including a plurality of entries, each of said at least one drug library being used with at least one medical device, said drug library editing software being executed by a server; at least one drug library database; at least one database of medical data; at least one editor computer, each comprising a processor in communication with a user interface, the user interface being 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 being configured to communicate over a network; wherein when creating or revising the at least one drug library, the drug library editing software is configured to display medical data in the at least one database of medical data in the user interface and filter the medical data using filter criteria. Medical error reduction system.

24. the at least one medical device is an infusion pump; 24. The system of claim 23.

25. said at least one drug library database being in a hosted environment; 24. The system of claim 23.

26. said at least one database of medical data being in a hosted environment; 24. The system of claim 23.

27. the filter criteria being user selectable; 24. The system of claim 23.

28. the filter criterion is a type of medical device; 24. The system of claim 23.

29. the filter criteria being a category of data; 24. The system of claim 23.

30. wherein the filter criteria are treatment-based criteria; 24. The system of claim 23.

31. the filter criteria being a medical device identifier; 24. The system of claim 23.

32. the filter criteria being a caregiver identifier; 24. The system of claim 23.

33. the filter criteria being care area based criteria; 24. The system of claim 23.

34. the filter criteria being drug criteria; 24. The system of claim 23.

35. The drug criteria is a drug identifier.

35. The system of claim 34.

36. The drug criteria is a type of drug; 35. The system of claim 34.

37. 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; 24. The system of claim 23.

38. said filter criteria are applied by interaction with said medical data displayed in said user interface to allow scoping of said medical data; 24. The system of claim 23.

39. The medical data may be displayed on the user interface in one or more of several formats specified by a user; 24. The system of claim 23.

Images