System for electronic patient care

Abstract

To provide a system and a device for electronic patient care.SOLUTION: A system for electronic patient care includes a network, a facility gateway, a device gateway application, and a medical device. The facility gateway is configured to provide a publish-subscribe service for the application. The device gateway application is configured to be executed by the facility gateway. The device gateway is configured to communicate over the network by providing web service. The medical device may be in operative communication with the network. The medical device is configured to communicate with the device gateway using the web service.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. Nonprovisional Patent Application No. 13 / 836,497, entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed March 15, 2013 (Attorney Docket No. K22). The application entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed March 15, 2013, U.S. patent application Ser. No. 13 / 836,497 (Attorney Docket No. K22), claims the benefit of priority to and the benefit of the following applications: U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled "Systems, Methods, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow"; and U.S. Provisional Patent Application No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, both of which are incorporated herein by reference in their entireties. The application entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed March 15, 2013, U.S. patent application Ser. No. 13 / 836,497 (Attorney Docket No. K22), claims the benefit of priority to, and is a continuation-in-part of, the following applications: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is a continuation-in-part of U.S. Application No. 13 / 011,543, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM. is a continuation of U.S. patent application Ser. No. 13 / 011,543, which was published on December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544, entitled ELECTRONIC ORDER BROKERAGE SYSTEM FOR HEALTHCARE FACILITIES, filed on January 22, 2010 (Attorney Docket No. H53), all of which applications are incorporated herein by reference; and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties. U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), is a continuation-in-part of U.S. patent application Ser. No. 13 / 723,238, filed December 21, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR CLAMPING, which claims the benefit of priority to and is a continuation-in-part of U.S. patent application Ser. No. 13 / 723,238, published July 18, 2013, and having publication number US2013-0182381-A1 (Attorney Docket No. J47), which claims the benefit of priority to and the benefit of the following applications:

[0002] Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled SYSTEMS, METHODS, AND APPARATUS FOR MONITORING, REGULATING, OR CONTROLLING FLUID FLOW; and No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, entitled ELECTRONIC PATIENT CARE SYSTEM, METHODS, AND APPARATUS, both of which are incorporated herein by reference in their entireties. U.S. Patent Application No. 13 / 723,238, published July 18, 2013, Publication No. US2013-0182381-A1 (Attorney Docket No. J47), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety. No. 13 / 333,574, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety in its entirety in its entirety. This application is a continuation-in-part of U.S. Patent Application No. 13 / 011,543, which was published on December 22, 2011, under Publication No. US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application No. 61 / 297,544, entitled "Electronic Order Brokerage System for Healthcare Facilities," filed on January 22, 2010 (Attorney Docket No. H53); and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties. U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), claims the benefit of priority to and is a continuation-in-part of U.S. patent application Ser. No. 13 / 723,235, filed December 21, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR ORAL DRUGS PACKAGING (Attorney Docket No. J74), published August 1, 2013, and having publication number US-2013-0179693-A1. U.S. patent application Ser. No. 13 / 723,235 claims the benefit of priority to and the benefit of the following applications: Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled "Systems, Methods, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow"; No. 61 / 651,322 (Attorney Docket No. J46), filed March 24, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, which applications are incorporated herein by reference in their entireties. The application entitled "Systems, Methods and Apparatus for Oral Medication Compounding," U.S. patent application Ser. No. 13 / 723,235, filed December 21, 2012, published August 1, 2013, having publication number US-2013-0179693-A1 (Attorney Docket No. J74), claims the benefit of priority to and is a continuation-in-part of the following application: The application entitled "Systems, Methods and Apparatus for Electronic Patient Care," U.S. patent application Ser. No. 13 / 333,574, filed December 21, 2011, having publication number US-2012-0179693-A1, published July 19, 2012, claims the benefit of priority to and is a continuation-in-part of the following application: 12-0185,267-A1 (Attorney Docket No. I97), which is a continuation-in-part of U.S. patent application Ser. No. 13 / 011,543, filed January 21, 2011, and entitled "Electronic Patient Monitoring System," which U.S. patent application Ser. No. 13 / 011,543 published December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544, filed January 22, 2010, and entitled "Electronic Order Brokerage System for Healthcare Facilities," which U.S. patent application Ser. No. 13 / 011,543 published December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52); and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties.

[0003] An application entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed March 15, 2013, U.S. patent application Ser. No. 13 / 836,497 (Attorney Docket No. K22), an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2012, PCT application Ser. No. PCT / US12 / 71131, which is a continuation-in-part of the application published July 27, 2013, bearing publication number WO2013 / 096718 (Attorney Docket No. J74WO), claims the benefit of priority to and the benefit of the following applications: Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05), entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011; U.S. Provisional Patent Application No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE; and U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR MONITORING, REGULATING OR CONTROLING FLUID FLOW, both of which are incorporated herein by reference in their entireties. The application entitled SYSTEMS, METHODS, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2012, PCT application PCT / US12 / 71131, published June 27, 2013, publication number WO2013 / 096718 (Attorney Docket No. J74WO), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is a continuation-in-part of U.S. Application No. 13 / 011,543, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM. is a continuation of U.S. patent application Ser. No. 13 / 011,543, which was published on December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544, entitled ELECTRONIC ORDER BROKERAGE SYSTEM FOR HEALTHCARE FACILITIES, filed on January 22, 2010 (Attorney Docket No. H53), all of which applications are incorporated herein by reference; and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties. U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), claims the benefit of priority to and is a continuation-in-part of U.S. patent application Ser. No. 13 / 724,568, filed December 21, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING FLUIDS DELIVERY (Attorney Docket No. J75), published July 18, 2013, having publication number US2013-0184676-A1, and U.S. patent application Ser. No. 13 / 724,568 claims the benefit of priority to and the benefit of the following applications: Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled "Systems, Methods, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow"; No. 61 / 651,322 (Attorney Docket No. J46), filed March 24, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, both of which are incorporated herein by reference in their entireties. The application entitled SYSTEMS, METHODS, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2012, U.S. patent application Ser. No. 13 / 724,568, published July 18, 2013, publication number US2013-0184676-A1 (Attorney Docket No. J75), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety. No. 13 / 333,574, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety in its entirety in its entirety. This application is a continuation-in-part of U.S. Patent Application No. 13 / 011,543, which was published on December 22, 2011, under Publication No. US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application No. 61 / 297,544, entitled "Electronic Order Brokerage System for Healthcare Facilities," filed on January 22, 2010 (Attorney Docket No. H53); and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties.

[0004] U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), claims the benefit of priority to and is a continuation-in-part of U.S. patent application Ser. No. 13 / 725,790, filed December 21, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR FLUID INJECTION, which was published on July 11, 2013, and has publication number US2013-0177455-A1 (Attorney Docket No. J76). U.S. patent application Ser. No. 13 / 725,790 claims the benefit of priority to and the benefit of the following applications: Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); An application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled "Systems, Methods, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow"; and U.S. Provisional Patent Application No. 61 / 651,322 (Attorney Docket No. J46), filed March 24, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, both of which are incorporated herein by reference in their entireties. The application entitled SYSTEMS, METHODS, AND APPARATUS FOR INJECTING FLUIDS, filed December 21, 2012, U.S. patent application Ser. No. 13 / 725,790, published July 11, 2013, publication number US2013-0177455-A1 (Attorney Docket No. J76), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety. No. 13 / 333,574, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety in its entirety in its entirety. This application is a continuation-in-part of U.S. Patent Application No. 13 / 011,543, which was published on December 22, 2011, under Publication No. US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application No. 61 / 297,544, entitled "Electronic Order Brokerage System for Healthcare Facilities," filed on January 22, 2010 (Attorney Docket No. H53); and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties.

[0005] U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), is also a continuation-in-part of PCT application Ser. No. PCT / US12 / 71490, filed December 21, 2012, entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUIDS (Attorney Docket No. J76WO), published June 27, 2013, having publication number WO2013 / 096909, and claims the benefit of priority to and the benefit of the following applications: an application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUIDS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled "Systems, Methods, and Apparatus for Monitoring, Regulating, or Controlling Fluid Flow"; No. 61 / 651,322 (Attorney Docket No. J46), filed March 24, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, which applications are incorporated herein by reference in their entireties. The application entitled SYSTEMS, METHODS, AND APPARATUS FOR INJECTING FLUIDS, PCT Application No. PCT / US12 / 71490, filed December 21, 2012, and published June 27, 2013, publication number WO2013 / 096909 (Attorney Docket No. J76), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is a continuation-in-part of U.S. Application No. 13 / 011,543, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM. is a continuation of U.S. patent application Ser. No. 13 / 011,543, which was published on December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544, entitled ELECTRONIC ORDER BROKERAGE SYSTEM FOR HEALTHCARE FACILITIES, filed on January 22, 2010 (Attorney Docket No. H53), all of which applications are incorporated herein by reference; and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties. U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013 (Attorney Docket No. K22), entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, claims the benefit of priority to and is a continuation-in-part of U.S. patent application Ser. No. 13 / 723,239, filed December 21, 2012 (Attorney Docket No. J77), entitled SYSTEM, METHOD AND APPARATUS FOR ELECTRONIC PATIENT CARE, which was published November 7, 2013, having publication number US2013-0297330-A1, and which claims the benefit of priority to and the benefit of the following applications: an application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUIDS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, entitled ELECTRONIC PATIENT CARE SYSTEM, METHODS, AND APPARATUS; and No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled SYSTEMS, METHODS, AND APPARATUS FOR MONITORING, REGULATING OR CONTROLLING FLUID FLOW, which application is incorporated herein by reference in its entirety. The application entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, U.S. Patent Application No. 13 / 723,239, filed December 21, 2012, and published November 7, 2013, having Publication No. US2013-0297330-A1 (Attorney Docket No. J77), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is a continuation-in-part of U.S. Application No. 13 / 011,543, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM. is a continuation of U.S. patent application Ser. No. 13 / 011,543, which was published on December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544, entitled ELECTRONIC ORDER BROKERAGE SYSTEM FOR HEALTHCARE FACILITIES, filed on January 22, 2010 (Attorney Docket No. H53), all of which applications are incorporated herein by reference; and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties.

[0006] U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), claims the benefit of priority to and is a continuation-in-part of U.S. patent application Ser. No. 13 / 723,242, filed December 21, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. J78), published November 28, 2013, having publication number US2013-0317753-A1, which claims the benefit of priority to and the benefit of the following applications: No. 61 / 651,322 (Attorney Docket No. J46), filed March 24, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, which applications are incorporated herein by reference in their entireties. An application entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013 (Attorney Docket No. K22), and entitled SYSTEM, METHOD AND APPARATUS FOR MONITORING, REGULATING OR CONTROLING FLUID FLOW, filed December 21, 2012, claims the benefit of priority to and is a continuation-in-part of U.S. patent application Ser. No. 13 / 723,244, published July 25, 2013 (Attorney Docket No. J79), publication number US2013-0188040-A1, which claims the benefit of priority to and the benefit of the following applications: an application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUIDS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); An application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); U.S. Provisional Patent Application, Ser. No. 61 / 651,322 (Attorney Docket No. J46), entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed on March 24, 2012; and and U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR MONITORING, REGULATING OR CONTROLING FLUID FLOW, both of which are incorporated herein by reference in their entireties. The application entitled SYSTEMS, METHODS AND APPARATUS FOR MONITORING, REGULATING OR CONTROLLING FLUID FLOW, filed December 21, 2012, U.S. Patent Application No. 13 / 723,244, published July 25, 2013, Publication No. US2013-0188040-A1 (Attorney Docket No. J79), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is a continuation-in-part of U.S. Application No. 13 / 011,543, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM. is a continuation of U.S. patent application Ser. No. 13 / 011,543, which was published on December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544, entitled ELECTRONIC ORDER BROKERAGE SYSTEM FOR HEALTHCARE FACILITIES, filed on January 22, 2010 (Attorney Docket No. H53), all of which applications are incorporated herein by reference; and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties. U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), is a continuation-in-part of an application entitled SYSTEMS, METHODS, AND APPARATUS FOR MONITORING, REGULATING, OR CONTROLLING FLUID FLOW, filed December 21, 2012, which claims the benefit of priority to and is a continuation-in-part of an application published July 27, 2013, having publication number WO2013 / 096722 (Attorney Docket No. J79WO), which claims the benefit of priority to and the benefit of the following applications: Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); U.S. Provisional Patent Application No. 61 / 651,322 (Attorney Docket No. J46), filed March 24, 2012, entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE; and U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR MONITORING, REGULATING OR CONTROLING FLUID FLOW, both of which are incorporated herein by reference in their entireties. The application entitled SYSTEMS, METHODS, AND APPARATUS FOR MONITORING, REGULATING OR CONTROLING FLUID FLOW, filed December 21, 2012, PCT Patent Application No. PCT / UIS12 / 71142, published June 27, 2013, publication number WO2013 / 096722 (Attorney Docket No. J79WO), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is a continuation-in-part of U.S. Application No. 13 / 011,543, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM. is a continuation of U.S. patent application Ser. No. 13 / 011,543, which was published on December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544, entitled ELECTRONIC ORDER BROKERAGE SYSTEM FOR HEALTHCARE FACILITIES, filed on January 22, 2010 (Attorney Docket No. H53), all of which applications are incorporated herein by reference; and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties.

