System, method and apparatus for data communication

Abstract

To provide a hub for communicating data between medical devices and one or more enterprise servers.SOLUTION: The system 2 of the present invention includes a first hub 12 and a second hub 20. The first hub communicates data to and from the medical devices 4, 6, 8, 10 via the local area network and packages the data into at least one application-layerpacket. The second hub of the backbone system 22 operatively receives the at least one application layer packet from the first hub via at least one cellular network 14 of any type.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a non-provisional patent application claiming benefit of priority to U.S. Provisional Patent Application No. 61 / 740,474 (Attorney Docket No. J80), filed December 21, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR DATA COMMUNICATIONS, which is incorporated herein by reference in its entirety. This application is also a continuation-in-part of U.S. patent application Ser. No. 13 / 723,253, filed December 21, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, and Publication No. US-2013-0191413-A1 (Attorney Docket No. J85), published July 25, 2013, which claims 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 are hereby incorporated by reference in their entireties.

[0002] U.S. patent application Ser. No. 13 / 723,253, filed December 21, 2011, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE; U.S. patent application Ser. No. 13 / 333,574, published July 19, 2012, U.S. Publication No. US-2012-0185,267-A1 (Attorney Docket No. I97); and This is a continuation-in-part of PCT application No. PCT / US11 / 66588 (Attorney Docket No. I97WO), filed December 21, 2011, and entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, which applications are incorporated herein by reference in their entireties. U.S. patent application Ser. No. 13 / 333,574, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM, is a continuation-in-part of U.S. patent application Ser. No. 13 / 011,543, which was 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, entitled ELECTRONIC ORDER BROKERAGE SYSTEM FOR HEALTHCARE FACILITIES (Attorney Docket No. H53), both of which are incorporated herein by reference.

[0003] This application is a continuation-in-part of U.S. patent application Ser. No. 13 / 723,239, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed December 21, 2012, and published November 7, 2013, bearing publication number US2013-0297330-A1 (Attorney Docket No. J77), 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); 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 applications are incorporated herein by reference in their entireties.

[0004] U.S. Patent Application, Serial No. 13 / 723,239 claims priority to, the benefit of, 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, which is a continuation-in-part of U.S. patent application Ser. No. 13 / 011,543, filed January 21, 2011, entitled ELECTRONIC PATIENT MONITORING SYSTEM, which was published December 22, 2011, with publication number US-2011-0313789-A1 (Attorney Docket No. I52). This application claims priority to U.S. Provisional Patent Application No. 61 / 297,544, entitled ELECTRONIC ORDER BROKERAGE SYSTEM FOR HEALTHCARE FACILITIES, filed January 22, 2010 (Attorney Docket No. H53); and PCT application No. PCT / US11 / 66588, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed December 21, 2011, published September 12, 2013, having publication number WO2013 / 095459 (Attorney Docket No. I97WO), which are incorporated herein by reference in their entireties.

[0005] This application is also a continuation-in-part of U.S. patent application Ser. No. 13 / 723,242, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, filed December 21, 2012, and published November 28, 2013, bearing Publication No. US2013-0317753-A1 (Attorney Docket No. J78), which claims the benefit of priority to and the benefit of the following applications: No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, entitled SYSTEMS, METHODS AND APPARATUS FOR ELECTRONIC PATIENT CARE, which is incorporated herein by reference in its entirety. This application is a continuation-in-part of U.S. patent application Ser. No. 13 / 900,655, filed May 23, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, which was published on November 28, 2013, having publication number US2013-0317837-A1 (Attorney Docket No. K66), which claims the benefit of priority to and the benefit of U.S. provisional patent application Ser. No. 61 / 651,322, filed May 24, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR ELECTRONIC PATIENT CARE (Attorney Docket No. J46), both of which are incorporated herein by reference in their entireties.

[0006] U.S. Patent Application No. 13 / 900,655 is also a continuation-in-part application claiming the benefit of priority to and the benefit of the following applications: an application entitled BLOOD PROCESSING SYSTEM AND METHOD, filed May 24, 2012, U.S. patent application Ser. No. 13 / 480,444, published February 14, 2013, publication number US2013-0037485-A1 (Attorney Docket No. J43); and PCT application entitled BLOOD PROCESSING SYSTEM AND METHOD, filed May 24, 2012, application number PCT / US12 / 00257, published November 29, 2012, publication number WO2012 / 161744 (Attorney Docket No. J43WO). This application is also a continuation-in-part of PCT application Ser. No. PCT / US13 / 42350 (Attorney Docket No. K66WO), filed May 23, 2013, and entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE, which claims priority to and the benefit of U.S. Provisional Patent Application Ser. No. 61 / 651,322 (Attorney Docket No. J46), filed May 24, 2012, and entitled SYSTEM, METHOD, AND APPARATUS FOR ELECTRONIC PATIENT CARE, both of which are incorporated herein by reference in their entireties.

[0007] PCT application, application number PCT / US13 / 42350, is also a continuation-in-part application that claims priority to and the benefit of the following application: an application entitled BLOOD PROCESSING SYSTEM AND METHOD, filed May 24, 2012, U.S. patent application Ser. No. 13 / 480,444, published February 14, 2013, publication number US2013-0037485-A1 (Attorney Docket No. J43); and PCT application entitled BLOOD PROCESSING SYSTEM AND METHOD, filed May 24, 2012, application number PCT / US12 / 00257, published November 29, 2012, publication number WO2012 / 161744 (Attorney Docket No. J43WO).

[0008] This application is also related to one or more of the following patent applications, filed December 21, 2012, which are incorporated herein by reference in their entireties: Application entitled SYSTEM, METHOD AND APPARATUS FOR CLAMPING, U.S. Nonprovisional Patent Application No. 13 / 723,238 (Attorney Docket No. J47); Application entitled SYSTEM, METHOD AND APPARATUS FOR ORAL DRUGS PREPARING, U.S. Nonprovisional Patent Application No. 13 / 723,235 (Attorney Docket No. J74); an application entitled "Systems, Methods, and Apparatus for Dispensing Oral Medication," PCT Application No. PCT / US12 / 71131 (Attorney Docket No. J74WO); The application entitled SYSTEM, METHOD, AND APPARATUS FOR ESTIMATING LIQUID DELIVERY, U.S. Nonprovisional Patent Application No. 13 / 724,568 (Attorney Docket No. J75); Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUIDS, U.S. Nonprovisional Patent Application No. 13 / 725,790 (Attorney Docket No. J76); Application entitled SYSTEM, METHOD, AND APPARATUS FOR INJECTING FLUIDS, PCT Application, Application No. PCT / US12 / 71490 (Attorney Docket No. J76WO); Application entitled SYSTEMS, METHODS AND APPARATUS FOR MONITORING, REGULATING OR CONTROLLING FLUID FLOW, U.S. Nonprovisional Patent Application No. 13 / 723,244 (Attorney Docket No. J79); an application entitled "SYSTEMS, METHODS, AND APPARATUS FOR MONITORING, REGULATING OR CONTROLLING FLUID FLOW," PCT Patent Application No. PCT / UIS12 / 71142 (Attorney Docket No. J79WO); The application entitled "System, Method, and Apparatus for Estimating Liquid Supply," U.S. Nonprovisional Patent Application No. 13 / 723,251 (Attorney Docket No. J81); and The application entitled "Systems, Methods, and Apparatus for Estimating Liquid Supply," PCT Patent Application No. PCT / US12 / 71112 (Attorney Docket No. J81WO).

