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

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

Info

Publication number
EP2936360A2
EP2936360A2 EP13824438.9A EP13824438A EP2936360A2 EP 2936360 A2 EP2936360 A2 EP 2936360A2 EP 13824438 A EP13824438 A EP 13824438A EP 2936360 A2 EP2936360 A2 EP 2936360A2
Authority
EP
European Patent Office
Prior art keywords
drug library
medical device
drug
user
medical
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP13824438.9A
Other languages
German (de)
English (en)
French (fr)
Inventor
John J. BIASI
Richard M. NEWMAN
Eric L. PRIBYL
John M. Kerwin
Rahul Gupta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deka Products LP
Original Assignee
Deka Products LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/723,242 external-priority patent/US10911515B2/en
Priority claimed from US13/723,239 external-priority patent/US10108785B2/en
Priority claimed from US13/723,253 external-priority patent/US11210611B2/en
Priority claimed from US13/900,655 external-priority patent/US11881307B2/en
Application filed by Deka Products LP filed Critical Deka Products LP
Priority to EP21204062.0A priority Critical patent/EP3965112A1/en
Publication of EP2936360A2 publication Critical patent/EP2936360A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
    • G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/40—ICT specially adapted for the handling or processing of medical references relating to drugs, e.g. their side effects or intended usage