[0007] U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), claims the benefit of priority to and is a continuation-in-part of an application filed December 21, 2012, entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING FLUIDS DELIVERY, U.S. patent application Ser. No. 13 / 723,251, published August 8, 2013, having publication number US2013-0204188-A1 (Attorney Docket No. J81), which claims the benefit of priority to and the benefit of the following applications: Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, entitled ELECTRONIC PATIENT CARE SYSTEM, METHODS, AND APPARATUS; and No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled SYSTEMS, METHODS, AND APPARATUS FOR MONITORING, REGULATING OR CONTROLLING FLUID FLOW, both of which are incorporated herein by reference in their entireties. An application entitled SYSTEMS, METHODS, AND APPARATUS FOR ESTIMATING FLUIDS DELIVERY, filed December 21, 2012, U.S. patent application Ser. No. 13 / 723,251, which claims the benefit of priority to and is a continuation-in-part of an application (Attorney Docket No. J81) published August 8, 2013, having Publication No. US2013-0204188-A1; an application entitled SYSTEMS, METHODS, AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed December 21, 2011, having Publication No. US2013-0204188-A1, U.S. patent application Ser. No. 13 / 333,574, which claims the benefit of priority to and is a continuation-in-part of an application (Attorney Docket No. J81) published July 19, 2012, having Publication No. US2013-0204188-A1; 12-0185,267-A1 (Attorney Docket No. I97), which is a continuation-in-part of U.S. patent application Ser. No. 13 / 011,543, filed January 21, 2011, and entitled "Electronic Patient Monitoring System," which U.S. patent application Ser. No. 13 / 011,543 published December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application Ser. No. 61 / 297,544, filed January 22, 2010, and entitled "Electronic Order Brokerage System for Healthcare Facilities," which U.S. patent application Ser. No. 13 / 011,543 published December 22, 2011, under publication number US-2011-0313789-A1 (Attorney Docket No. I52); and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties.

[0008] U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled "System and Apparatus for Electronic Patient Care," (Attorney Docket No. K22), is a PCT patent application Ser. No. PCT / US12 / 71112, filed December 21, 2012, and entitled "System, Method, and Apparatus for Estimating Fluid Delivery." is a continuation-in-part of the application published on June 27, 2013, having publication number WO 2013 / 096713 (Attorney Docket No. J81WO), application number PCT / US12 / 71112, which claims the benefit of priority to and the benefit of the following application: Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); U.S. Provisional Patent Application No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, entitled ELECTRONIC PATIENT CARE SYSTEMS, METHODS, AND APPARATUS; and U.S. Provisional Patent Application No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled SYSTEMS, METHODS, AND APPARATUS FOR MONITORING, REGULATING, OR CONTROLLING FLUID FLOW, which applications are incorporated herein by reference in their entireties. The application PCT / US12 / 71112, entitled SYSTEMS, METHODS, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2012, and published June 27, 2013, publication number WO 2013 / 096713 (Attorney Docket No. J81WO), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety. No. 13 / 333,574, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety in its entirety in its entirety. This application is a continuation-in-part of U.S. Patent Application No. 13 / 011,543, which was published on December 22, 2011, under Publication No. US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application No. 61 / 297,544, entitled "Electronic Order Brokerage System for Healthcare Facilities," filed on January 22, 2010 (Attorney Docket No. H53); and

[0009] PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties. U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. K22), claims the benefit of priority to and is a continuation-in-part of U.S. patent application Ser. No. 13 / 723,253, publication number US2013-0191513-A1 (Attorney Docket No. J85), filed December 21, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING FLUIDS DELIVERY, which claims the benefit of priority to and is a continuation-in-part of the following application: Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUID, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,649 (Attorney Docket No. J02); an application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,658 (Attorney Docket No. J04); an application entitled SYSTEM, METHOD, AND APPARATUS FOR PREPARING ORAL MEDICATIONS, filed December 21, 2011, U.S. Provisional Patent Application No. 61 / 578,674 (Attorney Docket No. J05); Application entitled ELECTRONIC PATIENT CARE SYSTEM, METHODS, AND APPARATUS, filed May 24, 2012, U.S. Provisional Patent Application No. 61 / 651,322 (Attorney Docket No. J46) 4); and No. 61 / 679,117 (Attorney Docket No. J30), filed August 3, 2012, entitled SYSTEMS, METHODS, AND APPARATUS FOR MONITORING, REGULATING OR CONTROLLING FLUID FLOW, which application is hereby incorporated by reference in its entirety. The application entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed December 21, 2012, U.S. Patent Application Serial No. 13 / 723,253, having Publication No. US2013-0191513-A1 (Attorney Docket No. J85), claims the benefit of priority to and is a continuation-in-part of the following application: No. 13 / 333,574, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety. No. 13 / 333,574, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM, published July 19, 2012, with U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97), which is incorporated herein by reference in its entirety in its entirety in its entirety. This application is a continuation-in-part of U.S. Patent Application No. 13 / 011,543, which was published on December 22, 2011, under Publication No. US-2011-0313789-A1 (Attorney Docket No. I52), which claims priority to U.S. Provisional Patent Application No. 61 / 297,544, entitled "Electronic Order Brokerage System for Healthcare Facilities," filed on January 22, 2010 (Attorney Docket No. H53); and PCT application No. PCT / US11 / 66588, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties.

[0010] U.S. patent application Ser. No. 13 / 836,497 (Attorney Docket No. K22), filed March 15, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, is also related to one or more of the following U.S. patent applications, each of which is incorporated by reference in its entirety: U.S. patent application Ser. No. 13 / 836,497, filed March 15, 2013, and entitled DEVICE FOR INJECTING FLUID (Attorney Docket No. K14); PCT application PCT / US13 / 32445, filed March 15, 2013, entitled "Apparatus for Injecting Fluids" (Attorney Docket No. K14WO); U.S. patent application Ser. No. 13 / 833,432, filed March 15, 2013, entitled "Injection Pump and Related Methods," published application under Publication No. US-2011-0281965-A1 (Attorney Docket No. K21); U.S. patent application Ser. No. 13 / 833,712, entitled SYSTEM, METHOD AND APPARATUS FOR CLAMPING, filed March 15, 2013, which application published October 17, 2013, under publication number US-2011-0272773-A1 (Attorney Docket No. K23); U.S. patent application Ser. No. 13 / 834,030, entitled SYSTEMS, METHODS AND APPARATUS FOR MONITORING, REGULATING OR CONTROLLING FLUID FLOW, filed March 15, 2013, and published November 21, 2013, under publication number US-2013-0310990-A1 (Attorney Docket No. K28); U.S. Provisional Patent Application No. 13 / 860,398, entitled SYSTEMS, METHODS AND APPARATUS FOR MICROWAVE AIR DETECTION, filed July 31, 2013 (Attorney Docket No. J31); U.S. Provisional Patent Application No. 61 / 740,474, entitled SYSTEM, METHOD AND APPARATUS FOR DATA COMMUNICATIONS, filed December 21, 2012 (Attorney Docket No. J80); U.S. Provisional Patent Application No. 61 / 900,431, entitled SYSTEMS, METHODS AND APPARATUS FOR MONITORING, REGULATING OR CONTROLING FLUID FLOW, filed November 6, 2013 (Attorney Docket No. K52); U.S. Provisional Patent Application No. 61 / 894,431 (Attorney Docket No. K88), entitled "Injection Pump and Related Methods," filed October 23, 2013; An application entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed May 23, 2013, U.S. Patent Application No. 13 / 900,655 (Attorney Docket No. K66); PCT application entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed May 23, 2013, Application No. PCT / US13 / 42350 (Attorney Docket No. K66WO); U.S. Provisional Patent Application No. 61 / 843,574, entitled SYSTEM, METHOD AND APPARATUS FOR CLAMPING, filed July 8, 2013 (Attorney Docket No. K75); U.S. patent application Ser. No. 13 / 971,258 (Attorney Docket No. K84), filed August 20, 2013, entitled ELECTRONIC PATIENT MONITORING SYSTEM; U.S. Provisional Patent Application No. 61 / 904,123, entitled "Injection Pump and Related Methods," filed November 14, 2013 (Attorney Docket No. L33); [Technical Field]

[0011] TECHNICAL FIELD This disclosure relates to patient care. More particularly, this disclosure relates to systems and devices for electronic patient care. Related literature references

[0012] Providing patient care in a hospital typically requires the interaction of numerous professionals and caregivers (e.g., physicians, nurses, pharmacists, technicians, nursing specialists, etc.) and numerous medical devices / systems necessary for the treatment of a given patient. Despite the existence of systems intended to facilitate the care process, incorporating electronic medical records ("EMRs") and computerized provider order entry ("CPOE"), the process of providing comprehensive care to patients, including ordering and administering therapeutic agents such as medications, presents numerous significant challenges.

[0013] Despite the existence of systems incorporating electronic medical records ("EMRs") and computerized provider order entry ("CPOE"), the process of ordering and administering treatment still leaves room for critical information to be miscommunicated, for treatment decisions to be made without ready access to complete information, and for treatment orders to be delayed due to unnecessary duplicative and inefficient procedures.

[0014] Medication errors may cause more than 300 deaths and more than 1 million injuries each year in the United States. Struggling hospitals may increase the incidence of medication errors. Medications associated with the most dangerous medication errors include insulin, narcotics, heparin, and chemotherapy drugs. Causes of errors include administering the wrong medication, prescribing the wrong strength of medication, administering it too frequently, or administering it by the wrong route (drugs can be administered orally, intravenously, intramuscularly, subcutaneously, rectally, topically on the skin, through the eye or ear, intrathecally, intraperitoneally, or even intravesically). Even with proper ordering and proper labeling, medications can still be administered inappropriately due to illegible handwriting, miscommunication of orders, and mispronunciation of medications with similar names. The increasing use of electronic medical records (EMRs) and drug barcode systems has been shown to reduce the occurrence of medication errors. EMR systems, for example, facilitate computerized provider order entry (CPOE) and can flag medication orders that are inconsistent with patient characteristics such as diagnosis, allergies, weight, age, etc. However, these systems are not widely adopted, which can result in significant delays and inefficiencies in medication ordering, dispensing, and administration.

[0015] It is estimated that drug infusion devices are involved in up to one-third of all medication errors resulting in serious harm. The wrong drug may be infused, incorrect parameters (e.g., drug concentration or infusion rate) may be entered, or existing infusion parameters may be inappropriately changed. Nearly half of infusion pump-related deaths are due to user error, and most of these can be attributed to programming errors in the infusion device.

[0016] An effective monitoring system should monitor and intervene during all phases of the medication ordering and administration process to minimize any of the many adverse events that may result from treatment. The medication process can be conceptually divided into three phases: the prescription phase, the medication preparation phase, and the administration phase. Errors can occur when a prescription is written or entered, when a medication is retrieved for use or mixed in solution, or when it is administered to a patient. It is particularly desirable for a monitoring system to not significantly impair the efficiency with which medications are ordered, prepared, or administered, and to actually reduce the time required to perform these activities by collecting, organizing, and presenting relevant information for analysis. Summary of the Invention

[0017] In one embodiment of the present disclosure, a system for electronic patient care includes a network, a facility gateway, a device gateway application, and a medical device. The facility gateway is configured to provide a publish-subscribe service for an application. The device gateway application is configured to be executed by the facility gateway. The device gateway is configured to communicate over the network by providing web services. The medical device is capable of operatively communicating with the network. The medical device is configured to communicate with the device gateway using web services.

[0018] The system further includes a publish-subscribe engine configured to provide a publish-subscribe service. The network may be a TCP / IP-based network. The device gateway application may be a web server for the web service, and the medical device is a client of the web service. The device gateway application is configured to record topics using the publish-subscribe service. The system includes an integration API configured to be executed by the facility gateway. The integration API is configured to subscribe to topics and communicate events received from subscribing to the topics to at least one external server.

[0019] The topic may be one or more reportable biomedical event topics and / or reportable clinical event topics. The topic may be a reportable biomedical event topic, and the device gateway may reformat the medical device events received via the web services into reportable biomedical events that can be received by subscribers via a publish-subscribe engine. The medical devices may communicate the medical device events over a network using web services. The topic may be a reportable clinical event topic, and the device gateway may reformat the medical device events received via the web services into reportable clinical events that can be received by subscribers to the topic via a publish-subscribe engine. The medical devices may communicate the medical device events over a network using web services.

[0020] The topic may correspond to at least one class of pump event, such as at least one of an infusion event related to an alarm, warning, or notification, an infusion event related to an infusion (hereinafter also referred to as an infusion or infusion), an infusion event related to programming, a device event related to communication, a device event related to an access request, a device event related to a configuration update, a device event related to logging, and / or a device event related to power consumption.