[0009] This application is also related to one or more of the following patent applications, which are incorporated herein by reference in their entireties: an application entitled SYSTEM, METHOD AND APPARATUS FOR DETECTING AIR IN A FLUID LINE USING ACTIVE COMMUNICATION, filed December 18, 2012, U.S. Provisional Patent Application No. 61 / 738,447 (Attorney Docket No. J32); U.S. patent application Ser. No. 13 / 840,339, entitled "Apparatus for Injecting Fluids," filed March 15, 2013 (Attorney Docket No. K14); PCT application PCT / US13 / 32445, entitled "Apparatus for Injecting Fluids," filed March 15, 2013 (Attorney Docket No. K14WO); An application entitled INJECTION PUMP AND RELATED METHODS, filed March 15, 2013, U.S. Patent Application No. 13 / 833,432 (Attorney Docket No. K21);

[0010] U.S. patent application Ser. No. 13 / 836,497 (Attorney Docket No. K22), filed March 15, 2013, entitled SYSTEM AND APPARATUS FOR ELECTRONIC PATIENT CARE; An application entitled SYSTEM, METHOD AND APPARATUS FOR CLAMPING, filed March 15, 2013, U.S. Patent Application No. 13 / 833,712 (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 (Attorney Docket No. K28); and U.S. patent application entitled SYSTEM, METHOD AND APPARATUS FOR COMMUNICATING DATA, filed December 20, 2013 (Attorney Docket No. L49). [Background technology]

[0011] The present disclosure relates to communicating data, and more particularly, to systems, methods, and apparatus for communicating data between, for example, medical devices and one or more enterprise servers. Related technologies

[0012] In some examples, one or more medical devices may be used by a particular patient to treat an acute or chronic illness. These medical devices may include electronic control circuits that execute software algorithms to ensure that the patient is being treated appropriately, that the treatment is not outside of predetermined norms, and that the medical device itself is operating within acceptable parameters.

[0013] Because each specific treatment prescribed for a patient is unique and / or results in the use of multiple devices, external databases and computer systems (e.g., enterprise systems) can be used to provide these devices with information related to the patient and the patient's treatment plan. The information can be used to facilitate the interoperation of multiple medical devices during a treatment session. Various communication technologies can be used to implement one or more device-to-server communication links. Summary of the Invention

[0014] In one embodiment of the present disclosure, a method of communication includes: communicating data from a medical device to a first hub over a local area network; packaging the data from the medical device into at least one packet, the at least one packet including a header; communicating the at least one packet over the network via at least one communication channel of the first hub; and optionally, communicating an alarm from the first hub to the medical device when an alarm condition occurs within the first hub. The method may be performed within the application layer (e.g., the packets may be application layer level packets) or may be performed within any other layer or combination of layers. A first communication channel of the at least one communication channel may be over a first cellular network, e.g., plain old telephone service ("POTS") or broadband. A second communication channel of the at least one communication channel may be over a second cellular network, e.g., plain old telephone service ("POTS") or broadband. The first hub may be associated with an identification value (e.g., a serial number), a patient, a medical device, and / or a treatment.

[0015] The act of communicating data from the medical device to the first hub over the local area network may be an act of receiving data by the first hub over the local area network from the medical device.

[0016] In yet other embodiments of the present disclosure, the method may further include an act of encrypting the data (e.g., by the first hub and / or by the medical device). The method may include an act of receiving at least one packet over the network through the at least one communication channel by a second hub, and an act of decrypting the data within the second hub.

[0017] The method can include an act of determining a time parameter, for example, a date and / or a time. Satellite system signals can be used to determine the time parameter. Additionally or alternatively, the method may use a cellular time server, a Network ID and Time Zone ("NITZ") server, a time server, etc. to determine the time parameter. The method may include an act of adding the time parameter to a header of the packet. The method may perform an act of determining whether the time parameter in the header of the packet meets a first predetermined criterion.

[0018] The method may further include acts of adding a sequence number to a header of the packet; reconstructing the data using the sequence number in the header of the packet; determining an error detection code corresponding to at least a portion of the packet and adding the error detection code to the header of the packet; and / or determining whether at least a portion of the packet is error-free by examining the error detection code in the header of the packet.

[0019] In yet another embodiment of the present disclosure, the method may include an act of determining whether at least one of the packet and the data meets a second predetermined criterion; and / or an act of communicating an affirmative character corresponding to at least one of the packet and the data to the first hub if the second predetermined criterion is met.

[0020] In yet other embodiments of the present disclosure, the method may include receiving, by the second hub, at least one packet over the network through at least one communication channel and / or sending data from the second hub to at least one enterprise server (e.g., a transaction server) or an analytics server.

[0021] The act of packaging data from the medical device into at least one packet may include packaging the data into that packet and other packets. The packet may include a header, and the other packet may include another header. The method may further include an act of adding a first sequence number to the header of the packet and a second sequence number to the other header of the other packet.

[0022] The act of communicating at least one packet over the network through one of the at least one communication channels of the first hub may include acts of communicating the packet over a first communication channel of the at least one communication channel of the first hub; and communicating another packet over a second communication channel of the at least one communication channel of the first hub. The method may include receiving the packet and the other packet; and reconstructing the data according to a first sequence number of the packet and a second sequence number of the other packet.

[0023] In some further embodiments of the present disclosure, the method may include encrypting data from the medical device (or the first or second hub) before communicating the data to the first hub over a local area network; receiving at least one packet over the network through one or more communication channels (e.g., two communication channels) by the second hub; sending the data from the second hub to an enterprise server; and / or decrypting the data by the enterprise server for processing by the enterprise server.

[0024] In yet another embodiment of the present disclosure, a hub includes a local area network interface component, first and second system-on-module ("SOM") modules, and a processor. The local area network interface component is configured to communicate data with a medical device. The first SOM is configured to interface with a first communication channel, and the second SOM is configured to interface with a second communication channel. The first communication channel may be a first cellular network, and the second communication channel may be a second cellular network. The processor is configured to package data from the medical device into at least one packet. The at least one packet includes a header, and the processor is further configured to operatively communicate with one of the first and second SOMs to communicate the at least one packet over one of the first and second communication channels. The processor may further be configured to associate the hub with one of an identification value, a patient, a medical device, and a therapy. Additionally, alternatively, or optionally, the processor may be configured to encrypt the data.

[0025] In yet another embodiment of the present disclosure, the processor is configured to add a time parameter to the packet's header. The time parameter can include a date and / or a time. The hub may include a satellite system component, and the processor is configured to use the satellite system component to add the time parameter to the header using a time determined by the satellite system. In some embodiments, the hub uses a cellular time service, a network ID and time zone ("NITZ"), a time server, or the like to determine the time.

[0026] In yet another embodiment of the present invention, the processor is further configured to add a sequence number to the packet header, which may be configured to reconstruct the data using the sequence number in the packet header.

[0027] In yet another embodiment of the present invention, the processor is further configured to add to a header of the packet an error detection code corresponding to at least a portion of the packet, the error detection code being an error correction code.

[0028] The processor may be configured to package the data into a packet and another packet, where the packet includes a header and the other packet includes another header.

[0029] In yet another embodiment of the present disclosure, the hub includes a fail-safe bus that may be configured to signal medical devices coupled to the hub when a fault condition occurs in the hub or the communication link.

[0030] In yet another embodiment of the present disclosure, the hub further includes an alarm bus that may be configured to signal medical devices coupled to the hub when an alarm condition in the hub occurs or when an alarm condition in the communication link occurs if the link quality of the communication link degrades.

[0031] In yet another embodiment of the present disclosure, the hub further includes a plain-old-telephone-service component. If the first and second communication channels are unavailable, the processor can be configured to send packets over plain-old-telephone-service ("POTS"). For example, if an emergency condition is determined to exist, the hub can call 911. In some embodiments, the hub may, for example, download audio data from a server into an audible broadcast instruction. The hub's serial number can be used to determine which language the audio message is in from a list of possible languages.

[0032] In yet another embodiment of the present disclosure, a system includes first and second hubs. The first hub is configured to communicate data to and from a medical device over a local area network and package the data into at least one application-layer packet. The second hub is configured to operably receive the at least one application-layer packet from the first hub over at least one cellular network. The first hub may be configured to encrypt the data, and the second hub may be configured to decrypt the data.

[0033] The first hub can communicate at least one application layer packet over the first and second of the at least one cellular networks, and the second hub can be configured to reconstruct data from the at least one application layer packet. The first hub may be configured to balance the transmission of at least one application layer packet between the first and second cellular networks or to transmit data redundantly using both the first and second cellular networks. For example, each packet may be transmitted twice, once using the first cellular network and once using the second cellular network. The backbone system may compare the received packets to determine whether they contain identical data. That is, the data in the two packets may not be identical if the data in one or both of the packets was corrupted during transmission.

[0034] The system can further include an enterprise server. The medical device can be configured to encrypt the data, the second hub can be configured to send the data to the enterprise server, and the enterprise server can be configured to decrypt the data.

[0035] In yet another embodiment of the present disclosure, a first hub includes a global positioning component configured to determine a time parameter using at least one global positioning signal, the first hub adds the time parameter to an application layer packet header of at least one application layer packet, and a second hub is configured to determine whether the time parameter meets a predetermined criterion.

[0036] The second hub can include another global positioning component configured to determine another time parameter using the at least one global positioning signal, and the second hub can be configured to determine whether the time parameter satisfies a predetermined criterion as a function of the other time parameter.

[0037] In another embodiment of the present disclosure, the at least one application layer packet includes a first application layer packet, and the first hub is configured to append a corresponding error detection code to at least a portion of the first application layer packet. The second hub can be configured to determine whether at least a portion of the first application layer packet is error-free using the error detection code. The error detection code can be an error correction code, in which case the second hub is further configured to correct errors in at least a portion of the first application layer packet, if necessary.

[0038] The at least one application layer packet may include a first application layer packet, and the second hub is configured to communicate an acknowledgment to the first hub if the first application layer packet meets a predetermined criterion.

[0039] In another embodiment of the present disclosure, the system further includes an enterprise server. The medical device is configured to encrypt the data. The second hub is configured to send the data to the enterprise server, which is configured to decrypt the data. Once the data is written to the enterprise server, an acknowledgement can be sent back to the first hub and / or the medical device.

[0040] In some embodiments, the at least one application layer packet includes first and second application layer packets. The first hub is configured to add a first sequence number to a first header of the first application layer packet and a second sequence number to a second header of the second application layer packet. The second hub is configured to reconstruct the data according to the first and second sequence numbers. The first hub may be configured to communicate the first application layer packet over a first cellular network of the at least one cellular network. The first hub is configured to communicate the second application layer packet over a second cellular network of the at least one cellular network.

[0041] In yet another embodiment of the present disclosure, a first hub includes an alarm bus component configured to provide an alarm status signal, a medical device is operably connected to the first hub to receive the alarm status signal, and the medical device is configured to provide at least one mitigation strategy when an alarm condition is received via the alarm status signal.

[0042] In yet another embodiment of the present disclosure, a first hub includes a fail-safe component configured to provide a fatal error condition signal. A medical device is operably connected to the first hub to receive the fatal error condition signal. The medical device is configured to operate independently of the hub when a fatal error condition is indicated via the fatal error condition signal. [Brief explanation of the drawings]

[0043] 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.

[0044] [Figure 1] FIG. 1 illustrates a block diagram of a system for communicating data according to an embodiment of the present disclosure.

[0045] [Figure 2] FIG. 2 shows a block diagram of a hub of the system of FIG. 1 according to an embodiment of the present disclosure; and

[0046] [Figure 3A] 3A-3B show flow chart diagrams illustrating methods for communicating data according to embodiments of the present disclosure. [Figure 3B] 3A-3B show flow chart diagrams illustrating methods for communicating data according to embodiments of the present disclosure. Detailed Description of the Invention

[0047] 1 shows a block diagram of a system 2 for communicating data according to an embodiment of the present disclosure. The system includes hubs 12, 20 that communicate with each other over a network 14. A first hub 12 is operably coupled to medical devices 4, 6, 8, and 10. That is, the first hub 12 is in operative communication with one or more of the medical devices 4, 6, 8, and 10. In some embodiments, multiple hubs 12 can be used (e.g., one device per hub).

[0048] The hub 12 may include requirements that must be met before a medical device can connect to it. Additionally or alternatively, the hub 12 may require that the link quality between the first and second hubs 12, 20 must meet certain criteria before data can be communicated therebetween. The hub 12 may communicate the link quality between the hubs 12, 20 to one or more medical devices 4, 6, 8, 10.

[0049] The second hub 20 is operatively coupled to various enterprise servers 16, 18, 24, 26, 28, 30, 32, 34, and 36 of an enterprise system 22. The enterprise system 22 may be implemented by one or more servers, may be a server farm, may be implemented as one or more virtual servers, and / or may be software programs implemented by one or more processors. The various enterprise servers 16, 18, 24, 26, 28, 30, 32, 34, and 36 may be transaction servers.

[0050] The hubs 12, 20 can communicate data between the medical devices 4, 6, 8, 10 and the enterprise servers 16, 18, 24, 26, 28, 30, 32, 34 so that data is communicated seamlessly therebetween. For example, in some specific embodiments, the hubs 12, 20 can wrap data into packets so that data communicated between the medical devices 4, 6, 8, 10 and the enterprise servers 16, 18, 24, 26, 28, 30, 32, 34, 36 is communicated between each other as if they were on the same local area network. In some specific embodiments, the data may be wrapped into one or more packets at an application layer, such as the application layer of the Open Systems Interconnection Model (ISO / IEC 7498-1) (the "OSI Model"), the entire contents of which are incorporated herein by reference. In some embodiments, the data may be wrapped in one or more layers of any communications standard known to those skilled in the relevant art, such as the application layer of another model. In some further embodiments, the data may be wrapped in one or more layers of any packet model known in the art, including the OSI model. In some further embodiments, the wrapping of one or more packets may be performed in a combination of the application, presentation, and session layers of the OSI model, and / or the presentation and session layers may not be implemented. Hub 20 may transmit data from one of medical devices 4, 6, 8, 10 to one of enterprise servers 16, 18, 24, 26, 28, 30, 32, 34, 36.

[0051] Hubs 12, 20 can communicate with each other in a synchronous or asynchronous manner. Hubs 12, 20 can also communicate heartbeat signals with each other. For example, each of hubs 12, 20 can periodically, at predetermined intervals, send a signal to the other hub 12, 20 indicating that it is operating normally. If one of hubs 12, 20 does not receive a heartbeat signal (or, in some embodiments, any signal) from the other hub within a predetermined time, the hub that did not receive the heartbeat signal within the predetermined time can (1) request that the other hub send a heartbeat signal, (2) determine that the other hub has failed and take appropriate mitigation measures, (3) signal that an alarm has occurred on the alarm bus, and / or (4) signal via the failsafe bus that a heartbeat signal was not received within the predetermined time.

[0052] The hubs 12, 20 communicate with each other, and the receiving hub (i.e., receiving the data) can send an acknowledgment to the sending hub. In some particular embodiments, the acknowledgment can also include a sequence number or other packet identifier.

[0053] The hub 12 and / or medical devices 4, 6, 8, 10 may have associated identification values ​​that grant data from the medical devices 4, 6, 8, 10 predetermined access to one or more enterprise servers 16, 18, 24, 26, 28, 30, 32, 34, 36. Additionally, alternatively, or as needed, the associated identification values ​​may be associated with access to different subsets of services or data within each enterprise server 16, 18, 24, 26, 28, 30, 32, 34, 36.

[0054] In some embodiments, the hub 12 may be associated with a patient, one or more medical devices 4, 6, 8, 10, and / or a treatment regime.

[0055] Each of the medical devices 4, 6, 8, 10 or the first hub 12 may communicate its capabilities, its configuration, and / or any alerts or faults to one or more enterprise servers 16, 18, 24, 26, 28, 30, 32, 34, 36 or the second hub 20.

[0056] Hubs 12, 20 can wrap data into one or more packets, each of which includes a header that may include (1) a sequence number; (2) an error detection code, such as an error correction code; and / or (3) one or more time parameters, such as a date and / or time.

[0057] The sequence number can be used to reconstruct the data. For example, the hub 12 can divide the data into multiple packets, each of which is assigned a sequence number. The hub 12 can communicate the multiple packets over a first cellular network via a first cell modem 64 and over a second cellular network via a second cell modem 84 (see FIG. 2). The first and second cellular networks can be 2G networks, 3G networks, 4G networks, LTE networks, or WiFi Internet connections. The hub 12 can perform load balancing. When the data reaches the second hub 20, the second hub 20 uses the sequence numbers to reconstruct the data.

[0058] The error detection code can be used, for example, as an error correction code that can detect and correct errors contained within the data. Any error detection code can be used, such as a cyclic redundancy check ("CRC"), a checksum, a hash value, a parity bit, a parity word, MD5, etc. The first hub 12 can add the error detection code to the header of one or more packets before sending them to the second hub 20. The second hub 20 uses the error detection code to determine if there are one or more errors in the data, and in some specific embodiments, the second hub 20 corrects the data (or vice versa when transmitting from the second hub 20 to the first hub 12).

[0059] The first hub 12 and / or the second hub 20 can add a time parameter, such as a date / time stamp, to the header before communicating it to the other of the hubs 12, 20. The receiving hub of the hubs 12, 20 can determine if the date / time stamp meets predetermined criteria, such as a requirement that the packet was received within a predetermined time. The receiving hub of the hubs 12, 20 can compare the date / time stamp to an internally determined time parameter to determine if the packet was received within the predetermined time, since the date / time was determined by the transmitting hub of the hub 12, 20. The hubs 12, 20 can use a time reference determined using one or more satellites of a satellite system. In some embodiments, the satellites may be part of a global navigation satellite system, such as the Global Positioning System constellation, the Globalnaya Navigatsionnaya Sputnikovaya Sistema (“GLONASS”) constellation, the Indian Regional Navigation Satellite System (“IRNSS”) constellation, the BeiDou Navigation System constellation, the Galileo constellation, or the like, and signals from one or more satellites may be used to determine the time parameter.

[0060] Data may be encrypted by a sending one of the hubs 12, 20 and similarly decrypted by a receiving one of the hubs 12, 20. Additionally, alternatively, or optionally, the medical devices 4, 6, 8, 10 may encrypt data before sending it to the enterprise servers 16, 18, 24, 26, 28, 30, 32, 34, 36, which may further decrypt the data upon receiving it, and similarly, the enterprise servers 16, 18, 24, 26, 28, 30, 32, 34, 36 may encrypt data before sending it to the medical devices 4, 6, 8, 10, which may decrypt the data upon receiving it. Any encryption method may be used, such as public key cryptography, symmetric key cryptography, session key cryptography, Advanced Encryption Standard ("AES"), Data Encryption Standard ("DES"), Triple DES, Hypertext Transfer Protocol Secure ("HTTPS"), Transport Layer Security ("TLS"), Secure Sockets Layer ("SSL"), Federal Information Processing Standard ("FIPS") encryption standards, some other encryption technique known to those skilled in the art, or a combination thereof.

[0061] A medical device 4, 6, 8, 10 or hub 12 can communicate various information to the infrastructure system 22, such as (1) its status, e.g., whether the device is operational or inoperable, (2) its location, (3) its configuration, e.g., software version, its hardware version, its capabilities, etc., (4) available bandwidth, and / or (5) medical device requirements. In some embodiments, a medical device can connect to hub 12 only if the available bandwidth exceeds a predetermined threshold.

[0062] The medical devices 4, 6, 8, 10 may communicate software and / or firmware version numbers to the enterprise system 22 to obtain updates. The updates may be verified and / or validated using any known technique, such as cryptographic verification. The enterprise system 22 may use the version number to send updated software and / or updated firmware to one or more medical devices 4, 6, 8, 10 if the received version number is not the most current version.

[0063] Additionally, alternatively, or if necessary, to obtain updates, hub 12 may communicate software and / or firmware version numbers to enterprise system 22. If the received version number is not the most current version, enterprise system 22 may use the version number to send updated software and / or updated firmware to hub 12.

[0064] In some embodiments, software may be stored in the hub 12, and the hub 12 may be used to update software in one or more medical devices 4, 6, 8, 10. The hub 12 may request that firmware and / or software version numbers present in one or more medical devices 4, 6, 8, 10 be sent to the hub 12. The hub 12 may then determine whether the medical devices 4, 6, 8, 10 have the latest software or firmware versions by referencing an internal database or by referencing version information received from the enterprise system 22. The hub 12 can download software or firmware from the enterprise system 22. The hub 12 can load software onto the medical devices 4, 6, 8, 10, which can then execute any known algorithm to update the software and / or firmware. For example, a new version of firmware may be loaded onto one of the medical devices 4, 6, 8, 10 and then verified. The medical device (4, 6, 8, 10) can then verify (e.g., via a pointer) the new firmware and "switch" the medical device to use the new firmware.

[0065] Additionally, in some embodiments, the medical devices 4, 6, 8, 10 and / or the hub 12 communicate alerts, alarms, faults, log information, or other diagnostic information to the central system 22 for recording by the continuous quality improvement (“CQI”) server 36.

[0066] Hubs 12, 20 communicate over network 14, which can include any type of network. For example, hub 12 can communicate data over one or more cellular networks that transmit data to hub 20 over the Internet. In some embodiments, hubs 12, 20 communicate using a wireless Internet link, a wired Internet link, a broadband link, POTS, or other known communication technologies known to those skilled in the art. In some embodiments, a cellular network provider may couple backbone system 22 directly to a data connection configured to receive data over one or more cellular networks.

[0067] The medical devices 4, 6, 8, and 10 operatively communicate with the hub 12 through a LAN connection 38, an alarm bus 40, and a failsafe bus 42. The LAN connection 38 can use any local area network technology and protocol, and the hub 12 can support multiple LAN technologies and protocols. Each of the medical devices 4, 6, 8, and 10 may use a different local area network technology from the others.

[0068] The alarm bus 40 may be implemented by a wire that is normally held in a “high” state (e.g., at 5 volts) by the hub 12. When the hub 12 determines that an internal alarm has occurred, the hub 12 may signal via an alarm condition signal (e.g., by setting the wire to 0 volts) that an alarm condition has occurred within the hub 12. That is, the alarm bus 40 may be used to communicate that an alarm condition has occurred. When each of the medical devices 4, 6, 8, 10 determines that an alarm condition has occurred, the medical devices 4, 6, 8, 10 may take at least one mitigating action, such as reducing the bandwidth of the LAN 38 connection using the cellular network over which they connect to communicate with the network 14, or other mitigating action. In some embodiments, when an alarm condition is reported to the medical devices 4, 6, 8, 10 by the hub 12 (or, in some embodiments, when one of the medical devices 4, 6, 8, 10 detects an internal alarm), the medical devices 4, 6, 8, 10 may enter a safety mode. In some embodiments, the alarm bus 40 is a digital communication bus that communicates information about alarms to the medical devices 4, 6, 8, 10.

[0069] In some embodiments, the alarm bus 40 configures alarm conditions as a function of the capabilities or performance of the network 14 or of the hub 12. Each of the medical devices 4, 6, 8, 10 can communicate to the hub 12 a list of conditions that the hub 12 should communicate to the requesting medical device 4, 6, 8, 10 when an alarm condition occurs.

[0070] The hub 12 may also include a fail-safe bus 42. The fail-safe bus 42 is coupled between the hub 12 and the medical devices 4, 6, 8, and 10. A fatal error condition signal is provided to indicate that a fatal error condition has occurred within the hub 12. The signal may transition from a "high" value (e.g., 5 volts) to a "low" value (e.g., 0 volts), indicating the existence of a fatal error condition within the hub 12. When a fatal error condition exists as indicated by the fatal error condition signal, the medical devices 4, 6, 8, 10 may be configured to operate independently of the hub. In some embodiments, the fatal error condition may be defined by the hub 12 and / or the medical devices coupled to the hub 12. In some embodiments, the failsafe bus 42 is a digital communication bus that communicates information about fatal error conditions of the medical devices 4, 6, 8, 10.

[0071] The peristaltic infusion pump 4 may be any type of peristaltic infusion pump 4, such as a finger pump or a rotary infusion pump. The syringe infusion pump 6 may be, for example, any syringe pump driven by a motor. The other device 10 may be any medical device. In some embodiments, the pump 4 , 6 (or other device 10 ) receives feedback from a medical sensor 8 .

[0072] The medical sensor 8 may be any patient or environmental sensor, such as, for example, a blood pressure sensor, a temperature sensor, a blood glucose meter, a heart rate monitor, a pulse oximeter, or the like.

[0073] In one particular embodiment, the medical sensor 8 may be a blood pressure cuff or a pill delivery device that provides feedback to one or more medical devices 4, 6, 10. Information regarding blood pressure compliance may be used to adjust the flow rate of the pumps 4, 6. In some embodiments, the feedback may be sent to a physician via the backbone system 22 (e.g., an electronic message may be sent to a tablet or smartphone).

[0074] In yet another embodiment, medical sensor 10 may be a pulse oximeter that provides feedback to peristaltic infusion pump 4. If peristaltic infusion pump 4 determines that the oxygen saturation of the patient's blood falls below a predetermined threshold and / or the patient's heart rate falls below a predetermined threshold, infusion pump 4 may stop fluid flow. In some embodiments, hub 12 shuts off peristaltic infusion pump 4 when the patient's blood oxygen level is below a predetermined threshold or the patient's heart rate is below a threshold.

[0075] In one embodiment, the other device 10 generates oxygen for the patient. The medical sensor 8 may be a pulse oximeter that provides the patient's blood oxygen saturation as feedback to the other device 10. The other device 10 may generate oxygen to ensure that the patient's blood oxygen saturation is at least at a predetermined level.

[0076] In yet other embodiments, the other device 10 can initiate a "call-in" when a predetermined condition is met. For example, if the other device 10 is a pill dispenser, the pill dispenser can send an alarm or alert to the physician when non-compliance occurs. The provider can change the next dose to be delivered by the pill dispenser via a tablet or smartphone user interface.

[0077] In some embodiments of the present disclosure, the hub 12 transmits information from one or more medical sensors 8 to one or more devices 4, 8, 10. This closed-loop configuration can form a real-time feedback system. In some specific embodiments, the one or more medical sensors 8 can form a closed-loop configuration with one or more devices 4, 8, 10, as long as the following requirements are met: (1) communication latency is below a predetermined threshold; (2) wireless signal noise is below a predetermined threshold; and / or (3) a predetermined amount of bandwidth is available, or a combination thereof. In some embodiments, the hub 12 can signal to the medical devices 4, 6, 8, 10 that an alarm or critical condition has occurred if one or more of these conditions are not met. The alarm or alert condition can be communicated to the infrastructure system 22. In some embodiments, the hub 12, 20 and / or the medical devices 4, 6, 8, 10 can enter a fail-safe / operational mode in response to the alarm or alert.

[0078] In some embodiments, a hierarchy of responses can be programmed into one of the medical devices 4, 6, 8, 10 or into the hub 12 based on the occurrence of an alarm or alert and / or how much time has passed without a user interacting with the hub 12 or any of the medical devices 4, 6, 8, 10. A caregiver can program the hierarchy of responses, for example, from a general framework. In some embodiments, the hierarchy of responses can be confirmed by the core system 22.

[0079] The core systems 22 may include one or more of the following: a database / analysis engine, a patient cache 18, a hub 20, a CPOE 24, another HIS 26, an APIS 28, an EMR 30, a DERS 32, an LIS 34, and / or a CQI 36.

[0080] The database / analytics engine 16 collects data from the hub 12 and / or the devices 4, 6, 8, 10 to determine trends and / or one or more statistics. The database / analytics engine 16 may interface with one or more of the servers 18, 24, 26, 28, 30, 32, 34, 36 to generate one or more reports for users that interface with the database / analytics engine 16.

[0081] The hub 12 and / or any one of the devices 4, 6, 8, 10 can determine the patient's identifier (e.g., using a bar code scanner, an RFID scanner, or by manually entering the patient's ID into a screen). Patient data related to treatment may be loaded into a patient cache 18, which can instruct the hub 12 and / or any one of the medical devices 4, 6, 8, 10 on what to do with the data. The patient cache 18 may be implemented in memory, such as RAM, or such as hard drive memory. The patient cache 18 can load data from any one of the servers 24, 26, 28, 30, 32, 34, 36, thereby providing faster response to patient data from the hub 12 and / or devices 4, 6, 8, 10, or organizing the data in a different manner.