Definitions

  • U.S. Patent Application Serial No. 13/723,253 is a Continuation-In-Part of U.S. Patent Application Serial Number 13/333,574, filed December 21, 2011 and entitled System, Method, and Apparatus for Electronic Patient Care, now U.S. Publication No. US-2012-0185267-A1, published July 19, 2012 (Attorney Docket No. 197), and
  • U.S. Patent Application Serial Number 13/333,574 is a Continuation-In-Part Application of U.S. Patent Application No. 13/011,543, filed January 21, 2011 and entitled Electronic Patient Monitoring System, now U.S. Publication No. US-2011-0313789-A1, published December 22, 2011 (Attorney Docket No. 152), which claims priority to U.S. Provisional Patent Application No. 61/297,544, filed January 22, 2010 and entitled Electronic Order Intermediation System for a Medical Facility (Attorney Docket No. H53), both of which are hereby incorporated herein by reference in their entireties.
  • PCT Application Serial No. PCT/US 13/42350 is also a Continuation-In-Part Application which claims priority to and the benefit of the following:
  • Nonprovisional application for System, Method, and Apparatus for Clamping (Attorney Docket No. J47), Serial No. 13/723,238;
  • Nonprovisional application for System, Method, and Apparatus for Dispensing Oral Medications Attorney Docket No. J74), Serial No. 13/723,235;
  • Nonprovisional application for System, Method, and Apparatus for Infusing Fluid (Attorney Doceket No. J76), Serial No. 13/725,790;
  • Nonprovisional application for System, Method, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow (Attorney Docket No. J79), Serial No. 13/723,244;
  • Nonprovisional application for System, Method, and Apparatus for Estimating Liquid Delivery (Attorney Docket No. J81), Serial No. 13/723,251; and
  • the present disclosure relates to patient care. More particularly, the present disclosure relates to a system and apparatus for electronic patient care.
  • Patient care often involves administering fluids such as medications directly into the patient. This can be accomplished by way of gravity-fed tubing connected to a reservoir (e.g., an IV bag). Fluids or medication can also be administered by way of forced infusion. Administering fluids or medication to a patient often requires the interaction of many parties (e.g., doctors, nurses, pharmacists). These interactions can be subject to miscommunication, mistakes, or other events that result in an inaccurate amount of fluid being administered to the patient.
  • parties e.g., doctors, nurses, pharmacists.
  • a medical error reduction system comprises medical error reduction software for use in creating and revising at least one drug library that is configured for use in at least one medical device.
  • the software is configured to provide sets of privileges to sets of users.
  • the sets of privileges allocate a degree of software functionality to the sets of users, the degree of software functionality configured to define the ability of a user to alter the at least one drug library.
  • the medical error reduction system also comprises at least one server and at least one editor computer.
  • the editor computer is in communication with the server via a network, and includes a processor in communication with a display.
  • a medical error reduction system may include a medical error reduction software for use in creating and revising at least one drug library.
  • the software may be configured to provide one of a plurality of sets of privileges to each of a plurality of sets of users.
  • Each of the plurality of sets of privileges may be arranged to allocate a degree of software functionality to one of the plurality of sets of users.
  • the degree of software functionality may be configured to define the ability of a user to alter the at least one drug library.
  • the medical error reduction system may include at least one server.
  • the medical error reduction system may include at least one editor computer. Each of the at least one editor computer may comprise a processor in
  • the at least one editor computer and at least one server may be configured to communicate via a network in a client-server based model.
  • Each of the at least one drug library may be for use in at least one medical device.
  • each of the at least one drug library may be organized in a hierarchy.
  • the hierarchy may include a plurality of care areas which are subordinate to at least one care group.
  • each level of the hierarchy may include a number of delivery parameters for the at least one medical device.
  • each of the at least one drug library includes a plurality of entries each corresponding to a specific medicament.
  • the at least one drug library may include a number of parameters to inform operation of the at least one medical device
  • the drug library may include a plurality of programming limits for the at least one medical device.
  • the medical error reduction software may further be configured to provide quality improvement information to a user.
  • At least one of the plurality of sets of privileges may allocate a drug library review privilege to one of the plurality of sets of users. In some embodiments, at least one of the plurality of sets of privileges may allocate a drug library editing privilege to one of the plurality of sets of users. In some embodiments, at least one of the plurality of sets of privileges may allocate a privilege set editing or creation privilege to one of the plurality of sets of users. In some embodiments, at least one of the plurality of sets of privileges may allocate an add user privilege to one of the plurality of sets of users. In some embodiments, the plurality of sets of privileges allocated to each of the plurality of sets of users may force a collaborative process between the plurality of sets of users for the creating and revising of the at least one drug library.
  • a medical error reduction system may include at least one server.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may include a processor in communication with a display.
  • the at least one editor computer and at least one server may be configured to communicate via a network in a client-server based model.
  • the medical error reduction system may include a medical error reduction software configured to be executed by the at least one server.
  • the medical error reduction software may be accessible via the at least one editor computer for use in creating and revising at least one drug library.
  • Each of the at least one drug library may be for use in at least one medical device.
  • Each of the at least one medical device may include a medical device processor and a medical device graphical user interface configured to display a user interface.
  • the user interface may convey information and may be used to program its respective medical device.
  • Each of the at least one drug library may contain a plurality of entries which guide user programming of the at least one medical device.
  • the medical error reduction software may be configured to display a simulated medical device graphical user interface.
  • the simulated medical device graphical user interface may mimic behavior of the medical device graphical user interface for a medical device using a selected drug library of the at least one drug library.
  • the simulated medical device graphical user interface is context sensitive.
  • the medical error reduction software may include a number of privilege sets. Each of the privilege sets may be assigned to one of a plurality of sets of users. The number of privilege sets may each allocate a degree of software functionality to each of the plurality of sets of users.
  • the simulated medical device graphical user interface may be a software functionality which may be toggled on or off the number of sets of privileges.
  • each of the at least one drug library may be organized in a hierarchy.
  • the hierarchy may include a plurality of care areas which are subordinate to at least one care group.
  • each level of the hierarchy may include a number of delivery parameters for the at least one medical device.
  • each of the at least one drug library may include a plurality of entries each corresponding to a specific medicament.
  • the at least one drug library may include a number of parameters to inform operation of the at least one medical device.
  • the drug library may include a plurality of programming limits for the at least one medical device.
  • the medical error reduction software may be further configured to provide quality improvement information to a user.
  • a medical device for delivering a medicament to a patient may include a controller configured to control operation of a pumping mechanism which causes the medicament to be delivered.
  • the medical device may include a display.
  • the medical device may include a computer readable memory configured to store program code for a drug library.
  • the drug library may contain a plurality of entries.
  • the plurality of entries may comprise at least one entry corresponding to a portion of a facility. For each such entry there may be at least one drug entry.
  • Each of the at least one drug entry may have parameters associated therewith.
  • At least one drug entry in the drug library may not be associated with a specific drug, but rather a broad drug category.
  • the medical device may include a processor configured to display a graphical user interface on the display of the medical device. The graphical user interface may be for use by a user to program the controller using the drug library.
  • a user may select one of the at least one drug entry in the drug library not associated with a specific drug, but rather a broad drug category to program delivery of the medicament to the patient.
  • at least one drug entry in the drug library not associated with a specific drug, but rather a broad drug category may be associated with at least one parameter governing medicament delivery.
  • the drug library may be created or modified with a medical error reduction software.
  • the display may be a touch screen display.
  • at least one of the at least one drug entry in the drug library not associated with a specific drug, but rather a broad drug category may allow the user to program the medical device to deliver the medicament in a volume per hour mode.
  • each of the plurality of entries may be associated with at least one parameter.
  • at least one of the at least one parameters may be a medicament delivery parameter.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries.
  • Each of the at least one drug library may be for use with at least one medical device.
  • the software may be configured to provide one of a plurality of sets of privileges to each of a plurality of sets of users.
  • Each of the plurality of sets of privileges may be arranged to allocate a degree of software functionality to one of the plurality of sets of users.
  • the medical error reduction system may include at least one server.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may include a processor in communication with a user interface.
  • the at least one editor computer and at least one server may be configured to communicate via a network in a client-server based model. At least one of the plurality of sets of users may use the software to request a change to at least a portion of the at least one drug library.
  • At least one of the plurality of sets of privileges may be configured to allow a user to decline implementation of the change. In some embodiments, at least one of the plurality of sets of privileges may be configured to allow a user to accept implementation of the change. In some embodiments, at least one of the plurality of sets of privileges may be configured to allow a user to submit a question to the change. In some embodiments, at least one of the plurality of sets of privileges may be configured to allow a user to propose a revision to the change. In some embodiments, the server may be configured to execute the medical error reduction software. In some embodiments, the degree of software functionality may be configured to define the ability of a user to alter the at least one drug library. In some embodiments, the at least one medical device may be an infusion pump.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries.
  • Each of the at least one drug library may be for use with at least one medical device.
  • the medical error reduction system may include at least one server configured to execute the medical error reduction software.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may include a processor in communication with a user interface.
  • the user interface may be for use by one or more user to edit the at least one drug library.
  • the at least one editor computer and at least one server may be configured to communicate via a network. At least one of the one or more user may request a change to the at least one drug library by tendering an electronic change request.
  • the at least one medical device may be an infusion pump.
  • the electronic change request may be linkable to medical data.
  • the medical data may be stored in an electronic database to provide contextual information.
  • the electronic database may be in a hosted environment.
  • the medical data may be generated from the at least one medical device.
  • the medical data may be stored in an electronic database
  • the medical data may be associated with the one of the at least one drug library used in the at least one medical device which generated the medical data.
  • 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.
  • 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 diagram. In some embodiments, the medical data may be displayed in the form of an infusion story. In some embodiments, a user may use the drug library editing software to search the medical data. In some embodiments, a user may use the drug library editing software to filter the medical data. In some embodiments the medical data may be displayed in a user selectable format. In some embodiments, the user may only access medical data for versions of the one of the at least one library currently being edited. In some embodiments, the plurality of entries may be each associated with one or more delivery parameters. In some embodiments, at least one of the one or more user may accept the electronic change request.
  • At least one of the one or more user may respond to the electronic change request. In some embodiments, at least one of the one or more user may propose an alteration to the electronic change request. In some embodiments, at least one of the one or more user may deny the electronic change request.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries. Each of the at least one drug library may be for use with at least one medical device.
  • the drug library editing software may be executed by a server.
  • the medical error reduction system may include at least one drug library database.
  • the medical error reduction system may include at least one medical data database.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may comprise a processor in communication with a user interface.
  • the user interface may be for use by a user to edit the at least one drug library.
  • the at least editor computer, at least one drug library database, and at least one medical data database may be configured to communicate via a network. While editing the at least one drug library, the user may use the drug library editing software to access medical data.
  • the medical data may be stored in the at least one medical data database. In some embodiments, the at least one medical data database may be stored in a hosted environment. 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 the form of a table. In some embodiments, the medical data may be displayed in the form of a diagram. In some embodiments, the medical data may be displayed in the form of an infusion story. In some embodiments, the medical data may be displayed in a user selectable format. In some embodiments, the accessed medical data is searchable. In some embodiments, the accessed medical data may be filterable by applying a filter.
  • the filter may be a device type filter. In some embodiments, the filter may be a data category. In some embodiments, the filter may be a therapy based criteria. In some embodiments, the filter may be a medical device identifier. In some embodiments, the filter may be a care giver identifier. In some embodiments, the filter may be an area based criteria. In some embodiments, the filter may be a drug criteria. In some embodiments, the drug criteria may be a drug identifier. In some embodiments, the drug criteria may be a drug type. In some embodiments, the at least one drug library database may be in a hosted environment. In some embodiments, the medical device may be an infusion pump.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries.
  • Each of the at least one drug library may be for use with at least one medical device.
  • the drug library editor software may be executed by a server.
  • the medical error reduction system may include at least one drug library database.
  • the medical error reduction system may include at least one medical data database.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may include a processor in communication with a user interface. The user interface may be for use by a user to edit the at least one drug library.
  • the at least one editor computer, at least one drug library database, and at least one medical data database may be configured to communicate via a network. While creating or revising the at least one drug library, the drug library editing software may be configured to display medical data from the at least one medical data database on the user interface and filter the medical data with a filter criteria.
  • the at least one medical device may be an infusion pump.
  • the at least one drug library database may be in a hosted environment.
  • the at least one medical data database may be in a hosted
  • the filter criteria may be user selectable. In some embodiments, the filter criteria may be a medical device type. In some embodiments, filter criteria may be a data category. In some embodiments, the filter criteria may be a therapy based criteria. In some embodiments, the filter criteria may be a medical device identifier. In some embodiments the filter criteria may be a care giver identifier. In some
  • the filter criteria may be a care area based criteria. In some embodiments the filter criteria may be a drug criteria. In some embodiments, the drug criteria may be a drug identifier. In some embodiments, the drug criteria may be a drug type. In some
  • the filter criteria may be applied by interaction with the medical data displayed on the user interface to display a subset of the medical data.
  • the filter criteria may be applied by interaction with the medical data displayed on the user interface to drill down on the medical data.
  • the medical data may be display on the user interface in one or more of a number of user specified formats.
  • a medical device may include a processor.
  • the medical device may include a graphical user interface.
  • the processor may be configured to generate at least one screen for display on the graphical user interface. At least one of the at least one screen may include one or more parameter value.
  • the processor may be further configured to visibly alter the font of at least one of the one or more parameter value in response to a change in the one or more parameter value.
  • the change may be an order of magnitude change in the one or more parameter value.
  • the processor may be configured to visibly alter the font by changing the size of the font. In some embodiments, the processor may be configured to visibly alter the font by changing the color of the font. In some embodiments, at least one of the one or more parameter value must be specified by a user. In some embodiments, one of the one or more parameter value may be a patient weight. In some embodiments, one of the one or more parameter value may be a patient body surface area. In some embodiments, one of the one or more parameter value may be a dose value. In some embodiments, one of the one or more parameter value may be a time value.
  • one of the one or more parameter value may be a volume to be infused volume. In some embodiments, one of the one or more parameter value may be an infusion rate value. In some embodiments, one of the one or more parameter value may be a medicament concentration value. In some embodiments, at least one or more parameter value may be pre-programmed. In some embodiments, the processor may be configured to visibly alter the font by decreasing the size of the parameter value.
  • a medical device may include a graphical user interface.
  • the medical device may include a processor.
  • the processor may be configured to generate at least one screen for display on the graphical user interface.
  • At least one of the at least one screen may be a therapy in progress screen.
  • the therapy in progress screen may include a pressure indicator which indicates the pressure of a fluid in an infusion line.
  • the pressure indicator may be a pressure trend indicator. In some embodiments, the pressure trend indicator may depict a pressure trend over the last four hours. In some embodiments, the pressure indicator may be a bar. In some
  • the bar may include a number of segments.
  • the pressure indicator may be configured to indicate different pressures by filling a different number of segments.
  • the pressure indicator may be configured to indicate different pressures by filling different amounts of the bar.
  • the graphical user interface may be a touch screen.
  • a medical device may include a graphical user interface.
  • the medical device may include a processor.
  • the processor may be configured to generate at least one screen for display on the graphical user interface. At least one of the at least one screen may be a therapy in progress screen displayed when the medical device is delivering a therapy.
  • the therapy in progress screen may include a medicament indicator indicating a medicament which is being delivered by the medical device.
  • the processor may color code at least a portion of the medicament indicator displayed on the user interface in one of a plurality of colors depending on a classification of a plurality of classification assigned to the medicament.
  • the graphical user interface may be a touch screen.
  • the processor may be in communication with a memory storing a drug library for use with the medical device.
  • the drug library may contain color coding information for the portion of the medicament indicator.
  • at least one of the at least one screen may be a programming screen where the medicament to be delivered by the medical device is specified.
  • at least one of the plurality of classifications may be a high risk classification.
  • at least one of the plurality of classifications may be a drug type.
  • at least one of the plurality of classifications may be an anesthetic classification.
  • the medicament indicator may include a name for the medicament.
  • the medicament indicator may include a non text indicia. In some embodiments, the non text indicia may be the only portion of the medicament indicator which is color coded.
  • a medical device may include a graphical user interface.
  • the medical device may include a processor.
  • the processor may be configured to generate at least one screen for display on the graphical user interface.
  • the medical device may include a computer readable memory.
  • the computer readable memory may store a plurality of parameter values related to therapies which may be programmed into the medical device. At least one of said parameter values may be a value for a user overrideable limit for a therapy parameter value.
  • the user overrideable limit for a therapy parameter value may be overrideable by one or more user via the graphical user interface.
  • the processor may cause an indicia to be displayed next to the therapy parameter value in response to override of the user overrideable limit.
  • the graphical user interface may be a touch screen. In some embodiments, at least one of the at least one screen may display a limit violation
  • the limit violation notification may not display the value of the overrideable limit.
  • the limit violation notification may include an override option.
  • the user overrideable limit for a therapy parameter value may require both a first user and a second user to override the limit via the graphic user interface.
  • the plurality of parameter values related to therapies which may be programmed into the medical device may be part of a drug library file stored in the computer readable memory.
  • the indicia may be a non text indicia.
  • a medical device may include a graphical user interface.
  • the medical device may include a processor.
  • the processor may be configured to generate at least one screen for display on the graphical user interface.
  • the medical device may include a computer readable memory.
  • the computer readable memory may store a plurality of medicaments which may be delivered by the medical device.
  • the medicaments may be organized by one or more medicament category.
  • Each of the medicaments may further be associated with one or more parameter values related to therapies which may be programmed into the medical device.
  • a user may program the medical device to deliver a therapy using the graphical user interface.
  • At least one step in programming the medical device may include selecting a medicament category from which a medicament to be delivered by the medical device is included.
  • the graphical user interface may be a touch screen.
  • the plurality of medicaments and one or more medicament categories are a part of a drug library file.
  • the medicament categories may be searchable via the graphical user interface.
  • the medicament categories may be filterable via the graphical user interface.
  • at least one of the one or more parameter values may be a user overrideable parameter limit.
  • a medical error reduction system may include a medical error reduction software for use in creating and revising at least one drug library that is configured for use in at least one medical device.
  • the software may be configured to provide one of a plurality of sets of privileges to each of a plurality of sets of users.
  • Each of the plurality of sets of privileges may be arranged to allocate a degree of software functionality to one of the plurality of sets of users.
  • the degree of software functionality may be configured to define the ability of a user to alter the at least one drug library.
  • the medical error reduction system may include at least one server.
  • the medical error reduction system may include at least one editor computer including a processor in communication with a display. The at least one editor computer may be configured to communicate to the at least one server via a network in a client-server based model.
  • a medical error reduction system may include a medical device.
  • the medical device may include a medical device processor.
  • the medical device may include a medical device graphical user interface configured to allow a user to program the medical device.
  • the medical device may include at least one server.
  • the medical error reduction system may include at least one editor computer including a processor in communication with a display.
  • the at least one editor computer may be configured to communicate to the at least one server via a network in a client-server based model.
  • the medical error reduction system may include a medical error reduction software configured to be executed by the at least one server and accessible via the at least one editor computer for use in creating and revising at least one drug library.
  • the at least one drug library may be for use in the at least one medical device and include a plurality of entries that guide user programming of the at least one medical device.
  • the medical error reduction software may further be configured to display a simulated medical device graphical user interface.
  • the simulated medical device graphical user interface may mimic behavior of the medical device graphical user interface for a medical device using one of the at least one drug library.
  • a medical device for delivering a medicament to a patient may include a controller configured to control operation of a pumping mechanism which causes the medicament to be delivered.
  • the medical device may include a display.
  • the medical device may include a computer readable memory configured to store program code for a drug library.
  • the drug library may have a plurality of entries.
  • the plurality of entries may include at least one entry corresponding to a portion of a facility. For each such entry, the plurality of entries may further comprise at least one drug entry corresponding to the portion of the facility.
  • the medical device may include a processor configured to display a graphical user interface on the display of the medical device. The graphical user interface for use by a user to program the controller using the drug library. A user may select one of the at least one drug entry corresponding to the portion of the facility to program delivery of the medicament to the patient.
  • the at least one drug entry may comprise parameters associated therewith.
  • the drug library may further comprise at least one drug entry not associated with a specific drug, but rather a broad drug category.
  • the user may select one of the at least one drug entry in the drug library not associated with a specific drug, but rather a broad drug category to program delivery of the medicament to the patient.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library for use with at least one medical device.
  • the at least one drug library may contain a plurality of entries.
  • the software may be configured to provide at least one of a plurality of sets of privileges to each of a plurality of sets of users.
  • Each of the plurality of sets of privileges may be configured to allocate a degree of software functionality to one of the plurality of sets of users.
  • the degree of software functionality may be configured to define the ability of a user to alter the at least one drug library.
  • the medical error reduction system may include at least one server configured to execute the drug library editing software.
  • the medical error reduction system may include at least one editor computer including a processor in communication with a user interface.
  • the at least one editor computer may be configured to communicate with the at least one server via a network in a client-server based model.
  • At least one of the plurality of set of users may use the at least one editor computer to access the drug library editing software to request a change to the at least one drug library.
  • At least one of the plurality of sets of privileges may be further configured to allow a user to decline implementation of the requested change to the at least one drug library or to accept implementation of the requested change to the at least one drug library.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library, the at least one drug library may include a plurality of entries.
  • the at least one drug library may be for use with at least one medical device.
  • the medical error reduction system may include at least one server configured to execute the drug library editing software.
  • the medical error reduction system may include at least one editor computer comprising a processor in communication with a user interface.
  • the user interface may be for use by a user to edit the at least one drug library.
  • the at least one editor computer may be configured to communicate with the at least one server via a network in a client-server based model such that the at least one editor computer is able to access the drug library editing software.
  • a user may request a change to the at least one drug library by tendering an electronic change request via the user interface.
  • the electronic change request may be linkable to medical data in an electronic database to provide contextual information.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries. Each of the at least one drug library may be for use with at least one medical device.
  • the drug library editing software to may be executed by a server.
  • the medical error reduction system may include at least one drug library database.
  • the medical error reduction system may include at least one medical data database.
  • the medical error reduction system may include at least one editor computer configured to communicate with the server at least one drug library database, and the at least one medical data database via a network.
  • the at least one editor computer may include a processor in communication with a user interface. The user interface may be for use by a user to edit the at least one drug library using the at least one drug library editing software. While editing the at least one drug library, the user may use the drug library editing software to access medical data from the at least one medical data database.
  • the user may use the drug library editing software to access medical data from the at least one medical data database.
  • the medical data may be in the form of at least one of a chart, graph, plot, and diagram displayed on the user interface.
  • a user may use the drug library editing software to display medical data from the at least one medical data database on the user interface and filter the medical data such that only medical data of interest to the user is displayed on the user interface.
  • a medical device may include a graphical user interface.
  • the medical device may include a processor.
  • the processor may be configured to generate at least one screen for display on the graphical user interface.
  • the at least one screen may include at least one parameter value.
  • the processor may be further configured to visibly alter the font of the at least one parameter value in response to a change in the order of magnitude of the at least one parameter value.
  • the at least one screen may include a therapy in progress screen, the therapy in progress screen including a pressure indicator which indicates the pressure of a fluid in an infusion line.
  • the at least one screen may be a therapy in progress screen.
  • the therapy in progress screen may include a medicament indicator indicating a medicament which is being delivered by the medical device.
  • the processor may be further configured to color code the medicament indicator displayed on the user interface in one of a plurality of colors. Each of the plurality of colors may correspond to a classification of the medicament.
  • the medical device may include a computer readable memory.
  • the computer readable memory may store a plurality of parameter values related to therapies that may be programmed into the medical device.
  • At least one of the parameter values may be a user overrideable limit for a therapy parameter value.
  • the user overrideable limit for a therapy parameter value may be overrideable by a user via the graphical user interface.
  • the processor may be further configured to display an indicia next to the therapy parameter value in response to the user overriding the user overrideable limit.
  • the computer readable memory may be configured to store a plurality of medicaments that may be delivered by the medical device. Each medicament may be organized into one or more medicament category. Each of the medicaments may further be associated with one or more parameter values related to therapies that may be programmed into the medical device.
  • a user may program the medical device, using the graphical user interface, to at least select a medicament category within which a medicament to be delivered by the medical device is included.
  • a medical error reduction system may include a medical error reduction software for use in creating and revising at least one drug library.
  • the software may be configured to provide a set of privileges to each of a plurality of users.
  • the set of privileges may be arranged to allocate a degree of software functionality to each of the plurality of users.
  • the degree of software functionality may be configured to define the ability of users to alter the at least one drug library.
  • the medical error reduction system may include at least one server.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may include a processor in communication with a display.
  • the at least one editor computer and at least one server may be configured to communicate via a network in a client-server based model.
  • Each of the at least one drug library may be for use in at least one medical device.
  • each of the at least one drug library may be organized in a hierarchy.
  • the hierarchy may include a plurality of care areas which are subordinate to at least one care group.
  • each level of the hierarchy may include a number of delivery parameters for the at least one medical device.
  • each of the at least one drug library may include a plurality of entries each corresponding to a specific medicament.
  • the at least one drug library may include a number of parameters to inform operation of the at least one medical device.
  • the drug library may include a plurality of programming limits for the at least one medical device.
  • the medical error reduction software may be further configured to provide quality improvement information to the plurality of users.
  • the set of privileges may be configurable to allocate a drug library review privilege. In some embodiments, the set of privilege may be configurable to allocate a drug library editing privilege. In some embodiments, the set of privileges may be configurable to allocate and editing or creation privilege. In some embodiments, the set of privileges may be configurable to allocate an add user privilege. In some embodiments, the set of privileges allocated to each of the plurality of users may force a collaborative process between the plurality of users for the creating and revising of the at least one drug library.
  • a medical error reduction system may include a drug library editing software for use in creating and revising a number of drug libraries.
  • the number of drug libraries may each contain a plurality of entries.
  • Each of the a number of drug libraries may be for use with at least one medical device.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may comprise a processor in
  • the user interface may be for use by one or more user to edit the at least one drug library.
  • the drug library editing software may be configured to import entries of the plurality of entries in a first drug library in the number of drug libraries to a second drug library in the number of drug libraries.
  • the system may further comprise at least one server configured to execute the medical error reduction software.
  • the number of drug libraries are stored on a drug library database.
  • the drug library database is in a hosted environment.
  • the one or more user may specify the entries of the plurality of entries they would like to import to the first drug library in the number of drug libraries to the second drug library in the number of drug libraries.
  • the first drug library in the number of drug libraries and the second drug library in the number of drug libraries may both belong to a sub-set of drug libraries in the number of drug libraries.
  • the sub-set of drug libraries may be associated with a set of permissions allowing access to the sub-set of drug libraries by the one or more user.
  • the set of permissions disallows access to the sub-set of drug libraries by another one or more user.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries.
  • Each of the at least one drug library may be for use with at least one medical device.
  • the drug library editor software may be executed by a server.
  • the medical error reduction system may include at least one drug library database storing the at least one drug library.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may comprise a processor in communication with a user interface. The user interface may be for use by a user to edit the at least one drug library.
  • the at least one editor computer and at least one drug library database may be configured to
  • the plurality of entries may include one or more clinical advisory.
  • the drug library database is in a hosted environment.
  • the one or more clinical advisory may be a free text entry.
  • the one or more clinical advisory may include an image.
  • the one or more clinical advisory may include a document. In some embodiments, the one or more clinical advisory may be limited to be between 0 and 100 characters in length. In some embodiments, each of the one or more clinical advisory may be associated with a short text clinical advisory. In some embodiments, the short text clinical advisory may be limited to be between 0 and 100 characters in length. In some embodiments, the short text clinical advisory may be displayed on at least one screen of a graphic user interface of the at least one medical device. In some embodiments, each of the one or more clinical advisory may be displayed on at least one screen of a graphic user interface of the at least one medical device. In some embodiment, each of the at least one clinical advisory may be associated with a drug entry in the at least one drug library.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries.
  • Each of the at least one drug library may be for use with at least one medical device.
  • the drug library editor software may be executed by a server.
  • the medical error reduction system may include at least one drug library database storing the at least one drug library.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may comprise a processor in communication with a user interface. The user interface may be for use by a user to edit the at least one drug library.
  • the at least one editor computer and at least one drug library database may be configured to
  • the drug library editing software may be configure to allow a user to enter a note for one or more of the plurality of entries.
  • the drug library database may be in a hosted environment.
  • the note may be a free text entry.
  • the note may include an image.
  • the note may include a document.
  • the drug library editing software may be configured to allow a user to enter a note for one or more sub- set of the plurality of entries.
  • the drug library editing software may be configured to allow a user to enter a note for each of the plurality of entires.
  • each of the plurality of entries associated with a note may be depicted on the user interface with a note indicator.
  • user interaction with the note indicator may cause the note to be displayed on the user interface.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries. Each of the at least one drug library may be for use with at least one medical device.
  • the drug library editor software may be executed by a server.
  • the medical error reduction system may include at least one drug library database storing the at least one drug library.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may include a processor in communication with a user interface. The user interface may be for use by a user to edit the at least one drug library.
  • the at least one editor computer and at least one drug library database may be configured to
  • the plurality of entires may include a flush parameter.
  • the flush parameter may govern flushing of a fluid line associated with the at least one medical device.
  • the flush parameter may include default delivery parameter values to be used by the at least one medical device when the medical device flushes a fluid line associated therewith.
  • the flush parameter may include a volume to be delivered.
  • the flush parameter may include a delivery rate.
  • the flush parameter may include a time.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries.
  • Each of the at least one drug library may be for use with at least one medical device.
  • the drug library editor software may be executed by a server.
  • the medical error reduction system may include at least one drug library database storing the at least one drug library.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may comprise a processor in communication with a user interface. The user interface may be for use by a user to edit the at least one drug library.
  • the at least one editor computer and at least one drug library database may be configured to
  • the drug library editing software may be configured to display a user customizable screen which provides desired at a glance information to the user.
  • the user customizable screen may include one or more widget.
  • the user may choose the one or more widget which is included on the user customizable screen.
  • one of the one or more widget may be a progress widget.
  • one of the one or more widget may be a trend widget.
  • one of the one or more widget may be an overview widget.
  • one of the one or more widget may be a quick links widget.
  • one of the one or more widget may be a change request widget.
  • one of the one or more widget may be a feedback widget.
  • one of the one or more widget may be a medical data widget.
  • one of the one or more widget may be a changes to review widget. In some embodiments, one of the one or more widget may be an administrator comments widget. In some embodiments, the user may choose the one or more widget from a list of permitted widgets. In some embodiments, the user may be assigned a specific role in the medical error reduction software, the list of permitted widgets associated the specific role. In some embodiments, the system further may comprise a user database. In some embodiments, the user customizable screen, once customized, may be stored on a user database and associated with the user. In some embodiments, the user customizable screen may be selected from a number of loadable, customized screen configurations.
  • a medical error reduction system may include a drug library editing software for use in creating and revising at least one drug library.
  • the at least one drug library may contain a plurality of entries. Each of the at least one drug library may be for use with at least one medical device.
  • the drug library editor software may be executed by a server.
  • the medical error reduction system may include at least one drug library database storing the at least one drug library.
  • the medical error reduction system may include at least one editor computer.
  • Each of the at least one editor computer may comprise a processor in communication with a user interface.
  • the user interface may be for use by a user to edit the at least one drug library.
  • the at least one editor computer and at least one drug library database may be configured to communicate via a network.
  • the user may compare two or more entries of the plurality of entries using the drug library editing software. The comparison may be displayed on the user interface.
  • the comparison may be display on the user interface in a table. In some embodiments, the comparison may be a side by side comparison. In some embodiments, differences between the two or more entries in the comparison may be visually indicated on the user interface. In some embodiments, the comparison may include a difference only option. In some embodiments, interaction with the difference only option may toggle the comparison between a state in which only differences between the two or more of the plurality of entries are shown and a state in which all information associated with the two or more of the plurality of entries is shown. In some embodiments, the comparison may include an edit option which may be used to open one of the two or more of the plurality of entries for editing.
  • a method for producing a drug library file may comprise, assigning one of a plurality of sets of privileges to each of a plurality of sets of users.
  • the plurality of sets of privileges may be arranged to allocate a degree of software functionality in a drug library editing software.
  • the degree of software functionality may be configured to define the ability of a user to alter the at least one drug library.
  • the method for producing a drug library file may comprise creating a drug library using at least one editor computer.
  • Each of the at least one editor computer may comprise a processor in communication with a user interface.
  • the user interface may be for use by a user to edit the at least one drug library using the drug library editing software.
  • Creating the drug library may comprise appropriate users of the plurality of sets of users, the appropriate users defined by the plurality of sets of privileges, specifying a master medication list for an institution, defining medication records for one or more portion of the institution, and verifying the defined medication records.
  • the method may include approving the drug library for release to at least one medical device in the institution.
  • producing a drug library file further may comprise conducting a pilot phase for the drug library file in which the drug library file is tested on a test medical device. In some embodiments, producing a drug library file further may comprise conducting a pilot phase for the drug library file in which the drug library file is tested on a simulated medical device user interface. In some embodiments, verifying the defined medication records may comprise reviewing the defined medication records using a simulated medical device user interface.
  • a method for deploying a drug library file to at least one medical device may include creating the drug library file.
  • the method may include approving the drug library file for release to the at least one medical device.
  • the method may include sending a notification to a user via a drug error reduction system editor service.
  • the method may include downloading the drug library file to a device gateway.
  • the method may include disseminating the drug library file to the at least one medical device over a network which allows the device gateway to communicate with the at least one medical device.
  • the method may further comprise the user commanding downloading of the drug library file to device gateway. In some embodiments, the method may further comprises selecting the at least one medical device from a list of medical devices. In some embodiments, the method may further comprise the device gateway periodically checking for updates to the drug library file. In some embodiments, the method further may comprise the at least one medical device validating the drug library file. In some embodiments, the method further may comprise sending a confirmation message to the device gateway from each of the at least one medical device in the event that the drug library file is successfully validated and updated.
  • FIG. 1 shows a block diagram of a system for electronic patient care in accordance with an embodiment of the present disclosure
  • FIG. 2 shows a block diagram of some aspects of the system of Fig. 1 in accordance with an embodiment of the present disclosure
  • FIG. 3 shows a diagram illustrating the aggregation of several facilities for communication in accordance with an embodiment of the present disclosure
  • Fig. 4 shows a diagram illustrating a system for electronic patient care in accordance with an embodiment of the present disclosure
  • FIG. 5 is a block diagram to illustrate some aspects of an electronic communication between a medical device and a device application in accordance with an embodiment of the present disclosure
  • FIG. 6 shows a state diagram illustrating a method of programming an infusion device in accordance with an embodiment of the present disclosure
  • Fig. 7 illustrates a software program that is executable on a processor, the software program and processor are configured for implementing a publish-subscribe model for use by the facility gateway of Fig. 1, and by the applications and the device gateway shown in Figs. 2 and 4 in accordance with an embodiment of the present disclosure;
  • Fig. 8 illustrates a software program that is executable on a processor, the software program and processor are configured for implementing a capability-registry model in accordance with an embodiment of the present disclosure
  • Fig. 9 illustrates a software program that is executable on a processor, the software program and processor are configured for implementing a drug safety method used to generate a drug administration library file in accordance with an embodiment of the present disclosure
  • Fig. 10 depicts an example conceptual diagram detailing possible roles, responsibilities, and privileges of various users and parties which may be involved in the creation of a drug administration library file in accordance with an embodiment of the present disclosure
  • Fig. 11a depicts a diagram which outlines an example hierarchical organization structure of a drug administration library ("DAL”) file in accordance with an embodiment of the present disclosure
  • Fig. l ib depicts a diagram which outlines an example hierarchical organization structure of a drug administration library file in accordance with an embodiment of the present disclosure
  • Fig. 12 depicts a flowchart detailing a number of example steps which may be part of a drug error reduction system setup phase of drug administration library file creation in accordance with an embodiment of the present disclosure
  • Fig. 13 depicts a flowchart detailing a number of example steps which may be used to update reference tables loaded on to a drug error reduction system database in accordance with an embodiment of the present disclosure
  • Fig. 14 depicts a flowchart showing a number of example steps which may be used to establish institution and organizational hierarchies in a drug error reduction system database in accordance with an embodiment of the present disclosure
  • Fig. 15 shows a flowchart showing a number of exemplary steps which may be used when giving a subscribing party access to a drug error reduction system editor
  • Fig. 16a depicts a flowchart detailing a number of example steps which may be used to setup various aspect of a drug error reduction system within an organization or institution in accordance with an embodiment of the present disclosure
  • Fig. 16b depicts a flowchart detailing a number of example steps which may be used to define users, the groups they belong to, and their various permissions and privileges in relation to a drug error reduction system editor in accordance with an embodiment of the present disclosure
  • Fig. 17 shows a flowchart detailing a number of example steps which 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
  • Fig. 18 depicts a flowchart detailing a number of example steps which may be used to create or update an institution/organization master medication list in accordance with an embodiment of the present disclosure
  • Fig. 19 depicts a flowchart detailing a number of example steps which may be used to add clinical advisory entries to a database in accordance with an embodiment of the present disclosure
  • FIG. 20 depicts a flowchart detailing a number of example steps which may be used to modify the general settings for an institution or organization in accordance with an embodiment of the present disclosure
  • Fig. 21 depicts a flowchart detailing a number of example steps which may be used to add a care group to a drug administration library file in accordance with an embodiment of the present disclosure
  • Fig. 22 depicts a flowchart detailing a number of example steps which may be used to add a care area to a drug administration library file in accordance with an embodiment of the present disclosure
  • Fig. 23 depicts a flowchart detailing a number of example steps which may be used in the verification of a care area in accordance with an embodiment of the present disclosure
  • Fig. 24 depicts a flowchart detailing a number of example steps which may be used to update a care area in accordance with an embodiment of the present disclosure
  • Fig. 25 depicts a flowchart detailing a number of exemplary steps which may be used to add drug records or medication records to a specified care area in accordance with an embodiment of the present disclosure
  • Fig. 26 depicts a flowchart detailing a number of example steps which may be used to review a medication list for a particular care area in accordance with an embodiment of the present disclosure
  • Fig. 27 depicts a flowchart detailing a number of example steps which may be used to update a medication list in accordance with an embodiment of the present disclosure
  • Fig. 28 depicts a flowchart detailing a number of example steps which may be used to re-verify a medication list in accordance with an embodiment of the present disclosure
  • Fig. 29 depicts a flowchart which details a number of example steps which may be used to submit a drug administration library file for approval in accordance with an embodiment of the present disclosure
  • Fig. 30 depicts a flowchart detailing a number of example steps which may be used to place a drug administration library file into condition for release in accordance with an embodiment of the present disclosure
  • Fig. 31a depicts a flowchart detailing a number of exemplary steps which may be used to deploy a drug administration library file onto various system components in accordance with an embodiment of the present disclosure
  • Fig. 31b depicts an example flowchart detailing a number of steps which may be used to package and stage a resource for release to a facility gateway in accordance with an embodiment of the present disclosure
  • Fig. 31c depicts an flowchart detailing a number of example steps which may be used to track the deployment of various resources in accordance with an embodiment of the present disclosure
  • Fig. 32 depicts a flowchart which details a number of example steps which may be used to update an existing drug administration library file in accordance with an embodiment of the present disclosure
  • Fig. 33 depicts a flowchart detailing a number of example steps which may be used to update an institution/organization's master medication list in accordance with an embodiment of the present disclosure
  • Fig. 34 depicts a flowchart detailing a number of example steps which may be used to update the clinical advisories list in accordance with an embodiment of the present disclosure
  • Fig. 35 depicts a flowchart detailing a number of example steps which may be used to update the general settings for an institution/organization in accordance with an embodiment of the present disclosure
  • Fig. 36 depicts a flowchart detailing a number of example steps which may be used to update a care area in accordance with an embodiment of the present disclosure
  • Fig. 37 depicts a flowchart detailing a number of example steps which may be used to update Medication Records for a care area in accordance with an embodiment of the present disclosure
  • Fig. 38 depicts a flowchart detailing a number of example steps which may be used to create and save a drug administration library report in accordance with an embodiment of the present disclosure
  • Fig. 39 depicts a flowchart detailing a number of example steps which may be used to create a drug administration library difference report in accordance with an embodiment of the present disclosure
  • Fig. 40 depicts flowchart detailing a number of example steps which may be used to create an intra-organization drug administration library Comparison Report in accordance with an embodiment of the present disclosure
  • Fig. 41 depicts a flowchart detailing a number of example steps which may be used to create an inter-organization drug administration library Comparison Report in accordance with an embodiment of the present disclosure
  • Fig. 42 depicts a flowchart detailing a number of example steps which may be followed to create a drug administration library History Report in accordance with an embodiment of the present disclosure
  • Fig. 43 depicts a flowchart detailing a number of example steps which may be used to log into a drug error reduction system editor in accordance with an embodiment of the present disclosure
  • Fig. 44 depicts an example flowchart detailing a number of steps which may be used to change a password for a drug error reduction system editor service in accordance with an embodiment of the present disclosure
  • Fig. 45 depicts a flowchart detailing a number of example steps which may be used to recover a password for a drug error reduction system editor service in accordance with an embodiment of the present disclosure
  • Fig. 46 depicts a flowchart detailing a number of example steps which may be used to review drug library entry using a medical device programming simulator in accordance with an embodiment of the present disclosure
  • Fig. 47 depicts a flowchart detailing a number of exemplary steps which may be used to compare records in a drug administration library file in accordance with an embodiment of the present disclosure
  • Fig. 48 depicts a flowchart detailing a number of example steps which may be used to update a drug administration library file on a medical device in accordance with an embodiment of the present disclosure
  • Fig. 49 depicts a flowchart detailing a number of example steps which may be used to update a DAL file on a medical device in accordance with an embodiment of the present disclosure
  • Fig. 50 depicts a flowchart detailing a number of example steps which may be used to configure a user interface for a drug error reduction system editor service or Continuous Quality Improvement ("CQI") service in accordance with an embodiment of the present disclosure
  • Fig. 51 depicts a flowchart detailing a number of example steps which may be used to view and make use of Continuous Quality Improvement data in accordance with an embodiment of the present disclosure
  • Fig. 52 depicts a flowchart detailing a number of exemplary steps which may be used to display a desired continuous quality improvement report on a user interface in accordance with an embodiment of the present disclosure
  • Fig. 53 depicts a flowchart detailing a number of example steps which may be used to configure a Continuous Quality Improvement report in accordance with an embodiment of the present disclosure
  • Fig. 54 depicts a flowchart detailing a number of example steps which may be used to configure a Continuous Quality Improvement report in accordance with an embodiment of the present disclosure
  • Fig. 55 depicts a flowchart detailing a number of example steps which may be used to apply a filter to Continuous Quality Improvement data using organization/institutional hierarchy in accordance with an embodiment of the present disclosure
  • Fig. 56 depicts a flowchart detailing a number of example steps which may be used to apply a filter to Continuous Quality Improvement data using a date range or time frame in accordance with an embodiment of the present disclosure
  • Fig. 57 depicts a flowchart detailing a number of example steps which may be used to apply a filter to Continuous Quality Improvement data based on user defined, custom filtering criteria in accordance with an embodiment of the present disclosure
  • Fig. 58 depicts a flowchart detailing a number of example steps which may be used to modify the appearance of Continuous Quality Improvement data such as a Continuous Quality Improvement report on a user interface in accordance with an embodiment of the present disclosure
  • Fig. 59 depicts a flowchart detailing a number of example steps which may be used to modify the time units in a Continuous Quality Improvement report based on a user input in accordance with an embodiment of the present invention.
  • Fig. 60 depicts a flowchart detailing a number of example steps which may be used to hide a shown panel or show a hidden panel in a Continuous Quality Improvement report in accordance with an embodiment of the present invention.
  • Fig. 61 depicts a flowchart detailing a number of example steps which may be used to toggle between a summary view and a detailed view in a Continuous Quality Improvement report in accordance with an embodiment of the present invention.
  • Fig. 62 depicts a flowchart detailing a number of example steps which may be used to sort CQI data in a CQI report in accordance with an embodiment of the present invention.
  • Fig. 63 depicts a flowchart detailing a number of example steps which may be used to toggle between a counts view and a dates view in a CQI report in accordance with an embodiment of the present invention.
  • Fig. 64 depicts a flowchart detailing a number of example steps which may be used to select a utility on a user interface which may allow a user to perform a function or functions in accordance with an embodiment of the present disclosure
  • Fig. 65 depicts a flowchart detailing a number of example steps which may be used to print a continuous quality improvement report in accordance with an embodiment of the present disclosure
  • Fig. 66 depicts a flowchart detailing a number of example steps which may be used to download a continuous quality improvement report in accordance with an embodiment of the present disclosure
  • Fig. 67 depicts a flowchart detailing a number of exemplary steps which may be used to email a continuous quality improvement report in accordance with an embodiment of the present disclosure
  • Fig. 68 depicts a flowchart detailing a number of example steps which may be used to export data from a continuous quality improvement report in accordance with an embodiment of the present disclosure
  • Fig. 69 depicts a flowchart detailing a number of example steps which may be used to schedule a continuous quality improvement report for automatic generation and distribution in accordance with an embodiment of the present disclosure
  • Fig. 70 depicts a flowchart showing a number of example steps which may be used to generate and distribute a scheduled continuous quality improvement report in accordance with an embodiment of the present disclosure
  • Fig. 71 depicts a flowchart showing a number of example steps which may be used to generate an automated continuous quality improvement summary report in accordance with an embodiment of the present disclosure
  • Fig. 72 depicts an example graphical user interface login screen which may be presented to a user when a user attempts to access a drug error reduction system editor service or continuous quality improvement service in accordance with an embodiment of the present disclosure
  • Fig. 73 depicts an example graphical user interface login screen which may be presented to a user when a user attempts to access a drug error reduction system editor service or continuous quality improvement service in accordance with an embodiment of the present disclosure
  • Fig. 74 depicts an example initialization screen which may be displayed on a user interface in accordance with an embodiment of the present disclosure
  • Fig. 75 depicts an example initialization wizard screen in accordance with an embodiment of the present disclosure
  • Fig. 76 depicts an example initialization wizard screen in accordance with an embodiment of the present disclosure
  • Fig. 77 depicts an example initialization wizard screen in accordance with an embodiment of the present disclosure
  • Fig. 78 depicts an example embodiment of a "welcome" screen which may be displayed on a user interface such as a drug error reduction system editor service user interface in accordance with an embodiment of the present disclosure
  • Fig. 79 depicts an example of a drug error reduction system editor dashboard screen in accordance with an embodiment of the present disclosure
  • Fig. 80 depicts an example care area screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 81 depicts an example add care area screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 82 depicts an example add care area screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 83 depicts an example add care area screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 84 depicts an example add care area screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 85 depicts an example add care area screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 86 depicts an example add care area screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 87 depicts an example care area screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 88 depicts an example medication screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 89 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 90 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 91 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 92 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 93 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 94 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 95 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 96 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 97 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 98 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 99 depicts an example medication screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 100 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 101 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 102 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 103 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 104 depicts an example add medication record screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 105 depicts an example medication screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 106 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 107 depicts an example medication screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 108 depicts an example medication record comparison screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 109 depicts an example medication screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 110 depicts an example medication record comparison screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. I l l depicts an example medication record comparison screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 112 depicts an example medical device simulator screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 113 depicts an example medical device simulator screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 114 depicts an example medical device simulator screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 115 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 116 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 117 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 118 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 119 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 120 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 121 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 122 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 123 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 124 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 125 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 126 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 127 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 128 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 129 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 130 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 131 depicts an example continuous quality improvement screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 132 depicts an example of a drug error reduction system editor dashboard screen in accordance with an embodiment of the present disclosure
  • Fig. 133 depicts an example of a drug error reduction system editor dashboard screen in which a feedback item has been accessed in accordance with an embodiment of the present disclosure
  • Fig. 134 depicts an example of a drug error reduction system editor dashboard screen in accordance with an embodiment of the present disclosure
  • Fig. 135 depicts an example of a drug error reduction system editor dashboard screen in which a change request has been accessed in accordance with an embodiment of the present disclosure
  • Fig. 136 depicts an example of a drug error reduction system editor dashboard screen in accordance with an embodiment of the present disclosure
  • Fig. 137 depicts an example of a drug error reduction system editor dashboard screen in accordance with an embodiment of the present disclosure
  • Fig. 138 depicts an example of a drug error reduction system editor dashboard screen in accordance with an embodiment of the present disclosure
  • Fig. 139 depicts an example of a drug error reduction system editor dashboard screen in which a change request has been accessed in accordance with an embodiment of the present disclosure
  • Fig. 140 depicts an example of a drug error reduction system editor dashboard screen in which a change request has been accessed in accordance with an embodiment of the present disclosure
  • Fig. 141 depicts an example of a drug error reduction system editor dashboard screen in accordance with an embodiment of the present disclosure
  • Fig. 142 depicts an example of a drug error reduction system editor dashboard screen in which a proposed change has been accessed for review in accordance with an embodiment of the present disclosure
  • Fig. 143 depicts an example of a drug error reduction system editor dashboard screen in which a proposed change has been accessed for review in accordance with an embodiment of the present disclosure
  • Fig. 144 depicts an example of a drug error reduction system editor dashboard screen in accordance with an embodiment of the present disclosure
  • Fig. 145 depicts an example of a drug error reduction system editor dashboard screen in which a proposed change has been accessed for review in accordance with an embodiment of the present disclosure
  • Fig. 146 depicts an example of a drug error reduction system editor dashboard screen in which a user is using a search utility in accordance with an embodiment of the present disclosure
  • Fig. 147 depicts an example of a review screen which 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. 148 depicts an example of a review screen which 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. 149 depicts an example of a review screen which 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. 150 depicts an example of a review screen which 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. 151 depicts an example of a review screen which 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. 152 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 153 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 154 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 155 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 156 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 157 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 158 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 159 depicts an example drug library entry screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 160 depicts an example drug library screen which may be displayed on a user interface such as the user interface of a drug error reduction system in accordance with an embodiment of the present disclosure
  • Fig. 161 depicts an example drug library screen which 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. 162 depicts an example drug library screen which 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. 163 depicts an example drug library screen which 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. 164 depicts an example prompt which 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. 165 depicts an example drug library screen which 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. 166 depicts an example prompt which 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. 167 depicts an example drug library screen which 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. 168 depicts an example prompt which 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. 169 depicts an example drug library screen which 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. 170 depicts an example drug library screen which 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. 171 depicts an example master medication list screen which 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. 172 depicts an example prompt which 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. 173 depicts an example prompt which 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. 174 depicts an example prompt which 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. 175 depicts an example prompt which 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. 176 depicts an example master medication list screen which 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. 177 depicts an example prompt which 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. 178 depicts an example drug library screen which 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. 179 depicts an example prompt which 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. 180 depicts an example prompt which 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. 181 depicts an example software architecture block diagram for an example medical device in accordance with an embodiment of the present disclosure
  • Fig. 182 depicts a flowchart detailing a number of example steps which may be used to install a syringe on a medical device when preparing to administer an infusion with the medical device in accordance with an embodiment of the present disclosure
  • Fig. 183 depicts a flowchart detailing a number of example steps which may be used to prime an IV line of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 184 depicts a flowchart detailing a number of example steps which 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 depicts a flowchart detailing a number of example steps which may be used to select a care area, medication, clinical use, and a concentration for a medication when programming an infusion on a medical device in accordance with an embodiment of the present disclosure
  • Fig. 186 depicts a flowchart detailing a number of example steps which may be used to program an infusion on a medical device in accordance with an embodiment of the present disclosure
  • Fig. 187 depicts a flowchart detailing a number of example steps which may be used to determine if a parameter entered on a medical device falls outside the limits defined for that parameter in accordance with an embodiment of the present disclosure
  • Fig. 188 depicts a flowchart which details a number of example steps which may be used to deliver a primary continuous infusion in accordance with an embodiment of the present disclosure
  • Fig. 189 depicts a flowchart detailing a number of example steps which may be used to deliver a bolus of a medication with a medical device in accordance with an embodiment of the present disclosure
  • Fig. 190 depicts a flowchart detailing a number of example steps which may be used to deliver a secondary infusion in accordance with an embodiment of the present disclosure
  • Fig. 191 depicts an example flowchart which details a number of steps which may be used to deliver a multi-step infusion with a medical device in accordance with an embodiment of the present disclosure
  • Fig. 192 depicts a flowchart detailing a number of example steps which may be used to titrate an infusion being administered by a medical device in accordance with an embodiment of the present disclosure
  • Fig. 193 depicts a flowchart detailing a number of exemplary steps which may be used at and near the end of an infusion administered by a medical device in accordance with an embodiment of the present disclosure
  • Fig. 194 depicts a flowchart detailing a number of steps which may be used to detect and resolve an air-in-line condition on a medical device in accordance with an embodiment of the present disclosure
  • Fig. 195 depicts a flowchart detailing a number of example steps which may be used to detect and resolve an occlusion in an infusion line associated with a medical device in accordance with an embodiment of the present disclosure
  • Fig. 196 depicts a flowchart detailing a number of steps which may be used to change the care area for a medical device during an on-going therapy in accordance with an embodiment of the present disclosure
  • Fig. 197 depicts a flowchart detailing a number of example steps which may be used to stop an on-going infusion on a medical device in accordance with an embodiment of the present disclosure
  • Fig. 198 depicts a flowchart detailing a number of exemplary steps which may be used in the event that the batteries of a medical device become drawn down to a predetermined level in accordance with an embodiment of the present disclosure
  • Fig. 199 depicts a flowchart detailing a number of steps which may be used to lock and unlock the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 200 depicts a flowchart detailing a number of exemplary steps which may be used to power down a medical device or put a medical device into a sleep state in accordance with an embodiment of the present disclosure
  • Fig. 201 depicts a flowchart detailing a number of steps which may be used to flush an IV line associated with a medical device in accordance with an embodiment of the present disclosure
  • Fig. 202 depicts a flowchart detailing a number of example steps which may be used to install a replacement syringe on a medical device during the course of an infusion in accordance with an embodiment of the present disclosure
  • Fig. 203 depicts a flowchart detailing a number of example steps which may be used to set up a relay infusion with a number of medical devices in accordance with an embodiment of the present disclosure
  • Fig. 204 depicts a flowchart detailing a number of example steps which may be used if a medical device which is part of an established relay infusion is removed from a medical device rack in accordance with an embodiment of the present disclosure
  • Fig. 205 depicts a flowchart detailing a number of exemplary steps which may be used in the event that a medical device which is part of an established relay infusion is removed from a medical device rack in accordance with an embodiment of the present disclosure
  • Fig. 206 depicts an example start up screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 207 depicts an example start up screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 208 depicts an example start up screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 209 depicts an example login screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 210 depicts an example login screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 211 depicts an example login screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 212 depicts an example select care group screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 213 depicts an example select care area screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 214 depicts an example select patient screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 215 depicts an example select medication screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 216 depicts an example select medication screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 217 depicts an example select medication screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 218 depicts an example select medication screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 219 depicts an example select medication screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 220 depicts an example select clinical use screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 221 depicts an example select clinical use screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 222 depicts an example select concentration screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 223 depicts an example enter patient weight screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 224 depicts an example enter patient weight screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 225 depicts an example enter patient weight screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 226 depicts an example load administration set screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 227 depicts an example troubleshooting screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 228 depicts an example load syringe screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 229 depicts an example select syringe screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 230 depicts an example therapy programming screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 231 depicts an example therapy programming screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 232 depicts an example therapy programming screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 232 depicts an example therapy programming screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 233 depicts an example therapy programming screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 234 depicts an example therapy programming screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 235 depicts an example therapy programming screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 236 depicts an example limit override screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 237 depicts an example second user approval screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 238 depicts an example therapy programming screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 239 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 240 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 241 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 242 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 243 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 244 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 245 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 246 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 247 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 248 depicts an example therapy stopped screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 249 depicts an example alarm screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 250 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 251 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 252 depicts an example locked therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 253 depicts an example therapy in progress screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 254 depicts an example therapy complete screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 255 depicts an example therapy complete screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 256 depicts an example notification settings screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • Fig. 257 depicts an example therapy parameters screen which may be displayed on a user interface such as the user interface of a medical device in accordance with an embodiment of the present disclosure
  • FIG. 1 shows a block diagram of a system 1 for electronic patient care in accordance with an embodiment of the present disclosure.
  • System 1 includes facility IT applications/services 11, a facility 10, and a cloud services 2.
  • the facility 10 may be a hospital, a clinic, a medical facility, an outpatient care center, an urgent care center, or a combination or grouping thereof.
  • the facility 10 may include a facility gateway 21 such that various medical devices 26 can communicate with the facility IT applications/services 11 and/or with the cloud services 2.
  • the facility 10 includes various medical devices 26 operated and used by nurses 9 on patients that are in the care of the facility 10.
  • the medical devices 26 may be infusion pumps, peristaltic pumps, syringe pumps, nephrology devices, physiological parameter monitoring devices, other patient-care devices, or some combination thereof.
  • the facility gateway 21 may be hosted, may be in the cloud, may be maintained for the facility 10 by a service provider, may be controlled, maintained or serviced by a combination of service providers and/or facility IT 18 personnel, and/or may be implemented in a virtual or physical environment. In some embodiments, the facility gateway 21 may be implemented in an appliance in a patient's home.
  • the facility gateway 21 may be hosted, may be in the cloud, may be maintained for the facility 10 by a service provider, may be controlled, maintained or serviced by a combination of service providers and/or facility IT 18 personnel, and/or may be implemented in a virtual or physical environment. In some embodiments, the facility gateway 21 may be implemented in an appliance in a patient's home.
  • the facility gateway 21 may be hosted, may be in the cloud, may be maintained for the facility 10 by a service provider, may be controlled, maintained or serviced by a combination of service providers and/or facility IT 18 personnel, and/or may be implemented in a virtual or physical environment. In some embodiments, the facility gateway 21 may be implemented
  • IDN integrated delivery network
  • a biomed PC tool 20 may be used by a biomed technician 19 to update the software of the devices 26.
  • the biomed PC tool 20 may be a browser-based tool for Biomed users 19 to monitor the health of their medical devices 26, view log files, track maintenance activities, and manage the installation of software/firmware.
  • the biomed technician 19 may be a hospital employee (or contract service) who installs, upgrades, and services medical devices 26 (including infusion pumps) to ensure they are in proper working order.
  • the biomed PC tool 20 may interface into the devices 26 via a physical data connection, such as a USB connection or serial cable connection so that the biomed technician 19 may perform these services.
  • the biomed technician 19 may also use the device manager 24 to update the devices 26 wirelessly.
  • the devices 26 communicate with the facility IT applications/services 11
  • the communications links 343 and 344 may use WiFi, Ethernet, TCP/IP, WiMax, fiber optic cables, or any other known communication technology.
  • the devices 26 communicate with the facility gateway 21 by establishing communications (e.g., via registering) with the device gateway 22.
  • the facility gateway 21 may be a computer, a virtual machine, a hardware device, a software device, a hosted device, software in execution, the like, or some combination thereof.
  • the device gateway 22 may be software executable by the facility gateway 21.
  • the devices 26 may communicate with the device gateway 22 using web services. In some specific embodiments, only the medical devices 26 initiate communication with the device gateway
  • the device gateway 22 may include a message routing engine that supports both publish/subscribe and point-to-point routing mechanisms.
  • the device gateway 22 may also provide name resolution and capability registry capabilities.
  • Object-Relational Mapping may be used by the device gateway 22 for small- scale object persistence (e.g., using an object-relational mapping (ORM) engine).
  • ORM object-relational mapping
  • the device manager 24 can provide name resolution and/or registry capabilities.
  • a device of the devices 26 is a monitoring client, such as a tablet computer, a tablet device, a PDA, a smart phone, a laptop computer, or a touchscreen-based computer.
  • a monitoring client of the devices 26 may have a monitoring client app within the device apps 23 which allows a caregiver to communicate with other devices of the devices 26.
  • the monitoring client may be used to receive status information from a medical device of the devices 26, receive CQTmessages from a medical device of the devices 26, receive reportable biomed events (RBEs) or reportable clinical events (RCEs) from a medical device of the devices 26, to program a medical device of the devices 26, or otherwise communicate with a medical device of the devices 26.
  • RBEs reportable biomed events
  • RCEs reportable clinical events
  • the communication links 343 between the devices 26 and the facility gateway 21 may use WiFi, Ethernet, TCP/IP, WiMax, fiber optic cables, or any other known communication technology.
  • the devices 26 communicate with the facility gateway 21 through a cellular connection (e.g., the communications link 343 includes a cellular connection).
  • the devices 26 may be a located within a patient's home, within a clinic, within a field facility (e.g., a tent facility), emergency location, other location, or some combination thereof.
  • the device gateway 22 may provide: (1) component registry and license management (e.g., using the device manager 24); (2) an installation repository for receiving, maintaining and tracking new versions of installable components, such as device firmware/software, drug administration libraries, enterprise application software, and infrastructure software (e.g. operating system releases, application servers, database management system ("DBMS”)); and/or (3) message routing capabilities, such as distributing messages, both among applications within the facility gateway 21 and with external subsystems (e.g. the cloud services 2).
  • component registry and license management e.g., using the device manager 24
  • an installation repository for receiving, maintaining and tracking new versions of installable components, such as device firmware/software, drug administration libraries, enterprise application software, and infrastructure software (e.g. operating system releases, application servers, database management system (“DBMS”)
  • message routing capabilities such as distributing messages, both among applications within the facility gateway 21 and with external subsystems (e.g. the cloud services 2).
  • Deployment environments where medical devices 26 maintain active network connections to the device gateway 22 are called connected environments and may, as previously mentioned, be achieved using wireless networks (IEEE 802.11 b/g/n). Also as previously mentioned, in other embodiments, network connectivity may be achieved through other technologies, like cellular technology.
  • Event subscribers such as the device applications 23, may refine the event stream and republish higher-level events back to the device gateway 22.
  • Reportable biomed events (“RBE"), described below, will be among the events republished by these applications.
  • the RBEs may be reported as CQI messages to the cloud services 2.
  • an application running on the facility gateway 21 is a Biomed Server that subscribes to RBEs and stores them in a local database within the facility gateway 21.
  • Biomed technicians 19 may use their browser to access the device manager
  • the UI of the device manager 24 may command the biomed server to access the database and generate HTML/JS pages for browser display to the biomed technician 19.
  • the biomed technician 19 before a new device of the medical devices 26 is authorized for use with the device gateway 22, the biomed technician 19 must register the new device using its serial number. This may be validated using asymmetric key (public/private key pairs) encryption, and may be performed as part of the manufacturing process. Once a device of the medical devices 26 is registered with the device gateway 22, the biomed technician 19 configures its wireless protocol and encryption settings. Once a medical device of the medical devices 26 is registered with the device gateway 22, it reports its initial configuration, including model, options, and hardware, firmware and device control software version for storage within the device gateway 22 and/or within the device manager 24. Similarly, when a device is removed from the list of authorized devices of the device gateway 22, the biomed technician 19 can unregister it.
  • asymmetric key public/private key pairs
  • Each of the medical devices 26 may run a self-test on startup, and publish an event to the device gateway 22 containing the results.
  • the medical devices 26 may routinely run for a long time interval between restarts, the medical devices 26 may automatically schedule and run certain self-tests at times which do not interfere with patient safety and/or treatment.
  • the facility gateway 21 includes device apps 23 which may communicate data using publish-subscribe data connections (described below). Each device app of the devices apps 23 may be for a particular type and/or model of device of the devices 26. These applications may provide software intelligence to medical devices 26, by receiving, filtering and analyzing raw events, and retransmitting higher-level interpretations. Each type of medical device (of the medical devices 26) may have a corresponding device application (of the device applications 23).
  • the facility gateway 21 also includes a device manager 24 for controlling, managing, or monitoring the devices 26.
  • the device manager 24 may be used to update and/or download configuration files (e.g. DAL files) into a device of the devices 26.
  • the biomed technician 19 may control the updating of software, firmware, or configuration files of the devices 26.
  • the device manager 24 may provide a browser-based tool for IT managers and/or technicians 18 to monitor the health of the hardware, software and network resources used to support delivery of patient care. That is, the facility gateway 21 may be managed by a facility IT employee/contractor 18.
  • a secure messaging link may send the DAL file from the DAL manager 5 to the device gateway 22 to notify the Biomed technician 19 of its availability.
  • This notification specifies the device type, location of the DAL, documentation, release notes URL, installer URL, checksum, and installation dependencies.
  • the device manager 24 has access to the new DAL file, receives the DAL file from the device gateway 22, receives the DAL file directly from the DAL manager 5, and/or controls the updating of the medical devices 26 using the DAL file.
  • the Biomed technician 19 uses the release notes
  • the biomed technician 19 selects one or more of the medical devices 26 to copy the new DAL file to.
  • the selected one or more of the medical devices 26 may then be notified (e.g., via the device gateway 22) that a new DAL file is available for them.
  • the selected group of the medical devices 26 installs the new DAL version (backing it out on error) and notifies the device gateway 22 and/or the device manager 24 of the outcome.
  • Any of the procedures described herein to update the DAL file may be used to update firmware, software, an OS, or other configuration files of a medical device of the medical devices 26.
  • the facility gateway 21 may also include an integration API 25 that allows the devices 26, the device apps 23, and/or the device manager 24 to communicate with various databases of the facility IT apps 11, such as the Patient Information System 16, the Electronic Medical Records 17, the Computerized Physician Order Entry 14, the Laboratory Information System 15, the Real-Time Location Services 12, and/or other databases or services 13.
  • the integration API 25 enables the components within the facility gateway 21 to interoperate with the facility IT applications/services 11.
  • the facility gateway 21 may communicate with the facility IT apps 11 via a communications link 341 that may include a wireless link, a hardwired link, a TCP/IP link, an internet link, a software communications link, a hardware communications link, or other communications technique or technology.
  • the facility IT apps/services 11 support the administrative functions of the hospital (e.g. admission, discharge, transfer, coding, billing, collections, etc.).
  • the integration API 25 isolates differences in the applications 12-17 of the facility IT apps 11 from the applications 23-24, the device gateway 22, and/or the devices 26.
  • a device of the devices 26 may request from the device gateway 22 programming information (or the programming information may be pushed to the device of the devices 26).
  • the patient ID, the pump ID, the drug, and the rate of flow may reside in one or more of the facility IT apps 11; the integration API 25 provides a common format for communicating this information to the devices 26 regardless of the needs or requirements of the facility IT apps 11.
  • This information may be gathered by the integration API 25 querying various ones of the facility IT apps 11 to obtain the data and provide the data to the devices 26 in a standardized format.
  • the integration API 25 may be capable of being used with a variety of facility IT apps 12-17 having different formats, data standards, communication standards, encryption standards, etc., but provides a standard interface with the apps 22-24 and/or the devices 26.
  • the integration API 25 facilitates auto-programming of one or more of the devices 26.
  • the prescription may be sent from one of the servers of the facility IT applications 14.
  • the integration API 25 may receive the prescription to reformat it and send it to the device gateway 22.
  • the facility gateway 21 may include a clinical server which writes the prescription event to a persistent cache.
  • the clinical server may start an auto- programming workflow. This workflow may identify a medical device of the medical devices 26 corresponding to the target patient and send a command message to the respective device of the medical devices 26 to load the prescription.
  • the respective medical device of the medical devices 26 will acknowledge receipt of the prescription and display a notification on the display.
  • the clinician may locate the medication bag and may use a barcode reader, for example, on the respective medical device of the medical devices 26 to validate the medication and patient.
  • the respective medical device of the medical devices 26 may then confirm that the medication matches the prescription, and the clinician starts administration.
  • the respective medical device of the medical devices 26 completes the auto-programming workflow by sending a message to the clinical server
  • the caregiver may use a UI to verify the programming of a medical device of the devices 26.
  • the clinician locates the medication, and uses the user interface of the respective medical device of the medical devices 26 to either verify the auto-programming parameters of the medical device of the devices 26 and/or manually program the medical device of the medical devices 26.
  • the PIS 16 is a departmental system used by the pharmacists 8 to receive, review, track and fill orders for prescription medications.
  • the EMR 17 system keeps track of patient medical history in the health care institution (encounters, exams, diagnoses, procedures, etc.).
  • the CPOE 14 is a system used by doctors or nurses 9 to order lab tests, prescription drugs, medical images and other clinical procedures.
  • the LIS 15 is a departmental system used by lab technicians to receive and process orders for clinical samples (e.g. tissue, blood, urine, etc.)
  • the RTLS 12 tracks the location and status of the devices 26.
  • the other 13 may be any other database used for patient care.
  • the cloud services 2 include a cloud-hosted infusion safety manager 3
  • ISM Infusion safety manager may be used interchangeably herein with the term hosted safety manager (“HSM”).
  • HSM 3 includes a Continuous Quality Improvement (“CQI”) manager 4 and a DAL manager 5.
  • CQI Continuous Quality Improvement
  • the risk officers 6, the nurse managers 7, and the pharmacists 8 may all review the CQI messages retrieved by the CQI manager 4 to facilitate the development and improvement of a DAL file via the DAL manager 5.
  • the DAL file may thereafter be downloaded into one or more of the devices 26.
  • the DAL manager 5 may include or is associated with a Drug Error Reduction System (“DERS”) editor (e.g., the DERS editor 112 of FIG. 4, described below).
  • DERS Drug Error Reduction System
  • FIG. 2 shows a block diagram of some aspects of the system of FIG. 1 in accordance with an embodiment of the present disclosure. That is, FIG. 2 shows more details of some aspects of FIG. 1.
  • the device gateway 40, the device manager 41 and the integration API 65 are all part of the facility gateway 21 of FIG. 1.
  • the large volume app 44, the syringe pump app 43, and the other app 42 are all applications that are part of the device apps 23 of FIG. 1.
  • the device manager 41 including its associated database 45 may be the device manager 24 of FIG. 1.
  • LVP app 44 is an application for the LVP 36.
  • the syringe app 43 is an application for the syringe pump 38, and the other application 42 is an application for another device 39.
  • the other application 42 and the another device 39 may correspond to any medical device.
  • the device gateway 40 provides publish-subscribe data connections 58-64.
  • the applications 42, 43, 44 also provide publish-subscribe data connections 49-57.
  • the publish-subscribe messaging pattern provides for the communication between the device gateway 40 and/or the applications 41, 42, 43, 44, 65, 72.
  • another messaging pattern may be utilized for communications.
  • the CQI listener 72 may subscribe to various data feeds from the applications 42, 43, 44 to report CQI messages to the CQI manager 29 which may store them in the database 30.
  • the CQI listener 72 may report the raw results of the published connections 49-57 and/or 58-64, and/or may format them.
  • the applications 42, 43, 44 reformat the raw events from a respective device of the devices 36-39 (that are received via subscriptions to topics registered by the device gateway 40) into CQI- messages.
  • the applications 42, 43, 44 may register CQI-topics which are subscribed to by the CQI-listener 72.
  • the applications 42, 43, 44 publish the CQI-messages into these CQI-topics which causes the CQI-listener 72 to receive the CQI messages.
  • the CQI-listener 72 transmits the CQI messages to the cloud services 28.
  • a single GUI interface 33 may be used to view the
  • FIG. 3 shows a diagram 73 illustrating the aggregation of several facilities
  • the several facilities 76-80 may each include a facility gateway 21 (see FIG. 2) for communication with cloud services, such as the infusion safety manager 74.
  • the several facilities 76-80 are part of a group of facilitates that share a common infusion safety manager 74 that is not accessible by other facilities not within the group of facilities 76-80.
  • the group of facilities 76-80 in FIG. 3 communicates with the infusion safety manager via the communications link 344. Such an arrangement may be used in the event that a group of facilities 76-80 is grouped into a larger organization such as an Integrated Delivery Network (IDN) 75.
  • IDN Integrated Delivery Network
  • FIG. 4 shows a diagram illustrating a system 81 for electronic patient care in accordance with an embodiment of the present disclosure.
  • the system 81 includes a facility, e.g., a hospital network 82, and cloud services 83.
  • the hospital network 82 includes a hospital information network 84, an
  • EMR 85 EMR 85, a CPOE 86, a PIS 87, a LIS 88, an integration engine 89, a integration capabilities component 90, a clinical state manager 91, databases 92, 95 and 98, a biomed application 94, a CQI listener 93, a pump application 96, a syringe application 97, a device gateway 99, a firewall 100, and medical devices 101.
  • systems 84-88 may be external to the hospital network 82.
  • a team of biomed technicians 102 may be available to use the biomed application 94.
  • the cloud services 83 includes databases 104, 105, 106 and 113, a firewall
  • a CQI receiver 108 may interface into the DERS editor 112 and/or the CQI UI 110.
  • Safety staff 107 may interface into the CQI UI 110 and/or the DERS editor 112.
  • the DERS editor 112 and/or the CQI UI 110 may be a browser-based interface. In some embodiments, the DERS editor 112 and CQI UI 110 may be accessed by the same browser- based interface.
  • the HIS 84 supports the administrative functions of the hospital (e.g. admission, discharge, transfer, coding, billing, collections).
  • the EMR 85 keeps track of patient medical history in the health care institution (encounters, exams, diagnoses, procedures, etc.).
  • the CPOE 86 is a system used by doctors to order lab tests, prescription drugs, medical images and other clinical procedures.
  • the PIS 97 is a departmental system used by pharmacists to receive, review, track and fill orders for prescription medications.
  • the LIS 88 is a departmental system used by lab technicians to receive and process orders for clinical samples (e.g. tissue, blood, urine, etc.).
  • the hospital integration engine 89 provides message translation capabilities to enable the information system 84-88 to interoperate with each other and with external systems.
  • An Integration Engine may be located on the device gateway 99 to interoperate with the HIS, EMR and PIS, through the hospital integration engine 89.
  • the device gateway 99 provides message routing engine, supporting both publish/subscribe and point-to-point routing mechanisms.
  • the device gateway 99 also provides name resolution and capability registry capabilities.
  • Various devices 101 are used to treat patients, such as infusion devices that deliver medication, nutrition and hydration in liquid form to patients via intravenous (IV), subcutaneous, or other routes.
  • a pump application 96 and a syringe application 97 are applications that provide software intelligence to medical devices 101, by receiving, filtering and analyzing raw events, and retransmitting higher-level interpretations.
  • Each type of medical device of the devices 101 may have a corresponding device application, e.g., one of the applications 96-97.
  • Each infusion device of the devices 101 may be used to control delivery of a specific infusate (e.g. hydration, nutrition, blood or medication in liquid form) to a specific patient. Dose adjustments, in the form of loading or bolus doses, or dose titrations may be considered to be separate infusion phases within a parent infusion. A collection of infusions or infusion events for the same patient as part of the same therapy are considered to be an "Infusion Story" which may be recorded by a CQI server 109.
  • a specific infusate e.g. hydration, nutrition, blood or medication in liquid form
  • Dose adjustments, in the form of loading or bolus doses, or dose titrations may be considered to be separate infusion phases within a parent infusion.
  • a collection of infusions or infusion events for the same patient as part of the same therapy are considered to be an "Infusion Story" which may be recorded by a CQI server 109.
  • An infusion may be organized into a setup phase, a programming phase, and a delivery phase.
  • a clinician verifies the infusate, patient and pump, and connects the tubing from the infusate to the pump and the pump to patient, which may be recorded by the CQI server 109.
  • the clinician enters the dose parameters into the pump and the pump verifies them using the installed DAL version (which may also be recorded by the CQI server 109).
  • the pump delivers the specified volume of infusate at the programmed rate.
  • Each of the medical devices 101 may detect alarm conditions (i.e. situations where the pump is not infusing), as well as alert and advisory conditions, which may or may not be safety-critical. Each of the medical devices 101 may attempt to establish a secure network connection to the device gateway 99. Each of the medical devices 101 may collect programming, delivery status and exception events for each infusion and provide them to the device gateway 99 so that they may be reported as CQI messages to the CQI receiver 108. Each of the medical devices 101 may communicate these events to the device gateway 99, which routes the data to the CQI receiver 108 (directly or indirectly).
  • alarm conditions i.e. situations where the pump is not infusing
  • alert and advisory conditions which may or may not be safety-critical.
  • Each of the medical devices 101 may attempt to establish a secure network connection to the device gateway 99.
  • Each of the medical devices 101 may collect programming, delivery status and exception events for each infusion and provide them to the device gateway 99 so that they may be reported as CQI messages to the CQI receiver 108.
  • the medical device may save these events in an internal buffer, and permit the biomed technician 102 to copy them to portable media (e.g., a memory stick) with or without the use of the biomed application 94.
  • these events may be downloaded via the biomed application 94 running on a personal computer that has a USB cable coupled to the medical device.
  • the biomed app 94 provides a browser-based tool for biomed users 102 to monitor the health of their medical devices 101, view log files, track maintenance activities, and manage the installation of software/firmware.
  • the log files, maintenance logs, and software/firmware installation and upgrade tracking data may be stored in the database 95.
  • the device gateway 99 may be a bed-side device that couples to all of the devices 101 associated with a particular patient.
  • the device gateway 99 is a software application executable on a facility gateway.
  • the device gateway 99 is software executable on a bed-side appliance (e.g., a compact computer).
  • the device gateway 99 may be a message router, a service registry, and/or a pump authorization registry.
  • the device applications 96-97 can register message types and publish messages to the gateway device 99. Any medical device of the medical devices 101, including sensors that may plug into a medical device (see other 37 in FIG. 2) of the medical devices 101 (e.g. respiratory monitor into PCA) can be used to publish data via the gateway device 99.
  • the device applications 96-97 may act as "information refineries.” Each of the device applications 96-97 subscribes to messages from a particular type of bed-side device of the medical devices 101 via the gateway device 99. Each of the device applications 96-97 can synthesize CQI, clinical, and biomed information from an event stream received from one or more of the medical devices 101 through the device gateway 99. In some embodiments, each of the device applications 96-97 re-publishes these higher level events to the device gateway 99 or to other subscribers, such as the CQI listener 93. [00309] In some embodiments, some of the CQI messages may be used for auto- documentation, auto-programming and billing functions.
  • the CQI messages may be used for auto-documentation from the medical device 101 into the EMR 85 and/or for auto-programming of the medical device 101 from an eMAR system (e.g., part of HIS 84).
  • the CQI messages may include drug safety events and latency information.
  • the CQI listener 93 subscribes to events related to continuous quality improvement of drug safety and ensures their reliable delivery to the hosted environment.
  • the CQI listener 93 may store the events in the database 98 for periodic transmission to the CQI receiver 108 (through the firewall 103).
  • the CQI receiver 108, the CQI server 109, and the CQI UI 110 may be provided in a hosted environment 83 (i.e., cloud services).
  • a master-slave database replication (database 105 as master and 106 as slave) may be used in the hosted environment 83 in order to reduce conflicts between user queries and CQI data updates.
  • the CQI server 109 may post-process CQI events into summary (reportable) form prior to storing them in the database 105 in order to reduce response time for top-level queries and presentation requests.
  • the CQI UI 110 may provide a series of standard reports (compliance, limit violations, titration safety, events by stage, and events by priority).
  • the CQI sever 109 may support a query API, to be used by the DERS editor 112 and the CQI UI 110 to drill down to more detailed summaries and into details of particular CQI messages.
  • the CQI server 109 provides analysis and query services for a user using the
  • the CQI server 109 may provide the user of the CQI UI 110 summary totals for CQI messages and update summary tables (on a configurable interval). The purpose of these summary tables is to reduce response time for top-level CQI queries.
  • These summaries may cover the following statistical measures: (1) programming modes used, such as infusions using DERS limits vs. wildcard; (2) soft and hard limit violations; (3) titration safety information, such as titration increase/decrease settings and dose limit violations; (4) reportable clinical events (e.g., RCEs 149 of FIG. 5, described below) by priority level; and/or (5) reportable clinical events (e.g., RCE 149 of FIG. 5, described below) by infusion stage.
  • a web service query API may be used to enable the CQI UI 110 and/or the
  • DERS editor 112 to select: (1) summary totals for each data view described above, filtered by the specified selectors; (2) RCE detail by infusion; and/or (3) actual programming, limits and infusion statistics by patient (i.e. infusion stories).
  • the DERS editor 112 and/or any system of the hosted services 83 may be based upon a J2EE- compliant application server.
  • the databases 104, 105, 106, and 113 may use a database management server.
  • DERS database 113 may be imported to perform a DERS database 113 initialization: (1) reference tables, such as units of measure, dose modes, etc.; (2) access control tables for administrative users, roles, privileges and permissions; (3) DERS medication list; (4) National Database of Nursing Quality Indicators (NDNQI) care area list; (5) institution attributes; and/or (6) database tables required by the DERS editor 112.
  • the DERS editor 112 may be used to add or edit organizations, add or edit regions, and/or add or edit access control (each with or without attributes).
  • the DERS Editor 112 and/or the DERS database 113 may run in a single application server and database environment for multiple facilities 82.
  • each institution 82 may be hosted in its own virtual environment (e.g., cloud services 2).
  • the CQI UI 110 and/or DERS editor 112 may support an HTTP/Javascript interface for producing CQI reports and interactive drill-down operations to users who are running a web browser, in some specific embodiments.
  • the CQI messages are received by the CQI receiver 108 which stores them in the database 105. If the CQI receiver 108 cannot process all of the incoming CQI messages at a predetermined rate and/or the CQI receiver's 108 buffer is full, the CQI messages are temporarily stored in the database 104, which may be accessed by the CQI receiver 108 for storage within the database 105 when the CQI receiver is unloaded.
  • the database 105 may be replicated by the database 106.
  • the database 106 is user accessible via the CQI server 109 using either the CQI user interface 110 and/or the DERS editor 112.
  • the CQI databases' 105, 106 records depend on the DERS editor 112.
  • the records include: (1) reference tables, such as units of measure, dose modes, etc.; (2) access control tables for administrative users, roles, privileges and permissions; (3) DERS Medication List; (4) NDNQI care area list; and/or (5) institution attributes.
  • reference tables such as units of measure, dose modes, etc.
  • DERS Medication List for administrative users, roles, privileges and permissions
  • NDNQI care area list and/or (5) institution attributes.
  • Access control for the CQI databases 105, 106 may be similar in structure but different in content versus the DERS database 113. Some users may be defined for the CQI server 109 but not for the DERS editor 112. Even for those users which appear in both, permissions may differ (e.g. some CQI data is read-only). In some embodiments, users and their permissions and access credentials may be stored in a user database 7000 which may be in the hosted environment.
  • Certain database tables may be required by the CQI databases 105, 106 and may be setup when the CQI databases are 105, 106 created.
  • the CQI UI 110 and/or the DERS editor 112 may each utilize data from the
  • CQI server 109 (and thus data from the database 106) and data from the DERS editor 112 (and thus with the database 113) to generate a DAL file 114.
  • the clinical state manager 91 is an intermediary between the device gateway 99 the integration engine 89 which orchestrates asynchronous workflows involving several actors and components.
  • Pharmacists and select clinicians 111 use the DERS editor 112 to define drug limits for an institution and create a DAL file 114 (which may be in an XML format).
  • the drug limits may be defined using a well-defined, carefully controlled, fully documented process, with controlled release procedures. Drug limits may be specified using the DERS editor 112 of the DAL manager 5.
  • the facility 82 may use common reference models for medications, care areas, dose modes, etc. to facilitate later cross-institutional comparison.
  • the DERS editor 112 may run in the hosted environment 83 such that users access it using a web browser. In some embodiments, no client-side software is required to run the DERS editor 112 except for a sufficient browser.
  • the DERS editor 112 may provide drug limits and defaults that are organized by care area, medication, clinical use, medication concentration, etc.
  • the DERS editor 112 may support a query interface to the CQI server 109 to integrate the search and analysis of CQI insights to improve the next DAL version.
  • a formulary database 7002 may also be included.
  • the formulary database 7002 may include a master list of medications and drugs which may be included in various DAL files 114.
  • the formulary database 7002 may interface with the DERS editor 112 and the CQI server.
  • the DERS editor 112 may draw from the formulary database 7002 during the creation of DAL files 114. This may help to ensure consistency of data across various DAL files and facilitate comparison of a number of DAL files 114.
  • FIG. 5 shows a block diagram 144 to illustrate some aspects of a communication between a medical device 145 (e.g., an infusion pump) and a device application 151 (e.g., a pump application) in accordance with an embodiment of the present disclosure.
  • a medical device 145 e.g., an infusion pump
  • a device application 151 e.g., a pump application
  • FIG. 5 shows a block diagram 144 to illustrate some aspects of a communication between a medical device 145 (e.g., an infusion pump) and a device application 151 (e.g., a pump application) in accordance with an embodiment of the present disclosure.
  • a pump 145 is described herein with reference to FIG. 5, it is contemplated to use any other medical device in place of or with the pump 145 to generate the event 146.
  • a medical device 145 e.g., an infusion pump
  • an event 146 e.g., a pump event
  • the pump event 146 may be a CQI-message, may be the basis for a CQI-message, or it may be other data, such as raw data, from the medical device 145.
  • the pump event 146 may be an operating parameter, a delivery parameter, and/or other operating events.
  • the pump event 146 may use Simple Object Access Protocol ("SOAP") using Web Services (“WS”) addressing.
  • SOAP Simple Object Access Protocol
  • WS Web Services
  • the event 146 is communicated using Representational State Transfer (“REST”) which may use the full HTTP (or HTTPS) protocol.
  • REST Representational State Transfer
  • the event 146 may be an event as shown Table 1 as follows:
  • Device Hardware Status Array (provide a set of hardware parameters, e.g., 20 hardware parameters specific to the internal functioning of the device) Table 1
  • the items listed as 1, 2, 3, 4, 5, 6, 7, 8, and 9 in Table 1 are pump event classes.
  • these events are stored in a local memory buffer of the medical device 145. While connected (and once re-connected), these events are published to the device gateway 147 using a secure protocol, e.g., SSL, SSH, symmetrical-key encryption, and/or asymmetrical-key encryption. Alternatively, these events may be copied to a portable storage medium and manually published to a device gateway 147.
  • the device gateway 147 may act as (or contain) a publish-subscribe engine that is configured to route pump events to interested subscribers.
  • the pump events may be sent to the CQI manager 4 that relates to the device events of the devices 26. These events may be used to monitor an entire fleet of the medical devices 26 across many facilities 10.
  • the Device Hardware Status Array 9.71 may be converted to a CQI message and is communicated to the CQI manager 4.
  • a user may log into the CQI manager 4 to schedule maintenance events, order new parts based upon the data, to provide predictive or preventive maintenance, and/or to order new parts for preventative reasons or predictive reasons.
  • the user may use deterministic heuristics to determine what to order, when to order it, and/or when to flag some of the devices 26 in various facilities 10 for maintenance.
  • the CQI manager 4 may be used for supply chain management of parts for a fleet of devices 26, and may provide real-time information about the status of the fleet of devices 26.
  • the Device Hardware Status Array may include battery information such as the current at full charge, which indicates the health of an internal battery.
  • the CQI manager 4 may automatically order new batteries when the health of the battery falls below a predetermined threshold. Additionally or alternatively, the CQI manager 4 may automatically schedule for the battery to be replaced in these identified devices of the devices 26.
  • a device application 151 e.g., a pump application configured for operation with a pump
  • the device gateway 147 may be different hardware and/or software.
  • the device application 151 subscribes to events published by the medical device 145.
  • the pump app 151 may process the stream of raw events and refine them into streams of higher-level clinical events, e.g., the reportable clinical event 149 which may be reported to a server of the hosted cloud services for storage therein (e.g., the database 30 of FIG. 2).
  • a server of the hosted cloud services for storage therein e.g., the database 30 of FIG. 2.
  • the device application 151 is deployed in a J2EE application server as a message driven bean ("MDB").
  • the MDB is a stateless component that subscribes to a Java Message Service (JMS) Topic, e.g., PumpTopic 150.
  • JMS Java Message Service
  • An application server of the device gateway 147 may activate the device application 151 on a worker thread when a message is available.
  • the device application 151 is a stateful component and contains one pump handler 153 instance for each pump 145 deployed in the institution.
  • the pump dispatcher 152 maintains a lookup table of pump handlers 153 using the pump's 145 serial number as a unique key.
  • the pump MDB uses the application server's naming service to access the pump application 151. It gets the pump's 145 serial number from the message header, and uses the pump dispatcher 152 to find the appropriate pump handler of the pump handlers 153. If the respective pump handler of the pump handlers 153 is busy (processing another message, on another thread, etc.), the pump MDB queues the message to the pump dispatcher 152 (to ensure messages are processed in sequence). If the respective pump handler of the pump handlers 153 is idle, the pump MDB asks the respective pump handler of the pump handlers 153 to process the event.
  • Each pump handler of the pump handlers 153 maintains a set of finite state machines ("FSM”), each of which processes a relevant subset of the pump events (see Table 1 above), including a pump FSM 156, a program FSM 157, and a delivery FSM 158.
  • FSM finite state machines
  • the pump FSM 156 is the top-level state machine that processes events which do not belong to any infusion.
  • the program FSM 157 is a child state machine which is activated when an infusion programming context is started, and is responsible for processing infusion programming events.
  • the delivery FSM 158 is a child state machine which is activated when infusion delivery is started, and is responsible for processing operational events during an infusion.
  • a separate programming FSM 157 and delivery FSM 158 may be used because a secondary infusion (incl. loading, bolus, or titration) can be programmed while a primary infusion is in progress.
  • the medical device's 145 operating model e.g., pump FSM 156
  • the medical device's 145 operating model may be used to construct reportable clinical events (RCEs) 149 or to construct reportable biomed events (RBEs) 148.
  • the pump FSM 156 may: keep track of the pump 145 when it completes one infusion and reverts to another which was suspended; keep track of programming of one infusion while another is running; and/or keep track of more than one high-priority operational alarm that may occur at one time. That is, the pump FSM 156 may include nested state models.
  • Each pump handler of the pump handlers 153 may also maintain some context objects to hold programming and delivery context information. These context objects will be generated as Biomed Events (for tracking pump utilization) when complete, and will be persisted for recovery, in case the pump application 151 needs to be restarted.
  • the context objects may include an infusion state, an infusion mode, and an infusion segment.
  • the infusion state includes the programming/delivery state data for primary and secondary infusions.
  • the infusion mode includes the programming/delivery state data for a particular dose/rate (e.g. loading, bolus, and/or titration).
  • the infusion segment includes the delivery state for an operational period within an infusion mode (e.g. pumping, stopped, alarmed, etc.).
  • a respective FSM 156, 157, or 158 may transition to a new state, create, update or delete a context object, and output a reportable event (a CQI-message), such as a reportable biomed event 148 or a reportable clinical event 149.
  • a reportable event a CQI-message
  • a reportable biomed event 148 a reportable biomed event 148 or a reportable clinical event 149.
  • the CQI Listener 93 of FIG. 4 may run inside each facility 82, can connect to the device gateway (99 in FIG. 4 or 147 of FIG. 5), and subscribe to CQI RCEs 149 or the CQI RBEs 148.
  • the CQI Listener 93 of FIG. 4 may establish a secure private connection to the CQI receiver 108 in the hosted environment 83 (see FIG. 4). This connection may be physical (continuously connected) or logical (transient connection while transmitting messages).
  • the device gateway 147 may route the RCEs 149 or RBEs 148 to the CQI listener 93.
  • the CQI listener 93 may ensure message durability (i.e.
  • the CQI listener 93 may: (1) store each message to be transmitted to a local persistent queue (for buffering); (2) transmits each of the RCEs 149 and/or RBEs 148 from the head of the queue to the CQI Receiver 108; and/or (3) remove the message after receiving acknowledgement from the CQI receiver 108.
  • the CQI receiver 108 runs inside a hosted environment within the hosted environment 83.
  • the CQI receiver 108 listens for and accepts secure network connection requests from one or more CQI listeners 93.
  • the CQI receiver 108 receives RCEs 149 from each connected CQI listener 93.
  • the CQI receiver 108 may ensure message durability, so upon receipt, it writes each RCE 149 into the database 105.
  • the CQI receiver 108 (1) stores each message received (CQI messages) to a local persistent queue (for buffering); (2) appends each CQI message from the head of the queue to a table in a CQI event database; (3) acknowledges receipt of the message to the CQI listener 93 that sent the message; and (4) removes the CQI message from the local queue (as it is safely in the CQI event database 105).
  • the CQI Event Database 105 is implemented using a Master-Slave replication. That is, database 105 is the master while database 106 is the slave. With this approach, there are two copies of the CQI event database with identical schemas, in some specific embodiments. As insert, update, and delete transactions are applied to the master database 105, a database management system (DBMS) within the database 105 writes the changes to a journal, and is able to transmit unposted changes to the slave database 106.
  • DBMS database management system
  • Each CQI message (e.g., a RCE) may belong to a specific institution. This institution reference should match the institution which operates the medical device (e.g., a medical device of the medical devices 101 of FIG. 4 or the medical device 145 of FIG. 5) and which released the Drug Administration Library (DAL) which is deployed in that device.
  • the CQI databases 105, 106 may require a list of institutions which are consistent with the DERS database 113.
  • FIG. 6 shows a state diagram illustrating a method 161 of programming an infusion device (e.g., of devices 16 of FIG. 1) in accordance with an embodiment of the present disclosure.
  • the method 161 begins with the user capable of interfacing with a UI of the device.
  • State 162 is when the basic mode programming is used (e.g., when a DERS compliance exception device is used, for example). After programming using a DERS compliance exception device, the method transitions to state 165 in which the drug programming is complete.
  • State 166 is when the DERS-based protection is used and dose parameters are programmed into the device, which transitions to state 165 if no limit violation is detected. If there is a soft limit violation detected or a hard limit violation detected, the method 161 transitions to state 167. If it is a soft limit, the clinician may: (1) override the software limit which causes the method to continue to state 165; (2) program the infusion attributes with unchanged infusion intent, which either continues to state 165 if no new violation is found or to state 167 if a new violation is found; or (3) change the infusion intent (e.g. change the medication, care area, clinical use and/or concentration) which causes the method 161 to restart at state 166.
  • the clinician may: (1) override the software limit which causes the method to continue to state 165; (2) program the infusion attributes with unchanged infusion intent, which either continues to state 165 if no new violation is found or to state 167 if a new violation is found; or (3) change the infusion intent (e.g. change the medication
  • the infusion method 161 may be cancelled during many states.
  • the clinician can cancel the infusion before programming is completed.
  • the DERS programming state 166 the clinician can cancel the infusion before the programming is completed.
  • state 167 when a DERS soft limit or hard limit violation has been detected, the clinician can cancel the infusion.
  • the medical device will present an "infusion start” button in which the caregiver can press to transition a medical device to state 163, in which the infusion begins.
  • a suspend button may be present on the user interface when in state 163, which causes the device to suspend when pressed thereby transitioning the device to state 164.
  • a continue button may be present on the user interface when in state 164, which causes the device to return to state 163 when pressed to continue therapy. If a fatal error (a predetermined set of errors) is detected in states 163 and/or 164, the method 161 transitions to the end state.
  • the pump Upon completion of the infusion, the pump sends an infusion complete message to the clinical server via the device gateway.
  • the clinical server links the completion event to the prescription record.
  • the clinical server may format an IHE auto- documentation message and sends it to one of the facility IT apps 11 (see FIG. 1), e.g., for recording in an Electronic Medical Administration Record (“eMar"), to update the patient's Electronic Medical Record (EMR) 17, and/or update the hospital's billing system to record successful infusion of the medication.
  • eMar Electronic Medical Administration Record
  • EMR Electronic Medical Record
  • FIG. 7 illustrates a publish-subscribe model 168 for use by the facility gateway 21 of FIG. 1, by the applications 41, 42, 43, 44 and device gateway 40 in FIG. 2 or FIG. 4 in accordance with an embodiment of the present disclosure.
  • the model uses a pub/sub engine 169 that allows publishers 171 to register one or more topics 170 with the pub-sub engine 169. Once the topic 170 is registered, one or more subscribers 172 can subscribe to the topic 170. The subscribers 172 may subscribe using a guaranteed subscription to the topic 170, in some specific embodiments. When a publisher of the publishers 171 posts an event related to the topic 170, all subscribers of the subscribers 172 that have subscribed to the topic 170 receive the data from the pub/sub engine 169.
  • a publisher (of the publishers 171) may register one or more topics 170.
  • Each topic of the topics 170 may be a unique topic.
  • One or more subscribers 172 may subscribe to one or more topics of the topics 170 to receive events therefrom.
  • a publisher 171 posts an event to a unique topic (e.g., a "first topic") of the topics 170, all subscribers to the first topic of the topics 170 will receive that event; nonsubscribers to the first topic of the topics 170 will not receive that event.
  • the topics 170 may provide a level of indirection enabling the publishers
  • the pub/sub engine 169 may allow the communication to be one-way and asynchronous (e.g., a "fire and forget" communication).
  • the pub/sub engine 169 may provide durable message delivery, on both sides.
  • Durable topics of the topics 170 may ensure that messages will not be lost if the pub-sub engine 169 fails.
  • Durable subscriptions used by the subscribers 172 may ensure that a subscriber 172 will not miss messages when it is not running.
  • the pub/sub engine 169 may be part of the device gateway 22, may be part of any other software within the facility gateway 21, or may be a stand-alone application of FIG. 1.
  • the pub/sub engine 169 may be part of the device gateway 40, within an application 41-44, or may be a stand-alone application of FIG. 2.
  • the pub/sub engine 169 may be part of the device gateway 99 of FIG. 4, may be part of the applications 94, 96, 97, or may be a stand-alone application of FIG. 4.
  • FIG. 8 illustrates a capability-registry model 173 in accordance with an embodiment of the present disclosure.
  • a provider 176 registers its capability 175 with a capability registry 174.
  • the capability 175 may include two aspects, including an interface and an attribute.
  • the interface is the list of request/response pairs and notifications (in both directions).
  • the attributes is the service level agreement parameters specifying limits on the quality of delivery (e.g. response times, error rates and recovery policies, costs, etc.).
  • An initiator 177 can communicate with the capability registry 174 to find and bind to the capability 175. Thereafter, the initiators 177 can request information from the providers 176 and receive a response.
  • the capability registry 174 may be part of the device gateway 22, may be part of any other software within the facility gateway 21, or may be a stand-alone application of FIG. 1.
  • the capability registry 174 may be part of the device gateway 40, within an application 41-44, or may be a stand-alone application of FIG. 2.
  • the capability registry 174 may be part of the device gateway 99 of FIG. 4, may be part of the applications 94, 96, 97, or may be a stand-alone application of FIG. 4.
  • the capability registry 174 may supplement or replace the pub/sub engine 169 in some specific embodiments.
  • FIG. 9 shows a drug safety method 115 used to generate a DAL file in accordance with an embodiment of the present disclosure.
  • the method 115 may be used with the system 1 of FIG. 1, the system 27 of FIG. 2, the system 81 of FIG. 4, or any other electronic patient care system.
  • the method 115 is but one of many methods which may be used to generate a DAL file. Some embodiments may differ.
  • Participants from a pharmacy, clinical care area, etc. may be selected to help generate and define a DAL File 35 (see FIG. 2) that contains safety rules for drug administration that may consider the type of medication, clinical care group, clinical care area, mode (e.g. amount-based, rate-based or weight-based, dose strategy (loading, bolus, ramp), etc.), concentration, etc.
  • Method 115 includes acts 116 and 117. Act 116 includes acts 118-125 as subacts and act 117 includes acts 126-127 as subacts. Act 116 generates a DAL file and act 117 monitors the use of the DAL file to help inform updates of the DAL file 35 (see FIG. 2).
  • Act 122 sets up a DAL file, e.g., an initial DAL file without field entries or a template DAL file.
  • Act 123 receives modifications to the DAL file in accordance with an entry from one of the selected users (e.g. via the DERS editor 112 of FIG. 4).
  • Act 121 reviews the DAL file, e.g., by running a medical device simulator via the DERS editor 112 of FIG. 4. After review during act 121, a pilot DAL file may be (electronically) released in act 120.
  • Act 118 approves the pilot DAL file. However, after the pilot has completed, adjustments may be made to the DAL. Act 118 may be performed via clicking on a "approve" button on a web browser to approve the use of a referenced file (e.g., referenced by version number, creation date, etc.).
  • a referenced file e.g., referenced by version number, creation date, etc.
  • act 119 the DAL file is released and is sent to the medical device.
  • the CQI server imports reference data (i.e. medications, care areas, dose modes, etc.) from the DAL file.
  • a file containing the drug records is released to both the hospital and to the CQI environment.
  • a biomed technician may install the DAL file on each device after release in act 119.
  • Act 126 is the medical device sending CQI events to the CQI receiver 108.
  • the CQI events sent in act 126 may be generated in therapies performed by a device using the DAL file in act 127
  • CQI events i.e., CQI messages.
  • the CQI messages may include information about when a normal infusion occurs, when an infusion bypasses the DERS checks, when a soft limit is exceeded and overridden, and/or when a soft or hard limit is exceeded and the therapy is reprogrammed, among others.
  • the CQI events are transmitted to a CQI Server in act 126, which collects and stores them. Safety officers can run reports which summarize these events and provide drill-down capabilities to identify opportunities for procedural improvement in act 124. Similarly, pharmacists and clinicians can query the CQI database to identify opportunities to improve drug records in the next release of the DAL file in act 124. That is, in act 124, the CQI messages are analyzed or reviewed. Modifications to the DAL file may be made in act 123 to create a new version of the DAL file. The new DAL file may then be reviewed, piloted, and released as described above. [00365] In some embodiments, usage of a DERS editor, such as the DERS editor 112 in FIG.
  • DAL file is a collaborative process involving a number of individuals or parties. Every person or party involved in the creation of a DAL file may contribute to the creation of the DAL file by accessing the DERS editor and interacting with a DERS editor user interface. In some embodiments, no client-side software may be required to access the DERS editor except a sufficient web browser. In some embodiments, the DERS editor user interface may be accessed via an app on a tablet computer or the like. The individuals or parties involved in the creation of the DAL file may use an internet capable computer, tablet computer, smartphone, etc. to access the DERS editor and make contributions to the DAL file.
  • Each individual or party involved in building a DAL file may have specific assigned roles, responsibilities, and/or privileges. These roles may be assigned using an Access Control List (ACL) and/or Role Based Access Control (RBAC) model. The roles and responsibilities may be fulfilled as part of a method which may be used to generate a DAL file.
  • the roles, responsibilities, privileges, etc. may be assigned to structure the collaborative process. They may also be assigned to encourage maximum input and oversight for DAL file generation. This may help to assure that the DAL file created by the collaborative process is well designed and mitigates drug errors to the greatest possible extent.
  • Various roles and privileges for users may be stored in a user database (not shown) which is hosted in a hosted environment. In some embodiments, various roles and privileges may instead be stored in a DERS database.
  • a DERS editor may also allow users to provide unsolicited contributions, feedback, requests, comments, notes, questions, etc. which may be used to build a DAL file or better a DAL file. If during a DAL file pilot, simulation, or during everyday usage, a user finds an issue, concern, opportunity for improvement, etc. a user may submit a change request to address it. Such a request may be tied to CQI data or a specific CQI report to provide context to a reviewer.
  • CQI data may be readily accessible, perhaps to differing degrees depending on user or party, while contributing to a DAL file. This information may be presented on the DERS editor user interface in an easily comprehensible form. In some embodiments, at least some of this data may be presented in the form of a graph, chart, or other visual aid. Users may also use the DERS editor to filter out undesired CQI data so as to present a more concise data set which focuses more narrowly on data of interest to the user. The availability of this CQI data may be utilized by an individual or party to help inform decisions about modifications, etc. to various entries. The data may also be used to evaluate the appropriateness of various entries in a DAL file.
  • DAL files via the DERS editor may be an entirely traceable process.
  • Each entry or modification made in the DERS editor may be tied to a unique user login or ID which is associated with a specific individual or party.
  • Each modifiable item within a DERS editor may be associated with a stored historical record documenting all past comments, notes, modifications, requests, parameter values, etc. related to the item.
  • FIG. 10 An example conceptual diagram showing possible roles, responsibilities, and privileges of various users and parties involved in collaboratively creating a DAL file is shown in FIG. 10.
  • the example conceptual diagram is one of many possible examples and in alternate embodiments, may be arranged differently. For example, some actors/parties may be combined or not included. Roles and responsibilities may also differ. As shown, the roles, responsibilities and privileges are allocated to promote creation of a well thought out DAL file which minimizes the possibility for potential drug errors. Multiple reviews of entries and a consensus of a number of individuals is required for a DAL file to be released in the example embodiment.
  • Each actor may make contributions to a DAL file with a DERS editor such as the DERS editor 112 shown in FIG.4.
  • various actors may access the DERS editor via a DERS editor user interface which may be navigated to on a web browser.
  • a number of actors are shown to the left of the diagram.
  • Other embodiments may include additional actors or fewer actors than shown here.
  • Some actors may be a single individual in some embodiments and at least one group of multiple individuals in others. In some embodiments, two different actors may, in fact, be the same individual or party performing different roles.
  • the actors shown in the example in FIG. 10 include a drug library administrator 200, resource clinicians 202, a review pharmacist 204, a pharmacy consultant 206, and a clinical consultant 208. In the example embodiment, the actors fall into two broad categories; administrator or editing users (drug library administrator 200) and reviewing users (resource clinician 202, review pharmacist 204, pharmacy consultant 206, and clinical consultant 208).
  • the drug library administrator 200 may be an individual or individuals such as doctors, care givers, pharmacists, etc. In some embodiments, the drug library administrator 200 may for example be the pharmacist 8 shown in FIG. 1 or the safety staff 107 shown in FIG. 4.
  • the drug library administrator 200 may be given administrator capabilities in the DERS editor. That is, the drug library administrator 200 may have editing permissions granting them the ability to alter most, if not all, modifiable entries and have final oversight over any proposed changes to a DAL file.
  • the drug library administrator 200 may have privileges which allow them access to most if not all functionalities of the DERS editor.
  • the drug library administrator 200 may also be required to sign off on a finalized DAL file before it is released for use on various medical devices.
  • the resource clinicians 202 may in some embodiments be an individual or individuals such as doctors, nurses, nurse managers, etc. In some embodiments the resource clinicians 202 may be the nurse manager 7 and/or nurses 9 of FIG. 1. In some embodiments, the resource clinicians 202 may be the pharmacy and clinicians of FIG. 4. The resource clinicians 202 may have the ability to review, comment, add notes, propose changes, etc. to a DAL file via the DERS editor. Resource clinicians 202 may be divided into a number of sub groupings. For example, resource clinicians 202 may be divided into care area groups in some embodiments.
  • the review pharmacist 204 may in some embodiments be an individual or individuals such as a pharmacist, etc. In some embodiments, the review pharmacist 204 may be the pharmacist 8 in FIG. 1. The review pharmacist 204 may review all entries in a DAL file via the DERS editor and check for any entries which may need to be revised. The review pharmacist 204 may also have the ability to comment, add notes, request changes, etc. to various entries in a DAL file.
  • the pharmacy consultant 206 may in some embodiments be an individual or individuals such as a pharmacist, etc. In some embodiments the pharmacy consultant 206 may be the pharmacist 8 in FIG. 1. A pharmacy consultant 206 may review one or more portion(s) of all of the entries in a DAL file via the DERS editor. The pharmacy consultant 206 may check for any entries which may need to be revised and may also have the ability to comment, add notes, request changes, etc. to various entries in a DAL file.
  • the clinical consultant 208 may in some embodiments be an individual or individuals such as doctors, nurses, nurse managers, risk officers, other suitable personnel, etc. In some embodiments, the clinical consultant 208 may be the nurse manager 7, nurses 9, biomed 19, and/or risk officer 6 of FIG. 1. The clinical consultant 208 may in some embodiments be the safety staff 107 of FIG. 4. The clinical consultant 208 may be involved in performing a pilot of a DAL file. The clinical consultant 208 may have the ability to review, comment, add notes, etc. to entries in a DAL file or a portion of entries in a DAL file.
  • the DERS is first setup in the DERS SETUP act 122.
  • various actors may be identified and assigned user IDs which allow the various actors differing degrees of DERS functionality.
  • the environment in which a DAL file is to be used in may be divided up into a number of different sub- environments or groupings. This may be done according to the environments organizational hierarchy. For example, a hospital may be divided into its constituent care groups (ICU, ER, NICU, Oncology, etc.).
  • the roles, responsibilities, and privileges assigned to each actor may differ. For example, in some embodiments, a larger number of actors may be required to sign off on a DAL file before it is released for use in various medical devices. Various actors may be allocated a greater or less degree of software functionality.
  • the DERS medication list or lists may then be setup in the medication list customization step 210.
  • the drug library administrator 200 may be the only actor with the privileges required to do this. In some embodiments, this step may be performed by a pharmacist for example.
  • all of the medications which are available for use within a facility or number of facilities that will use a DAL may be compiled into a single list. Additionally, if a medication has a number of different names or aliases, these may be defined and linked to their respective medications. Other information may also be defined for each medication.
  • the full list of medications created in the medication list customization step 210 may be used in subsequent steps to ensure uniformity and increase efficiency.
  • the full medication list may be created by selecting medications from a master list or medications provided by a DERS editor service. In some embodiment, the full medication list may be created by selecting various medications from a master list of medications stored on a formulary database in a hosted environment.
  • the Drug Library Administrator 200 may perform the Drug Selection and Record Specification sub- step 214.
  • various medications identified in step 210 may be selected for inclusion in specific sub-divisions or care areas/groups of an institution.
  • a sub-set of the drugs defined in step 210 may be selected as drugs which are used in intensive care units of the hospital.
  • the various medications which are selected for each care group may then have their records modified to suit the needs of each care area within the care group.
  • a drug for a specific care area may have various clinical uses, concentrations, limits, etc. specified.
  • this step may be carried out by one or more pharmacist(s) in addition or in conjunction with the Drug Library Administrator 200.
  • the Per Care Area Verification sub- step 216 may be performed by at least one resource clinician 202.
  • the selected drugs and their records are reviewed and verified for each care area.
  • one or more nurses or doctors who are assigned or work in a particular care area may be the resource clinicians 202 who perform this sub-step for that care area.
  • the resource clinicians 202 may provide feedback on the various drug selections and records for each care area.
  • Drug Records step 212 are reviewed to ensure that they are appropriate and correct.
  • the Drug Library Administrator 200 edits and revises records which may need such action in the Editing and Revising sub-step 220. This may include addressing any feedback or requests produced by the resource clinicians 202 in the Care Area Drug Records step 212. It may also include addressing any feedback, concerns, requests, etc. from other actors involved in the Review step 218.
  • a Per Care Area Review 222 sub-step may be performed by at least one resource clinician 202.
  • the selected drugs and their records are reviewed for each care area.
  • one or more nurses or doctors who are assigned or work in a particular care area may be the resource clinicians 202 who perform this sub-step for that care area.
  • the resource clinicians 202 may provide feedback or change requests on the various drug selections and records for each care area.
  • a Cross Care Area Review sub-step 224 and Care Group Review 226 sub-step may be respectively performed by the review pharmacist 204 and the pharmacy consultant 206.
  • the selected drugs and their records for each care area may be reviewed by the review pharmacist 204 and feedback denoting any concerns, suggestions, requests, etc. may be produced.
  • a pharmacy consultant 206 may review a care group's drug list, drug records, and feedback denoting any concerns, suggestions, requests, etc.
  • the pharmacy consultants 206 may additionally review other records as well.
  • the pharmacy consultants 206 may also review the records for all drugs within an institution which are considered to be high risk if delivered in erroneous fashion.
  • pilot step 2208 all of the actors shown in FIG. 10 (and perhaps other actors not shown in FIG. 10) participate in a pilot of the new DAL file which has been produced through steps 210, 212, and 218.
  • various actors may use a pump simulator on a DERS UI to test or review all of the entries for each care area.
  • a provisional DAL file may be created and sent to a test medical device. The DAL file may be tested and reviewed on the UI of the test medical device by various actors. Any feedback produced by various actors involved in the Pilot step 228 may be addressed and any necessary changes may be made to the DAL file.
  • the DAL file may be required to go through the
  • Approval step 230 various actors may sign off on the DAL file and thus allow it to be released to medical devices in an institution.
  • the Drug Library Administrator 200 and the Resource Clinicians 202 are required to sign off on the DAL file.
  • a larger number or a smaller number of actors may be required to sign off on the DAL file before it is released.
  • the DAL file may be released for use in the institution.
  • a DAL file may be arranged in a hierarchical fashion. That is, a DAL file may include a number of superior and subordinate entries or parent and child entries which specify settings for a DAL file. These entries may be arranged in various strata. As one progresses farther down a hierarchy, entries for the DAL file may become more specific. Parent entries, for example, may broadly define parameters, limits, etc. and child entries may further narrow or refine these parameters, limits, etc.
  • FIG. 11a depicts an example hierarchical arrangement of a DAL file. As shown, the example hierarchical arrangement shown in FIG. 11a is similar to an institution/organization's hierarchy. In some embodiments, the hierarchical arrangement of a DAL file may differ. For example, some DAL files may not include the care group and/or organization strata shown in FIG. 11a. This may be particularly true of DAL files used in a small, stand alone institution.
  • the hierarch of the example hierarchy for a DAL file may be the organization 2350 in which a DAL file is to be used.
  • the organization 2350 may be the constituent institutions 2352 which make up the organization 2350.
  • an institution 2352 may be the hierarch of the DAL file hierarchy. This may, for example, be true in scenarios where a DAL file is being created for an institution 2352 which is not part of an organization 2350.
  • Each institution 2352 may be divided into a number of care groups 2354.
  • the care groups 2354 may each include a number of care areas 2356.
  • a care group 2354 may be an organizational category into which a number of care areas 2356 may belong.
  • a number of ICU type care areas 2356 e.g. neonatal, pediatric, adult, medical, surgical, cardiac, neuro, trauma, burn, etc. ICU's
  • ICU's may be grouped into an ICU care group 2354.
  • Each care area 2356 may include a number of specific drug or medication records 2358 which are associated with that care area 2356.
  • a number of parameters may be defined. The defining of these parameters may be the process through which a DAL file is created. These parameters may include but are not limited to various operational settings, data formatting settings, acceptable input ranges or values for data on a medical device, guardrails or limits for therapies or medical devices, etc. A number of possible example settings which may be defined in a DAL file are described throughout the specification. Other settings may also be included in some embodiments. In some instances, values defined at higher levels of the hierarchy may act as parent values for other values defined at lower levels of the hierarchy.
  • the same parameters may be defined at multiple levels of the hierarchy.
  • the child parameter value (value defined at the subordinate hierarchical level) may default to the value defined for the parent parameter (value defined at the superior hierarchical level) when a user is specifying parameter values for subordinate levels of the hierarchy.
  • a user may alter these child values.
  • a user may only be able to alter the value to a more restrictive value.
  • a user may define a patient weight high hard limit at the care group level. This value may act as the default setting for the same parameter in any care areas which are included in the care group. If the care group included a care area for pediatric patients, a user may desire to make the patient weight high hard limit more restrictive and may be allowed to do so.
  • Such inheritance of parameter values may help to facilitate DAL file creation and improvement, as well as increase ease of use and efficiency.
  • a care group 2354 may have a number of drugs which are associated with it. Drug records 2358 for these drugs defined at the care areas 2356 level within that care group 2354 may specify the specific drug's clinical uses and concentrations that are appropriate for the specific care areas 2356. As an example, in a care group 2354 consisting of five care areas 2356 which use similar drugs, a user may only need to add the common drugs at the care group 2354 level instead of once for each care area 2356 in the care group 2354. Adding the drugs to the care group 2354 may cause the drug to consequentially be added to the care areas 2356 in the care group. Additionally, in some embodiments, a user may define some or all parameters for each common drug at the care group 2354 level. These parameters may then be inherited as the defaults for their respective child parameters in each care area 2356 in the care group 2356. Such an arrangement may facilitate DAL file creation and improvement, as well as increase ease of use and efficiency.
  • some levels of the example DAL file hierarchy may be divided into a number of sub levels.
  • drug records 2358 may be divided into general drug settings, clinical use settings, and settings for specific concentrations of the drug. These sub levels may furthermore have their own hierarchical arrangement.
  • FIG. 1 lb depicts another example embodiment of a DAL file hierarchy 4500.
  • the DAL file hierarchy 4500 shown in FIG. 1 lb includes a number of additional hierarchical strata than that shown in FIG. 11a. Other embodiments may include different or a different number of strata.
  • a user may be able to define various parameter values to create the DAL file at each level shown.
  • the same or related parameter values may be defined at multiple levels of the hierarchy.
  • a value defined at a higher level of a DAL file hierarchy 4500 may operate as a parent value for the same or related value at lower levels of a DAL file hierarchy 4500.
  • the hierarch of the DAL file hierarchy 4500 is an IDN or organization 2350.
  • the next level down is the region 4502.
  • This level may be included in instances where an IDN includes a number of institutions which are spread out of a large geographic area. In other embodiments, this level of the hierarchy may be used to create groups of similar institutions (e.g. urgent care centers, clinics, etc.)
  • the next level of the DAL file hierarchy 4500 is shared.
  • a user may define various settings at an institution level 2352.
  • a user may also define general settings 4504.
  • a user may also define medications and medication categories 4506 at this level. In some embodiments this may be done at a higher level of a DAL file hierarchy 4500. These may be defined by creating a master medications list for an institution and then dividing it into a number of categories.
  • a user may also define parameters for medications and categories 4506. Any values defined at this shared level of a DAL file hierarchy 4500 may act as parent settings for the care group 2354 level of a DAL file hierarchy 4500.
  • a user may define various parameters for the care group 2354 level of a
  • a user may define one or more medication records 2358 and parameters for those medication records 2358 for each care group 2354.
  • Various parameters defined for a care group 2354 may function as parent settings for any medication records 2358 defined for the care group 2354.
  • Care group 2354 parameter settings may also act as parent settings for entries in care areas 2356 within a care group 2354. Additionally, any medication records 2358 and parameters associated with them defined for a care group 2354 may be included automatically in care areas 2356 within a care group 2354.
  • a user may define various parameters at the care area 2356 level of a DAL file hierarchy 4500.
  • a user may define one or more medication records 2358 and parameters for those medication records 2358 for each care area 2356.
  • Various parameters defined for a care area 2356 may function as parent settings for any medication records 2358 defined for the care area 2356.
  • medication records 2358 are divided into a number of sub levels.
  • Medication records 2358 in the example embodiment in FIG. l ib include a medication 4508 sub level which is at the top of their internal hierarchy.
  • a user may choose the name of a medication from a master medication list to populate this sub level of the hierarchy. This may apply any parent values defined for that medication in the master medication list or medication categories list.
  • a user may be able to define additional other parameters at the medication 4508 sub level. Any values defined for the medication 4508 sub level may act as parent values for the clinical use 4510 sub level.
  • a user may define various parameters at a clinical use 4510 sub level. These values may act as parent values for the concentration 4512 sub level.
  • a user may also be able to define various parameters at the concentration 4512 sub level.
  • Figs. 12-71 depict a number of example flowcharts which detail a number of aspects of DERS editor usage. These flowcharts and the steps shown within these flowcharts are only exemplary. In other embodiments, usage of the DERS editor may differ from that shown and described in Figs. 12-71. Some steps, for example, may not be performed or may not be performed in the same order as shown and described herein. Some embodiments may include different or additional steps. It should also be recognized that some of the flowcharts depicted detail only one example of many possible ways of accomplishing the same result. Many embodiments may include multiple alternative workflows which may be followed to realize the same end result. For the sake of brevity, not all alternative workflows considered within the scope of this disclosure are shown. The flowcharts shown and described in Figs. 12-71 may be related to the various screens shown and described in Figs. 72-181.
  • FIG. 12 depicts a flowchart detailing a number of exemplary steps which may be a part of the DERS SETUP 122 (see, for example, FIG. 9) phase of the creation of a DAL file.
  • the steps detailed in the flowchart in FIG. 12 may be performed prior to any use of a DERS editor at a medical institution.
  • a user may log into a DERS hosting environment in step 240.
  • the user may be a part of the hosting IT for the hosted environment 83 in FIG. 4.
  • the user may be a DERS editor service administrator.
  • the user may login to the DERS database within the DERS hosted environment.
  • the DERS database may, in some embodiments, be the DERS database 113 depicted in FIG. 4.
  • a user may run a database loading script on the DERS database.
  • This loading script may load DERS reference tables onto the DERS database.
  • the loading script may load DERS reference tables which will be used for all institution and organizations which use the DERS editor service.
  • the reference tables may load drugs, drug aliases, substitute drugs, drug incompatibilities, care area types, roles, units of measure, comment types, approval/verification states, various attributes, etc. onto the database.
  • the correctness of the database loading script may be confirmed by the user.
  • a user may load a test institution DERS instance. This instance may be used by the user to test the correctness of the reference tables which were loaded onto the DERS database in step 249.
  • FIG. 13 depicts a flowchart detailing a number of example steps which may be used to update reference tables loaded on to a DERS database.
  • the reference tables may be those described in relation to FIG. 12.
  • a user logs into a DERS hosting environment.
  • the user may be a part of the hosting IT for the hosted environment 83 in FIG. 4.
  • the user may be a DERS editor service administrator.
  • the user may login to the DERS database within the DERS hosted environment.
  • the DERS database may, in some embodiments, be the DERS database 113 depicted in FIG. 4.
  • a user may run a database update script on the DERS database.
  • This update script may update DERS reference tables on the DERS database.
  • This update script may update the DERS reference tables used by all institutions or organizations which use the DERS editor service.
  • the correctness of the database update script may be confirmed by the user.
  • a user may load a test institution DERS instance. This instance may be used by the user to test the correctness of the reference tables which were updated on the DERS database in step 259.
  • the steps detailed in the flowchart in FIG. 13 may be performed by a user with direct or remote access to the DERS hosted environment.
  • FIG. 14 depicts a flowchart showing a number of example steps which may be used to establish institution and organizational hierarchies in a DERS database.
  • the various steps shown in the flowchart in FIG. 14 may be performed as part of the DERS SETUP 122 (see, for example, FIG. 9) phase of the creation of a DAL file.
  • step 260 the organizational structure of the institution or organization is determined. In the simplest cases, there may be only a single institution which uses its own DAL and has no parent organization. In other cases, an organization may include a number of different institutions all of which use the same DAL. In some cases, an organization may include a number of different institutions with at least 2 different DAL files. In cases where a DERS database is being used by an organization, a field for the institution name may be included. This name may be used for intra-organizational data comparison and may be included in CQI messages from institutions within the organization.
  • step 262 the loading/update script for the organizational schema may be created.
  • a user logs into a DERS hosting environment.
  • the user may be a part of the hosting IT for the hosted environment 83 in FIG. 4.
  • the user may be a DERS editor service administrator.
  • the user may login to the DERS database within the DERS hosted environment.
  • the DERS database may, in some embodiments, be the DERS database 113 depicted in FIG. 4.
  • step 268 a user may run a database update script on the DERS database. This update script may create a new database or databases for the specified organizational schema.
  • the correctness of the database update script may be confirmed by the user.
  • a user may load a test institution DERS instance. This instance may be used by the user to test the correctness of the organizational schema which was updated onto the DERS database.
  • the steps detailed in the flowchart in FIG. 14 may be performed by a user with direct or remote access to the DERS hosted environment.
  • FIG. 15 shows a flowchart showing a number of exemplary steps which may be used when giving a subscribing institution access to a DERS editor.
  • an institution or organization may sign a contract for enrollment in the DERS service with a DERS editor service provider.
  • the DERS editor service may be configured to support the new institution or organization in step 282. In some embodiments, this may involve setting up a database and application server for the new institution or organization. In some other embodiments, a new dataset may be created within an existing database for the new institution or organization. This step may be performed by hosting IT for a hosted environment in which the DERS editor service databases, servers, etc. reside. In some embodiments, step 282 may involve performing the steps detailed and depicted in FIG. 14.
  • DERS editor service personnel may set up a user account for a user at the institution or organization.
  • this user may be a drug library administrator such as the drug library administrator 200 shown in FIG. 10.
  • the access information for the user account may also be provided to the user at the institution or organization in this step.
  • the user at the institution or organization may log in to the DERS editor.
  • the user at the institution may also be required to change their password in step 286.
  • the user at the institution may then be provided training by DERS editor service personnel in step 288.
  • the user at the institution may then have access to the DERS editor.
  • FIG. 16a A flowchart detailing a number of example steps which may be used to setup various aspect of a DERS within an organization or institution is shown in FIG. 16a.
  • the example steps shown in the flowchart in FIG. 16a may be used to define users, the groups they belong to, and their various permissions and privileges.
  • the steps shown in FIG. 16a may be part of a DERS SETUP 122 phase (see, for example, FIG. 9).
  • a user may log into the DERS editor.
  • the user may, in some embodiments, be the drug library administrator 200 of FIG. 10. This may be done by accessing a DERS editor user interface. As mentioned above, this may be accessed via a suitable web browser with no client-side software needed.
  • the user may then navigate to a user editor on a DERS editor user interface in step 302.
  • the user may then perform any of steps 304, 306, 308, and 310.
  • Step 304 changes the values of the group permissions for Group A.
  • Step 306 changes the values of the group permissions for Group B.
  • Step 308 changes the values of the group permissions for Group C.
  • Step 310 changes the values of the group permissions for Group D.
  • Groups A-D may be various categories of possible institution employees. For example, one of Group A-D may be a pharmacist group, another may be a biomed group, another may be a nurse manager group, and the last may be a safety staff group. In various embodiments, there may be additional groups for other categories of institution or organization employees.
  • the groups may be user defined in some embodiments.
  • the groups may be predefined and may have a set of default values of group permissions which are provided by the DERS editor service.
  • Some embodiments may not include groups, but rather allocate permission based on specific user. Additionally, some groups may include sub-groups (not shown). The permissions which are available for allocation may allow a user to customize groups or subgroups to best fit the needs and/or current structuring of their institution/organization.
  • a user may also choose to create a new user in step 312. This may involve defining a user name and a temporary password for the new user. It may also involve providing the email address of the new user. A user may then proceed to any of steps 314, 316, 318, and 320. A user may also choose to proceed to any of steps 314, 316, 318, and 320 from step 313 in which the user selects an existing user.
  • a user may assign a newly created user, or existing user to Group A.
  • 316 a user may assign a newly created user or existing user to Group B.
  • a user may assign a newly created user or existing user to Group C.
  • a user may assign a newly created user or existing user to Group D.
  • a user may assign a newly created user or existing user to more than one group.
  • additional steps may be included where a user may assign a newly created user or existing user to further groups or sub-groups.
  • the DERS editor service may save the changes to a database.
  • the database may be the DERS database 113 of FIG. 4.
  • the database may, for example, be a user database in a hosted environment.
  • the DERS editor service may notify the appropriate users that changes have been made. For example, if a new user account is created the new user may be notified. As shown in 322b, in some embodiments, this may involve an automatically generated email message which is sent to the new user. This message may provide the new user with a hyperlink to the DERS editor in embodiments where the DERS editor may be accessed via a suitable web browser. This message may include account information and instructions detailing how the new user should make use of the DERS editor. It may also include password and access information to the newly created user. Alternatively, this information may be manually provided to the new user.
  • FIG. 16b depicts a flowchart detailing a number of example steps which may be used to define users, the groups they belong to, and their various permissions and privileges.
  • the example flowchart shown in FIG. 16b depicts a number of steps which may be used with a web browser based DERS editor service.
  • a user may log into the DERS editor and indicate that they would like to use a user editor.
  • a web tier for the DERS editor may then render the user editor page in step 4402.
  • a user may then have the choice of adding a new user or updating/deleting an existing user.
  • a user may indicate, in step 4404, that they would like to add a new user.
  • a web tier for the DERS editor may then render an add user page in step 4406.
  • the user may then add various user metadata for the new user in step 4408.
  • a web tier may create the user credentials for the new user in step 4410.
  • the new user data may be inserted into a database.
  • the database may, for example, be the DERS editor database 113 of FIG. 4 or a user database in a hosted environment.
  • a web tier may retrieve the user privileges and information in step 4416.
  • a query record set for the requested user may be built and sent to the web tier in step 4418.
  • the web tier may then render a user editor interface for the selected user in step 4420.
  • a user may make desired edits to the user and submit any changes. Such edits may include, but are not limited to, modifying group assignments, modifying privileges, deletion of the user, assigning user responsibilities, etc.
  • a web tier may update the user account data in step 4424.
  • the data for the edited user may be written or committed to a database.
  • a success notification may be sent to the web tier to indicate a successful update of the database.
  • a web tier may display a success dialog box in step 4428 to indicate that the user account information has been updated.
  • FIG. 17 shows a flowchart detailing a number of example steps which may be used to update various aspects of a DERS within an organization or institution. Specifically, the example steps shown in the flowchart in FIG. 17 may be used to update users, the groups they belong to, and their various permissions and privileges.
  • a user may login to the DERS editor.
  • the user may, in some embodiments, be the drug library administrator 200 of FIG. 10. This may be done by accessing a DERS editor user interface. As mentioned above, this may be accessed via a suitable web browser with no client-side software needed. The user may then navigate to a user editor on a DERS editor user interface in step 332.
  • step 334 a user may modify the various permissions for a group which may, for example, be one of Groups A-D shown in FIG. 16a.
  • step 336 the user may add a user to a group which has been previously created. This may be done, for example, to add a newly hired employee to a group.
  • step 338 the user may individually modify the permissions of users with access to the DERS editor. In some embodiments, this step may not be included. In some embodiments, this step may be included while steps 334 and 336 are not included.
  • the former case may be well suited to institutions which are relatively large and/or complex.
  • the latter case may be well suited to small institutions or medical settings where the DERS editor may only have a small number of total users.
  • the DERS editor service may save any changes to a database in step 339.
  • This database may be the database 113 of FIG. 4 or a user database in some embodiments.
  • the DERS editor service may notify affected users of any updates in step 340. This may be accomplished by an automatically generated email which is sent to affected users.
  • FIG. 18 depicts a flowchart detailing a number of example steps which may be used to create or update an institution/organization master medication list.
  • the steps shown in the flowchart in FIG. 18 may be a part of the medication list customization 210 described in relation to FIG. 10.
  • the user navigates to the medication list for the institution or organization on the DERS editor user interface.
  • the DERS editor service may then display the medication list editor in step 352.
  • the user may be a drug library administrator such as the drug library administrator 200 in FIG. 10.
  • the user may be a pharmacist, or any user granted permission 0.04 of Table 3.
  • the user may either import a medication list from the DERS editor service or may select a medication or medications from a master list provided by the DERS editor service.
  • step 356 If a user elects to import a list from the DERS editor service, the user may be prompted by the DERS editor service to select a medication list to import in step 356. This step may involve displaying a list of importable lists stored by the DERS editor service or on a database associated with the DERS editor service. The user may then import the desired list in step 358. The DERS editor service may then update the medication list for the institution/organization so that it includes the imported entries in step 359. If a user desires to add more medications to the institution/organization medication list, the user may import another medication list or may select a medication from a master medication list accessed via the DERS editor service. If a user is finished updating or creating the institution/organization medication list, the user may proceed to step 366. Step 366 will be described later in the specification.
  • step 360 the DERS editor service may prompt the user to select a medication to add to the medication list as illustrated by step 361. These medications may be selected by a user from a master medication list provided by the DERS editor service in some embodiments.
  • the DERS editor service may then prompt users to enter an alias or other name for the medication in step 362.
  • the user may provide the alias in step 363.
  • the DERS editor service may solicit the user to provide additional information for added medications in step 364.
  • the user may provide any additional information in step 365.
  • a user wants to add other medications to the institution/organization medication list after completing step 365, the user may decide whether they would like to import a medication list or select a medication from a master list and proceed as described above.
  • the user may proceed to step 366.
  • the user may indicate they are finished adding medication in step 366.
  • the DERS editor service may then prompt the user to save the created or updated medication list for the institution or organization in step 367.
  • the user may then save the created or updated medication list in step 368. This may cause the medication list to be saved on a database such as the DERS database.
  • the DERS editor service may then notify appropriate users at the institution or organization that its medication list has been created or updated in step 369. For instance, the DERS editor service may notify all users responsible for creating or maintaining care area medication lists that the institution/organization medication list has been created or updated.
  • a clinical advisory may provide information about a medication to a user of a medical device. This information may include administration guidelines, information from a pharmacy formulary, contraindications, etc.
  • a clinical advisory may include text, an image or graphic, and/or and electronic file such as a .pdf or the like.
  • a clinical advisory may be a free text entry in which a user may enter anything they desire.
  • Some embodiments may include a number of types of clinical advisories. For example, some embodiments may include a short text clinical advisory and a full clinical advisory. The short text clinical advisory may be limited to a predefined number of characters (e.g. 40) to allow it to be easily displayed on a graphic user interface of a medical device.
  • a user navigates to the clinical advisory list.
  • the user may then decide to either import a clinical advisories list from the DERS editor service or may add his or her own clinical advisories to the clinical advisories list. If the user decides to import a list of clinical advisories from the DERS editor service, the user may import the list in step 372. If the user decides to add their own clinical advisories to the list, the user may proceed to step 374 and add these clinical advisories. The user may repeat step 374 as many times as desired until the user is finished adding clinical advisories to the clinical advisories list.
  • the user may log out and save changes to the clinical advisory list for the institution or organization. Changes may be saved on the DERS database.
  • the DERS editor service may notify all pertinent users that the clinical advisories list has been updated. Step 378, in some embodiments, may include automatically sending an email to relevant users informing them of the changes.
  • additional steps may be included in which a user may upload files (e.g. images, documents, etc.) to a clinical advisory.
  • clinical advisories may not be added, modified, etc. at the clinical use level. Instead, these advisories may be added to medication records when such records are being defined by a user.
  • a user may define clinical uses for a drug as well as the various clinical uses and concentrations of the drug.
  • FIG. 20 shows a flowchart detailing a number of example steps which may be used to modify the general settings for an institution or organization. The steps may be performed as part of a DERS SETUP 122 (see, for example, FIG. 9) phase.
  • a user navigates to the general settings list on a DERS editor user interface. As mentioned above, this may be accessed via a suitable web browser with no client-side software needed.
  • the DERS editor service may prompt the user to enter values for various general settings in step 381. The user may then modify, enter, update, etc. any of the desired values in the general settings in step 382.
  • the user may log out and save any changes made to the general settings.
  • FIG. 21 shows a flowchart detailing a number of example steps which may be used to add a care group to an institution or organization.
  • an organization or institution may be broken into a number of sub-areas or groups which may, for example, reflect departments within the organization or institution.
  • the steps shown in FIG. 21 may be part of a DERS SETUP 122 (see, for example, FIG. 9) phase.
  • step 2370 a user navigates to a care group list on the DERS editor user interface. The user chooses to add a new care group to the list in step 2372.
  • a user may have a number of options.
  • a user may start from a blank template or nearly blank template.
  • a user may also choose to copy the information for an existing care group to expedite the process. If a user elects to copy a pre-existing care group, the user proceeds to step 2374.
  • a user specifies the pre-existing care group which the user would like to copy, and copies the care group. The user may then change the type of care group by modifying the care group type to that of the new care group in step 2376.
  • a user may also adjust care group settings in step 2376.
  • step 2378 a user specifies the type of new care group which will be added to this list. This step may include selecting a care group from a list of possible care group types.
  • the care group type may be a broad category into which a number of care areas within an institution or organization may fit.
  • Example care groups may include ICU, Emergency, Pediatric, Neonatal, Adult, Step Down, Surgery, Psychiatric, etc.
  • a user may proceed from step 2376 or step 2378 to step 2380.
  • a user may modify the name of the care group so that it matches the name used for that care group within the institution or organization.
  • a user may specify various users that are associated with the newly created care group in step 2382. For example, a user may specify a number of clinicians which work in or are assigned to the care group in step 2382.
  • a user may also specify other individuals within an institution or organization which may have responsibilities for reviewing or contributing to the new care group.
  • a user may define various care group parameters for the new care group. This may involve modifying default values, filling in a blank template, modifying copied values, etc.
  • a non- limiting list of possible care group parameters is shown in Table 5 as follows:
  • a user may save the new values in step 2386.
  • the care group and the parameter values may be saved on the DERS editor database.
  • the user may then indicate that the new care group is ready to be reviewed by those responsible for reviewing the care group in step 2388.
  • the DERS editor service may then notify the appropriate users that the care group has been created and is ready for review in step 2390. This may be done by an automatically generated email.
  • Similar steps may, for example be followed to add a care area to a DAL file in some embodiments.
  • a user may define similar information and parameters for a care area.
  • some of the care group parameters shown in Table 5 may instead or also be defined at the care area level.
  • Parameters at the care group may act as parent parameters for a care area.
  • a care group parameter may be the default setting for the same parameter at the care area level.
  • a user may create a list of medications which may be used within the care group when defining a care group. This may be accomplished following steps similar to those shown and described in relation to FIG. 18.
  • FIG. 22 shows a flowchart detailing a number of example steps which may be used to add a care area to an institution or organization.
  • an organization or institution may be broken into a number of sub-areas or groups which may, for example, reflect departments with the organization or institution.
  • the steps shown in FIG. 22 may be part of a DERS SETUP 122 (see, for example, FIG. 9) phase.
  • step 390 a user navigates to a care area list on the DERS editor user interface. The user chooses to add a new care area to the list in step 392.
  • the user may have a number of options.
  • a user may start from a blank template or nearly blank template.
  • a user may also choose to copy the information for an existing care area to expedite the process. If a user elects to copy a pre-existing care area, the user may proceed to step 394.
  • a user specifies the pre-existing care area which the user would like to copy and copies the care area. The user may then change the type of care area by modifying the care area type to that of the new care area in step 398. In some embodiments, a user may also adjust care area settings in step 398.
  • step 396 a user specifies the type of new care area which will be added to this list. This step may include selecting a care area from a list of possible care area types. In a specific embodiment of the present disclosure, a non-limiting list of possible care areas is shown in Table 6 as follows:
  • a user may proceed from step 396 or step 398 to step 400.
  • a user may modify the name of the care area so that it matches the name used for that care area within the institution or organization.
  • a user may specify a care group (if any) to which the new care area belongs in step 401.
  • a user may specify various users that are associated with the newly created care area in step 402. For example, a user may specify a number of clinicians which work in or are assigned to the care area.
  • a user may also specify other individuals within an institution or organization which may have responsibilities for reviewing or contributing to the new care area.
  • a user may define various care area parameters for the new care area. This may involve modifying default values, filling in a blank template, modifying copied values, etc.
  • parent parameter values i.e., values defined for the same parameter at the care group level, may be automatically used as default values for child parameters at the care area level.
  • Table 7 a non-limiting list of possible care area parameters is shown in Table 7 as follows: Care Area Parameters
  • the care area and the parameter values may be saved on the DERS editor database.
  • the user may then indicate that the new care area is ready to be reviewed by those responsible for reviewing the care area in step 408.
  • the DERS editor service may then notify the appropriate users that the care area has been created and is ready for review in step 410. This may be done by an automatically generated email.
  • FIG. 23 a flowchart detailing a number of example steps which may be used in the verification of a care area is shown. Similar steps may also be well suited to the verification of a care group. The steps may need to be performed by all designated reviewers before a DAL file containing the care area may be released. In some embodiments, these steps may define one of many processes which need to be completed before a DAL file may be released. These steps may be performed as a part of the Review 121 phase of FIG. 9 or the Per Care Area Verification sub-step 216, Per Care Area Review sub-step 222, Cross Care Area Review sub-step 224, and/or Care Area Review sub-step 226 of FIG. 10 in some embodiments. The steps shown in FIG.
  • step 23 may be performed by one or more actors.
  • the steps may be performed by the nurse managers 7, pharmacist 8, risk officer, 6, and/or biomed 19 of FIG. 1. These steps may be performed by the resource clinician 202, review pharmacist 204, pharmacy consultant 206, and/or clinical consultant 208 of FIG. 10.
  • the steps shown in FIG. 23 may be completed on a DERS editor user interface which may be accessible through a suitable internet browser.
  • a reviewing user may navigate to the care areas list.
  • the DERS editor may then solicit the reviewing user to select a care area from the list in step 421.
  • step 422 a reviewing user may select the care area they would like to or are responsible for reviewing.
  • a reviewing user may be responsible for reviewing all items, elements, parameters, etc. in a care area. In some embodiments, a reviewing user may only be assigned a portion of the items, elements, parameters, etc. in a care area. The reviewing user may review an element of the care area in step 424.
  • the reviewing user may be required to enter a comment for all items, elements, or parameters of a care area as the reviewing user is reviewing the care area.
  • the reviewing user is required to either approve the item, element, parameter, etc. or enter a comment about the item, element, parameter, etc. If a reviewing user has no concern or question about the element, the user may indicate their verification of the element in step 425.
  • a reviewing user may proceed from step 424 to step 426.
  • the reviewing user may enter a comment, question, or provide feedback about a specific item, element, parameter, etc. for the care area.
  • a parameter for Patient Weight High Hard Limit in a Neonatal Intensive Care Unit was specified as 70kg
  • a reviewer may enter a comment saying, "this limit appears to be very high, perhaps a typo was made and a zero was added to the entry. Should this value be lower?"
  • some comments in some embodiments may include a change request which can be accepted or denied. Any comment, question, or feedback may be tied to the parameter such that other users or actors may view and in some cases act on the comment or feedback.
  • a reviewing user may include various attachments, links, pictures, CQI data, etc. in comments.
  • step 424 the user may return to step 424 if there are further items, elements, parameters, etc. to review. If there is nothing left in the care area which requires review, a reviewing user may have the option of providing general feedback about the care area.
  • step 428 the user may provide general feedback or comments about the care area as a whole. Comments, questions, and/or feedback provided in step 428 may be tied to the care area such that other users may view and in some cases act on the comment or feedback.
  • the reviewing user may indicate they have completed their review in step 429.
  • Various comments, questions, feedback, etc. may be saved on the DERS editor database.
  • a DERS editor service may send out a notification that the user has finished reviewing the care area in step 430.
  • This notification may be sent out to other users or actors and may be in the form of an automatically generated email message.
  • This message may, for example, be sent to a drug library administrator such as the drug library administrator 200 shown in FIG. 10.
  • a drug library administrator such as the drug library administrator 200 shown in FIG. 10.
  • it may be necessary for at least one actor or user to address all comments, questions, and feedback provided in steps 426 and 428 before a DAL file containing the care area may be released.
  • FIG. 24 shows a flowchart detailing a number of example steps which may be used to update a care area. Specifically, the example flowchart in FIG. 24 details a number of steps which may be used to update a care area after it has been reviewed. The review process may be that described and shown in relation to FIG. 23. The steps shown in the example flowchart in FIG. 24 may be a part of the Editing and Revising sub-step 220 shown in FIG. 10. The steps depicted in FIG. 24 may be performed by a user such as a drug library administrator. Steps similar to those in FIG. 24 may be used to update a care group.
  • a user may navigate to a care area list on a DERS editor user interface.
  • the DERS editor user interface in some embodiments, may be accessed via a suitable web browser.
  • the DERS editor service may prompt the user to select a care area in step 441.
  • a user may select the care area they would like to revise in step 442.
  • the user reviews a comment, question, or feedback regarding the new care area or a parameter within the new care area.
  • a user may take a number of actions with each comment, question, or piece of provided feedback.
  • a reviewing user asked a question about the care area or a parameter in the care area, a user may proceed to step 446.
  • a user may enter an answer to the question. This answer may then be made available for the initial reviewing user to see.
  • a DERS editor service may notify the reviewing user who asked the question that an answer has been made available. This notification may be sent as part of step 448.
  • the reviewing user may be able to respond to the answer if necessary or may be required to acknowledge that a satisfactory answer was received.
  • a reviewing user may proceed to step 450.
  • a user may enter a question regarding the reviewing user's initial input. This question may then be made available for the initial reviewing user to see and respond to.
  • a DERS editor service may notify the reviewing user that a question has been entered about a comment, question, or feedback of theirs. This notification may be sent as part of step 452.
  • a reviewing user enters a comment, question, or feedback which includes a request to change a parameter of the care area
  • a user may accept or deny the change request. If a user accepts a change, they may proceed to step 454 and change the parameter in the care area in response to the change request. If a user decides to deny the change request provided by the reviewing user, the user may deny the request in step 456.
  • a user may be able accept or deny a change request by interfacing with one or more virtual buttons which are included as part of the change request on a DERS editor user interface. In such embodiments, acceptance of a change request may automatically change the parameter for the care area.
  • a reviewing user enters a comment or feedback which does not include a change request, give rise to a question, or require a response, a user may be required to mark the comment or feedback as read in step 458.
  • the DERS editor service may update the DERS Review Status information in step 459.
  • a user may then review other comments, questions, and, feedback until all comments, questions, and feedback from reviewing users have been addressed.
  • a user may proceed to step 460.
  • step 460 a user may indicate that they have finished updating the care area. The updates may be saved and the user may then log out of the DERS editor in step 462.
  • the DERS editor service may notify all of the relevant users that the care area has been updated and is ready for re-verification. This notification may consist, in some embodiments, of an automatically generated email message.
  • the re- verification process may be similar to that described and shown in relation to FIG. 23.
  • FIG. 25 a flowchart detailing a number of exemplary steps which may be used to add drug records or medication records to a specified care area.
  • drug record and “medication record” are herein used interchangeably. These drug records may define the medications available for use within a care area and various limitations, characteristics, etc. which may apply to those medications.
  • the Drug Selection and Record Specification sub-step 214 may be performed as a part of the Drug Selection and Record Specification sub-step 214 shown in FIG. 10. In some embodiments, these steps may be performed by a drug library administrator such as the drug library administrator 200 shown in FIG. 10. In other embodiments a different individual such as a pharmacist or other actor may be responsible for adding drug records to a care area. In some embodiments, similar steps may be used to add a drug record to a care group.
  • a user may navigate to a list of care areas on a DERS editor user interface. A user then may select a care area to add drug records to in step 471. In some embodiments, it may be required that parameters for the care area have been pervious defined and verified before drug records may be added to the care area. In such embodiments, the defining and verification of parameters may be accomplished by performing steps similar to those shown and described in relation to FIGS. 22-24.
  • a user may decide to add a specific drug or may elect to add a non-specified drug. If a user elects to add a specific drug, a user may copy a Medication Record from an existing group (step 474) or may define a medication to create a Medication Record for the care area (step 476). If a user elects to copy a Medication Record, the user may proceed to step 474. In step 474 a user may copy a Medication Record for a desired medication from an existing care area. In some embodiments, this may involve selecting a medication record from a list of medication records displayed on the DERS user interface. In some embodiments and situations, a user may be able to copy a medication record from a different institution. This may be especially true if an institution is part of an IDN, for example.
  • Copying of the Medication Record may copy all of the Rule Sets and
  • a user may have the ability to opt out of copying some or all of the Rule Sets and/or Concentration Records when copying the Medication Record over to the new care area.
  • a user may repeat step 474 for as many records as desired or may perform step 476 to add additional Medication Records. If, after copying a Medication Record, there are no more medications to add to the care area, a user may proceed to step 486. Step 486 will be described later in the specification.
  • a step may be included to allow a user to make adjustments and modifications to a copied care area.
  • Step 476 may be performed if a user wants to create a Medication Record without copying the record from another care area.
  • a user may define the name of the medication for which the Medication Record will be created.
  • a user may select the name of the medication from a master list of medications. Such a list may be provided by a DERS editor service or may be compiled within an institution or organization.
  • a non-limiting list of possible Medication Record parameters is shown in Table 8 as follows:
  • Each Rule Set in some embodiments, may be provided for a specific clinical usage of a drug or medication. Rule Set and clinical use are used herein interchangeably.
  • a medication may, for example, have a Rule Set which governs how the medication may be delivered when it is delivered as a weight based infusion and another which governs how the medication may be delivered when delivered as an intermittent infusion.
  • a non-limiting list of other possible clinical usages may include: non-weight based infusion, body surface area (BSA) based infusion, continuous infusion, etc.
  • the user may have a choice between copying a Rule Set for a medication from an existing Medication Record (step 478) or defining their own Rule Set for the drug (step 480). If a user elects to copy a Rule Set, the user may proceed to step 478. In step 478, a user may choose a Rule Set to copy from an existing Medication Record. This may involve selecting a desired Rule Set from a list displayed on a DERS editor user interface. In some embodiments and situations, a user may be able to copy a Rule Set from a different institution. This may be especially true if an institution is part of an IDN, for example.
  • Copying of the Rule Set may copy all of the Concentration Records for the
  • a user may have the ability to opt out of copying certain Concentration Records or all Concentration Records when copying the Rule Set. After copying a Rule Set, a user may repeat step 478 for as many Rule Sets as desired or may perform step 480 to add additional Rule Sets. If, after copying a Rule Set, there are no more Medication Records or Rule Sets to add to the care area, a user may proceed to step 486. Step 486 will be described later in the specification. Some embodiments may include a step where a user may edit or modify the copied Rule Set.
  • Step 480 may be performed by a user if a user desires to create a Rule Set for a Medication Record without copying a pre-existing Rule Set.
  • a user may create the Rule Set and define parameters for the Rule Set.
  • a user may be required to define different parameters.
  • Table 9 a non-limiting list of possible Rule Set parameters is shown in Table 9 as follows:
  • a user may then be required to define one or more Concentration Records for each Rule Set.
  • Each Concentration Record may be created for every concentration of the medication which is to be used with a particular Rule Set.
  • the user may have a choice between copying a Concentration Record for a Rule Set of an existing Medication Record (step 482) or defining their own Concentration Record for the Rule Set (step 484).
  • step 482 a user may choose a Concentration Record to copy from an existing Rule Set. After copying a Concentration Record, a user may repeat step 482 for as many Concentration Records as desired or may perform step 484 to add additional Concentration Records. If, after copying a Concentration Record, there are no more Medication Records, Rule Sets, or Concentration Records to add to the care area, a user may proceed to step 486. Step 486 will be described later in the specification. In some embodiments, an additional step may be included in which a user may alter or adjust the copied Concentration Record.
  • Step 484 may be performed by a user if a user desires to create a
  • Concentration Record for a Rule Set without copying a pre-existing Concentration Record.
  • a user may create the Concentration Record and define parameters for the Concentration Record.
  • Table 10 a non-limiting list of possible Concentration Record parameters is shown in Table 10 as follows:
EP13824438.9A 2012-12-21 2013-12-20 Computer-implemented method, system, and apparatus for electronic patient care Withdrawn EP2936360A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP21204062.0A EP3965112A1 (en) 2012-12-21 2013-12-20 Computer-implemented method, system, and apparatus for electronic patient care

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201261740474P 2012-12-21 2012-12-21
US13/723,242 US10911515B2 (en) 2012-05-24 2012-12-21 System, method, and apparatus for electronic patient care
US13/723,239 US10108785B2 (en) 2010-01-22 2012-12-21 System, method, and apparatus for electronic patient care
US13/723,253 US11210611B2 (en) 2011-12-21 2012-12-21 System, method, and apparatus for electronic patient care
PCT/US2013/042350 WO2013177357A1 (en) 2012-05-24 2013-05-23 Method and system for communication between a monitoring client and a base
US13/900,655 US11881307B2 (en) 2012-05-24 2013-05-23 System, method, and apparatus for electronic patient care
PCT/US2013/077258 WO2014100736A2 (en) 2012-12-21 2013-12-20 Computer-implemented method, system, and apparatus for electronic patient care

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP21204062.0A Division EP3965112A1 (en) 2012-12-21 2013-12-20 Computer-implemented method, system, and apparatus for electronic patient care

Publications (1)

Publication Number Publication Date
EP2936360A2 true EP2936360A2 (en) 2015-10-28

Family

ID=50979412

Family Applications (6)

Application Number Title Priority Date Filing Date
EP13826687.9A Active EP2936362B1 (en) 2012-12-21 2013-12-20 System, method, and apparatus for electronic patient care
EP13824562.6A Ceased EP2936361A2 (en) 2012-12-21 2013-12-20 System, method, and apparatus for communicating data
EP21204062.0A Pending EP3965112A1 (en) 2012-12-21 2013-12-20 Computer-implemented method, system, and apparatus for electronic patient care
EP13824438.9A Withdrawn EP2936360A2 (en) 2012-12-21 2013-12-20 Computer-implemented method, system, and apparatus for electronic patient care
EP19155938.4A Pending EP3511943A1 (en) 2012-12-21 2013-12-20 System, method, and apparatus for electronic patient care
EP19172031.7A Pending EP3537449A1 (en) 2012-12-21 2013-12-20 System, method, and apparatus for communicating data

Family Applications Before (3)

Application Number Title Priority Date Filing Date
EP13826687.9A Active EP2936362B1 (en) 2012-12-21 2013-12-20 System, method, and apparatus for electronic patient care
EP13824562.6A Ceased EP2936361A2 (en) 2012-12-21 2013-12-20 System, method, and apparatus for communicating data
EP21204062.0A Pending EP3965112A1 (en) 2012-12-21 2013-12-20 Computer-implemented method, system, and apparatus for electronic patient care

Family Applications After (2)

Application Number Title Priority Date Filing Date
EP19155938.4A Pending EP3511943A1 (en) 2012-12-21 2013-12-20 System, method, and apparatus for electronic patient care
EP19172031.7A Pending EP3537449A1 (en) 2012-12-21 2013-12-20 System, method, and apparatus for communicating data

Country Status (11)

Country Link
EP (6) EP2936362B1 (ru)
JP (6) JP6750943B2 (ru)
CN (6) CN104969228B (ru)
AU (4) AU2013364039B2 (ru)
BR (1) BR112015015060A2 (ru)
CA (3) CA3190143A1 (ru)
ES (1) ES2728466T3 (ru)
MX (1) MX358021B (ru)
RU (1) RU2015129753A (ru)
SG (3) SG11201504872YA (ru)
WO (1) WO2014100736A2 (ru)

Families Citing this family (121)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9123077B2 (en) 2003-10-07 2015-09-01 Hospira, Inc. Medication management system
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
AU2007317669A1 (en) 2006-10-16 2008-05-15 Hospira, Inc. System and method for comparing and utilizing activity information and configuration information from mulitple device management systems
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
US10453157B2 (en) 2010-01-22 2019-10-22 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US20110313789A1 (en) 2010-01-22 2011-12-22 Deka Products Limited Partnership Electronic patient monitoring system
US9808572B2 (en) 2010-01-22 2017-11-07 Deka Products Limited Partnership System, method and apparatus for clamping
US9151646B2 (en) 2011-12-21 2015-10-06 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US11227687B2 (en) 2010-01-22 2022-01-18 Deka Products Limited Partnership System, method, and apparatus for communicating data
US10911515B2 (en) 2012-05-24 2021-02-02 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11881307B2 (en) 2012-05-24 2024-01-23 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11210611B2 (en) 2011-12-21 2021-12-28 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US9400873B2 (en) 2011-12-21 2016-07-26 Deka Products Limited Partnership System, method, and apparatus for dispensing oral medications
US9295778B2 (en) 2011-12-21 2016-03-29 Deka Products Limited Partnership Syringe pump
US9789247B2 (en) 2011-12-21 2017-10-17 Deka Products Limited Partnership Syringe pump, and related method and system
US9518958B2 (en) 2012-12-18 2016-12-13 Deka Products Limited Partnership System, method, and apparatus for detecting air in a fluid line using active rectification
US11164672B2 (en) 2010-01-22 2021-11-02 Deka Products Limited Partnership System and apparatus for electronic patient care
US9488200B2 (en) 2010-01-22 2016-11-08 Deka Products Limited Partnership System, method, and apparatus for clamping
US9636455B2 (en) 2011-12-21 2017-05-02 Deka Products Limited Partnership System, method, and apparatus for estimating liquid delivery
US9759369B2 (en) 2011-12-21 2017-09-12 Deka Products Limited Partnership System, method, and apparatus for clamping
US9677555B2 (en) 2011-12-21 2017-06-13 Deka Products Limited Partnership System, method, and apparatus for infusing fluid
US11244745B2 (en) 2010-01-22 2022-02-08 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
US9744300B2 (en) 2011-12-21 2017-08-29 Deka Products Limited Partnership Syringe pump and related method
JP6033874B2 (ja) 2011-10-21 2016-11-30 ホスピーラ インコーポレイテッド 医療装置更新システム
US9746094B2 (en) 2011-12-21 2017-08-29 Deka Products Limited Partnership Flow meter having a background pattern with first and second portions
US10655779B2 (en) 2011-12-21 2020-05-19 Deka Products Limited Partnership System, method, and apparatus for clamping
US9372486B2 (en) 2011-12-21 2016-06-21 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US10722645B2 (en) 2011-12-21 2020-07-28 Deka Products Limited Partnership Syringe pump, and related method and system
US11295846B2 (en) 2011-12-21 2022-04-05 Deka Products Limited Partnership System, method, and apparatus for infusing fluid
US10228683B2 (en) 2011-12-21 2019-03-12 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US9746093B2 (en) 2011-12-21 2017-08-29 Deka Products Limited Partnership Flow meter and related system and apparatus
US9724466B2 (en) 2011-12-21 2017-08-08 Deka Products Limited Partnership Flow meter
US10488848B2 (en) 2011-12-21 2019-11-26 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US10563681B2 (en) 2011-12-21 2020-02-18 Deka Products Limited Partnership System, method, and apparatus for clamping
US11649924B2 (en) 2011-12-21 2023-05-16 Deka Products Limited Partnership System, method, and apparatus for clamping
US9435455B2 (en) 2011-12-21 2016-09-06 Deka Products Limited Partnership System, method, and apparatus for monitoring, regulating, or controlling fluid flow
US9675756B2 (en) 2011-12-21 2017-06-13 Deka Products Limited Partnership Apparatus for infusing fluid
US10082241B2 (en) 2011-12-21 2018-09-25 Deka Products Limited Partnership System, method, and apparatus for clamping
US11217340B2 (en) 2011-12-21 2022-01-04 Deka Products Limited Partnership Syringe pump having a pressure sensor assembly
US9759343B2 (en) 2012-12-21 2017-09-12 Deka Products Limited Partnership Flow meter using a dynamic background image
CN109817323B (zh) 2012-12-21 2023-10-13 德卡产品有限公司 用于传输数据的系统、方法和装置
WO2014138446A1 (en) 2013-03-06 2014-09-12 Hospira,Inc. Medical device communication method
USD767756S1 (en) 2013-06-11 2016-09-27 Deka Products Limited Partnership Medical pump
USD736370S1 (en) 2013-06-11 2015-08-11 Deka Products Limited Partnership Medical pump
USD735319S1 (en) 2013-06-11 2015-07-28 Deka Products Limited Partnership Medical pump
WO2015017275A1 (en) 2013-07-31 2015-02-05 Deka Products Limited Partnership System, method, and apparatus for bubble detection in a fluid line using a split-ring resonator
US20150066531A1 (en) 2013-08-30 2015-03-05 James D. Jacobson System and method of monitoring and managing a remote infusion regimen
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
USD745661S1 (en) 2013-11-06 2015-12-15 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD752209S1 (en) 2013-11-06 2016-03-22 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD751689S1 (en) 2013-11-06 2016-03-15 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD751690S1 (en) 2013-11-06 2016-03-15 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
USD749206S1 (en) 2013-11-06 2016-02-09 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
AU2014353130B9 (en) 2013-11-19 2019-09-05 Icu Medical, Inc. Infusion pump automation system and method
USD760782S1 (en) 2013-12-20 2016-07-05 Deka Products Limited Partnership Display screen of a medical pump with a graphical user interface
USD768716S1 (en) 2013-12-20 2016-10-11 Deka Products Limited Partnership Display screen of a medical pump with a graphical user interface
USD760289S1 (en) 2013-12-20 2016-06-28 Deka Products Limited Partnership Display screen of a syringe pump with a graphical user interface
USD760288S1 (en) 2013-12-20 2016-06-28 Deka Products Limited Partnership Medical pump display screen with transitional graphical user interface
USD756386S1 (en) 2013-12-20 2016-05-17 Deka Products Limited Partnership Display screen with graphical user interface
USD758399S1 (en) 2013-12-20 2016-06-07 Deka Products Limited Partnership Display screen with graphical user interface
CA3175252A1 (en) 2014-02-21 2015-08-27 Deka Products Limited Partnership Syringe pump having a pressure sensor assembly
US9730731B2 (en) 2014-02-27 2017-08-15 Deka Products Limited Partnership Craniofacial external distraction apparatus
US9364394B2 (en) 2014-03-14 2016-06-14 Deka Products Limited Partnership Compounder apparatus
WO2015168427A1 (en) 2014-04-30 2015-11-05 Hospira, Inc. Patient care system with conditional alarm forwarding
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
CN106794302B (zh) 2014-09-18 2020-03-20 德卡产品有限公司 通过将管适当加热来穿过管输注流体的装置和方法
US20160128647A1 (en) * 2014-11-07 2016-05-12 Welch Allyn, Inc. Medical Device With Enhanced Viewing Mode
US9943645B2 (en) 2014-12-04 2018-04-17 Medtronic Minimed, Inc. Methods for operating mode transitions and related infusion devices and systems
US9636453B2 (en) 2014-12-04 2017-05-02 Medtronic Minimed, Inc. Advance diagnosis of infusion device operating mode viability
USD792963S1 (en) 2015-02-10 2017-07-25 Deka Products Limited Partnership Bumper for a medical pump
USD754065S1 (en) 2015-02-10 2016-04-19 Deka Products Limited Partnership AC-to-DC power supply
USD805183S1 (en) 2015-02-10 2017-12-12 Deka Products Limited Partnership Medical pump
USD803386S1 (en) 2015-02-10 2017-11-21 Deka Products Limited Partnership Syringe medical pump
USD803387S1 (en) 2015-02-10 2017-11-21 Deka Products Limited Partnership Syringe medical pump
USD801519S1 (en) 2015-02-10 2017-10-31 Deka Products Limited Partnership Peristaltic medical pump
USD774645S1 (en) 2015-02-10 2016-12-20 Deka Products Limited Partnership Clamp
WO2016189417A1 (en) * 2015-05-26 2016-12-01 Hospira, Inc. Infusion pump system and method with multiple drug library editor source capability
US10478261B2 (en) 2015-05-29 2019-11-19 Deka Products Limited Partnership System, method, and apparatus for remote patient care
CN113855905B (zh) 2016-01-28 2024-01-12 德卡产品有限公司 滴注室和用于将流体输注到患者体内的设备
USD905848S1 (en) 2016-01-28 2020-12-22 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
US11244758B2 (en) * 2016-04-12 2022-02-08 White Bear Medical, LLC Self-validating module for software control of medical devices
USD854145S1 (en) 2016-05-25 2019-07-16 Deka Products Limited Partnership Apparatus to control fluid flow through a tube
EP3484541A4 (en) 2016-07-14 2020-03-25 ICU Medical, Inc. SELECTION OF SEVERAL COMMUNICATION PATHS AND SECURITY SYSTEM FOR A MEDICAL DEVICE
CN108039954A (zh) * 2016-10-28 2018-05-15 北京东软医疗设备有限公司 一种实现查看医疗设备日志的方法、装置及系统
US11837342B2 (en) 2017-01-26 2023-12-05 Joshua J. Dronzek Method and system for backing up and maintaining electronic medical records for periods of temporary loss of connectivity to an electronic storage facility
RO132971A2 (ro) * 2017-06-12 2018-12-28 Fresenius Medical Care Deutschland Gmbh Metodă şi aparat pentru generarea unui regim de tratament
SG11202009657YA (en) 2018-04-17 2020-10-29 Deka Products Lp Peritoneal dialysis cassette with pneumatic pump
EP3794601A1 (en) * 2018-05-15 2021-03-24 Fresenius Vial SAS Therapy-based database model for generating drug libraries
NZ793485A (en) 2018-07-17 2023-06-30 Icu Medical Inc Systems and methods for facilitating clinical messaging in a network environment
US11139058B2 (en) 2018-07-17 2021-10-05 Icu Medical, Inc. Reducing file transfer between cloud environment and infusion pumps
US10964428B2 (en) 2018-07-17 2021-03-30 Icu Medical, Inc. Merging messages into cache and generating user interface using the cache
CA3106516C (en) 2018-07-17 2023-07-25 Icu Medical, Inc. Updating infusion pump drug libraries and operational software in a networked environment
US11501859B1 (en) 2018-07-20 2022-11-15 MedAmerica Data Services, LLC Patient callback tool and interface
US11482322B1 (en) 2018-07-20 2022-10-25 MedAmerica Data Services, LLC Patient trackerboard tool and interface
US11626192B1 (en) 2018-07-20 2023-04-11 MedAmerica Data Services, LLC Real time parser for use with electronic medical records
US11177041B1 (en) 2018-07-20 2021-11-16 MedAmerica Data Services, LLC Method and system for cardiac risk assessment of a patient using historical and real-time data
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
WO2020023231A1 (en) 2018-07-26 2020-01-30 Icu Medical, Inc. Drug library management system
USD917045S1 (en) 2018-08-16 2021-04-20 Deka Products Limited Partnership Slide clamp
JP7047185B2 (ja) 2018-08-16 2022-04-04 デカ・プロダクツ・リミテッド・パートナーシップ 医療用ポンプ
AU2019390392A1 (en) 2018-11-26 2021-06-10 Kpr U.S., Llc Cassette for a flow control apparatus
TWI686817B (zh) * 2019-06-05 2020-03-01 彰化基督教醫療財團法人彰化基督教醫院 藥物傳遞系統及方法
US11839741B2 (en) 2019-07-26 2023-12-12 Deka Products Limited Partneship Apparatus for monitoring, regulating, or controlling fluid flow
USD964563S1 (en) 2019-07-26 2022-09-20 Deka Products Limited Partnership Medical flow clamp
CN112295051B (zh) * 2019-07-26 2022-04-19 深圳迈瑞科技有限公司 输注泵的快速推注方法及输注泵
CN114175179A (zh) * 2019-09-25 2022-03-11 深圳迈瑞科技有限公司 一种输注泵及输液参数设置方法
CN111430008A (zh) * 2020-02-25 2020-07-17 广州七乐康药业连锁有限公司 基于云平台下的医疗数据处理方法及医疗数据处理系统
AU2021309952A1 (en) 2020-07-16 2023-03-16 Ventec Life Systems, Inc. System and method for concentrating gas
JP7414355B2 (ja) 2020-07-16 2024-01-16 ベンテック ライフ システムズ， インコーポレイテッド ガスを濃縮するためのシステムおよび方法
US20220157445A1 (en) * 2020-11-18 2022-05-19 Carefusion 303, Inc. Auto-programming request rejection reduction
CN112883344A (zh) * 2021-02-03 2021-06-01 中国工商银行股份有限公司 一种代码操作权限的控制方法及装置
DE102021104411A1 (de) 2021-02-24 2022-08-25 B. Braun Melsungen Aktiengesellschaft Vorrichtung und Verfahren zum Verabreichen von Flüssigkeiten
TWI795928B (zh) * 2021-09-29 2023-03-11 國立陽明交通大學 用於預測透析中不良事件之系統、方法及其電腦可讀媒介
WO2023069836A1 (en) * 2021-10-22 2023-04-27 Icu Medical, Inc. Medical device message coding management
WO2023122219A1 (en) * 2021-12-23 2023-06-29 Carefusion 303, Inc. System and method for intelligently controlling medical devices
WO2023183343A1 (en) * 2022-03-22 2023-09-28 Carefusion 303, Inc. Device, method, and system for accurate delivery of flush infusion
WO2023219607A1 (en) * 2022-05-10 2023-11-16 Carefusion 303, Inc. Remote scanning and validating of clinical order device configurations
WO2024039697A1 (en) * 2022-08-17 2024-02-22 Fresenius Kabi Usa, Llc Alert management in fluid delivery system
CN116763272B (zh) * 2023-06-08 2024-01-26 中国人民解放军总医院第七医学中心 一种基于蓝牙技术的便携式多人共享血压监测系统、应用方法及设备

Family Cites Families (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3660678B2 (ja) * 1992-10-15 2005-06-15 ザ ゼネラル ホスピタル コーポレーション 電子的にロード可能な薬剤ライブラリ付き注入ポンプ
US5782805A (en) * 1996-04-10 1998-07-21 Meinzer; Randolph Medical infusion pump
BR9814637A (pt) * 1997-11-12 2001-11-27 I Flow Corp Método e aparelho para monitorar um paciente
WO2002005061A2 (en) * 2000-07-06 2002-01-17 David Paul Felsher Information record infrastructure, system and method
JP2002046315A (ja) * 2000-08-03 2002-02-12 Toshiba Tec Corp 画像形成装置
KR20010044394A (ko) * 2001-02-16 2001-06-05 이승국 전자카드를 이용한 전자처방전달 방법 및 그 장치
US7306578B2 (en) 2002-01-04 2007-12-11 Deka Products Limited Partnership Loading mechanism for infusion pump
CN1169494C (zh) * 2001-05-23 2004-10-06 中国科学院化学研究所 组织工程用复合结构细胞支架及其制法和用途
CN1554061A (zh) * 2001-06-20 2004-12-08 ͨ��ҽ�ƹ�˾ 用于集成医疗跟踪的方法和系统
WO2003038566A2 (en) * 2001-11-01 2003-05-08 Scott Laboratories, Inc. User interface for sedation and analgesia delivery systems and methods
US20040032426A1 (en) * 2002-04-23 2004-02-19 Jolyn Rutledge System and user interface for adaptively presenting a trend indicative display of patient medical parameters
CN1472681A (zh) * 2002-08-02 2004-02-04 中电科技电子信息系统有限公司 大中型药业连锁物流计算机管理系统及方法
US20050288571A1 (en) * 2002-08-20 2005-12-29 Welch Allyn, Inc. Mobile medical workstation
US7835927B2 (en) * 2002-12-27 2010-11-16 Carefusion 303, Inc. Medication management system
US20050021368A1 (en) * 2003-07-25 2005-01-27 Debra Burkeen Enhanced safety medication administration system
US20050021367A1 (en) * 2003-07-25 2005-01-27 Deborah Saeger Medication administration system
DE10334516B4 (de) * 2003-07-29 2006-06-14 Sorin Group Deutschland Gmbh Anzeige- und Bedienvorrichtung für medizintechnische Geräte und Anzeige-/Bedieneinheit dafür
US7895053B2 (en) * 2003-10-07 2011-02-22 Hospira, Inc. Medication management system
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
EP1744262A3 (en) * 2003-11-13 2007-03-28 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
CN101907630B (zh) * 2004-04-07 2012-03-07 泰肯贸易股份公司 识别、定位和跟踪实验室设备上的物体的装置和方法
JP4273036B2 (ja) 2004-05-12 2009-06-03 中 奥村 投薬支援プログラム、投薬支援装置、投薬支援プログラムを記録した記録媒体及び投薬支援システム
CN1811782A (zh) * 2004-09-16 2006-08-02 西门子医疗健康服务公司 医嘱管理系统和用户界面
JP2006163891A (ja) * 2004-12-08 2006-06-22 Canon Inc 作業制御装置
CN2868184Y (zh) * 2005-06-21 2007-02-14 耿洪彪 无线健康监测系统
US8527888B2 (en) * 2006-04-11 2013-09-03 Invensys Systems, Inc. Method and supporting configuration user interfaces for streamlining installing replacement field devices
US7733224B2 (en) * 2006-06-30 2010-06-08 Bao Tran Mesh network personal emergency response appliance
JP2007143834A (ja) * 2005-11-28 2007-06-14 Tosho Inc 抗ガン剤適正使用支援システム
WO2007095093A2 (en) 2006-02-09 2007-08-23 Deka Products Limited Partnership Pumping fluid delivery systems and methods using force application assembly
US20070219481A1 (en) 2006-03-16 2007-09-20 Eilaz Babaev Apparatus and methods for the treatment of avian influenza with ultrasound
AU2007245050B2 (en) * 2006-03-28 2012-08-30 Hospira, Inc. Medication administration and management system and method
US20080160492A1 (en) * 2006-08-08 2008-07-03 Insulet Corporation Interactive training system and method
CN1936974A (zh) * 2006-10-31 2007-03-28 上海康驰生物科技有限公司 一种电子药房系统
CN101528118A (zh) * 2006-11-03 2009-09-09 Ric投资有限责任公司 患者信息管理系统
US8195478B2 (en) * 2007-03-07 2012-06-05 Welch Allyn, Inc. Network performance monitor
US20090177769A1 (en) * 2007-08-10 2009-07-09 Smiths Medical Md Determining online status of a medical device
JP2009059040A (ja) * 2007-08-30 2009-03-19 Accel:Kk 管理システム
CN101149823A (zh) * 2007-10-29 2008-03-26 浙江大学 一种基于中医药本体的在线编辑和维护方法
US9026370B2 (en) 2007-12-18 2015-05-05 Hospira, Inc. User interface improvements for medical devices
EP3679969A3 (en) 2007-12-31 2020-09-30 DEKA Products Limited Partnership Infusion pump assembly
CN104874047B (zh) 2007-12-31 2019-05-28 德卡产品有限公司 输注泵组件
JP2009163534A (ja) * 2008-01-08 2009-07-23 Carecom:Kk 服薬管理システムおよび服薬管理装置
US9577934B2 (en) * 2008-02-29 2017-02-21 Koninklijke Philips N.V. Optimizing physiologic monitoring based on available but variable signal quality
US9417626B2 (en) * 2008-09-29 2016-08-16 Fisher-Rosemount Systems, Inc. Efficient design and configuration of elements in a process control system
US8223028B2 (en) 2008-10-10 2012-07-17 Deka Products Limited Partnership Occlusion detection system and method
US8016789B2 (en) 2008-10-10 2011-09-13 Deka Products Limited Partnership Pump assembly with a removable cover assembly
US8267892B2 (en) 2008-10-10 2012-09-18 Deka Products Limited Partnership Multi-language / multi-processor infusion pump assembly
US8066672B2 (en) 2008-10-10 2011-11-29 Deka Products Limited Partnership Infusion pump assembly with a backup power supply
US9180245B2 (en) 2008-10-10 2015-11-10 Deka Products Limited Partnership System and method for administering an infusible fluid
US8262616B2 (en) 2008-10-10 2012-09-11 Deka Products Limited Partnership Infusion pump assembly
US9492092B2 (en) * 2009-05-20 2016-11-15 Sotera Wireless, Inc. Method for continuously monitoring a patient using a body-worn device and associated system for alarms/alerts
ES2685772T3 (es) * 2009-12-30 2018-10-11 Jvm Co., Ltd. Sistema de gestión de medicamentos
JP5438529B2 (ja) * 2010-01-18 2014-03-12 ココリサーチ株式会社 デジタルパネルメータ
US10453157B2 (en) * 2010-01-22 2019-10-22 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US10108785B2 (en) 2010-01-22 2018-10-23 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11881307B2 (en) 2012-05-24 2024-01-23 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US20110313789A1 (en) 2010-01-22 2011-12-22 Deka Products Limited Partnership Electronic patient monitoring system
US10911515B2 (en) 2012-05-24 2021-02-02 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US20110218406A1 (en) * 2010-03-04 2011-09-08 Nellcor Puritan Bennett Llc Visual Display For Medical Monitor
JP5897460B2 (ja) * 2010-04-27 2016-03-30 株式会社根本杏林堂 薬液注入装置およびｃｔ装置
WO2012050582A1 (en) 2010-10-14 2012-04-19 Hewlett-Packard Development Company, L.P. Continuous querying of a data stream
CN202168825U (zh) * 2010-12-30 2012-03-21 世意法（北京）半导体研发有限责任公司 对象监视器
US20120209619A1 (en) * 2011-02-16 2012-08-16 Knotts Larry E System and method for managing the tracking and dispensing of prescription medication
CN102122364B (zh) * 2011-02-22 2013-03-06 电子科技大学 一种基于rfid无线通信的输液监护系统
US8593275B2 (en) * 2011-03-08 2013-11-26 General Electric Company Wireless monitoring system and method with dual mode alarming
SG195155A1 (en) 2011-05-24 2013-12-30 Deka Products Lp Blood treatment systems and methods
NZ768254A (en) 2011-12-21 2022-04-29 Deka Products Lp System, method, and apparatus for electronic patient care
CN102708529B (zh) * 2012-05-16 2015-01-14 北京航空航天大学 一种药房药品仓储信息管理系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
EP3511943A1 (en) 2019-07-17
AU2021277639A1 (en) 2021-12-23
CN107256325B (zh) 2021-09-28
EP3537449A1 (en) 2019-09-11
CA3190111A1 (en) 2014-06-26
CN108806798A (zh) 2018-11-13
CN112270969A (zh) 2021-01-26
AU2019236691A1 (en) 2019-10-17
AU2019236691B2 (en) 2021-09-02
CN104969228B (zh) 2018-05-22
AU2023201519A1 (en) 2023-04-13
AU2013364039A1 (en) 2015-07-16
WO2014100736A3 (en) 2014-11-13
EP3965112A1 (en) 2022-03-09
MX2015008062A (es) 2015-11-13
RU2015129753A3 (ru) 2018-05-18
JP2023012513A (ja) 2023-01-25
MX358021B (es) 2018-08-02
EP2936361A2 (en) 2015-10-28
CA3190143A1 (en) 2014-06-26
NZ749334A (en) 2020-10-30
JP7197627B2 (ja) 2022-12-27
AU2021277639B2 (en) 2022-12-22
JP2019088862A (ja) 2019-06-13
SG11201504872YA (en) 2015-07-30
ES2728466T3 (es) 2019-10-24
CN107256325A (zh) 2017-10-17
CN113793695A (zh) 2021-12-14
SG10201607032QA (en) 2016-10-28
JP2016509709A (ja) 2016-03-31
SG10201803404VA (en) 2018-06-28
AU2013364039B2 (en) 2019-09-26
WO2014100736A2 (en) 2014-06-26
EP2936362A2 (en) 2015-10-28
BR112015015060A2 (pt) 2017-07-11
JP6882351B2 (ja) 2021-06-02
CA2896088A1 (en) 2014-06-26
JP6750943B2 (ja) 2020-09-02
JP2021131883A (ja) 2021-09-09
JP2021072959A (ja) 2021-05-13
RU2015129753A (ru) 2017-02-02
JP2023030032A (ja) 2023-03-07
CN104969228A (zh) 2015-10-07
EP2936362B1 (en) 2019-03-20
CA2896088C (en) 2023-04-11
JP7030222B2 (ja) 2022-03-04
CN112071379A (zh) 2020-12-11

Similar Documents

Publication Publication Date Title
AU2021277639B2 (en) Computer-implemented method, system, and apparatus for electronic patient care
US11810653B2 (en) Computer-implemented method, system, and apparatus for electronic patient care
US20210365849A1 (en) Computer-implemented method, system, and apparatus for electronic patient care
US20130204637A1 (en) Pharmacy workflow management system
EP2936363A2 (en) System and apparatus for electronic patient care
US20170011178A1 (en) Smart phone based multi-patient worklist (spwl)
Hoffman et al. Safe and successful implementation of CPOE for chemotherapy at a children's cancer center
US20100169109A1 (en) Managing Patient Care Plans
US20150234987A1 (en) System and Method for Processing Healthcare Information
CN116113965A (zh) 用于管理临床路径和处理计划的系统和方法
WO2014018413A1 (en) Methods and systems for order set processing and validation
AU2014248942A1 (en) Pharmacy workflow management system
NZ749334B2 (en) System for reducing medical errors

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20150416

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BIASI, JOHN, J.

Inventor name: KERWIN, JOHN, M.

Inventor name: PRIBYL, ERIC, L.

Inventor name: GUPTA, RAHUL

Inventor name: NEWMAN, RICHARD, M.

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170710

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20211022