[0021] The system may further include a continuous quality improvement listener configured for execution by the facility gateway. The continuous quality improvement listener may subscribe to a reportable biomedical event topic and a reportable clinical event topic. The continuous quality improvement listener may be configured to communicate reportable biomedical events received by subscribing to the reportable biomedical event topic to an external database. The continuous quality improvement listener may be configured to communicate reportable clinical events received by subscribing to the reportable clinical event topic to an external database.

[0022] The external database may record at least one of reportable biomedical events and reportable clinical events.

[0023] The system may include a device manager executable on a facility gateway. The device manager may be configured to maintain a list of medical devices, including the medical device. The list of medical devices may include a list of serial numbers corresponding to the list of medical devices.

[0024] The system can include a monitoring client in operative communication with the medical device over a network to receive status information therefrom.

[0025] In another embodiment of the present disclosure, a medical device includes a network, a processor, a transceiver, and a device gateway communications manager, wherein the transceiver is in operative communication with the processor and is configured to communicate over the network. The device gateway communication manager is executable on the processor and configured to operatively communicate via the transceiver. The device gateway communication manager can be configured to communicate device events using web methods over the network. The device can be configured to send data to the monitoring device over the network.

[0026] The network may be a WiFi network and the transceiver may be a WiFi transceiver. In some embodiments, only the device is configured to initiate communications using web methods.

[0027] In yet another embodiment of the present disclosure, a system for electronic patient care includes a network, a facility gateway, a device gateway application, a device application, and a medical device. The facility gateway can be configured to provide a publish-subscribe service. The device gateway application may be configured to be executed by the facility gateway. The device gateway may be configured to communicate over a network by providing web services. The device gateway can publish a medical device event topic. The device application is configured to run on the facility gateway and is configured to subscribe to the medical device event topic. The device application can publish a CQI message topic. The device application can be configured to receive events by subscribing to the medical device event topic and to publish events as CQI messages through the CQI message topic. The medical device operatively communicates with the network. The medical device is configured to communicate with the device gateway using web services and to generate events using web methods of the web services.

[0028] The device gateway can subscribe to a CQI message topic to receive the CQI message. The system can further include a CQI listener configured to execute with the facility gateway. The CQI listener can subscribe to a CQI message topic to receive the CQI message. The CQI listener can communicate the CQI message to an external database. The CQI message can be a reportable biomedical event and / or a reportable clinical event.

[0029] The system may include a monitoring client configured to operatively communicate with the medical device, the monitoring client being able to communicate with the medical device by subscribing to a CQI message topic.

[0030] In another embodiment, a system for electronic patient care includes a server and a pump (e.g., an infusion pump or a syringe pump). The server contains patient-related information, including drug metabolism information. The pump is configured to use the drug metabolism information to regulate a flow of medication to the patient based on the patient-related information. The pump receives the patient-related information from the server.

[0031] In some embodiments, a system for electronic patient care includes a server and a pump. The server contains information related to the patient, including drug metabolism information. The pump is configured to adjust the flow of the drug to the patient based on the respective information associated with the patient using the drug metabolism information. The pump receives the patient-related information from the server. [Brief explanation of the drawings]

[0032] These and other aspects will become more apparent from the following detailed description of various embodiments of the present disclosure, taken in conjunction with the drawings.

[0033] [Figure 1] 1 illustrates a block diagram of a system for electronic patient care according to an embodiment of the present disclosure.

[0034] [Figure 2] 2 shows a block diagram of several aspects of the system of FIG. 1 according to an embodiment of the present disclosure.

[0035] [Figure 3] FIG. 1 illustrates a collection of several facilities for communication according to an embodiment of the present disclosure.

[0036] [Figure 4] FIG. 1 illustrates a system for electronic patient care according to an embodiment of the present disclosure.

[0037] [Figure 5] 1 illustrates a drug safety method used to generate a dose administration library file according to an embodiment of the present disclosure.

[0038] [Figure 6] 1 illustrates a method of injecting a drug according to one embodiment of the present disclosure.

[0039] [Figure 7] 1 illustrates a method for updating a medical device with software, firmware, and / or configuration files according to one embodiment of the present disclosure.

[0040] [Figure 8] FIG. 1 is a block diagram illustrating some aspects of communication between a medical device and a device application, according to one embodiment of the present disclosure.

[0041] [Figure 9] 1 is a state diagram illustrating a method for programming an infusion device according to one embodiment of the present disclosure.

[0042] [Figure 10] 1 illustrates a publish-subscribe model used by the facility gateway of FIG. 1 and the application and device gateways of FIGS. 2 and 4 according to one embodiment of the present disclosure.

[0043] [Figure 11] 1 illustrates a capability-registry model according to one embodiment of the present disclosure.

[0044] [Figure 12] FIG. 1 is a system block diagram illustrating communication between a medical device and a device gateway, according to one embodiment of the present disclosure.

[0045] [Figure 13] 10 illustrates a disclosure of a data structure for use in a web method for facilitating communication between the medical device and device gateway of FIG. 1, 2, or 4, according to one embodiment of the present disclosure.

[0046] [Figure 14] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway, according to one embodiment of the present disclosure.

[0047] [Figure 15] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform status and communication checks, according to one embodiment of the present disclosure.

[0048] [Figure 16] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to synchronize their respective clocks, according to one embodiment of the present disclosure.

[0049] [Figure 17] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform a patient fluid infusion transaction, according to an embodiment of the present disclosure.

[0050] [Figure 18] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform a patient instruction transaction, according to an embodiment of the present disclosure.

[0051] [Figure 19] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform a patient scalar data transaction, according to one embodiment of the present disclosure.

[0052] [Figure 20] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform a device information transaction sequence, according to one embodiment of the present disclosure.

[0053] [Figure 21] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform an alert notification transaction according to one embodiment of the present disclosure.

[0054] [Figure 22] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform a software package check transaction, according to one embodiment of the present disclosure.

[0055] [Figure 23] 10 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform a dose administration library configuration file check transaction, according to an embodiment of the present disclosure.

[0056] [Figure 24] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway for performing a service log post transaction, according to one embodiment of the present disclosure.

[0057] [Figure 25] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway to perform an engineering log post transaction, according to one embodiment of the present disclosure.

[0058] [Figure 26] 1 is a flowchart illustrating a method of communication between a medical device and a device gateway for performing an infusion log post transaction, according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

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

[0060] Facility 10 may be a hospital, a clinic, a medical facility, an outpatient care center, an urgent care center, or any combination or grouping thereof. Facility 10 may include a facility gateway 21 so that various medical devices 26 can communicate with facility IT applications / services 11 and / or cloud services 2. Facility 10 includes various medical devices 26 operated and used by nurses 9 who care for patients receiving care from facility 10. Medical devices 26 may be infusion pumps, peristaltic pumps, syringe pumps, physiological parameter monitors, other patient care devices, or any combination thereof.

[0061] The facility gateway 21 may reside on a host computer, may reside in the cloud, may be maintained for the facility 10 by a service provider, may be maintained or serviced by a combination of the service provider and / or facility's IT personnel 18, and / or may be implemented in a virtual or real environment. In some embodiments, the facility gateway 21 may be implemented on a device in a patient's home. The facility gateway 21 may be used in a hospital, nursing group, integrated delivery network ("IDN"), integrated service group or clinic, group of clinics, central clinic, or other medical care facility or infrastructure.

[0062] The biomed PC tool 20 can be used by biomed technicians 19 to update software on devices 26. The biomed PC tool 20 may be a browser-based tool for biomed users 19 to monitor the status of their medical devices 26, view log files, track maintenance activities, and manage software / firmware installations. Biomedical technicians 19 may be hospital employees (or contracted services) who install, upgrade, and service medical devices 26 to ensure they are in good working condition. The biomed PC tool 20 may interface with the medical devices 26 through a physical data connection, such as a USB connection or a serial cable connection, so that the biomed technician 19 can perform these services. The biomed technician 19 can also use the device manager 24 to wirelessly update the devices 26.

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

[0064] Devices 26 communicate with facility gateway 21 by establishing communication (e.g., via registration) with device gateway 22. Facility gateway 21 may be a computer, a virtual machine, a hardware device, a software device, a hosted device, running software, or a 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 medical devices 26 initiate communication with the device gateway 22 (and thus the facility gateway 21). The device gateway 22 can include a message routing engine that supports both publish / subscribe and point-to-point routing mechanisms. The device gateway 22 also provides name resolution and registry capabilities. Object-relational mapping can be used by the device gateway 22 for small object persistence (e.g., using an object-relational mapping (ORM) engine). Additionally or alternatively, the device manager 24 can provide name resolution and / or registry capabilities.

[0065] In some embodiments of the present disclosure, one of the devices 26 is a monitoring client, such as a tablet computer, tablet device, PDA, smartphone, laptop computer, or touchscreen-based computer. The monitoring client of the device 26 may have a monitoring client application within the device application 23, which allows a caregiver to communicate with the other devices of the device 26. The monitoring client can be used to receive status information from a medical device of the device 26, receive CQI-messages from a medical device of the device 26, receive RBEs or RCEs from a medical device of the device 26, program a medical device of the device 26, or otherwise communicate with a medical device of the device 26.

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

[0067] The Device Gateway 22 provides: (1) component registry and license management (e.g., using Device Manager 24); (2) an installation repository for receiving, maintaining, and tracking new versions of installable components, e.g., device firmware / software, medication administration libraries, enterprise application software, and infrastructure software (e.g., operating system releases, application servers, database management systems (“DBMSs”)); and / or (3) message routing capabilities, e.g., message distribution, both between applications within the Facility Gateway 21 and to and from external subsystems (e.g., Cloud Services 2).

[0068] A deployment environment in which the medical device 26 maintains an active network connection to the device gateway 22 is called a connected environment, and as described above This can be achieved using a wireless network (IEEE 802.11b / g / n), and as previously mentioned, in other embodiments, network connectivity can be achieved by other technologies, such as cellular.

[0069] An environment in which devices do not maintain wireless connectivity is referred to as a standard environment, despite the fact that enterprise application components and external subsystems are still connected. In this particular embodiment, device gateway 22 still performs all three roles of enterprise application components and external subsystems. Meanwhile, message exchanges involving device 26 can allow biomedical technician 19 (e.g., using biomedical PC tool 26) to save messages to an external media device (e.g., a memory stick).

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

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

[0072] In some embodiments, before a new one of the medical devices 26 is authorized for use by the device gateway 22, the biomed technician 19 must register the new device using its serial number. This can be verified using asymmetric key (public / private key pair) encryption and may be performed as part of the manufacturing process. Once a medical device is registered with the device gateway 22, the biomed technician 19 configures the wireless protocol and encryption. Once a medical device is registered with the device gateway 22, it reports its initial configuration, including model, options, and versions of hardware, firmware, and device control software, for storage within the device gateway 22 and / or device manager 24. Similarly, if a device is removed from the list of authorized devices in the device gateway 22, the biomed technician 19 can deregister it.

[0073] Each medical device 26 can perform a self-test upon startup and issue an event to the device gateway 22 that stores the results. Additionally, because medical devices 26 typically run for long periods of time between reboots, the medical devices 26 can automatically schedule certain self-diagnostic tests to run at times that will not interfere with patient safety and / or treatment.

[0074] Facility gateway 21 includes device apps 23 (described below) that can communicate data using a publish-subscribe data connection. Each device app in device apps 23 may be for a particular type and / or model of device in devices 26. These applications provide software information to medical devices by receiving, filtering, and analyzing raw events and retransmitting higher-level interpretations. Each type of medical device (in medical devices 26) has a corresponding device application (in device applications).

[0075] The facility gateway 21 also includes a device manager 24 for controlling, managing, or monitoring the devices 26. For example, the device manager 24 can be used to update and / or download configuration files to one of the devices 26. As previously described, the biomedical technician 19 can control software, firmware, or configuration file updates to the devices 26. The device manager 24 can provide browser-based tools for the IT administrator and / or technician 18 to monitor the status of hardware, software, and network resources used to support the delivery of patient care. That is, the facility gateway 21 may be managed by the facility IT personnel / contractor 18.

[0076] When a new Dose Administration Library ("DAL") version is released, A secure messaging link can send the DAL file from the DAL manager 5 to the device gateway 22 to notify the biomedical technician 19 of its availability. This notification specifies the device type, DAL location, documentation, release note URL, checksum, and installation dependencies. In some embodiments of the present disclosure, the device manager 24 has access to new DAL files, receives DAL files from the device gateway 22, receives DAL files directly from the DAL manager 5, and / or uses DAL files to control updates to medical devices 22.

[0077] In certain embodiments, the biomed technician 19 uses the release notes URL to access information about the upgrade (e.g., via the Device Manager 24 web page and / or Biomed PC Tools 20) and uses the installer URL and checksum to download, verify, and save the DAL file to a storage location on the device gateway 22. The biomed technician 19 then selects one or more medical devices 22 that have been notified (e.g., via the device gateway 22) that a new DAL file is available for them and copies the new DAL file. At the next reboot of the medical devices (of the medical devices 26 selected to be updated), the selected group of medical devices will install the new DAL version (backing it up in case of an error) and notify the device gateway 22 and / or device manager 24 of the results. Any of the procedures described herein for updating the DAL file can be used to update firmware, software, OS, or other configuration files of one of the medical devices 26.

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