[0082] The infrastructure system 22 may also include a computerized physician order entry ("CPOE") server 24. The CPOE 24 may receive orders (over the Internet) for treatments and / or prescriptions for a particular patient. The CPOE 24 may be compared with medications scanned by the pumps 4, 6 to determine if it is correct for the authorized patient.

[0083] The CPOE 24 can receive a care algorithm from a caregiver. The care algorithm can include rules regarding feedback to use, points to achieve, and / or medications to administer. The caregiver can interface with the CPOE 24 using a computer terminal, tablet, smartphone, or other user interface. The CPOE 24 and / or the core system 22 can validate the care algorithm.

[0084] The core system 22 may also include a pharmacy information system ("PIS") server 28, an electronic medical record ("EMR") server 30, and a laboratory information system ("LIS") server 34, which may be accessed by the devices 4, 6, 8, 10. The core system 22 may also include other hospital information system ("HIS") servers 26.

[0085] The infrastructure system 22 may also include a Drug Error Reduction System ("DERS") server 32. The DERS server 32 may contain information that enables one or more devices 4, 6, 8, 10 to determine whether a therapy (e.g., delivery of a drug via an IV bag connected to a peristaltic infusion pump 4) is safe. For example, an IV bag may include a bar code attached thereto. The infusion pump 4 scans the bar code on the IV bag and communicates that information, for example, to the PIS 28, which determines the contents of the IV bag and communicates with the DERS 32 to determine whether the drug and treatment parameters are safe for the authorized patient or for any patient (through strict qualifications).

[0086] The core system 22 may also include a continuous quality improvement ("CQI") server 36. The CQI server 36 receives messages from the medical devices 4, 6, 8, 10 describing device operation. The CQI messages sent to the CQI server 36 may be used to monitor a fleet of medical devices to identify issues or problems with the devices 4, 6, 8, 10.

[0087] In some embodiments of the present disclosure, any one of the medical devices 4, 6, 8, 10 can use the resources of another of the medical devices 4, 6, 8, 10. In some embodiments, the medical devices 4, 6, 8, 10 and / or the hub 12 can operate as a mesh network.

[0088] A user interfacing with the enterprise system 22 can monitor the hub 12 and / or the medical devices 4, 6, 8, 10. The hub 12 and / or the medical devices 4, 6, 8, 10 can transmit images of their screens (e.g., JPEG) to the user interfacing with the enterprise system 22, or can also communicate audio (e.g., from a microphone). HTML5 can be used and / or telepresence can be used to allow a user to monitor the hub 12 and / or the medical devices 4, 6, 8, 10 using a user interface coupled to the enterprise system 22.

[0089]

[0023] Figure 2 shows a block diagram of hub 14 of the system of Figure 1 according to an embodiment of the present disclosure. In some particular embodiments, hub 20 of Figure 1 may use similar hardware as hub 14.