[0079] The electronic medical record may contain drug metabolism data for a particular patient. This data may come from clinical tests, genetic tests, or feedback from patient care devices may be used to generate automated tests. The results of these tests may be used by medical pump 26 to adjust the amount of a particular drug given to the patient based on whether the drug is metabolized more rapidly or more slowly.

[0080] Facility IT apps / services 11 support hospital administrative functions (e.g., admission, discharge, transfer, coding, billing, collections, etc.). Unified API 25 separates the differences between applications 12-16 of facility IT apps 11 and applications 23-24, device gateway 22, and / or devices 26. For example, one of devices 26 can request programming information from device gateway 22 (or programming information may be pushed to one of devices 16). The patient ID, pump ID, medication, and flow rate may reside in one or more facility IT apps 11; the unified API 25 provides a common format for communicating this information to devices 26 regardless of the needs or desires of the facility IT apps 11. This information may be collected by the unified API 25, which queries various applications in the facility IT apps 11 to obtain data and provide it to the devices 26 in a standardized format. The unified API 25 provides a standard interface with applications 22-24 and / or devices 26, although it may be used by various facility IT apps 12-17 that have different formats, data standards, communication standards, encryption standards, etc.

[0081] The integration API 25 facilitates the automatic programming of one or more devices 26. The prescription can be sent from any one of the facility IT application 14 servers. The integration API 25 receives the prescription, reformats it, and sends it to the device gateway 22. The facility gateway 21 can include a clinical server that writes prescription events to a persistent cache. The clinical server can initiate an automatic programming workflow that identifies a medical device in the medical devices 26 corresponding to the target patient and can send a command message to each device in the medical devices 26 to write the prescription. Each medical device in medical devices 26 acknowledges receipt of the prescription and displays a notification on its display. The clinician can locate the medication bag and identify the medication and patient using the barcode reader on each medical device in medical devices 26. Each medical device in medical devices 26 can then verify that the medication matches the prescription, and the clinician initiates the infusion. Each medical device in medical devices 26 completes the automated programming workflow by sending a message to the clinical server via the device gateway.

[0082] A caregiver uses the UI to confirm programming of one of the medical devices 26. A clinician finds medications and uses the user interface of each medical device in the medical devices 26 to confirm automatic programming parameters for and / or manually program that medical device in the medical devices 26.

[0083] The PIS 16 is a departmental system used by pharmacists 8 to receive, verify, track, and fulfill prescription drug orders. The EMR 17 system tracks a patient's medical history at a healthcare facility (encounters, tests, diagnoses, procedures, etc.). The CPOE 14 is a system used by doctors and nurses 9 to order lab tests, prescription medications, medical images, and other clinical procedures. The LIS 15 is a departmental system used by laboratory technicians to receive and process clinical samples (e.g., tissue, blood, urine, etc.). The RTLS 12 tracks the location and status of medical devices 26. Other 13 may be any other databases used for patient care.

[0084] Cloud service 2 includes a cloud-hosted Infusion Safety Manager 3. ISM 3 includes a Continual Quality Improvement ("CQI") Manager 4 and a DAL Manager 5. Risk Officer 6, Nurse Manager 7, and Pharmacist 8 can all review CQI messages captured by CQI Manager 4 to facilitate the development of DAL files via DAL Manager 5. The DAL files can then be downloaded to one or more devices 26. DAL Manager 5 may include or be associated with a Medication Error Reduction System ("DERS") editor (e.g., DERS Editor 112 of FIG. 4, described below).

[0085] Figure 2 shows a block diagram of some aspects of the system of Figure 1, in accordance with an embodiment of the present disclosure, i.e., Figure 2 shows details of some aspects of Figure 1.

[0086] The device gateway 40, device manager 41 and integration API 65 are all part of the facility gateway 21 of FIG. The large volume app 44, the syringe pump app 54, and the other apps 42 are all applications that are part of the device apps 23 of FIG. The device manager 41 including its relational database 45 may be the device manager 24 of FIG.

[0087] A large volume pump ("LVP") app 44 is an application for the LVP 36. A syringe app 43 is an application for the syringe pump 38, and other applications 42 are applications for other devices 39. Other applications 42 and other devices 39 may correspond to any medical device.

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

[0089] The CQI listener 72 can subscribe to various data feeds from the applications 42, 43, 44 to report CQI messages to the CQI manager 29, which can store them in the database 30. The CQI listener 72 can report and / or format the raw results of the issued connections 49-57 and / or 58-64.

[0090] In some embodiments, the applications 42, 43, 44 reformat raw events from each of the devices 36-39 (received by subscribing to topics registered with the device gateway 40) into CQI-messages. The applications 42, 43, 44 may subscribe to CQI-topics subscribed to by the CQI listener 72. The applications 42, 43, 44 publish CQI-messages to these CQI-topics, which cause the CQI listener 72 to receive the CQI-messages. The CQI-listener 72 transmits the CQI-messages to the cloud service 28.

[0091] In one particular embodiment, a single GUI interface 33 may be used to view the CQI messages in the database 30 while creating the DAL files 35 for use by devices 36 , 37 , 38 , and 39 . The software update 34 may also be sent to the device gateway 40 to update the medical devices 36, 37, 38, and 39.

[0092] 3 illustrates a diagram 73 showing a collection of several facilities 76-80 for communication according to an embodiment of the present disclosure. Each of the several facilities 76-80 can include a facility gateway 21 (see FIG. 2) for communication with a cloud service such as an infusion safety manager 74. In some embodiments, some facilities 76-80 are part of a group of facilities that share a common infusion safety manager 74 that is not accessible to other facilities not in the group of facilities 76-80.

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

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

[0095] The cloud service 83 includes databases 104, 105, 106, and 113, a firewall 103, a CQI receiver 108, a CQI server 109, a CQI UI 110, and a DERS editor 112. Pharmacies and clinicians 111 can interface with the DERS editor 111 and / or the CQI UI 110. Safety staff 107 can interface with the CQI UI 110. The DERS editor 112 and / or the CQI UI 110 may be browser-based interfaces.

[0096] The HIS 84 supports hospital administrative functions (e.g., admission, discharge, transfer, coding, billing, collections). The EMR 85 tracks a patient's medical history at the healthcare facility (encounters, tests, diagnoses, procedures, etc.). The CPOE 86 is a system used by physicians to order lab tests, prescription drugs, medical images, and other clinical procedures. The PIS 97 is a departmental system used by pharmacists to receive, verify, track, and complete prescription drug orders. The LIS 88 is a departmental system used by laboratory technicians to receive and process orders for clinical samples (e.g., tissue, blood, urine, etc.). The hospital integration engine 89 provides message translation capabilities that allow information systems 84-88 to interact with each other and with external systems. Most of these engines map between different dialects of HL7. The integration engine can be deployed in a device gateway 99 to interoperate with the HIS, EMR, and PIS through the hospital integration engine 89. The device gateway 99 provides a message routing engine and supports both publish / subscribe and point-to-point routing mechanisms. The device gateway 99 also provides name resolution and capability registry functions.

[0097] Various devices 101 are used to treat patients, such as infusion devices that provide medication, nutrition, and hydration in liquid form to patients via intravenous (IV) or subcutaneous routes. Pump application 96 and syringe application 97 are applications that provide software intelligence to medical device 101 by receiving, filtering, and analyzing raw events and retransmitting a higher level interpretation. Each type of medical device in device 101 can have a corresponding device application, e.g., any of applications 96-97.

[0098] Each infusion device in device 101 may be used to deliver a specific infusion (liquid hydration, nutrition, blood, or medication) to a specific patient in a controlled manner. Each preparation for administration in the form of a loading or bolus or dose titration can be considered a separate infusion step within a parent infusion. The totality of infusions for the same patient as part of the same treatment can be considered an "infusion story," which can be recorded by CQI server 109.

[0099] An infusion can be organized into a setup phase, a programming phase, and a delivery phase. During the setup phase, the clinician verifies the infusate, the patient, and the pump, and connects tubing from the infusate to the pump and from the pump to the patient, which can be recorded by the CQI server 109. During the programming phase, the clinician enters administration parameters into the pump, which the pump verifies using the installed DAL version (which may also be recorded by the CQI server 109). During the delivery phase, the pump delivers the specified volume of infusate at the programmed rate.

[0100] Each medical device 101 can detect alarm conditions (i.e., a situation where the pump is not infusing) and warning and advisory conditions that may or may not be critical to safety. Each medical device 101 can attempt to establish a secure network connection to the device gateway 99. Each medical device 101 can collect programming, delivery status, and exception events for its respective infusion and provide them to the device gateway 99 so that they can be reported as CQI messages to the CQI receiver 108. Each medical device 101 can communicate these events to the device gateway 99, which then sends this data to the CQI receiver 108 (directly or indirectly). In some embodiments, if a medical device 101 cannot establish or maintain an operational connection with the device gateway 99, the medical device can store these events in an internal buffer and allow the biomedical technician 102 to copy them to portable media (e.g., a memory stick) with or without the biomedical application 94. In some embodiments, these events can be downloaded via a biomedical application running on a personal computer that has a USB cable connected to the medical device.

[0101] The biomed app 94 provides biomed users 102 with browser-based tools to monitor the health of their medical devices 101, review log files, track the status of maintenance activities, and manage software / firmware installations. Log files, maintenance logs, and software / firmware installation and update tracking data may be stored in database 95.

[0102] The device gateway 99 may be ancillary equipment that connects all of the devices 101 associated with a particular patient. In other embodiments, the device gateway 99 is a software application executable on a facility gateway. In yet other embodiments, the device gateway 99 is software executable on a bedside device (e.g., a compact computer). The device gateway 99 may also 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 in the medical device 101, including sensors coupled to certain medical devices (see "Other" 37 in FIG. 2 ) (e.g., a respiratory monitor coupled to a PCA), can be used to publish data via the gateway device 99. The device applications 96-97 can act as "information refiners." Each device application 96-97 subscribes to messages for a particular type of bedside device in the medical device 101 via the gateway device 99. Each device application 96-97 can synthesize CQI, clinical, and biomedical information from event streams received from one or more medical devices 101 via the gateway device 99. In some embodiments, each device application 96-97 re-publishes these higher-level events to other subscribers, such as the device gateway 99 or the CQI listener 93.

[0103] In some embodiments, some of the CQI messages can be used for auto-documentation, auto-programming and billing functions. In some further embodiments, the CQI messages may be used for automated documentation from the medical device 101 to the EMR 85 and / or automated programming of the medical device 101 from an eMAR system (e.g., part of the HIS 84). The CQI messages may include medication safety events and potential information.

[0104] The CQI Listener 93 registers for events related to continuous quality improvement in medication safety and ensures reliable delivery to a hosted environment. The CQI listener 93 can store events in a database 98 for periodic transmission to a CQI receiver 108 (through a firewall 103).

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

[0106] The CQI server 109 provides analysis and query services to users of the CQI UI 110. The CQI server 109 may provide users of the CQI UI 110 with a full summary of CQI messages and updated summary tables (at configurable intervals). The purpose of these summary tables is to reduce response times to top-level CQI queries. These summaries can cover the following statistical measures: (1) program mode used, such as DERS limits vs. infusion using wildcards; (2) soft and hard limit violations; (3) titration safety information, such as titration up / down settings and dose limit violations; (4) reportable clinical events by priority level (e.g., RCE149 in Figure 8, described below); and / or (5) reportable clinical events by infusion phase (e.g., RCE149 in Figure 8, described below). Each of these summaries can calculate its subtotals for the following data observations: (1) organization name, (2) institution name (e.g., facility name), (3) care area, (4) time of day, and / or (5) week.

[0107] The web service query API may be used to enable the CQI UI 110 and / or DERS editor 112 to select: (1) summary totals for each data observation, filtered by specified selectors, as described above; (2) RCE details by infusion; and / or (3) actual programming, patient restrictions, and infusion statistics (i.e., infusion story). In some specific embodiments, the DERS editor 112 and / or any of the host services 83 systems may be based on a J2EE-compliant application server. The databases 104, 105, 106, and 113 may use a database management server.

[0108] Once the J2EE and database management servers are installed and configured, the following shared database tables may be imported to perform the initialization of the DERS database 113: (1) Reference tables, e.g., units of measure, method of administration, etc.; (2) Access control tables, roles, privileges and permissions for administrative users; (3) DERS medication list; (4) NDNQI care group list; (5) institution attributes; and / or (6) database tables required by the DERS editor 112. The DERS editor 112 can be used to add or edit organizations, add or edit regions, and / or add or edit access controls (each with or without attributes).

[0109] In one embodiment, the DERS editor 112 and / or DERS database may run in a single application server and database environment for multiple facilities 82. In yet other embodiments, each institution 82 may be hosted and / or in its own virtual environment (e.g., Cloud Services 2).

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

[0111] CQI messages are received by the CQI receiver 108, which stores them in database 105. If the CQI receiver 108 cannot process all of the incoming CQI messages at a given rate and / or the buffers of the CQI receiver 108 are full, the CQI messages are temporarily stored in database 104, which is accessed by the CQI receiver 108 for storage in database 105 when the CQI receiver is unloaded. Database 105 may be replicated by database 106. Database 106 is accessible to a user via the CQI server 109 using either a CQI user interface 110 and / or a DERS editor 112.