[0090] The hub 12 includes a LAN interface 44, an alarm bus 68, a failsafe bus 76, a battery 78, a power supply 80, memory 46, buttons 48, a GPS component 52, a display 54, a speaker 56, and first and second system-on-module ("SOM") modules 66, 86, a safety processor 70, a local memory cache 72, and a plain old telephone service ("POTS") 74.

[0091] Hub 12 may be powered by a power supply circuit 80 that converts AC mains power to DC power that powers the internal circuitry of hub 12. Power supply 80 may also charge battery 78. In the event that the power supply powering power supply circuit 80 runs out of power, battery 78 provides power to hub 12. In some particular embodiments, multiple batteries 78 and / or multiple power supplies 80 may be used to provide additional redundancy.

[0092] The LAN interface 44 includes a WiFi transceiver 50, a Bluetooth transceiver 58, and an Ethernet interface 60. In some embodiments, the LAN interface 44 uses any wired or wireless protocol or standard known to those skilled in the art. Medical devices can communicate with the hub 12 via the LAN interface 44.

[0093] Data received via the LAN interface 44 is buffered in the memory 46. Either an interrupt and / or an algorithm can select data in the memory 46 for transmission. The data is packaged into one or more packets and transmitted via the first SOM 66 and / or the second SOM 86. The first SOM 66 includes a processor 62 and a cellular network modem 64 for transmitting packets over a first cellular network. The second SOM 86 also includes a processor 82 capable of transmitting one or more packets through a second cellular modem 84 over a second cellular network. The SOM modules 66 and 86 can perform load balancing. If communication over both cellular networks is unavailable, the POTS 74 can be used. In some embodiments, if an emergency condition is determined to exist, the POTS 74 can call an emergency number (e.g., "911" in the United States). In yet some additional embodiments, if an alarm, alert, or fault condition is determined to exist (and reported), and the cellular network is unavailable, the hub 12 calls a service number.

[0094] Modules 77 and 86 may use local memory cache 72 to communicate and / or coordinate operations between one another. Local memory cache 72 may be part of memory 46 or may be separate therefrom. In some embodiments of the present disclosure, local memory cache 72 is a storage location for medical devices 4, 6, 8, 10 (e.g., communicating between one another). For example, if a link to network 14 is unavailable, local memory cache 72 may be filled with data for transmission to backbone system 22.

[0095] In some embodiments, the data in the local memory cache 72 may be reported to the backbone system 22 periodically, or according to predetermined rules, or according to rules communicated from the backbone system 22 to the hub 12 (e.g., via an end user of the backbone system 22).

[0096] Packets can be formed at the application layer level. Packets can include respective headers. The headers may include (1) location information; (2) time information determined by the global positioning system receiver 52; (3) an error detection code; (4) a sequence number; or (5) other information.

[0097] The hub 12 also includes an alarm bus 68 (ie, an alarm bus component). The alarm bus is configured to provide alarm status signals to one or more medical devices. The medical devices may be operatively connected to the hub to receive the alarm status signal from the alarm bus 68. The signal may indicate the existence of an alarm condition in the hub by transitioning from a "high" value (e.g., 5 volts) to a "low" value (e.g., 0 volts). When an alarm condition is received via the alarm status signal, the medical device can take at least one mitigating action. For example, the medical device may need to add error correction code to data sent to the hub 12. The safety processor 70 determines when an alarm condition exists and communicates the condition to the alarm bus 68. In some embodiments, the alarm condition can be defined by the hub 12 and / or the medical devices coupled to the hub 12. The safety processor 70 can use a local memory cache 72. The safety processor 70 can monitor the hub 12 independently of the operation of the processors 62, 82 of the SOMS 66, 86. For example, the safety processor 70 can act as a monitor for the processors 62, 82, independent of their use, in some specific embodiments.

[0098] The hub 12 includes a failsafe bus 78. The failsafe bus 76 provides a fatal error condition signal that indicates when a fatal error condition occurs within the hub 12. The signal may transition from a "high" value (e.g., 5 volts) to a "low" value (e.g., 0 volts) to indicate that a fatal error condition exists within the hub. When a fatal error condition exists as indicated by the fatal error condition signal, the medical device may be configured to operate independently of the hub. The safety processor 70 may determine when a fatal error condition exists and communicates that condition to the alarm bus 68. In some embodiments, the fatal error condition may be defined by the hub 12 and / or a medical device coupled to the hub 12. In some embodiments, the hub 12, 20, and / or the medical device 4, 6, 8, or 10 may enter a fail-safe / operational mode in response to an alarm or alert condition.

[0099] If communication between a medical device (e.g., devices 4, 6, 8, 10 in FIG. 1) and the backbone system 22 (see FIG. 1) fails, the medical devices 4, 6, 8, 10 and hub 12 can record all information in internal memory for reporting to the backbone system 22 when communication is restored. Additionally or alternatively, a computer may be coupled to the medical devices 4, 6, 8, 10 or hub 12 (e.g., via an RS-232 or USB connection) to download data.

[0100] A user can input settings into the hub 12 using buttons 48 and / or display 54. The hub 12 can provide audible feedback via a speaker 56 or display 54. The hub 12 can transmit sound via LAN 38 connected to one or more devices 4, 6, 8, 10 for playback using the built-in speaker.

[0101] The speaker 56 can be used to announce what the hub is doing, for example, by saying, "I'm trying to connect to the server" or "I'm calling 1-234-567-1829." In some embodiments, the speaker 56 can be used to audibly announce any error conditions, faults, and / or alarms. Messages can be pre-recorded and can be selected based on the patient's determined language. Messages can be sent from the backbone system 22 to the hub 12 (see FIG. 1). The language determined to be used by the patient can be determined based on the location of the hub 12 (e.g., determined via GPS signals), from patient records, or by other methods known to those skilled in the relevant arts. The pre-recorded voice can be the provider's voice familiar to the patient.