[0112] The records in the CQI databases 105, 106 depend on the DERS editor 112. The records include: (1) lookup tables, e.g., units of measure, methods of administration, etc.; (2) access control tables for administrative users, roles, privileges, and permissions; (3) DERS medication lists; (4) NDNQI care group lists; and (5) institutional attributes.

[0113] Since these references depend on the DERS editor database 112 version, consistency is preferred. One option is to share tables between the databases 113, 105, 106. This option is convenient but increases deployment coupling between the two databases 113 and 105, 106. Alternatively, coupling can be reduced by maintaining read-only copies of these tables in the CQI databases 105, 106, with a procedure to update them whenever changes occur in the DERS editor 112.

[0114] The access controls for the CQI databases 105, 106 are similar in structure to the DERS database 113 but may differ in content. Some users may be defined for the CQI server 109 but not in the DERS editor 112. Even for those users who appear in both, permissions may differ (e.g., some CQI data is read-only).

[0115] Certain database tables (eg, clinical events and statistical summaries to be reported) are required by the CQI databases 105, 106 and are set up when the CQI databases 105, 106 are created.

[0116] The CQI UI 110 and / or DERS editor 112 use data from the CQI server 109 (and thus data from database 106 ) and data from the DERS editor 112 (and thus database 113 ), respectively, to generate the DAL file 114 .

[0117] The Clinical State Manager 91 is the intermediary between the Device Gateway 99 and the Integration Engine 89, orchestrating asynchronous workflows involving several actors and components.

[0118] Pharmacists and selected clinicians 111 use the DERS editor 112 to define dosing limits for an institution and create a DAL file 114 (which may be in XML format). Dosing limits can be defined through a well-defined, carefully controlled, and well-documented process, such as controlled release procedures. Dosing limits can be specified using the DERS editor 112 in the DAL manager 5. The facility 82 can use a common reference model of drugs, care areas, administration methods, etc. to facilitate subsequent inter-institutional comparisons. The DERS editor 112 can run in the hosted environment 83, so users access it using a web browser. In some embodiments, no client-side software other than a sufficient browser is required to run the DERS editor 112. The DERS editor 112 can provide dosing limits and default values ​​organized by care area, drug, clinical use, and drug concentration. The DERS editor 112 can support a query interface to the CQI server 109 to integrate search and analysis of CQI findings for the improvement of the next DAL version.

[0119] 5 illustrates a medication safety method 115 used to generate a DAL file according to an embodiment of the present disclosure. Method 115 can be used with system 1 of FIG. 1, system 27 of FIG. 2, system 81 of FIG. 4, or any other electronic patient care system.

[0120] Participants from the pharmaceutical and clinical care domains (e.g., users selected from 6, 7, 8, 9, 18, and 19 in FIG. 1 or 102, 107, 111 in FIG. 4) may be selected to help create and define DAL files 35 (see FIG. 2), including safety rules for drug infusions that can take into account drug type, clinical care domain, method of administration (e.g., volume-based, rate-based, or weight-based, administration strategy (loading, bolus, ramp), etc.).

[0121] Method 115 includes acts 116 and 117. Act 116 includes acts 118-125 as sub-acts, and act 117 includes acts 126-127 as sub-acts. Act 116 generates the DAL file, and act 117 monitors the use of the DAL file to update DAL file 35 (see FIG. 2).

[0122] Act 122 sets up a DAL file, for example, an initial DAL file or template DAL file with no field entries. Act 123 receives changes to the DAL file according to entries from one of the selected users (e.g., via GUI interface 112 of FIG. 4). Act 112 reviews the DAL file, for example, by running a medical device simulator via GUI interface 112 of FIG. After review during act 112, the pilot DAL file is released (electronically) in act 120. Act 118 approves the pilot DAL file; however, adjustments may be made to the DAL after the pilot is complete. Act 118 can be performed by clicking an "Approve" button on a web browser to approve the use of the referenced file (e.g., referenced by version number, creation date, etc.).

[0123] In act 119, the DAL file is released and sent to the medical device in act 127. In act 125, the CQI server imports reference data (e.g., medication, care area, administration method, etc.) from the DAL file. Upon release of the DAL, the file containing the administration record is released to both the hospital and CQI environments. A biomedical technician installs the DAL on each infusion device after release in act 119. In act 126 , the medical device transmits the CQI event to the CQI receiver 108 .

[0124] During the infusion, the medical device generates CQI events (ie, CQI messages). The CQI message may include information on when a normal infusion occurs, when the infusion bypasses the DERS check, when a soft limit is exceeded and is overridden, and / or when a soft or hard limit is exceeded and the dose is reprogrammed, among other things.

[0125] CQI events are sent to the CQI server, which collects and stores them, in act 126. Safety personnel can run reports summarizing 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 for administration record improvement in the next release of DAL, in act 124. That is, CQI messages are analyzed and reviewed, in act 124. Changes to the DAL file can be made in act 123 to create a new version of the DAL file.

[0126] 6 illustrates a method 128 for infusing medication according to an embodiment of the present disclosure. Method 128 includes acts 129, 131, 133, 134, and 135. Method 128 may be used with system 1 of FIG. 1, system 27 of FIG. 2, system 81 of FIG. 4, or any other electronic patient care system.

[0127] In act 129, a physician writes an electronic prescription. The order is entered into CPOE 130, which transmits it electronically to the pharmacy. In act 131, a pharmacist reviews the order, evaluates drug interactions and drug supply, and either fills the prescription or modifies the prescription (e.g., in consultation with the physician). Also in act 131, the prescription is completed and the order is submitted to PIS 132. In act 133, the prescription is fulfilled. This can be done by, but is not limited to, the following methods: Using pre-prepared compounds with the drug already at the desired concentration; A pharmacist compounds the desired dosage and strength at the pharmacy; and / or a clinician (e.g., nurse) compounds the desired dosage and strength at the patient's bedside.

[0128] The dose is then administered to the patient in act 134. In inpatient settings (hospitals and nursing homes), a clinician typically administers the dose. In outpatient or home settings, administration may be performed by a clinician, the patient's family, or the patient themselves. Medication safety procedures strive to ensure that the "right patient," "right drug," "right dose," "right time," and "right route" tests are met. This can be accomplished in a variety of ways, including by a bedside point-of-care system, by barcoding the patient and drug, and / or using automated programming. The documented record is submitted to a record-keeping system in act 135. The document is provided to an EMR system in act 135 to update the patient's chart.

[0129] 7 illustrates a method 137 for updating a medical device's software, firmware, and / or configuration files according to an embodiment of the present invention. Method 137 includes acts 138-143. Method 137 may be used with system 1 of FIG. 1, system 27 of FIG. 2, system 81 of FIG. 4, or any other electronic patient care system.

[0130] In act 138, the biomedical technician 19 (see FIG. 1) installs software, firmware, or configuration files on the medical device (e.g., for the first time) and / or in act 140, the biomedical technician 19 updates software, firmware, or configuration files on the medical device. In act 139, the medical device is configured or reconfigured. Acts 138, 139 and / or 140 may be performed wirelessly or via a physical connection between the biomedical tool 20 (see FIG. 1) and the medical device.

[0131] Biomedical engineer 19 can perform act 138 and / or act 140 . In act 141, the medical device is monitored (eg, via CQI messages, etc.). In some embodiments, the biomedical technician 19 can copy the CQI event file from the infusion device to a portable memory stick, which can then be uploaded to the CQI. Act 141 may be used to perform the following: Identify when devices need preventative maintenance; Certify whether the medical device needs to download software, firmware, configuration files, and other updates and upgrades; Upload device log files; and / or perform other diagnostic and maintenance tasks.

[0132] Act 141 monitors a medical device (e.g., wirelessly). Act 142 determines if a problem has been detected with the medical device. The problem may be, for example, that the medical device is not operating within predetermined parameters, that the medical device has detected an internal error, and / or that the medical device has outdated software, firmware, or configuration files. In act 143, the medical device is repaired in response to the problem identified with the medical device.

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

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

[0135] Event 146 may be an event as shown in Table 1 as follows: [Table 1-1] [Table 1-2] [Table 1-3] [Table 1-4]

[0136] Listed in Table 1 as items 1, 2, 3, 4, 5, 6, 7, 8, and 9 are pump event classes. When the medical device 145 is not connected to the device gateway 147, these events are stored in a local memory buffer on the medical device 145. When connected (and reconnected), these events are published to the device gateway 147 using a secure protocol, such as SSL, SSH, symmetric key encryption, and / or asymmetric key encryption. As previously mentioned, the device gateway 147 can function as (or may include) a publish-subscribe engine configured to distribute pump events to interested subscribers.

[0137] Referring again to FIG. 1 , pump events may be sent to the CQI manager 4 related to device events for the devices 26. These events can be used to monitor a fleet of medical devices 26 across many facilities 10. For example, the Device Hardware Status Array 9.71 may be converted into a CQI message and communicated to the CQI manager 4. A user logs into the CQI manager 4 to schedule maintenance events, order new parts based on the data, provide predictive or preventive maintenance, and / or order new parts for preventative or predictive reasons. A user may use deterministic heuristics to determine what to order, when to order, and / or when to flag for maintenance certain devices 26 in various facilities 10. The CQI manager 4 can be used for supply chain management of parts for the fleet of medical devices 26 and can provide real-time information on the status of all devices in the fleet of medical devices 26. For example, the device hardware status array may contain battery information such as the current draw at full charge, indicating the health of the internal battery. For all devices 26 or a subset of devices 26 in some facilities, the CQI manager 4 can automatically order new batteries if the battery condition falls below a predetermined threshold. Additionally or alternatively, the CQI manager 4 may schedule automatic battery replacement in those identified ones of the devices 26 .

[0138] Referring again to FIG. 8, device applications 151 (e.g., a pump application configured to operate a pump) may run on device gateway 147 (although in some embodiments, these may be different hardware and / or software). The device application 151 subscribes to events published by the medical device 145 .

[0139] The pump application 151 processes the raw event stream and prepares it into a higher level clinical event stream, such as clinical events 149 to be reported to and stored on a hosted cloud service server (e.g., database 30 in FIG. 2).

[0140] In some embodiments of the present disclosure, 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. When a message becomes available, the device gateway 147's application server can activate the device application 151 on a worker thread.

[0141] The device application 151 is a stateful component and contains one instance of a pump handler 153 for each pump 145 located at each facility. A pump dispatcher 152 maintains a lookup table of pump handlers 153 using the serial number of the pump 145 as a unique key.

[0142] The pump MDB uses the application server's naming service to access the pump application 151. It gets the pump 145 serial number from the message header and uses the pump dispatcher 152 to find the appropriate pump handler among the pump handlers 153. If a respective pump handler in pump handlers 153 is busy (processing another message, pending another thread, etc.), the pump MDB queues the message for pump dispatcher 152 (to ensure messages are processed in order). If a respective pump handler in pump handlers 153 is idle, the pump MDB requests that respective pump handler in pump handlers 153 to process an event. Each pump handler in pump handlers 153 maintains a set of finite state machines ("FSMs"), including pump FSM 156, program FSM 157, and delivery FSM 158, that process an associated subset of pump events (see Table 1 above).

[0143] Pump FSM 156 is a top-level state machine that handles events not belonging to any infusion. Program FSM 157 is a child state machine that is invoked when an infusion programming context is initiated and is responsible for handling infusion programming events. Delivery FSM 158 is a child state machine that is invoked when an infusion delivery is initiated and is responsible for handling operational events during the infusion. Separate programming FSMs 157 and delivery FSMs 158 can be used to program secondary infusions (including loads, boluses, or titrations) while a primary infusion is in progress. An operational model of a medical device 145, such as the pump FSM 156, can be used to construct reportable clinical events (RCEs) and reportable biomedical events (RBEs). For example, the pump FSM 156 may track when the pump 145 completes one infusion and returns to another infusion that was interrupted; track the programming of one infusion while another infusion is running; and / or track multiple high-priority operational alarms that may occur at one time. That is, the pump 156 FSM may include a nested state model.

[0144] Each pump handler in the group of pump handlers 153 may also maintain several context objects to hold programming and delivery context information. These context objects are generated as biomedical events (for tracking pump usage) upon completion and are retained for recovery if the pump application 151 needs to be restarted. Context objects may include infusion states, infusion modes, and infusion segments. An infusion state contains programming / delivery state data for primary and secondary infusions. An infusion mode contains programming / delivery state data for a specific dose / rate (e.g., load, bolus, and / or titrate). An infusion segment contains the delivery state for a period of operation within an infusion mode (e.g., pump running, stopped, in alarm state, etc.). Upon processing a pump event 146, each FSM 156, 157, or 158 may transition to a new state, create, update, or delete context objects, and output a reportable event (CQI message), such as a reportable biomedical event 148 or a reportable clinical event 149. In a specific embodiment of the present disclosure, a list of reportable clinical events is shown in Table 2 below. [Table 2-1] [Table 2-2] [Table 2-3]