[0102] In addition to the audio component of the message, the message may include pre-recorded video that is displayed on display 54. The audio and video may be synchronized with each other.

[0103] The speaker 56 and display 54 may be used to provide training videos to the user regarding the operation or configuration of the hub 12 and / or medical devices 4, 6, 8, 10 (see FIG. 1). Additionally, in some embodiments, the speaker 56 and display 54 may be used to provide health notes and / or CPR training.

[0104] 3A-3B show a flow chart diagram 88 illustrating a method for communicating data according to an embodiment of the present disclosure.

[0105] Act 90 associates the first hub with one of the ID, patient, medical device, and treatment. Act 92 receives data from the medical device by the first hub (which may be stored in a local cache). Act 94 encrypts the data. Act 96 packages the data from the medical device into at least one packet, the packet of the at least one packet including a header.

[0106] Act 98 determines the current time and date. Act 100 adds the determined current time and date to a packet header. Act 102 adds a sequence number to the packet header. Act 104 determines an error detection code. Act 106 adds the error detection code to the packet header. Act 108 communicates the at least one packet over the network via at least one communication channel. If an alarm condition occurs in the first hub, act 125 communicates the alarm from the first hub to a medical device, as appropriate. For example, if the alarm is a fatal alarm. In some embodiments, the alarm can be communicated using alarm bus 68 of FIG. 2.

[0107] Act 110 receives at least one packet by a second hub operatively over the network via at least one communication channel. Act 112 determines whether the data in the packet is error-free by examining an error detection code in the header. Act 114 determines whether the current time and date in the packet's header meets a first predetermined criterion. Act 116 reconstructs the data using the packet's header sequence number.

[0108] Act 118 decodes the data. Act 120 determines whether at least one of the packet and the data meets a second predetermined criterion. If the second predetermined criterion is met, act 122 communicates a positive character corresponding to at least one of the packet and the data to the first hub. The second predetermined criterion may be, for example, that the data has been recorded in a database. Act 124 sends the data from the hub to at least one enterprise server. One or both hubs may monitor one or more communication channels, for example, using a heart rate signal.

[0109] 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 the present disclosure.

[0110] 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.

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