[0145] 4 and 8, the CQI listener 93 in FIG. 4 can move within each facility 82, connect to a device gateway (99 in FIG. 4 or 147 in FIG. 8), and register with a CQI RCE 149 or a CQI RBE 148. The CQI listener 93 of Figure 4 can establish a secure private connection to the CQI receiver 108 in the host environment 83 (see Figure 4). This connection can be physical (continuously connected) or logical (temporary connection while transmitting a message).

[0146] The device gateway 147 can route the RCEs 149 or RBEs 148 to the CQI listener 93. The CQI listener 93 can ensure message durability (i.e., messages are not lost during transmission due to network congestion or outages). As a result, the CQI listener 93 can: (1) store each message to be sent in a local persistent queue (for buffering); (2) send each of the RCEs 149 and / or RBEs 148 from the head of the queue to the CQI receiver 108; and / or (3) delete messages after receiving an acknowledgement from the CQI receiver 108.

[0147] The CQI receiver 108 operates within the host environment 83. The CQI receiver 108 listens for and receives requests for secure network connections from one or more CQI listeners 93. The CQI receiver 108 receives an RCE 149 from each connected CQI listener 93. The CQI receiver 108 may verify message durability and therefore write each RCE 149 to the database 105 upon receipt. The CQI receiver 108 (1) stores each received message (CQI message) in a local queue (for buffering); (2) adds each CQI message from the top of the queue to a table in the CQI event database 105; (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 (since it resides securely in the CQI event database 105).

[0148] As previously mentioned, the CQI event database 105 is implemented using master-slave replication. That is, database 105 is the master and database 106 is the slave. In some specific embodiments, with this approach, there are two copies of the CQI event database with identical schema. As insert, update, and delete transactions are applied to the master database 105, the database management system (DBMS) in database 105 can write changes to a journal and send any outstanding changes to the slave database 106.

[0149] Each CQI message (e.g., RCE) may belong to a particular institution. The institution's criteria should match those of the institution that operates the medical device and released the Drug Administration Library (DAL) located on that device (e.g., one of the medical devices 101 in FIG. 4 or medical device 145 in FIG. 8). As a result, the CQI databases 105, 106 will need a list of institutions that match the DERS database 113.

[0150] 9 is a state diagram illustrating a method 161 for programming an infusion device (such as that of device 16 of FIG. 1) according to an embodiment of the present disclosure. Method 161 begins with a user being able to interface with the equipment's UI.

[0151] Infusion programming begins at the state shown as the state labeled "Start." State 162 is when basic mode programming is used (e.g., when a DERS compliance exception device is used). After programming using the DERS compliance exception device, the method moves to state 165 where dose programming is complete.

[0152] State 166 is when DERS-based protection is used and dose parameters are programmed into the device; if no limit violation is detected, method 161 transitions to state 165. If a soft or hard limit violation is detected, method 161 transitions to state 167. If it is a soft limit, the clinician can either (1) ignore the software limit, so that the method continues to state 165; program the infusion attributes without changing the infusion intent, and either continue to state 165 if no new violations are found, or proceed to state 165 if new violations are discovered; or (3) change the infusion intent (drug, clinical care area, clinical use, and / or concentration), so that method 161 restarts at state 166.

[0153] If a hard limit is detected, the method transitions from state 166 to state 167, in which case the state must re-transition back to state 166 and the clinician cannot ignore the DERS violation.

[0154] The infusion method 161 may be canceled in a number of situations: In Basic Mode Programming state 162, the clinician can abort the infusion before programming is complete; In DERS Programming state 166, the clinician can abort the infusion before programming is complete. At state 167, if a DERS soft or hard limit violation is detected, the clinician can cancel the infusion 4.

[0155] While in state 165, the medical device presents a "start infusion" button that the caregiver can press to transition the medical device to state 163 where the infusion begins. In state 163, a pause button is present on the user interface that, when pressed, pauses the device, thereby transitioning it to state 164. In state 164, a continue button is present on the user interface that, when pressed, returns the device to state 163, allowing therapy to continue. If a fatal error (a predetermined set of errors) is detected in states 163 and / or 164, method 161 transitions to the end state.

[0156] Once the infusion is complete, the pump sends an infusion completion message to the clinical server via the device gateway. The clinical server links the completion event to the prescription record. The clinical server formats an IHE AutoDocument message to update the patient's electronic medical record (EMR) 17 and / or update the hospital's billing system to record the successful infusion of the medication, and sends it to one of the IT apps 11 (see Figure 1) for recording in, for example, the electronic medical management record ("eMar").

[0157] FIG. 10 illustrates a publish-subscribe model 168 used by the facility gateway 21 of FIG. 1, and by the applications 41, 42, 43, 44 and device gateway 40 of FIG. 2 or FIG. 4, according to an embodiment of the present disclosure.

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

[0159] A publisher in publishers 171 can subscribe to one or more topics 170, where each topic may be a unique topic. One or more subscribers 172 can subscribe to one or more topics to receive events from them. When publisher 171 posts an event to a unique topic (e.g., "topic 1") in topics 170, all subscribers to topic 170 receive the event; non-subscribers who are not subscribed to topic 170 do not receive the event; subscribers 172 who are subscribed to other topics in topic 170 (e.g., topic 2) but not to topic 170 do not receive the event sent corresponding only to topic 170.

[0160] In some embodiments, topics 170 may provide a level of indirection that allows publishers 171 and subscribers 172 to remain anonymous. The publish-subscribe engine 169 can allow communication to be one-way and asynchronous (e.g., "fire and forget"). The publish-subscribe engine 169 can provide durable message delivery on both sides. Durable topics in topics 170 can ensure that messages are not lost if the publish-subscribe engine 169 fails. Durable subscriptions used by subscribers 172 can ensure that subscribers 172 do not miss messages when it is not running.

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

[0162] 11 illustrates a capability-registry model 173 according to an embodiment of the present disclosure. A provider 176 registers its capabilities 175 in a capability registry 174. A capability 174 can have two aspects, including an interface and an attribute. An interface is a list of request / response pairs and notifications (in both directions). Attributes are service level agreement parameters that specify constraints on the quality of delivery (e.g., response time, error rate and recovery policy, cost, etc.).

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

[0164] FIG. 12 shows a block diagram of a system 178 to illustrate communication between a medical device 179 and a device gateway 185 according to an embodiment of the present disclosure. The medical device 179 may utilize a device gateway communications manager (“DGCM”) 342 to communicate with the device gateway 185 . The communication can be based on web services, where the medical device 179 is the client and the device gateway 185 is a web server using HTTPS communication transport.

[0165] Communications take the form of transactions in which the medical device 179 invokes web methods hosted on a device gateway 185 (e.g., medical device gateway). The medical device may use a WiFi connection 182 to communicate with the device gateway 185 using a WiFi router 183 connected to a network 184 that is coupled to the device gateway 185 via an Ethernet connection 186. In a particular embodiment, TCP / IP provides the transport protocol over the network 184. SOAP provides an HTTP-compliant messaging format, and SSL provides the encryption / authentication necessary for secure communications (HTTPS). Within the medical device 179 software, a communications manager manages the client side of the web services communications.

[0166] The Communications Manager communicates with the device gateway 185 by invoking one of the web methods hosted on the device gateway 185 using SOAP messaging and SSL over HTTPS. This can use the SOAP binding 187 for the software language used to implement the interface. Additionally, the SOAP binding 187 may have SSL capabilities to provide secure communication over HTTPS. A Web Services Description Language ("WSDL") is created that defines the web service operations (web methods 195) and the necessary schema for the device gateway 185's web server. WSDL files may be created for the web methods 195 and the data types used. Using the WSDL and the SOAP provider's utility tools, a SOAP client source code file is generated and added to the Communications Manager software. For the Communications Manager to successfully initiate a transaction with the device gateway 185, the following may be used / set up: (1) OpenSSL179 installed on medical device185 (2) the hostname and IP port of the device gateway 185 are stored in a data structure 192; (3) a public certificate data structure 193 for the device gateway 185 exists on the medical device 179; and (4) the private key and public certificate 194 for the medical device 170 exist on the medical device 179.

[0167] The device gateway 185 is configured as a web server and hosts web methods 195 that remote devices (e.g., medical devices 179) access to get information from or send information to the device gateway 185. HTTPS is used for secure communication, so the device gateway can use SOAP and SSL interfaces 187. A WSDL file can be created that defines the web service operations (e.g., web methods 195) and the data types required by the web server. A WSDL file is created for the web methods 195 and the required data types. Using the WSDL and SOAP provider's utility tools, a SOAP server source code file is generated and added to the device gateway 185 software to facilitate providing gateway functionality 188. For the device gateway 185 to process transactions from medical devices 179, the following may be used / set up: (1) OpenSSL installed on Device Gateway 185 187 (or equivalent software), and the device gateway 185 can provide a communication port 189 and a network connection 191; (2) the public certificate of the medical device 179 may reside on the device gateway 185 in the data structure 190, and / or (3) the private key and public certificate of the device gateway 185 reside on the device gateway 185 in the data structure 190.

[0168] The web service implementation defines a communication interface between the medical device 179 and the device gateway 179 to establish communication and exchange information. This communication is in the form of a transaction initiated by invoking a web method 195 hosted on the device gateway 185 . Four web methods are used to pass information between the medical device 179 (using the DGCM 342) and the device gateway 185. Web methods are hosted on the device gateway 185 and are invoked by the DGCM 342 to initiate information exchange transactions with the device gateway 185. Each web method can be used for a specific type of information moving, as identified in Table 3. In one specific embodiment, a list of these transactions and associated web methods is shown in Table 3 below. [Table 3]

[0169] The Communication Status Check transaction is used to register a medical device 179 with the device gateway 185, maintain communication with the device gateway 185, and obtain status regarding available information the device gateway 185 maintains for the medical device 179. The Patient Infusion Program Check, Patient Instructions Check, Patient Scalar Data Check, Device Information Check, Alert Notification Check, Debian Software Package Check, and DAL Configuration File Check transactions are used to obtain available device gateway 185 information qualified within a previous communication status check response from the device gateway 185. The Service Log File Post and Engineering Log File Post transactions are used to send log files to the device gateway 185, identified within a previous communication status check response from the device gateway 185. The Infusion Log Information Post transaction to the device gateway 185 is initiated whenever an infusion log event available in the medical device 179 has not been sent to the device gateway 185. Files can be transferred between the medical device 179 and the device gateway as a DIME attachment to a SOAP message. The Time Information Check transaction is used to obtain the time on the device gateway 185 for time synchronization.

[0170] Web methods 184 are used to get information from and pass information to the device gateway 185 . The web methods 184 are listed in Table 4 along with their C-style prototypes. [Table 4]

[0171] In some embodiments, each passed parameter may be a data structure or an int (i.e., an integer data type in the C language). In other embodiments, any data type may be passed. The data structure declaration is shown in Figure 13. All data structure member pointers (except for device_Image_T199, which is a data structure required by the gSOAP implementation) are null-terminated strings. The parameter list in a web method includes one or more parameters (see Figure 12) for passing information to the device gateway 185 and one parameter for receiving information from the device gateway 185. Parameters for passing information can be by value, by reference, or a pointer. Parameters for receiving information are always last in the parameter list and are of the referenced data type (&dataType). Even if the web method does not have any information to return, a receive parameter is still required. For example, device_infusionSendTransaction(..., int&result) and device_fileSendTransaction(...,int&result) use "&result" to meet this requirement.

[0172] Each web method has a return value that allows the initiator to identify the status of the transaction completion. An example set of return values ​​is provided in Table 5 as follows: [Table 5]

[0173] Referring again to FIG. 13, the member pointers of device_Header_T197 are shown and set forth in Table 6 below. [Table 6]

[0174] The member pointers of device_InternalStatus_T198 are shown and set forth in Table 7 below. [Table 7]

[0175] 12-13, the device_ClientRequest_T 200 identifies the type of information that the communications manager of the medical device 179 requests from the device gateway 185. In one particular embodiment, a request using the device_ClientRequest_T 200 is shown and set forth in Table 8 below. [Table 8]

[0176] device_GatewayResponse_T201 provides the device gateway's 185 response to a received request. Exemplary embodiments of states (eg, char*state_ptr) and their descriptions are shown in Table 9 below. [Table 9]

[0177] Char*payload_ptr provides the information requested by the medical device 179 via the device's 179 communications manager.

[0178] The device_FileData_T 203 identifies the type of file being sent to the device gateway 185. Exemplary embodiments of file types and their descriptions are shown in Table 10 below. [Table 10]

[0179] The device_FileResponse_T 204 provides the device gateway 184's response to a received request. Exemplary embodiments of its states and their descriptions are shown in Table 11 below. [Table 11]

[0180] The char*filename_ptr identifies the file that was transferred to the device gateway communications manager 342. The char*payload_ptr of device_InfusionData_T 202 provides the injection log information as XML to the device gateway 185. The payload is organized as an XML element, with a root element and child elements.

[0181] 14 is a flowchart illustrating a method 205 for communication between a medical device and a device gateway according to an embodiment of the present disclosure. That is, method 205 is a general transaction sequence between a medical device (using a DGM) and a device gateway. Method 205 can be used in the manner shown in Figures 15-26 to perform each transaction.

[0182] Generally, a transaction consists of the medical device's DGCM 342 invoking a web method hosted on the device gateway, which establishes an HTTPS connection with the device gateway. During connection establishment, authentication occurs between the medical device and gateway device using asymmetric encryption to establish a secure / trusted relationship. Once authentication occurs, an SSL session is established, and the two endpoints create a common key and use symmetric encryption to pass data. The transaction is processed, information is returned, and the HTTPS connection is closed. Up to three transaction retries are performed before a successful transaction is achieved. Figure 14 illustrates one specific embodiment, i.e., method 205, of this transaction.

[0183] Method 205 includes acts 206 through 232. The method is entered at act 206. Act 207 initiates gateway authentication of the device and requests credentials. A socket connection is established at act 223. In act 224, the device gateway receives the request and sends the public certificate to the medical device. In act 208, the medical device validates the public certificate by comparing it with a local copy. In act 209, the medical device requests that the device gateway prove its identity by encrypting data (e.g., predetermined data such as the device gateway's serial number or ID number). The data is then sent from the medical device to the device gateway.

[0184] The device gateway then encrypts a message (e.g., the device gateway's serial number or ID) using its private key during act 225 and sends the encrypted message to the medical device. In act 210, the message is decrypted using the device gateway's public certificate.

[0185] Act 226 begins medical device authentication by requesting a public certificate, which is received by the medical device, which sends it to the device gateway in act 211. In act 227, the device gateway validates the public certificate by comparing it with a local copy. In act 228, the device gateway requests that the medical device prove its identity by encrypting some data (e.g., predetermined data such as the medical device's serial number or ID number).

[0186] In act 212, the medical device encrypts data (e.g., predetermined data). The encrypted data is sent to the device gateway, which decrypts the data in act 229. In act 230, the device gateway determines whether the medical device is authenticated, and in act 213, the medical device determines whether the device gateway is authenticated. If both parties are authenticated, act 214 establishes a session key. If the device gateway cannot authenticate the medical device in act 230, the transaction is terminated in act 231. If the medical device cannot authenticate the device gateway, the medical device attempts authentication up to three times (see 219), and the transaction is deemed to have failed in act 220 after three attempts.

[0187] After the SSL session is established in act 214, the medical device uses the SSL symmetric encryption key to format a transaction (e.g., a web method) and send the transaction to the device gateway in act 215. Act 232 receives the web method, processes the web method, formats a response, and then decrypts the web method. Act 232 encrypts the response (e.g., a return value) to be sent to the medical device. The medical device decrypts the response and examines the return value in act 216. In act 217, the medical device determines if the return value corresponds to a successful transaction and declares the transaction successful in act 218. If the transaction is not successful, act 217 initiates another attempt via act 219.

[0188] 15 is a flow chart illustrating a method 233 of communication between a medical device and a device gateway to perform a status and communication check, according to an embodiment of the present disclosure. The communication status check transaction is periodically initiated by the DGCM 342 to establish communication with the device gateway (going from disconnected to connected), maintain communication with the device gateway (going from connected to disconnected), and obtain status information about the available information the device gateway has for the medical device.

[0189] Method 233 includes acts 234-238 and 240-241. Act 234 initiates a status check every 60 seconds. Act 234 receives a status check request (e.g., received by DGCM 342). Act 236 sends the request and establishes an HTTPS connection in act 241. Table 239 shows an access list of medical devices that can access the device gateway.

[0190] In act 240, the device gateway determines whether the medical device is on the access list 239 and formulates a response containing information available for the medical device. The response is sent to the medical device, which checks it in act 237.

[0191] If the medical device is not a member of the device access list 248, the device gateway sets the response status to "REJECTED." If the information is not available to the medical device, the device gateway sets the available information to NONE, otherwise Set the appropriate elements in the XML-based response payload to the values ​​in Table 12, as follows: [Table 12]

[0192] 16 is a flow chart illustrating a method 242 of communication between a medical device and a device gateway to synchronize their respective clocks, according to an embodiment of the present disclosure. The method 242 periodically performs a time synchronization transaction by the DGCM of the medical device to obtain the current date and time of the device gateway. That information is used to update the real-time clock of the medical device so that it matches the real-time clock of the device gateway.

[0193] Act 243 periodically (e.g., every 90 minutes) makes a "time" request, which is formatted as a web method in act 245, which communicates it to the device gateway by establishing an HTTPS connection in act 250. In act 249, a response is formatted that includes a payload indicating the device gateway's time. If the medical device is not a member of the device gateway's access list 248, the state is set to "REJECTED" otherwise it is set to "AVAILABLE." If the state is set to "Available", the device gateway formats the response payload as the number of seconds since January 1, 1970. The device gateway communicates the response over an HTTPS connection that is closed after transmission in act 247. Act 246 verifies the response with the device gateway.

[0194] 17 is a flow chart illustrating a method 251 of communication between a medical device and a device gateway to perform a patient infusion transaction according to an embodiment of the present disclosure. A patient infusion program check transaction performed as method 215 is initiated to obtain available patient infusion programs from the device gateway. The patient infusion program may be one or more infusion parameters, such as flow rate, delivered dose, medication to be infused, etc. The transaction is initiated whenever an "injection available" is received from a previous communication status check transaction, which triggers the start of method 251.

[0195] Act 252 receives a trigger. Act 253 initiates a "program" request that is formatted into a web method in act 254. The web method is sent to the device gateway over an HTTPS connection that is established in act 259. Act 258 processes the web method and formats a response. If the medical device is not part of the access list 257, the device gateway sets the response status to "REJECTED." If a patient infusion program is not available on the medical device, the status is set to "NONE", otherwise it is set to "AVAILABLE". The infusion program may be part of the payload or may reference a text-based infusion program. The response is sent to the medical device which checks the transaction response in act 255. After the response is sent, act 256 closes the HTTPS connection.

[0196] 18 is a flow chart illustrating a method 260 of communication between a medical device and a device gateway to perform a patient instructions transaction in accordance with an embodiment of the present disclosure. This Patient Instructions Check transaction is initiated from the device gateway to obtain available patient instructions. The transaction (shown as method 260) is initiated whenever "INSTRUCTIONS AVAILABLE" is received from a previous Communication Status Check transaction (see, e.g., FIG. 15).

[0197] In act 261, method 260 is initiated. In act 262, a patient instruction query request is initiated, and in act 263, a web method is formatted and sent to the device gateway using an HTTPS connection that is established in act 268. In act 267, the device gateway formats a response to be sent to the medical device. If the medical device is not a member of the device gateway's access list 266, the state is set to "REJECTED." If the medical device is part of the device gateway's access list 266 and patient instructions are not available, the state is set to "NONE." If the medical device is part of the device gateway's access list 266 and patient instructions are available, the state is set to "AVAILABLE," and the device gateway formats a response payload to include the reference or text-based patient instructions. After the response is sent, the HTTPS connection is closed in act 265, and the response is inspected in act 264.

[0198] FIG. 19 is a flow chart illustrating a method 269 of communication between a medical device and a device gateway to perform patient scalar data transactions according to an embodiment of the present disclosure. The Check Patient Scalar Data transaction (performed by method 269) is initiated by a medical device to obtain available patient scalar data from the device gateway. The transaction is initiated whenever available data has been received from a previous Check Communication Status transaction.

[0199] Method 269 begins in act 270. In act 271, a request is initiated, which in act 272 is formatted as a web method. The web method is communicated from the medical device to the device gateway via the HTTPS connection established in act 277. The device gateway formats a response to act 276. If the medical device is not a member of the device gateway's device access list 275, the status is set to "Rejected." If the medical device is a member of the device gateway's device access list 275 and patient-related scalar data is unavailable, the status is set to "NONE." If the medical device is a member of the device gateway's device access list 275 and patient-related scalar data is available, the status is set to AVAILABLE and the response payload includes or references text-based scalar data. Patient scalar data may be any data associated with the patient, such as the patient's age, weight, allergies, gender, height, etc. The response is sent, and the HTTPS connection is closed in act 274. In act 273, the medical device checks (e.g., processes and uses) the response.

[0200] 20 is a flow chart illustrating a method 278 of communication between a medical device and a device gateway to perform a device information transaction sequence according to one embodiment of the present disclosure. A device information check transaction (implemented as act 278) is initiated to obtain available device information from the device gateway. The transaction is initiated whenever a "device available" is received from a previous communication status check transaction.

[0201] In act 279, method 278 is initiated. In act 280, a device information query request is initiated, and in act 281, a web method is formatted. The web method is communicated to the device gateway over the HTTPS connection established in act 286. In act 285, a response is formatted. If the medical device is not a member of the device gateway's device access list 275, the state is set to "REJECTED." If the medical device is a member of the device gateway's device access list 275 and device information is unavailable, the state is set to "NONE." If the medical device is a member of the device gateway's device access list 275 and device information is available, the state is set to "AVAILABLE," and the response payload includes or references text-based device information. In some embodiments, the text-based device information may be any information related to the device gateway or the medical device. The response is communicated to the medical device, and the HTTPS connection is terminated in act 283. In act 282, the medical device checks the response.

[0202] 21 is a flow chart illustrating a method 287 of communication between a medical device and a device gateway to perform an alert notification transaction according to one embodiment of the present disclosure. The alert notification check transaction (implemented by method 287) is initiated to obtain an available alert notification from the device gateway. The transaction is initiated whenever a "notification available" is received from a previous communication status check transaction.

[0203] At act 288, method 287 begins. At act 289, an alert notification query request is initiated, and at act 295, a web method is formatted. The web method is communicated to the device gateway via the established HTTPS connection at act 295. At act 294, a response is formatted. If the medical device is not a member of the device gateway's access list 275, the state is set to "REJECTED." If the medical device is a member of the device gateway's access list 275, and alert notifications are not available, the state is set to "NONE." If the medical device is a member of the device gateway's access list 275, and alert notifications are available, the state is set to "AVAILABLE," and the response payload includes or references a text-based alert notification. In some embodiments, the text-based alert notification may be any information related to the device gateway or medical device alert. The response is communicated to the medical device and the HTTPS connection is terminated in act 295. In act 291, the medical device examines the response.

[0204] 22 is a flow chart illustrating a method 296 of communication between a medical device and a device gateway performing a software package check (e.g., Debian software package) transaction (implemented as method 296) according to an embodiment of the present disclosure. The software package check transaction is initiated to obtain available software packages from the device gateway. The transaction is initiated whenever available software has been received from a previous communication status check transaction.

[0205] Act 297 initiates method 269. Act 298 initiates a request which in act 299 is formatted as a web method. The web method is communicated from the medical device to the device gateway via an HTTPS connection established in act 304. The device gateway formats a response in act 303. If the medical device is not a member of the device gateway's access list 275, the state is set to "REJECTED." If the medical device is a member of the device gateway's access list 275 and the software package is not available, the state is set to "NONE." If the medical device is a member of the device gateway's access list 275 and the software package is available, the state is set to "AVAILABLE" and the response payload includes (or references) the software package file (e.g., using DIME). The response is communicated and the HTTPS connection is closed in act 301. In act 300, the medical device checks the response (e.g., process and use).

[0206] 23 is a flowchart illustrating a method 305 of communication between a medical device and a device gateway to perform a DAL Configuration File Check transaction according to an embodiment of the present disclosure. The DAL Configuration File Check transaction (implemented as act 305) is initiated to obtain an available DAL file from the device gateway. The transaction is initiated whenever an available DAL file is received from a previous Communication Status Check transaction.

[0207] Act 306 begins method 305. A request is initiated in act 306, and the request is formatted as a web method in act 308. The medical device communicates the web method to the device gateway by establishing an HTTPS connection in act 313. In act 312, a response is formatted. If the medical device is not a member of the device gateway's device access list 275, the state is set to "REJECTED." Otherwise, it is set to "AVAILABLE." If the status is set to AVAILABLE, the device gateway formats the response payload to include the DAL configuration file (which may be attached using DIME). The response is communicated to the medical device, which terminates the HTTPS connection in act 310. Act 309 inspects the response by the device gateway. The new DAL file can then be installed on the medical device.

[0208] 24 is a flow chart illustrating a method 314 of communication between a medical device and a device gateway to perform a service log post transaction according to an embodiment of the present disclosure. The service log post transaction (performed as act 314) is initiated to send a service log to the device gateway. The transaction is initiated whenever a service log request (SERVICELOG REQUEST) is received from a previous communication status check transaction.

[0209] Act 315 receives a trigger and initiates method 314. Act 316 initiates a post service log that is formatted into a web method in act 317. The web method is sent to the device gateway over the established HTTPS connection in act 322. Act 321 processes the web method and formats a response. The device gateway writes the information to a log file or communicates the service log post as a CQI message and sends it (as described above) to the cloud service. The response is communicated to the medical device, which inspects the transaction response in act 317 (e.g., by examining the return value to determine if it was a successful service log post). Act 319 closes the HTTPS connection after the response is sent.

[0210] 25 is a flow chart illustrating a method 232 of communication between a medical device and a device gateway to perform an Engineering Log Post transaction according to an embodiment of the present disclosure. The Engineering Log Post transaction is initiated to send an engineering log to the device gateway. The transaction is initiated whenever an Engineering Log (ENGINEERINGLOG) request is received from a previous Communication Status Check transaction.

[0211] Act 324 receives a trigger and starts method 323. Act 325 initiates a post engineering log that is formatted into a web method in act 326. The web method is sent to the device gateway over the established HTTPS connection in act 331. Act 330 processes the web method and formats a response. If the medical device is an authorized medical device as indicated by access list 239, the device gateway may write the information to a log file or communicate the service log post as a CQI message and send it to the cloud service (as described above). The response is communicated to the medical device, which inspects the transaction response in act 327 (e.g., by examining the return value to determine if it was a successful engineering log post). Act 328 closes the HTTPS connection after the response is sent.

[0212] 26 is a flow chart illustrating a method 332 of communication between a medical device and a device gateway to perform an infusion log post transaction according to an embodiment of the present disclosure. The infusion log post transaction (performed as act 332) is initiated to send XML-formatted infusion event information to the device gateway. The transaction is initiated whenever infusion event information is available that has not been previously sent to the device manager. If the transaction is successful, the DGCM 342 marks the record as delivered.

[0213] Act 333 receives a trigger and starts method 332. Act 334 initiates the injection log post, which is formatted into a web method in act 335. The web method is sent to the device gateway over an HTTPS connection, which is established in act 340. Act 339 processes the web method and formats a response. The device gateway may write the information to a log file or communicate the injection log post as a CQI message and send it to a cloud service (as described above). The response is communicated to the medical device, which inspects the transaction response in act 336 (e.g., by examining the return value to determine if it was a successful injection log post). Act 337 closes the HTTPS connection after the response is sent.

[0214] Various alternatives and modifications can be devised by those skilled in the art without departing from the present disclosure. Accordingly, the present disclosure is intended to embrace all such alternatives, modifications, and variations. Moreover, while several embodiments of the present disclosure are shown in the drawings and / or described herein, they are not intended to be limiting, and as such, the present disclosure is to be accorded the broadest scope permitted by the art, and the specification is to be interpreted accordingly. Therefore, the above description should not be construed as limiting, but merely as an exemplification of particular embodiments. Moreover, those skilled in the art will envision other modifications that fall within the scope and spirit of the appended claims. Other elements, steps, methods, and techniques that differ in nonessential features from those described above and / or in the appended claims are also understood to be within the scope of this disclosure.

[0215] The embodiments shown in the drawings are presented only to demonstrate certain examples of the present disclosure, and the drawings described are illustrative only and are not limiting. In the drawings, the size of some of the elements may be exaggerated and not drawn to particular scale for illustrative purposes. Furthermore, elements shown in the drawings having the same numbering may be the same element or, depending on the context, may be similar elements.

[0216] Where the term "comprising" is used in the present description and claims, it does not exclude other elements or steps. Where an indefinite or definite article is used when referring to a singular noun, e.g., "a," "an," or "the," this includes the plural of that noun unless specifically stated otherwise. Thus, the term "comprises" should not be interpreted as limiting the list to the items listed thereafter. It does not exclude other elements or steps, and the scope of the expression "a device comprising products A and B" should not be limited to a device consisting only of components A and B. In the context of the present invention, this expression means that the only relevant components of the device are A and B.

[0217] Furthermore, the terms "first," "second," "third," etc., whether used in the specification or the claims, are used to distinguish between similar elements and are not necessarily intended to describe a sequential or chronological order. It is understood that terms so used (unless expressly disclosed otherwise) are interchangeable under appropriate circumstances, and that the disclosed embodiments described herein are capable of operation in other orders and / or arrangements other than those described or illustrated herein. A first aspect of the present invention is 1. A system for electronic patient care, comprising: network, a facility gateway configured to provide publish-subscribe services for applications; a device gateway application configured to be executed by a facility gateway, the device gateway configured to communicate over a network by providing web services; and A system for electronic patient care comprising a medical device capable of operatively communicating with a network, the medical device configured to communicate with a device gateway using web services. A second aspect of the present invention is The system of the first aspect, further configured to provide a publish-and-subscribe service. The system includes a publish-subscribe engine. A third aspect of the present invention is The system of the first aspect, wherein the network is a TCP / IP-based network. A fourth aspect of the present invention is 10. The system of the first aspect, wherein the device gateway application is a web server for a web service and the medical device is a client for the web service. A fifth aspect of the present invention is 10. The system of claim 1, wherein the device gateway application is configured to record topics using a publish-subscribe service. A sixth aspect of the present invention is A system of a fifth aspect, further comprising an integration API configured to be executed by the facility gateway, the integration API configured to subscribe to a topic and communicate events received by subscribing to the topic to at least one external server. A seventh aspect of the present invention is A system according to a sixth aspect, wherein the topic is at least one of a reportable biomedical event topic and a reportable clinical event topic. An eighth aspect of the present invention is A system of a fifth aspect, wherein the topic is a reportable biomedical event topic, and the device gateway reformats the medical device events received via a web service into reportable biomedical events that can be received by topic subscribers via a publish-subscribe engine. A ninth aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to an eighth aspect, wherein the medical device communicates medical device events over a network using web services. A tenth aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system of a fifth aspect, wherein the topic is a reportable clinical event topic, and the device gateway reformats the medical device events received via web services into reportable clinical events that can be received by a subscriber to the topic via a publish-subscribe engine. An eleventh aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to a tenth aspect, wherein the medical device communicates medical device events over a network using web services. A twelfth aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to a fifth aspect, wherein the topic corresponds to at least one class of pump events. A thirteenth aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system of a twelfth aspect, wherein the at least one class of pump events includes at least one of an infusion event related to an alarm, warning or notification, an infusion event related to infusion, an infusion event related to programming, a device event related to communication, a device event related to an access request, a device event related to setting updates, a device event related to logging, and / or a device event related to power consumption. A fourteenth aspect of the present invention is a method for manufacturing a semiconductor device comprising: The system of the first aspect, further comprising a continuous quality improvement oriented listener configured for execution by the facility gateway; the continuous quality improvement oriented listener subscribes to a reportable biomedical event topic and a reportable clinical event topic; The continuous quality improvement organization is configured to communicate reportable biomedical events received by subscribing to a reportable biomedical event topic to an external database; and the continuous quality improvement organization is configured to communicate to an external database reportable clinical events received by subscribing to a reportable clinical event topic; The system is as described above. A fifteenth aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to a fourteenth aspect, wherein the external database records at least one of reportable biomedical events and reportable clinical events. A sixteenth aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system of the first aspect, further comprising a device manager executable on the facility gateway, the device manager configured to maintain a list of medical devices including the medical device. A seventeenth aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to a sixteenth aspect, wherein the list of medical devices includes a list of serial numbers corresponding to the list of medical devices. An eighteenth aspect of the present invention is a method for manufacturing a semiconductor device comprising: The system of the first aspect, further comprising a monitoring client in operative communication with the medical device over a network to receive status information therefrom. A nineteenth aspect of the present invention is a method for producing a medicament for a medicament comprising: A medical device comprising: network, processor, a transceiver in operative communication with the processor and configured to communicate over the network; and The medical device comprises a device gateway communications manager executable on a processor and configured to operatively communicate via a transceiver, the device gateway communications manager configured to communicate device events using web methods over a network. A twentieth aspect of the present invention is a method for manufacturing a semiconductor device comprising: The device of a nineteenth aspect, wherein the network is a WiFi network. A 21st aspect of the present invention is a method for manufacturing a semiconductor device comprising: A device according to a nineteenth aspect, wherein the transceiver is a WiFi transceiver. A 22nd aspect of the present invention is a method for manufacturing a semiconductor device comprising: The device of a nineteenth aspect, wherein only the device is configured to initiate communication using web methods. A 23rd aspect of the present invention is a method for manufacturing a semiconductor device comprising: The device of a nineteenth aspect, wherein the device is configured to transmit data to a monitoring device over a network. A 24th aspect of the present invention is a method for manufacturing a semiconductor device comprising: 1. A system for electronic patient care, comprising: network, a facility gateway configured to provide a publish-subscribe service; a device gateway application configured to be executed by a facility gateway, the device gateway configured to communicate over a network by providing web services, the device gateway publishing a medical device event topic; a device application configured to execute on the facility gateway and configured to subscribe to a medical device event topic, the device application publishing a CQI message topic, the device application configured to receive events by subscribing to the medical device event topic and to publish the events as CQI messages through the CQI message topic; and A system for electronic patient care comprising a medical device in operative communication with a network, the medical device configured to communicate with a device gateway using web services and to generate events using web methods of the web services. A 25th aspect of the present invention is a method for manufacturing a semiconductor device comprising: 24. The system of claim 23, wherein the device gateway subscribes to a CQI message topic to receive CQI messages. A 26th aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to a twenty-fifth aspect, further comprising a CQI listener configured to be executed by the facility gateway, the CQI listener subscribing to a CQI message topic to receive CQI messages. A 27th aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to a twenty-sixth aspect, wherein the CQI listener communicates the CQI message to an external database. A 28th aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to a twenty-fourth aspect, wherein the CQI message is one of a reportable biomedical event and a reportable clinical event. A 29th aspect of the present invention is a method for producing a medicament for use in a pharmaceutical composition comprising: The system of a twenty-fourth aspect further includes a monitoring client configured to operatively communicate with the medical device. A 30th aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system according to a twenty-ninth aspect, wherein the monitoring client communicates with the medical device by subscribing to a CQI message topic. A 31st aspect of the present invention is a method for manufacturing a semiconductor device comprising: 1. A system for electronic patient care, comprising: a server containing patient-related information including drug metabolism information; and The system includes a pump configured to use drug metabolism information to regulate the flow of drug to the patient based on information related to the patient, the pump receiving the patient-related information from the server. A 32nd aspect of the present invention is a method for manufacturing a semiconductor device comprising: All novel features of the system for electronic patient care that are described, referenced, illustrated, or shown in this specification, claims, or drawings are expressly construed as including all novel features of the system for electronic patient care.

Claims

1. 1. A system for electronic patient care comprising a facility gateway, the facility gateway comprising: Publication subscription services, providing a device gateway application configured to provide a web service configured for the publish-subscribe service; system.

2. the device gateway application is configured for a web server of the web service; The system of claim 1 .

3. the device gateway application is configured to subscribe to a topic using the publish-subscribe service; The system of claim 1 .

4. the facility gateway is adapted to execute an API adapted to subscribe to the topic and communicate communications regarding the topic to a server; The system of claim 3 .

5. the topic is a reportable biomedical event topic and / or a reportable clinical event topic; The system of claim 3 .

6. the topic is a reportable biomedical event topic, and the device gateway is configured to reformat medical device events received via the web service into reportable biomedical events that can be received by subscribers to the topic via a publish-subscribe engine. The system of claim 3 .

7. further comprising a medical device configured to communicate with the device gateway and the medical device events using the web services. The system of claim 6.

8. the topic is a reportable clinical event topic, and the device gateway is configured to reformat medical device events received via the web service into reportable clinical events that can be received by subscribers to the topic via a publish-subscribe engine. The system of claim 3 .

9. further comprising a medical device configured to communicate with the device gateway and the medical device events using the web services. The system of claim 8.

10. the topic corresponds to a class of pump event; The system of claim 3.

11. Classes of pump events include infusion events related to alarms, warnings or notifications, infusion events related to infusions, infusion events related to programming, device events related to communications, device events related to access requests, device events related to setting updates, device events related to logging, and / or device events related to power consumption; The system of claim 10.

12. The facility gateway is configured for a continuous quality improvement oriented listener, and the continuous quality improvement oriented listener comprises: Submit a reportable biomedical event topic and / or a reportable clinical event topic; communicating reportable biomedical events received via the reportable biomedical event topic to an external database; configured to communicate reportable clinical events received via the reportable clinical events topic to an external database. The system of claim 1 .

13. a medical device configured to communicate with the device gateway and generate the event on the topic; The system of claim 3 .

14. a medical monitoring client adapted to subscribe to a CQI message topic; The system of claim 13.

15. 1. A system for electronic patient care comprising a facility gateway, the facility gateway comprising: Publication subscription services, a device gateway application configured to provide web services and publish medical device event topics; configuring a device application, the device application comprising: Subscribing to the medical device event topic and defining the registration; Publish a CQI message topic; Receiving an event from said registration application; publishing the event as a CQI message through the CQI message topic; system.

16. the device gateway is configured to subscribe to the CQI message topic; The system of claim 15.

17. the device gateway is configured for a CQI listener configured to subscribe to the CQI message topic; 16. The system of claim 15.

18. the CQI listener is configured to communicate the CQI message to an external database; 20. The system of claim 17.

19. the CQI message is a reportable biomedical event and / or a reportable clinical event; 16. The system of claim 15.

20. a medical device configured to communicate with the device gateway and generate the event; 16. The system of claim 15.

21. a medical monitoring client adapted to subscribe to the CQI message topic; 21. The system of claim 20.

Images