[0112] 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 a method of communication comprising: communicating data from the medical device to a first hub over a local area network; packaging data from the medical device into at least one packet, the at least one packet including a header; communicating the at least one packet over a network via at least one communication channel of a first hub; and When an alarm condition occurs in the first hub, communicating an alarm from the first hub to the medical device. A second aspect of the present invention is the method of the first aspect, wherein the act of communicating data from the medical device to the first hub via the local area network is an act of receiving data by the first hub from the medical device via the local area network. A third aspect of the present invention is the method of the first aspect, wherein a first communication channel of the at least one communication channel is on a first cellular network and a second communication channel of the at least one communication channel is on a second cellular network. A fourth aspect of the present invention is the method of the first aspect, further comprising associating the first hub with an identification value. A fifth aspect of the present invention is the method of the first aspect, further comprising associating the first hub with the patient. A sixth aspect of the present invention is the method of the first aspect, further comprising associating the first hub with a medical device. A seventh aspect of the invention is the method of the first aspect, further comprising associating the first hub with a therapy. An eighth aspect of the present invention is the method of the first aspect, further comprising encrypting the data. A ninth aspect of the present invention is the method of the eighth aspect, further comprising: receiving at least one packet over the network through at least one communication channel by a second hub; and and decrypting the data within the second hub. A tenth aspect of the present invention is the method of the first aspect, further comprising a time parameter. An eleventh aspect of the present invention is the method of the tenth aspect, wherein the time parameters include a date and a time. A twelfth aspect of the present invention is the method of the tenth aspect, wherein the satellite system signals are used to determine the time parameter. A thirteenth aspect of the present invention is the method of the tenth aspect, further comprising adding a time parameter to the header of the packet. A fourteenth aspect of the present invention is the method of the thirteenth aspect, further comprising determining whether a time parameter in the header of the packet satisfies a first predetermined criterion. A fifteenth aspect of the present invention is the method of the first aspect, further comprising adding a sequence number to the header of the packet. A sixteenth aspect of the present invention is the method of the fifteenth aspect, further comprising reconstructing the data using sequence numbers in the packet headers. A seventeenth aspect of the present invention is the method of the first aspect, further comprising determining an error detection code corresponding to at least a portion of the packet. An 18th aspect of the present invention is the method of the 17th aspect, further comprising adding an error detection code to the header of the packet. A nineteenth aspect of the present invention is the method of the eighteenth aspect, comprising determining whether at least a portion of the packet is error-free by examining an error detection code in a header of the packet. A twentieth aspect of the present invention is the method of the first aspect, further comprising: determining whether at least one of the packet and the data meets a second predetermined criterion; and If the second predetermined criterion is met, the method includes communicating an affirmative character corresponding to at least one of the packet and the data to the first hub. A twenty-first aspect of the present invention is the method of the first aspect, further comprising: receiving, by a second hub, the at least one packet over a network through the at least one communication channel; and The method includes sending data from the second hub to at least one enterprise server. A 22nd aspect of the present invention is the method of the 1st aspect, wherein the act of packaging data from the medical device into at least one packet includes packaging data into the packet and another packet, the packet including a header, and the other packet including another header. A 23rd aspect of the present invention is the method of the 22nd aspect, further comprising: adding a first sequence number to the header of said packet; and adding a second sequence number to another header of the other packet. A twenty-fourth aspect of the present invention is the method of the twenty-third aspect, wherein the act of communicating the at least one packet over the network through one of the at least one communication channel of the first hub includes: communicating a packet over a first communication channel of the at least one communication channel of the first hub; and communicating another packet over a second one of the at least one communication channel of the first hub. A 25th aspect of the present invention is the method of the 24th aspect, further comprising: receiving the packet and the other packet; and reconstructing data according to a first sequence number of the packet and a second sequence number of the other packet. A 26th aspect of the present invention is the method of the first aspect, further comprising encrypting data by the medical device before communicating the data from the medical device to the first hub over a local area network. A 27th aspect of the present invention is the method of the 26th aspect, further comprising: receiving, by a second hub, at least one packet over the network through at least one communication channel; sending the data from the second hub to an enterprise server; and decrypting the data by the enterprise server for processing by the enterprise server. A 28th aspect of the present invention is the method according to any one of the first to 27th aspects, wherein the method is implemented in an application layer. A 29th aspect of the present invention is a hub comprising: a local area network interface component configured to communicate data with the medical device; a first system-on-module configured to interface with the first communication channel; a second system-on-module configured to interface with a second communication channel; and a processor configured to package data from the medical device into at least one packet; The at least one packet includes a header, and the processor is further configured to operatively communicate with one of a first and a second system-on-module to communicate the at least one packet over one of a first and a second communication channel. A 30th aspect of the present invention is the hub of the 29th aspect, wherein the first communication channel is a first cellular network and the second communication channel is a second cellular network. A thirty-first aspect of the present invention is the hub of the twenty-ninth aspect, wherein the processor is further configured to associate the hub with one of an identification value, a patient, a medical device, and a treatment. A thirty-second aspect of the present invention is the hub of the twenty-ninth aspect, wherein the processor is further configured to encrypt data. A thirty-third aspect of the present invention is the hub of the twenty-ninth aspect, wherein the processor is further configured to add a time parameter to a header of the packet. A thirty-fourth aspect of the present invention is the hub of the thirty-third aspect, wherein the time parameter includes one of a date and a time. A 35th aspect of the present invention is the hub of the 33rd aspect, further comprising a satellite system component, wherein the processor is configured to add a time parameter to the header using a time determined by the satellite system. A thirty-sixth aspect of the present invention is the hub of the twenty-ninth aspect, wherein the processor is further configured to add a sequence number to a header of the packet. A thirty-seventh aspect of the present invention is the hub of the thirty-sixth aspect, wherein the sequence numbers are configured to reconstruct data using sequence numbers in packet headers. A 38th aspect of the present invention is the hub of the 29th aspect, wherein the processor is further configured to add an error detection code corresponding to at least a portion of the packet to a header of the packet. A thirty-ninth aspect of the present invention is the hub according to the thirty-eighth aspect, wherein the error detection code is an error correction code. A 40th aspect of the present invention is a hub of the 29th aspect, wherein the processor is configured to package data into the packet and the other packet, the packet including a header and the other packet including a different header. A forty-first aspect of the present invention is the hub of the twenty-ninth aspect, further comprising a fail-safe bus configured to send a signal to medical devices coupled to the bus when a fault condition occurs in the hub. A forty-second aspect of the present invention is the hub of the twenty-ninth aspect, further comprising an alarm bus configured to send a signal to medical devices coupled to the bus when an alarm condition of the hub occurs. A forty-third aspect of the present invention is the twenty-ninth hub, further comprising a plain old telephone service component, wherein if the first and second communication channels are unavailable, the processor is configured to send packets through plain old telephone service. A forty-fourth aspect of the present invention is a system comprising: a first hub configured to communicate data to and from the medical device over the local area network and package the data into at least one application-layer packet; and The system includes a second hub configured to operably receive the at least one application layer packet from the first hub over at least one cellular network. A 45th aspect of the present invention is the system of the 44th aspect, wherein the second hub is configured to reconstruct data from the at least one application layer packet. A 46th aspect of the present invention is a system of the 44th aspect, wherein the first hub communicates the at least one application layer packet via a first and a second cellular network of the at least one cellular network. A 47th aspect of the present invention is the system of the 46th aspect, wherein the first hub is configured to balance and load the transmission of the at least one application layer packet between the first and second cellular networks. A 48th aspect of the present invention is the system of the 44th aspect, wherein the first hub is configured to encrypt data and the second hub decrypts data. A 49th aspect of the present invention is the system of the 44th aspect, further comprising an enterprise server, wherein the medical device is configured to encrypt data, the second hub is configured to send data to the enterprise server, and the enterprise server is configured to decrypt the data. A 50th aspect of the present invention is a method for manufacturing a semiconductor device comprising: 2. The system of claim 1, further comprising: the first hub includes a global positioning component configured to determine a time parameter using at least one global positioning signal; the first hub is configured to add a time parameter to an application layer packet header of the at least one application layer packet; and The second hub is the system configured to determine whether a time parameter meets a predetermined criterion. A fifty-first aspect of the present invention is a method for manufacturing a semiconductor device comprising: 50. A system according to the fiftieth aspect, comprising: the second hub includes another global positioning component configured to determine another time parameter using at least one global positioning signal; and The second hub is the system configured to determine whether a time parameter satisfies a predetermined criterion as a function of another time parameter. A 52nd aspect of the present invention is the system of the 44th aspect, the at least one application layer packet includes a first application layer packet; and The first hub is the system configured to add a corresponding error detection code to at least some of the first application layer packets. A 53rd aspect of the present invention is the system of the 52nd aspect, wherein the second hub is configured to use an error detection code to determine whether at least a portion of the first application layer packet is error-free. A 54th aspect of the present invention is the system of the 53rd aspect, wherein the error detection code is an error correction code, and the second hub is further configured to correct errors in at least some of the first application layer packets, if necessary. A 55th aspect of the present invention is the system of the 44th aspect, the at least one application layer packet includes a first application layer packet; and The system, wherein the second hub is configured to communicate an acknowledgment to the first hub if the first application layer packet meets predetermined criteria. A 56th aspect of the present invention is the system of the 44th aspect, further comprising an enterprise server, wherein the medical device is configured to encrypt data, and the second hub is configured to send data to the enterprise server, and the enterprise server is configured to decrypt the data. A 57th aspect of the present invention is the system of the 44th aspect, the at least one application layer packet includes first and second application layer packets; the first hub is configured to add a first sequence number to a first header of a first application layer packet and add a second sequence number to a second header of the second application layer packet; and The second hub is the system configured to reconstruct data according to the first and second sequence numbers. A 58th aspect of the present invention is the system of the 57th aspect, the first hub is configured to communicate the first application layer packets over a first cellular network of the at least one cellular network; and The first hub is the system configured to communicate the second application layer packets over a second cellular network of the at least one cellular network. A 59th aspect of the present invention is a method for manufacturing a semiconductor device comprising: 2. The system of claim 1, further comprising: the first hub includes an alarm bus component configured to provide an alarm status signal; and the medical device is operably connected to a first hub to receive an alarm condition signal, and when an alarm condition is received via the alarm condition signal, the medical device is configured to provide at least one mitigation measure. The system is as described above. A 60th aspect of the present invention is the system of the 44th aspect, the first hub includes a fail-safe component configured to provide a fatal error condition signal; and the medical device is operably connected to a first hub that receives a fatal error condition signal, and the medical device is configured to operate independently of the hub when a fatal error condition is indicated to exist via the fatal error condition signal; The system is as described above. A 61st aspect of the present invention is a method for manufacturing a semiconductor device comprising: The system of the 44th aspect, further comprising an enterprise server, the enterprise server being a transaction server. The system is as described above. A 62nd aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system as described in the present specification, claims, and drawings. A 63rd aspect of the present invention is a method for manufacturing a semiconductor device comprising: SUMMARY OF THE INVENTION An electronic patient care system as described herein, in the claims, and in the drawings. A 64th aspect of the present invention is a method for manufacturing a semiconductor device comprising: A pump substantially equivalent to the pump described in this specification, claims and drawings. A 65th aspect of the present invention is a method for manufacturing a semiconductor device comprising: A system substantially equivalent to the electronic patient care system described in this specification, claims, and drawings.

Claims

1. A hub having an alarm bus component, The alarm bus component An alarm condition occurs within the hub, and When the local area network is degraded, A hub configured to provide an alarm status signal from the hub to a medical device.

2. A hub as described in claim 1, configured to execute a fail-safe mode in response to the alarm condition.

3. The hub of claim 1, further comprising a processor configured to associate an identification value, a patient, the medical device, a treatment, and combinations thereof.

4. The hub of claim 1, further comprising a processor configured to package data from the medical device into packets.

5. A hub as described in claim 4, wherein the processor is configured to encrypt the data.

6. The hub of claim 4, wherein the data comprises a time parameter.

7. The hub of claim 4, wherein the data comprises an error detection code.

8. The hub of claim 4, wherein the processor is configured to package the packet into a second packet, the packet including a header, and the second packet including a second header.

9. The hub of claim 1, further comprising a failsafe bus component configured to provide a fatal error condition signal from the hub to the medical device when a fatal error fault condition occurs in the hub.

10. The hub of claim 9, configured to execute a fail-safe mode in response to the fatal error condition.

Images