Wireless Relay Module For Remote Monitoring Systems

Abstract

Systems and methods for communication include one or more wireless relay devices having a first receiver capable of wirelessly receiving medical device data over a wireless relay network from at least one network device, a first transmitter capable of wirelessly transmitting data over an internet-accessible wireless communications network and a second transmitter capable of wirelessly transmitting medical device data to a second medical device or a wireless relay module over the wireless relay network. Patient identification information can be obtained and/or communicated.

Description

FIELD

The present application is directed to systems and methods for communicating between a series of medical devices and remote monitoring devices, and more particularly, to a wireless relay module for receiving communications from and transmitting communications to medical devices via a wireless relay network, and for transferring the communications received from the remote monitoring devices via an internet-accessible wireless communications network.

BACKGROUND

In critical care and home care health service centers including hospitals, clinics, assisted living centers and the like, care giver-patient interaction time is at a premium. Moreover, response times by care givers to significant health conditions and events can be critical. Systems of centralized monitoring have been developed to better manage care giver time and patient interaction. In such systems, medical data from each patient is transmitted to a centralized location. At this centralized location, a single or small number of technicians monitor all of this patient information to determine patient status. Information indicating a patient alarm condition will cause the technicians and/or system to communicate with local care givers to provide immediate patient attention, for example via wireless pagers and/or cell phones, and/or by making a facility-wide audio page.

Implementing such centralized monitoring systems using wireless networks may present a number of difficulties. In order to effectively monitor patient status using information provided by a variety of medical devices that may be dynamically assigned to patients in a variety of rooms and on a variety of floors in a facility, it would be desirable to establish communications between the medical devices and the centralized location by means of a local area network such as, for example, a “WiFi” network based on IEEE 802.11 standards. However, as such networks are typically already in place in facilities to support a variety of other functions (for example, physician access to electronic medical records (EMRs), facility administrative systems and other functions), it is often undesirable to secure sufficient local area network access for the purpose of providing centralized monitoring. Moreover, when a patient is located remotely from a critical care health service center (for example, at home), access to traditional local area network facilities such as a WiFi network may be unavailable or not sufficiently reliable to support critical care monitoring applications.

SUMMARY

The present disclosure is directed to a wireless relay module for providing networked communications between a series of medical devices and remote monitoring devices. In accordance with embodiments of the disclosed technology, one or more medical devices (including but not limited to including for example, respirators, external feeding devices, pulse oximeters, blood pressure monitors, pulse monitors, weight scales and glucose meters) are provided at a patient facility. An interface circuit is coupled to each medical device, and is configured for communicating with at least one of a plurality of the wireless relay modules via a wireless relay network and/or with other medical devices. The wireless relay modules and medical devices are advantageously further configured to communicate with a remote monitoring device over an internet-accessible wireless communication network, and preferably, a wireless wide-area network (WWAN) such as a mobile telephone data network including (for example, based on a Global System for Mobile Communications (GSM) or Code Division Multiple Access (CDMA) cellular network or associated wireless data channels). Also, for compliance for example with HIPAA regulations, communications over each of the wireless networks are preferably conducted securely.

Systems and methods for providing communications between a medical device to be used by a patient and a remote monitoring device via an internet-accessible wireless communications network include obtaining identification information identifying the patient, obtaining identification information identifying the medical device transmitting each of the patient identification information and the medical device identification information to the remote monitoring device via the internet-accessible wireless communications network, receiving an acknowledgement status from the remote monitoring device via the internet-accessible wireless communications network; and transmitting data corresponding to an output of at least one sensor of the medical device for said patient by the medical device via the internet-accessible wireless communications network when the received acknowledgement status represents a particular status.

In a further aspect, the concepts, systems and techniques described herein are directed toward network architectures for providing networked communications between a series of medical devices and remote monitoring devices. In accordance with one illustrative embodiment, one or more medical devices including, for example, enteral feeding devices and systems, thermometers, pulse oximeters, respirators, blood pressure monitors, pulse monitors, weight scales and glucose meters) are provided at a patient facility. An interface circuit is coupled to each medical device, and is configured for communicating with one of a plurality of wireless relay modules via a wireless relay network. The wireless relay modules are further configured to communicate with a remote monitoring device over an internet-accessible wireless communication network, and preferably, a wireless wide-area network (WWAN) such as a mobile telephone data network, e.g. 3G or 4G network. Also, for compliance for example with HIPAA regulations, communications over each of the wireless networks are preferably conducted securely.

Each of the plurality of wireless relay modules includes a receiver capable of wirelessly receiving medical device data from respective interface circuits via the wireless relay network, a first transmitter capable of wirelessly transmitting medical device data to another one of the wireless relay modules over the wireless relay network, a second transmitter capable of wirelessly transmitting data over an internet-accessible wireless communications network; and a controller coupled to the first and second transmitters. The controller is configured to determine access status of the internet-accessible wireless communications network, and to select one of the first or second transmitters based on that status. For example, when the status indicates that the internet-accessible wireless communications network is accessible to the wireless relay module, the controller selects the second transmitter for transmitting medical device data transmitted by the interface circuit to the internet-accessible wireless communications network. When the status indicates that the internet-accessible wireless communications network is not accessible, the controller selects the first transmitter for transmitting the medical device data to another one of the wireless relay modules. In this manner, additional attempts to transmit the medical device data over the internet-accessible wireless communication network can be attempted by this other wireless relay module (and potentially additional ones of the wireless relay modules) until a successful transmission is achieved.

The wireless relay module may also advantageously communicate its status and the status of other wireless relay modules via the wireless relay network and over the internet-accessible wireless communications network. In addition, the wireless relay module may further include a second receiver for receiving data and commands from the internet-accessible wireless communications network for communicating to specific interface circuits and corresponding medical devices.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject of this disclosure will become more readily apparent from the Detailed Description, which proceeds with reference to the drawings, in which:

FIG. 1A is a block diagram of an embodiment of a medical device network architecture that incorporates a wireless relay module.

FIG. 1B is a block diagram of an embodiment medical device network architecture that incorporates a wireless relay module.

FIG. 1C is a block diagram of an embodiment medical device network architecture that incorporates a wireless relay module.

FIG. 1D is a perspective diagram of a personal enclosure for a medical device and/or a relay device.

FIG. 2A is a network diagram of a network including medical devices and/or relay devices.

FIG. 2B is a network diagram of a network including medical devices and/or relay devices.

FIGS. 3A-3D are block diagrams of embodiments of relay devices.

FIGS. 3E-3G are top, front, and side views of a relay device.

FIG. 3H is a diagram of a control panel associated with a relay device.

FIG. 3I is a diagram of a control panel associated with a relay device.

FIG. 4A and FIG. 4B are flow diagrams of processes for transmitting medical device data.

FIG. 4C is flow diagram of a process including determining module status.

FIG. 4D is a flow diagram of a process including determining WWAN status.

FIG. 4E is a flow diagram of a process including determining WLAN/WPAN status.

FIG. 4F is a flow diagram of a process including initiating a call to an emergency responder.

FIG. 4G is a flow diagram of a process including producing location data.

FIG. 4H is a table diagram of priority codes.

FIG. 5 is a flow diagram of a process including determining whether an interface device is accessible.

FIG. 6A and FIG. 6B are flow diagrams including producing an alert.

FIG. 6C is a flow diagram including transmitting a power alarm.

FIG. 6D is a flow diagram including transmitting a low battery alarm.

FIG. 7A is a flow diagram including sending a heartbeat request to a medical device.

FIG. 7B is a flow diagram including initiating patient/device synchronization.

FIG. 7C is a flow diagram including adding patient information to a local directory.

FIG. 8 is a flow diagram including logging in to a device set-up screen.

FIG. 9A is a flow diagram including displaying a list of active devices available.

FIGS. 9B-9D are screen displays for retrieving and viewing the medical data.

FIG. 10A is a flow diagram illustrating a method for issuing a command to a medical device via the remote monitoring system.

FIGS. 10B and 10C are screen displays for commanding a medical device.

FIG. 11A is a flow diagram illustrating a method for recognizing and reporting an alert condition according to medical data logged via the remote monitoring.

FIG. 11B is a screen display for selecting a recipient for receiving an alert message.

FIG. 12 is a block diagram of a computer or server device suitable for use in the remote monitoring system.

DETAILED DESCRIPTION

Reference will now be made in detail to embodiments of systems, apparatuses, and methods for communicating medical data, including the best modes contemplated by the inventors. Examples of these embodiments are illustrated in the accompanying drawings. While the systems, apparatuses, and methods are described in conjunction with these embodiments, it will be understood that it is not intended to limit the claims to the described embodiments. Rather, the claims are also intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the claims.

In the following description, specific details are set forth in order to provide a thorough understanding of the technology disclosed. The technology may be practiced without some or all of these specific details. In other instances, well-known aspects have not been described in detail in order not to unnecessarily obscure the description of the technology.

In this specification and the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood to one of ordinary skill in the art.

Further described herein is a network architecture for centralized monitoring of medical devices using wireless relay networks and/or internet-accessible wireless communications networks having emergency call functionality to provide a secondary level of protection when significant health conditions occur. The architecture in addition enables the approximate location of the monitored medical devices to be determined.

A schematic diagram of an architecture 100 for a system for monitoring medical devices is illustrated in FIG. 1. One or more medical devices 10 are provided at a patient facility 20 for monitoring the medical condition and/or administering medical treatment to one or more patients. Patient facility 20 may comprise a critical care health service center (for example, including hospitals, clinics, assisted living centers and the like) servicing a number of patients, a home facility for servicing one or more patients, or a personal enclosure (for example, a backpack) that may attached to and/or be worn by an ambulatory patient. Associated with each medical device 10 is an interface circuit 15 that includes a transceiver having one or more of a transmitter and/or a receiver for respectively transmitting and receiving signals in a facility-oriented wireless network such as, for example, a Low-Rate Wireless Personal Area Networks or “LR-WPAN,” ZIGBEE network or other low-power personal area networks such as a low power BLUETOOTH network, e.g. Bluetooth 4.0, existing or presently under development or consideration, for emulating a mesh network (such as ZIGBEE network) or otherwise. See, e.g., ZIGBEE Wireless Sensor Applications for Health, Wellness and Fitness, the ZIGBEE Alliance, March 2009, which is incorporated by reference herein in its entirety, for all purposes. See, also, Nick Hunn, Essentials of Short-Range Wireless, Cambridge University Press, 2010, which is also incorporated by reference herein in its entirety; See also Honda Labiod et al., Wi-Fi, Bluetooth, Zigbee and WiMax, Springer 2010, which is incorporated by reference herein in its entirety.

As illustrated in FIG. 1, a suitable access point 40 may include an inbound web server 41 that incorporates or otherwise has access to a transceiver for communicating with the relay modules 30a over the WWAN. Medical device data received by the inbound web server 41 over the WWAN is forwarded to a secure data storage server 42, which is configured for example to log the received data in association with identification information of the associated medical devices. As was previously described infra, “medical device data” and “data” as generally used herein means data from or about the medical device including, for example, medical device identification, medical device software, medical device settings or status information (including alarm information and/or alarm priority), patient identification information, patient personal identification number(s) “PIN(s)”, patient prescriptions, and/or patient medical and/or physiological data as is collected, produced and/or generated by the medical device.

An outbound web server 43 (which may be associated with access point 40) is configured, for example, to receive and qualify data retrieval requests submitted by one or more of remote monitoring devices 61, 62 and 63 over a broad-band network 50 (for example, over the Internet), to request associated medical device data to be retrieved from the secure data storage server 42, and to format and transmit the retrieved data to the one or more remote monitoring devices 61, 62 and 63 for display on associated device displays. It should be understood that any architecture for the access point 40 that enables the receipt, storage and retrieval of medical device data on a device display of the one or more remote monitoring devices 61, 62 and 63 is intended to be included within the scope of the technology disclosed here. Variations of the architecture may involve utilizing a web server integrated with a data storage server. For example, storage server 42 may be integrated into the outbound web server 43. Further alternative configurations may for example involve a plurality of mirror storage servers 42 each storing medical device data, and accessible as a plurality of outbound web servers 43.

For compliance with HIPAA regulations, communications over each of the facility-oriented wireless network and WWAN are preferably conducted securely using, for example, using a Secure Sockets Layer (SSL) protocol or a Transport Layer Security (TLS) protocol.

Referring to FIG. 1B, a diagram of another embodiment of a system 100B for monitoring medical devices is illustrated. Some or all of the elements shown in FIG. 1B may be the same as or similar to the elements in FIG. 1. One or more medical devices 10 are provided at a patient facility 20 for monitoring the medical condition and/or administering medical treatment to one or more patients. Patient facility 20 may comprise a critical care health service center (for example, including hospitals, clinics, assisted living centers and the like) servicing a number of patients, a home facility for servicing one or more patients, or a personal enclosure (for example, a backpack) that may be attached to or worn by an ambulatory patient. Examples of medical devices include, but are not limited to, include ventilators, urology devices, energy delivery devices, pulse oximeters, predictive thermometers, tympanic thermometers, patient electrodes, and food pumps.

Associated with each medical device 10 is an interface circuit 15 that includes a transceiver having one or more of a transmitter and/or a receiver for respectively transmitting and receiving signals in a facility-oriented wireless network 17 such as, for example, a Low-Rate Wireless Personal Area Networks or “LR-WPAN,” ZIGBEE network or another low-power personal area network such as a low power Bluetooth network, existing or presently under development or consideration. See, e.g., Houda Labiod et al., Wi-Fi, Bluetooth, Zigbee and WiMax, Springer 2010, which is incorporated by reference herein in its entirety. It should be understood that interface circuit 15 may be contained within or disposed external to medical device 10.

Also provided within the patient facility 20 are one or more relay modules 30a. Each relay module 30a may include a first transceiver for receiving signals from and transmitting signals to the interface circuits 15 in the facility-oriented wireless network 17, and further include a second transceiver for wirelessly transmitting signals to and receiving signals from an access point 40 via a wireless wide-area network (“WWAN”) 52. Suitable WWANs include, for example, networks based on a Global System for Mobile Communications (GSM) or Code Division Multiple Access (CDMA) cellular network or associated with the 2G, 3G, 3G Long Term Evolution, 4G, WiMAX cellular wireless standards of the International Telecommunication Union Radiocommunication Sector (ITU-R). See, e.g., Vijay Garg, Wireless Communications & Networking, Morgan Kaufmann 2007, which is incorporated by reference herein in its entirety. For compliance with HIPAA regulations, communications over each of the facility-oriented wireless network and WWAN are preferably conducted securely using, for example, a Secure Sockets Layer (SSL) protocol or a Transport Layer Security (TLS) protocol or other cryptographic protocols.

As illustrated in FIG. 1B, the access point 40 includes an inbound server (“device integration server”) 41 that incorporates or otherwise has access to a transceiver for communicating with the relay modules 30a over the WWAN. Medical device data, medical device identifier, and/or patient identifier received by the device integration server 41 over the WWAN is forwarded to a secure device web server 45, which is configured for example to log the received data in association with identification information of the associated medical devices in a device control database 44. “Medical device data” as generally used herein includes data from or about the medical device including, for example, medical device identification, medical device software, medical device settings or status information (including alarm information and/or alarm priority), patient identification information, patient personal identification number(s) “PIN(s)”, patient prescriptions, and/or patient medical and/or physiological data as is collected, produced and/or generated by at least one of the medical device and patient identification device; as well as wireless relay network information such as location or status information.

An outbound web server 43 is configured, for example, to receive and qualify data retrieval requests submitted by one or more of first remote monitoring devices 62 over a broad-band network 50 (for example, over the Internet), and/or second remote monitoring devices 73, 75 over a wired or wireless wide area network. It is advantageous for such requests be made in an encrypted format. Suitable encryption formats useable for such requests may include, for example, formats compliant with the HIPAA regulations described above. For each qualified request, the outbound web server 43 requests associated medical device data or portions thereof to be retrieved from the device control database 44 via the secure device web server 45, requests associated program data for constructing a display page from a metadata and applications database 46, and requests associated patient data to be retrieved from a patient database 66 provided in a patient care database node 60 over a secure link 54 via a secure patient web server 64. The secure link 54 can be implemented, for example as another WWAN using a SSL protocol or a TLS protocol. By separating medical device data and patient data to be respectively stored and managed by access point 40 and patient care database node 60, certain economies of scale can be achieved by configuring the access point 40 to support a number of different patient care facilities each maintaining its own secure patient care database node 60 to ensure privacy and control of its associated patient data.

In this case, for example, a third party service provider may host the access point 40 to simultaneously support a number of distinct patient and/or home care facilities, thereby eliminating the need for each of these facilities to configure and maintain their own private access point facilities and providing hosting service to each facility that are likely far less than the costs of configuring and maintaining dedicated access point facilities by each care facility provider. It should be noted however that access point 40 and patient care database node 60 may nevertheless be integrated into a single access point or node (for example, by a provider of a very large-scale facility provider monitoring many hundreds or thousands of patients). In either case, and as further described herein, the outbound web server 43 provides an interface for authenticated clinicians or other monitoring personnel to retrieve patient and medical device data from each of the patient care database node 60 and the access point 40 in a convenient and transparent manner such that the details of the configurations and operation of the access point 40 and patient care database node 60 are of no consequence to the clinicians or other monitoring personnel.

The first remote monitoring devices 67 are intended to be used by healthcare providers such for example, clinicians, physicians, technicians, nurses and other healthcare specialists monitoring patients associated with medical devices 10. Suitable first remote monitoring devices 67 may include, for example, desktop or laptop computers, tablet computer smart or other mobile phones, or other fixed or portable display devices. The second remote monitoring devices 73, 75 are advantageously intended to be used by caregivers and/or relatives of the patient such as parents, located proximate the patient such as in a homecare environment or small healthcare facility, or nurses at a larger healthcare facilities, e.g., hospitals. Suitable second remote monitoring devices 73, 75 likewise may include, for example, desktop or laptop computers, tablet computer, smart or other mobile phones, or other fixed or other portable communication devices.

In addition, the outbound web server 43 is depicted coupled to a network status server 80, which monitors the status of the facility-oriented wireless network 17 and associated medical devices 10. The network status server 80 is intended to provide status information concerning the facility-oriented wireless network 17 and associated medical devices 10 to the outbound web server 43. Status information concerning the facility-oriented wireless network 17 includes, for example, signal strength, data rates, particular transmission time stamps between modules comprising the network 17, number active relay modules in the network 17, unique identifier number for a particular relay module of the network 17.

The network status server 80 may be implemented in hardware or software running on an application specific or general purpose processor or computer, as part of or separate from the outbound web server 43. In addition, the network status server 80 is shown coupled to the outbound web server 43 for ease of illustration and discussion purposes only. The network status server 80 may be coupled to any component or network of the access point 40 or facility-oriented wireless network 17.

In FIG. 1B, upon retrieving the requested medical device data and patient data from the patient care database node 60, the outbound web server 43 then proceeds to format and transmit the retrieved medical device data and patient data (and/or provide status information concerning the facility-oriented wireless network 17 and associated medical devices 10) as respective webpages or other formats for display by corresponding first and second remote monitoring devices 67, 73, 75 according to the retrieved program data. It is possible for the webpages or other formatted information for display to include the same or differing content and format for the intended remote monitoring device user depending upon the retrieved program data. For example, the detailed medical device data provided to and displayed on a first remote monitoring devices 67 for a clinician may differ from the less detailed information provided to and displayed on a second remote monitoring devices 73 monitored by a parent or visiting nurse or other healthcare professional in a homecare environment. The status information concerning the facility-oriented wireless network 17 and associated medical devices 10 may advantageously be provided to first and/or second remote monitoring devices 67, 73 and 75 in the same or different encrypted formats as may be deemed appropriate.

In addition, and as will be further described herein, the device integration server 41 of FIG. 1B is configured to transmit information and commands to the relay modules 30a, for example, for transmitting medical device or alert messages to other WWAN-reachable nodes (for example, cellular telephones of emergency attendants), and/or transmitting operating commands and/or software or firmware updates to the medical devices 10 via the interface circuits 15 and facility-oriented wireless network 17.

Further, in addition to monitoring and sending commands to medical devices, the device integration server 41 may also be configured to receive and analyze patient metric information from the secure patient web server 64 via the outbound web server 43 and secure device web server 45, or by an alternate and direct secure data link to the secure patient web server 64 in order to prevent unsafe medical device usage based upon the patient metrics information. It is possible for a database (not depicted) accessible, for example, by the device integration server 41 and/or device web server 45, to store various safe and unsafe operating parameters and conditions for performing such analysis. In this manner, the device integration server 41 would function as an additional failsafe for preventing operating errors that could result in patient harm.

For example, in the case that the patient metric information indicates that an enteral feeding pump is associated with a neonate, the device integration server 41 may act, for example, to (1) discard remote monitoring commands programming large bolus or excessive feeding rates that could be harmful to a young child; and (2) provide a warning message or other notification to the user of the likely unsafe usage condition that may result by implementation of such comment. Alternatively, if the patient metric information indicates that a specific feeding rate or bolus amount has been prescribed by a doctor or clinician, then the device integration server may act to discard remote monitoring commands programming a rate or bolus that deviates from the prescription.

As illustrated in FIG. 1C, another embodiment of an architecture 100C may further include one or more wireless patient identification devices 17 in communication with one or more of the relay modules 30a and/or medical devices 10 in proximity to the patient identification device 17 via the interface circuits 15 and 17a operating over the facility-oriented wireless network. Alternatively, a wireless patient identification receiver may be integrated with each medical device 10, and access the facility-oriented wireless network via an associated interface circuit 15. The wireless patient identification devices 17 each receive patient identification data from a patient in proximity to the device 17 that uniquely identifies the patient using one of a variety of commercially-available sensors. For example, each patient identification device 17 may include a camera or other optical scanner and associated circuitry for sensing a barcode (for example, a UPC code or a QR matrix barcode) attached to or otherwise uniquely associated with a patient, such as a patient's wristband. Alternatively, each patient identification receiver 17 may include a radio-frequency identification (RFID) sensor and associated circuitry for sensing an RFID tag embedded in the patient wristband, or another commercially-available radio-frequency sensor capable of sensing an identification signal generated by a radio-frequency transmitter embedded in the patient wristband or otherwise provided as attached to or in proximity to the patient. Finally, each device 17 may in addition or instead include a commercially-available biometric sensor and associated circuitry for patient identification (for example, including one or more of a fingerprint reader, a retinal scanner or a vein-pattern scanner).

For improved efficiencies in centralized monitoring of critical care and home care health service centers, it may be desirable to provide a single “off-site” centralized monitoring location for monitoring several geographically-dispersed critical care health service centers. The architecture 100 of FIG. 1A has a suitable access point 40 that includes an inbound web server 41 that incorporates or otherwise has access to a transceiver for communicating with the relay modules 30a over the WWAN. Medical device data received by the inbound web server 41 over the WWAN is forwarded to a secure data storage server 42, which is configured for example to log the received data in association with identification information of the associated medical devices. An outbound web server 43 is configured, for example, to receive and qualify data retrieval requests submitted by one or more of remote monitoring devices 61, 62 and 63 over a broad-band network 50 (for example, over the Internet), to request associated medical device data to be retrieved from the secure data storage server 42, and to format and transmit the retrieved medical device data to the one or more remote monitoring devices 61, 62 and 63 for display on associated device displays. It should be understood that any architecture for the access point 40 that enables the receipt, storage and retrieval of medical device data on a device display of the one or more remote monitoring devices 61, 62 and 63 is suitable for use in conjunction with the disclosed concepts.

As was previously described infra, “medical device data” and “data” as generally used herein means data from or about the medical device including, for example, medical device identification, medical device software, medical device settings or status information (including alarm information and/or alarm priority), patient identification information, patient personal identification number(s) “PIN(s)”, patient prescriptions, and/or patient medical and/or physiological data as is collected, produced and/or generated by at least one of the medical device and patient identification device.

Thus, and as will be further described herein, the remote monitoring system of FIG. 1C is capable of obtaining patient identification information to be associated with a particular medical device, securely transmitting the patient identification information with medical device identification information of the associated medical device to verify that the association of the patient with the medical device is authorized, and beginning operation of the medical device and monitoring of medical data generated by the medical device once authorization has been received.

FIG. 1D illustrates a backpack 70 as may be suitable for use as a personal enclosure. The backpack 70 includes a pouch 71 for housing a relay module 30a, a pouch 72 for housing a power and charging circuit 39d for providing power to the relay module 30a, and a power cord 39e for supplying power from the power and charging circuit 39d to the relay module 30a. As depicted, the power and charging circuit 39d includes a battery compartment 39f, and a charging circuit (not shown) and a power cord 39g for providing external commercial AC power to the power and charging circuit 39d in order to charge batteries in the battery compartment 39f. One of ordinary skill in the art will readily appreciate that the backpack 70 provides but one of a number of suitable backpack arrangements.

FIG. 2A presents a block diagram that further illustrates components of the inventive architecture that are located within or otherwise associated with the patient facility 20. In FIG. 2, a number of interface circuits 15 and relay modules 30, 30a are arranged in a network 16, which may be a wireless relay network or mesh network 16 within the patient facility 20. It should be understood that network 16 is shown for illustration purposes only; other interface circuits 15 and relay modules 30, 30a may communicate over other wireless relay networks that are the same as or similar to network 16 in the patient facility 20.

In FIG. 2, the interface circuits 15 and relay modules 30, 30a are configured to communicate with one another via associated wireless links. In an embodiment represented in FIG. 2, the network 16 is a self-configurable mesh network and can also be a self-healing mesh network, for example a ZIGBEE compliant-mesh network based on the IEEE 802.15.4 standard. However, the wireless relay network 16 or additional wireless relay networks in the patient facility may be organized according to a variety of other wireless local area network (WLAN) or WPAN formats including, for example, WiFi WLANs based on the IEEE 802.11 standard and BLUETOOTH WPANs based on the IEEE 802.15.1 standard.

Each of the relay modules 30, 30a includes at least one transceiver configured to communicate with other relay modules 30, 30a in the wireless relay network 16. Relay modules 30a also may include at least a second transceiver for communicating over the WWAN with the access point 40. As further described in greater detail with regard to FIG. 3A-3D, each relay module 30 and/or 30a of FIG. 2A includes a first transceiver 31 for receiving signals from and transmitting signals to the interface circuits 15 in one or more of the facility-oriented wireless networks. Relay module 30a, as depicted in FIG. 3A for example, corresponds to relay modules 30 or 30a in FIG. 2A and may include a second transceiver 32 for wirelessly transmitting signals to and receiving signals from an access point 40 via a wireless wide-area network or “WWAN”. Suitable WWANs include, for example, networks based on a Global System for Mobile Communications (GSM) or Code Division Multiple Access (CDMA) cellular network or associated with the 2G, 3G, 3G Long Term Evolution, 4G, WiMAX cellular wireless standards of the International Telecommunication Union Radio communication Sector (ITU-R). Additional suitable WWANs include metropolitan area networks (MANs), campus area networks (CANs), local area networks (LANs), home area networks (HANs), personal area networks (PANs) and body area networks (BANs). It should be readily understood that the relay module 30a may include additional transceivers for communicating with additional WWANs or additional facility-oriented wireless networks.

As shown in FIG. 2B, the architecture may further include one or more wireless patient identification devices 17 in communication with one or more of the relay modules 30a and/or medical devices 10 in proximity to the patient identification device 17 via the interface circuits 15 and 17a operating over the facility-oriented wireless network. Alternatively, a wireless patient identification receiver may be integrated with each medical device 10, and access the facility-oriented wireless network via an associated interface circuit 15. The wireless patient identification devices 17 each receive patient identification data from a patient in proximity to the device 17 that uniquely identifies the patient using one of a variety of commercially-available sensors. For example, each patient identification device 17 may include a camera or other optical scanner and associated circuitry for sensing a barcode (for example, a UPC code or a QR matrix barcode) attached to or otherwise uniquely associated with a patient, such as a patient's wristband. Alternatively, each patient identification receiver 17 may include a radio-frequency identification (RFID) sensor and associated circuitry for sensing an RFID tag embedded in the patient wristband, or another commercially-available radio-frequency sensor capable of sensing an identification signal generated by a radio-frequency transmitter embedded in the patient wristband or otherwise provided as attached to or in proximity to the patient. Finally, each device 17 may in addition or instead include a commercially-available biometric sensor and associated circuitry for patient identification (for example, including one or more of a fingerprint reader, a retinal scanner or a vein-pattern scanner).

In the illustrated wireless relay network 16, each of the interface circuits 15 includes a communications interface such as, for example, a wired or wireless communications interface, to an associated medical device 10. In addition, each of the relay modules 30, 30a includes at least one transceiver configured to communicate with other relay modules 30, 30a in the wireless relay network 16. Relay modules 30a further include at least a second transceiver for communicating over the WWAN with the access point 40.

Each of the transceivers 31, 32 will typically include a mesh network transmitter (e.g. a ZIGBEE transmitter) for transmitting medical device data over one of the mesh network 16 or the WWAN, and a received for receiving medical device data transmitted over one of the mesh network 16 or the WWAN.

In accordance with IEEE 802.14.15, if the network 16 is a ZIGBEE mesh network then there is little risk that communications from more than one medical device will contend for simultaneous access to the network 16. The network 16 operates with a protocol in which a transmitting device checks for energy on a wireless bus component of the network 16. If the bus is in use, the transmitting device waits a preselected amount of time before checking again, and only proceeds to transfer data when the energy level suggests that no other transmission is actively underway on the wireless bus. Nevertheless, for circumstances in which data packets transmitted by the medical devices 10 arrive at a relay module 30, 30a at nearly at the same time, there may be a need to manage an order of delivery by the relay module 30.

The representative ZIGBEE mesh network 16 provides the advantages of being self-configurable when one or more interface circuits 15 and/or relay modules 30, 30a are added to the network, and self-healing when one or more interface circuits 15 and/or relay modules 30, 30a are removed from or otherwise disabled in the network. Sub-groupings of the interface circuits 15 and relay modules 30, 30a may be provided in a defined geographic space (for example, on an individual floor or within a region of a floor in a multi-floor home or care facility).

Referring to FIGS. 3A-3D, block diagrams illustrating components of embodiments of a relay module 30a are shown. The relay module 30a of FIG. 3A includes a first transceiver 31 for wirelessly communicating with interface circuits 15 and other relay modules 30, 30a in the WLAN or WPAN network 16 of FIG. 2A via an antenna 31a. A transceiver as contemplated in this description may include a receiver and/or transmitter. The relay module 30a further includes a second transceiver 32 for wirelessly communicating with the access point 40 over the WWAN via an antenna 32a. Each of the transceivers 31, 32 is in communication with a data processing circuit 33, which is configured to operate under the control of a processor 34 to accept data received by the transceivers 31, 32 and store the received data in a buffer element 35. One or more of the data processing circuit 33 and/or controller 34 may also preferably include commercially available encryption circuitry for encrypting data to be sent by the transceivers 31, 32 and to decrypt data received by the transceivers 31, 32, in accordance for example with HIPAA requirements. One or more of the data processing circuit 33 and/or controller 34 may also preferably include commercially available encryption circuitry for encrypting data to be sent by the transceivers 31, 32 and to decrypt data received by the transceivers 31, 32, in accordance for example with HIPAA requirements

Each rely module 30, 30a is capable of communicating with a number of medical devices 10 over a period of time. It is possible that communications with some of the medical devices 10 are more time-critical with regard to patient safety than other. For example, consider communications with medical devices 10 including each of a thermometer, a feeding pump and a ventilator. In this case, communications with the ventilator would likely be most time-critical among the three medical devices, while communications with the thermometer might be least time-critical among the three medical devices.

According to an embodiment, the processor 34 is configured to determine whether the received medical device data indicates an emergency condition. This determination may be performed by the processor 34 in a number of ways. For example, the processor 34 may compare a condition code in the received medical device data to a condition table located in memory 35b that, for example, includes one or more of corresponding codes for the emergency condition, a description of the emergency condition, symptoms of the emergency condition, an estimate of a future time at which the emergency condition may become harmful (or emergency condition harm time), rankings and/or weights for the emergency condition, related emergency conditions, physiological data (e.g., vital signs, blood pressure, pulse oximetry, ECG, temperature, glucose levels, respiration rate, weight, etc.) indicative of the medical condition, and so on. One form of the possible table is described with reference to FIG. 5C, which will be discussed below.

Longer term data storage may preferably be provided by a memory 35b, for example storing instructions for the controller 34, data encryption/decryption software for one of more of the data processing circuit 33 and/or controller 34, a patient identification directory identifying patients using each of the medical devices 10, and the like.

The data in the condition table may be initially entered and/or periodically refreshed from a master store or central repository of emergency condition data, for example, maintained by a designated relay module 30, 30a or other device accessible over one of the available networks. Associated emergency condition data may be periodically transmitted on a scheduled or as-needed basis, for example, from the access point 40 to each of the relay modules 30, 30a. Additionally, polling may be carried out, for example, by the central repository to determine whether any of the relay modules has been provided with emergency condition data not available in the central repository. This emergency condition data may then periodically be transmitted to the central repository, and the central repository may in turn transmit the data to the other modules that may be missing such data. In this way, the exchange of information between the central repository and the relay modules is bidirectional, thus ensuring all modules and the central repository are synchronized with the same emergency condition data. To avoid conflicts, emergency condition data may be time stamped or provided with another indicator of data currency. If a central repository is not used, the modules may exchange emergency condition information between themselves to ensure each module is synchronized. Other embodiments are possible, for example, using multiple central repositories according to conditions monitored, geographic location, and the like.

According to one embodiment, rankings and/or weights may be applied by the processor 34 to assign priority to different emergency conditions and/or perform a triage. For example, the processor 34 on receipt of multiple pieces of medical device data from different transceivers located in the same geographic location or a number of different geographic locations could determine that one medical device requires more immediate medical attention than the others. The priority analysis may also be performed, for example, using the emergency condition harm times.

For example, consider a data packet from a ventilator indicating disconnection from a comatose patient, with possible fatality. In this case, the ventilator should be assigned priority for transmitting to one or more of remote monitoring devices 61, 62 and 63 (as shown in FIG. 1), while data transmissions from thermometer and pump are discontinued until a response to the data packet transmitted by the ventilator is received from one of the remote monitoring devices 61, 62 and 63. For example, the ventilator might be assigned a priority of 1, while the feeding pump is assigned a priority of 2 and the thermometer is assigned a priority of 3. The assigned priority is preferably indicated in each data packet transmitted by and to the medical devices, for example, as a “priority nibble.”

With reference to FIGS. 3 and 3A-3D, the processor 34 may be configured to read the priority nibble from each received data packet, and to instruct the data processing circuit 33 to place the data packet at a logical position in the buffer element 35 based upon the priority designation. For example, critical-priority data packets (for example, data packets including an indication of a life threatening condition) for the ventilator would be positioned for first retrieval and transmission by the relay module 30, 30a, and other data packets are positioned in order according to their priority.

In addition, under circumstances where urgent commands may need to be transmitted by one of the remote monitoring devices 61, 62 and 63 anticipated based on an urgent data packet (for example, a data packet including an alarm) from the ventilator, the wireless relay module 30, 30a may in addition discontinue reception of any new medical device information from other medical devices until the urgent commands are relayed and an associated alarm condition has been terminated or released.

In one embodiment, it is possible that the medical device data analyzed by the processor 34 may not match any of the emergency conditions in the table and/or database because there is a misspelling and/or the medical condition is known by other names and/or represents a new medical condition. In this scenario, the processor 34 may, for example, perform a similarity analysis between the medical device data received and the symptoms and/or physiological data in the table and/or database (see, e.g., the disclosure herein supra in reference to FIG. 4D). Based on this similarity analysis, the processor 34 may select, if any, the emergency condition that closely approximates the medical device data. Also, the processor 34 may in addition or alternatively log the medical device data to a database and/or file to allow administrators to determine why the emergency condition did not match an exact emergency condition in the table and/or database.

According to another embodiment, in order to make processing more efficient, the processor 34 may compare the medical device data received at the transceiver to a list of prior determined emergency conditions and determine if there is a match or approximate match based on conventional interpolation and/or extrapolation techniques. In another embodiment, the processor 34 may also parse the medical device data to find a code which indicates that an emergency condition exists. Alternatively, the processor 34 may search a table and/or database located in a central repository to determine if the medical device data received indicates an emergency condition. In a another embodiment, the processor 34 in a relay module 30 and/or 30a may query a processor 34 in another device (not the central repository) to determine if that other device knows whether the medical device data includes emergency condition data representing an emergency condition.

Once an emergency condition is determined and an alarm condition is activated by the processor 34 of the relay module 30a, a message may be transmitted to an access point 40 by the relay module 30a (as shown in FIGS. 1 and 2), where the message is parsed to determine if alarms should be activated. The alarms could be anything from certain signals to care givers associated with the one or more medical devices which originated the alarms or alerting emergency responders.

A monitoring unit 37b (see e.g. FIG. 3B) may also be associated with the processor 34, and responsible for identifying trends in emergency conditions. The monitoring unit 37b may store the emergency conditions data received, the date/time, an identity of the medical device which provided the data, the location of the medical device, and so on. Using the emergency condition data and/or additional medical device data, the monitoring unit 37b may analyze the data for trends. This trend information may be used, for example, to determine whether one or more medical devices should be monitored. In addition, the trend information may be communicated to one or more devices (for example, PDAs, cell phones, pager, tablets, and the like) associated with relatives, friends, or caregivers and the like, who may use the knowledge to provide more efficient care.

Upon making a determination that an emergency condition exists, the processor 34 may transmit a message to a phone device 39a (discussed below and shown in FIG. 3D) to activate it and also initiate a connection (e.g., phone call, etc.) with an emergency responder, such as 911, relatives/friends, care givers, or police authorities, and the like. When a call is received by the emergency responder, an automated voice message may be transmitted to the emergency responder as a prerecorded message stored in a signal generator 39b (which is coupled to the phone device 39a and the processor 34). Preferably, the prerecorded message identifies an associated medical condition along with the location of the medical device. Alternatively, the signal generator 39b may generate a dynamic speech signal that contains the determined emergency condition and other information

The prerecorded or dynamic message described above may in addition include other relevant patient data to further allow the emergency responders to assess the situation. For example, a patient table stored at the relay module (or alternatively/in addition at the centralized location) may identify care givers of the patient, other present conditions of the patient, previous medical history (e.g., allergic to certain drugs, such as morphine), and additional relevant patient information. Preferably, storage and use of the data in the patient table would conform to HIPAA requirements. As an alternative to these voice messages, the signal generator 39b may transmit medical condition information in the form of a text message to the emergency responder. For example, a text message may be sent over one of a Short Message Service (also known as “SMS”) and/or Multimedia Messaging Service (also known as “MMS”).

The phone device 39a above could be connected via one or more of wireless relay network or internet-accessible wireless network to initiate the call over a voice over internet protocol (VoIP) network, a Public Switched Telephone Network (PSTN), or the like.

The call to the emergency responders may be unsuccessful for a variety of reasons (for example, associated E911 circuits may be busy or otherwise unavailable). In this situation, the processor 34 and/or phone device 39a may detect a non-response from the E911 circuits and transmit a non-response message to one or more of the medical device, the access point 40, and/or one or more other designated devices to indicate the unsuccessful call. In addition, the processor 34 may periodically perform self-diagnostics on the relay module 30a to confirm that each of the components of the modules 30a that is used to detect the emergency condition and make the emergency call is operational Of course while a single processor 34 is described, multiple processors 34 may be used in as appropriate.

The location of the medical device may be determined in a variety of ways well-known in the art. For example, location information may be provided to the processor 34 from a global positioning system signal (“GPS”) that is received and interpreted by the medical device located in the medical device data received, a GPS chip in the location device 38 (see e.g. FIGS. 3B and 3C), and/or location algorithm in the location device 38 discussed further below. In another embodiment, (e.g., location) as discussed above.

As discussed above, location information may be included in the medical condition data received by one of the relay modules 30, 30a to identify the location of the one or medical devices 10. Alternatively, the relay modules' location may also be determined using a conventional GPS receiver provided in the location device 38. In the latter case, at least an approximate or “zone” location of the one or more medical devices would be provided by the location information for the relay module 30a.

As an alternative to GPS-based location, each of the relay modules 30a may for example transmit and receive signals via the internet-accessible wireless communication network to two or more cell towers, beacons or other radio devices at fixed, known locations in order to determine a location of the relay module according to known geometric methods. Such techniques for determining location (for example, including triangulation form cell towers) are well known in the art. See, e.g., Shu Wang et at Location-Based Technologies for Mobiles: Technologies and Standards, presentation at IEEE ICC Beijing 2008, IEEE, 2008, which is incorporated by reference herein in its entirety, for all purposes. In one embodiment, triangulation may be carried out using other relay modules positioned at fixed, known locations in a facility.

The data processing circuit 33 may be further configured to retrieve data from the buffer element 35a under the direction of the processor 34 and provide the retrieved data to a selected one of the transceiver 31 or transceiver 32 for transmission. In order to make a selection, the processor 34 is configured to communicate with respective status modules 31b, 32b of the transceivers 31, 32 in order to determine a communications status of each of the transceivers 31, 32.

FIG. 3B depicts a block diagram illustrating components of an alternative configuration for the relay module 30a to the configuration of relay module 30a depicted in FIG. 3A. The relay module 30a shown in FIG. 3B may be the same as or similar to the relay module 30a shown in FIG. 3A. For example, transceivers 31 and 32, data processing circuit 33 and processor 34 may be the same or similar in both figures. The relay module 30a includes transceiver 31 for wirelessly communicating with interface circuits 15 (shown in FIGS. 1 and 2) and other relay modules 30, 30a in a particular WLAN or WPAN network 16 (shown in FIG. 2) via antenna 31a. The relay module 30a further includes a transceiver 32 for wirelessly communicating with the access point 40 over a particular WWAN (shown in FIG. 2) via an antenna 32a.

Added components to the relay module 30a in 3B that are not present in FIG. 3A include an additional transceiver 37, similar to transceiver 31, for wirelessly communicating via antenna 37a with interface circuits and other relay modules capable of communicating over a different WLAN or WPAN network than the network used by transceiver 31. Correspondingly, the relay module 30a in FIG. 3A includes yet a further transceiver 38, similar to transceiver 32, for wirelessly communicating via antenna 38a with an access point over a different WWAN than the WWAN used by transceiver 32.

Each of the transceivers 31, 32, 37 and 38 is in communication with data processing circuit 33, which is configured to operate under the control of processor 34 to accept data received by the transceivers 31, 32, 37 and 38 and store the received data in buffer element 35. In addition, the data processing circuit 33 is further configured to retrieve data from buffer element 35 under the direction of processor 34 and provide the retrieved data to a selected one of the transceivers 31, 32, 37 or 38 for transmission. Further embodiments can for example involve one or more processors 34 configured to accept medical device data from mesh network 16 and to send the medical device data through the WWAN without storing the medical device data in the relay module 30a. In order to make a selection, the processor 34 is configured to communicate with respective status modules 31b, 32b, 37b and 38b of respective transceivers 31, 32, 37 or 38 in order to determine a communications status of the transceivers 31, 32, 37 or 38. It should be understood that the data processing circuit 3 and processor 34 may be implemented as separate integrated circuits or chip sets or their functions may be combined and implemented on single integrated circuits or chip set

The processor 34 is also preferably in communication with an input/output circuit 36, which provides signals to one or more display elements of the relay module 30a, for example, for indicating a start-up or current status of the relay module 30a, including communication or connection status with the WLAN or WPAN networks and WWANs networks. Input/output circuit 36 may also be configured to provide signals to indicate an A/C power loss, and or to be responsive to signals provided by one or more input devices provided in proximity to the one or more display elements.

A control panel useable for the module 30a of FIG. 3B may be substantially similar to the control panel 380 depicted in FIG. 3H with corresponding multiple indicators 380e for indicating the status of the different WLAN or WPAN networks, and/or multiple indicators 380j for indicating the status of the different WWANs. The control panel 380 may include a synchronization switch 380k (shown in FIG. 3I), which may be used as further described herein to initiate a process for associating patient identification information with identification information of a medical device 10.

The processor 34 is also preferably in communication with a memory 35b for storing an operating program of the processor 34 and/or data stored by and/or retrieved by the processor 34. The processor 34 is also in communication with an input/output circuit 36, which provides signals to one or more display elements (not shown) of the relay module 30a, for example, for indicating a start-up or current status of the relay module 30a, including communication or connection status with the WLAN or WPAN network 16 and WWAN. The input/output circuit 37a may also be configured to provide signals to indicate an A/C power loss, and or to be responsive to signals provided by one or more input devices provided in proximity to the one or more display elements. The input/output circuit 37a may also be connected to user buttons, dials or input mechanisms and devices of module 30a. The input/output circuit 37a is further usable for providing alarm signals to indicate, for example, A/C power loss or loss of accessibility to the WWAN.

Relay module 30a may preferably be provided as a small physical enclosure with an integral power plug and power supply circuit, such that the relay module 30a may be directly plugged into and supported by a conventional wall outlet providing commercial A/C power. Relay module 30a may also preferably include a battery back-up circuit (not shown) to provide uninterrupted power in the event of A/C power outage, an A/C power outage of short duration as well as for ambulatory use of the relay module. Alternatively, relay module 30a may be provided with rechargeable and/or replaceable battery power as a primary power source for ambulatory use. It should be readily understood by one skilled in the art that processor 34 and devices 37a-39b are shown as separate and distinct devices in FIG. 3 for illustration purposes only and that the functionality of devices 34 and 37a-39b may be combined into a single or larger or smaller number of devices than illustrated.

Battery back-up may also be advantageous, for example, for using the relay module 30a in an ambulatory mode that enables the patient to move within and potentially at a distance from the facility 20, for example, with a medical device 10 that is a portable feeding device. In this configuration, for example, the medical device 10, the interface circuit 15 and relay module 30 may be conveniently carried in a mobile platform such as any patient-wearable backpack, vehicle, or other transport vessel.

The relay module 30a configuration of FIG. 3B may be operated in a substantially similar manner to the relay module 30a configuration of FIG. 3A employing, for example, corresponding methods of operation described below incorporating the use of a plurality of WWANs or WLAN or WPAN networks. However, in performing methods of operation for the relay module 30a of FIG. 3A, the depicted steps described with respect the flow diagrams below may be employed with the further transceiver selections of the additional transceivers 37 and 38.

FIG. 3C depicts a block diagram of an embodiment of a relay module 30a that enables voice communication and interaction between a caregiver proximate the relay module 30a and a clinician or technician at the remote monitoring device. The identical components in the FIGS. 3A, 3B, and 3C are like numbered including, for example, the first and second transceivers 31 and 32, data processing circuit 33, processor 34 and data buffer 35a. The relay module 30a of FIG. 3C further includes a speech codec 105 connected to a microphone 110 and the speaker 37.

The particular type or brand of speech codec selected for the codec 105 is not necessarily critical as long as it is compatible and/or interoperable with the speech codec of the corresponding remote monitoring device. Suitable codecs for the speech codec 105 include, for example, fixed rate codecs such as voice-over-Internet-protocol (VoIP) codecs in compliance with the ITU standard H.323 recommended protocol. Speech coding standards in accordance with VoIP include ITU standards G.711 (PCM), G.723.1 (MP-MLQ & ACELP), G.729 (CSACELP), GSM-FR; or Adaptable Multi-Rate (AMR) standards such the European Telecommunication Standard Institute (ETSI) and Third Generation Partnership Project (3GPP) IMT-2000. Alternatively, it is possible to employ codecs useable for transmitting encoded speech signals over a mobile telephone network.

The configuration of the relay module 30a of FIG. 3C enables a patient or caregiver proximate the relay module 30a to engage in a conversation with a user (for example, a clinician or technician) proximate the remote monitoring device using, for example, a VoIP or VoIP-like exchange of encoded speech signals. Specifically, in operation of the relay module 30a of FIG. 3C, speech uttered by the caregiver proximate the relay module 30a is converted by microphone 110 to analog speech signals that are digitized and encoded by the codec 105. The processor 34 then transmits the corresponding digitized and encoded speech signals produced by the codec 105 directly over the wireless internet-accessible network alone or in combination with the wireless relay module network to the remote monitoring device. The remote monitoring device then decodes the digitized and encoded speech signals and converts such decoded signals into analog signals supplied to a speaker to generate the speech sounds heard by the clinician or technician.

Conversely, digitized and encoded speech signals representing speech of the clinician or technician transmitted by the remote monitoring device are received by the module 30a wherein the processor 34 supplies such signals to the codec 105 which decodes the signals and converts the decoded signals to analog signals that are supplied to the speaker 37.

Although the implementation of the codec 105 and microphone 110 has been described with regard to exchanging VoIP signals, it should be readily understood that any method of communicating speech signals may be employed including, for example, utilizing a cellular or mobile telephone codec or modem for codec 105 to transmit and receive speech signals, e.g., CDMA- or GSM-compliant speech signals over a mobile telephone network. Further, it is possible for the codec 105 to be implemented as hardware and/or software in a single chip, chip set or as part of the processor 34.

In an alternative embodiment, it is possible to implement speech detection and/or recognition functionality into the codec 105 or processor 34 to enable the relay module 30a to identify specific command words to initiate the carrying out of a corresponding responsive/interactive action. For example, such speech recognition functionality may be triggered by processing signals supplied by the microphone 110 to identify terms “Help”, “Emergency” or “Call 911.” Upon detecting such trigger terms, the processor 34 initiates the process of dialing an emergency response service such as “911,” with or without using synthesized or recorded speech to request confirmation from the caregiver to place such a call and initiate communication between the caregiver and the emergency response service. The dialing may be performed by hardware or software implemented in the processor 34, codec 105 or other components coupled to the processor 34. The speech recognition functionality may alternatively or additionally transmit a text message or other text or audio-visual correspondence to the emergency response service based upon identified spoken works or commands by the caregiver.

It should be readily understood that the relay module 30a of FIG. 3C is shown with the codec 105 and microphone 110 in combination with the display 37 for illustration purposes only. It is possible to implement a relay module with the codec without a display or a relay module with a display and not a codec (as depicted in FIG. 3).

Referring also to FIG. 3D, alternatively or in addition, the processor 34 may instruct the location device 39a to obtain location information of the wireless relay module, and compare this to location information obtained from the medical device and/or by other means (for example, by using a conventional triangulation algorithm measuring transit times of signals transmitted by the medical device 10 to several wireless relay modules 30a with known locations) in order to determine whether the medical device 10 (for example, in the possession of an ambulatory patient) has moved outside of an area for safe communications with the relay module 30a (i.e., is outside the “geo-fence”).

In this case, the processor 34 may preferably transmit a “lost device” alarm message via at least one of the transceivers 31, 32 to the access point 40 and/or to any other Internet-accessible and/or wireless network-accessible recipients. In addition, in order to conserve power and or bandwidth of the wireless relay module 30a, the processor 34 may suspend all other measurements made to determine communications health with the medical device 10 (for example, heartbeat requests and signal quality measurements) until it has been determined that the medical device 10 is back within the geo-fence.

One of skill in the art will also readily understand that the elements used by the wireless relay module 30a to determine whether communications with a particular medical device 10 can be transmitted and/or received over the wireless relay network may be replicated in the medical device 10, such that the medical device 10 may determine whether communications with a particular wireless relay module 301 can be carried out over the wireless relay network, and to issue a visual and/or audible alarm at the medical device 10 when communications with the wireless relay module 30a cannot be carried out. This feature would be particularly useful, for example, to a patient in an ambulatory setting as a means for learning that he/she has exited the geo-fence.

It is possible for the relay module 30 to have a substantially similar configuration as the relay module 30a but excluding the transceiver for communicating over the WWAN with the access point 40.

The relay module 30a of FIG. 3D further preferably includes a location device 39a including, for example, a conventional global positioning system signal (“GPS”) chip for determining a GPS location of the relay module 30a. In addition, the relay module 30a of FIG. 3 includes a power monitoring device 39b for monitoring a voltage level of a external AC power source (not shown) providing power to the relay module 30a, and a secondary power source 39c comprising for example non-rechargeable lead-acid batteries, rechargeable lithium-ion batteries or other conventional rechargeable energy storage devices for providing a secondary power source to the relay module 30a, or a primary power source in the event of a failure of the external AC power source. Alternatively and/or additionally, the power monitoring device may for example monitor a sensor for detecting a disconnection of the external AC power supply by mechanical means (for example, using a spring-loaded push-pin switch that disengages when an associated AC plug of the relay module 30,30a is removed from an external AC receptacle), by electronic means (for example, using an inductive sensor incorporated in proximity to the AC power plug) and the like.

The processor 34 may be a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be implemented in one or more configurations.

In an embodiment, the medical device data received by one of the transceivers 31, 32 from the one or more medical devices 10 may include, for example, information indicative of an alarm condition. In addition to the types of medical device data previously provided herein, the received information may include, for example, at least one of medical device description, medical device identification (e.g., unique device number), medical device location (e.g., device/patient room number), patient identification (e.g., patient identification number), alarm type, alarm error code, and/or alarm severity. Methods in which an alarm condition may be determined include predetermined codes, look-up table(s) and or algorithms for identifying alarm conditions based on processing the received information.

In addition to information indicative of an alarm condition contained in the medical device data received from one or more medical devices 10, it is also possible to receive the alarm indication from another relay module and/or as a result of an indication internally generated in the relay module 30a itself. For example, the relay module 30a could receive such information from another relay module when the other relay module malfunctions. In this way, it is assured that the relay module 30a provides the necessary redundancy for another relay module. Additionally, it is further possible for such information to be transmitted to the relay module 30a from the other relay module when the information is indicative of a high severity alarm condition, e.g., a significant medical emergency, such as emergency 911. Such redundancy will enable a sufficient number of caregivers to be notified of the emergency condition through multiple relay modules to facilitate a prompt response.

In another implementation, the relay module 30a may be notified if another relay module is experiencing numerous alert conditions associated with other modules or medical devices and communicate the alarm information to caregivers. If this occurs, the other relay module may, for example, divert the information indicative of an alarm to the relay module 30a using the WLAN or WPAN 16. The particular relay module 30a selected to receive the alarm information from the other relay module may be based on many factors such as, for example, relay module location, relay module availability, number of caregivers at a given location and/or floor, defined master/slave relationships among the relay modules 30a, and the like.

In another embodiment, it is possible that the information indicative of an alarm condition is received at the relay module 30a, but for some reason, such as a malfunction and/or data transmission bottleneck, the alarm is not communicated audibly and/or visually to the caregivers. To prevent this occurrence, the relay module 30a can be configured to transmit a message back to the one or more medical devices 10 confirming that an alarm was presented to the caregiver. If the message is not received within a predetermined amount of time by the one or more medical devices 10, then one or more medical devices 10 may attempt to communicate with other relay modules to ensure the alarm is addressed. Similar factors, e.g., location, availability, number of caregivers, etc., as described above may be used to select the other relay module(s) for providing alerts for the one or more medical devices.

In a further embodiment, the relay module 30a may internally generate its own alarm and/or device signals in relation to the relay module 30a, for example, the current status of the relay module 30a (e.g., external AC power loss) and/or current communication or connection status (e.g., status with the WLAN or WPAN 16 or WWAN).

After identifying that received data is indicative of an alarm condition, the processor 34 may transmit a message containing alarm information including, for example, at least one of medical device description, medical device identification, medical device location, patient identification, alarm type, alarm error code, and/or alarm severity, to a display 36 attached to the relay module 30a. In this way, an alarm alert may mirror an alarm alert emitted by the originating medical device. The particular type of display chosen for use with the relay module 30a is not necessarily critical. Accordingly, it is possible for display 36 to be a monochrome or color dot matrix, LCD, LED or other display device. Alternatively and/or in addition, the processor 34 may transmit the message containing alarm information to a medical device 10 via the transceiver 31, and/or to the access point 40 via the transceiver 32.

In addition, the processor 34 may also employ a speaker 37, such as a loudspeaker, coupled to the relay module 30a to emit an audible alert indicative of the alarm condition. It is possible for the audible alert based on the alarm condition to be at least one of volume, pitch, tone, type, audible sequence or duty cycle, or recorded sound to indicate the type, urgency or severity of the alarm condition. It is advantageous for an alarm indicating a life-threatening emergency to be more attention-getting, e.g., loud siren, than alarms for less significant conditions that may be addressed by, for example, beeps or calmer tones.

It is also possible for the emitted audible alerts to be spoken words, commands, tones or other sounds. In this way, if the alert emitted from the one or more medical devices 10 is not directly addressed, then the relay module 30a alarm sounds should alert any caregivers located outside of the patient's room. The processor 34 may also cause a signal to be transmitted by, for example, the first transceiver 31 over the WLAN or WPAN 16 to one or more devices including, for example, PDAs, cell phones, pagers, and tablets. In addition, the alarm information may be transmitted over the WWAN using the second transceiver 32 to the one or more devices.

In addition, an input/output circuit 38 may be electrically connected to, for example, user-actuatable buttons, dials or input mechanisms associated with the relay module 30a. Using these buttons, dials, or input mechanisms, the audible alerts produced by the relay module 30a may be muted, i.e., disabled, or volumes substantially reduced. The muting or volume reduction may alternatively be in response to the relay module 30a receiving a signal from the originating medical device transmitting the information, such as in response to a caregiver acknowledging that the emergency condition is being addressed by entering the proper inputs to the originating medical device. Such acknowledgements may preferably take the form of corresponding acknowledgement codes each associated with a particular alarm condition. Even with the audible alerts muted or otherwise disabled, it may be advantageous to continue displaying the alerts on the display 36. The display 36 may continue to display alerts until likewise the alert condition is extinguished or confirmation from a caregiver at the originating medical device or the relay module 30a is received.

In accordance with another embodiment, the processor 34 may control the display 36 to alternate or cycle displayed information intermittently with information from a single medical device or multiple medical devices. For instance, the processor 34 may cause a visual alarm alert indicating an alarm condition (based upon a portion of medical device data) from a first medical device to be shown on the display 36, for example, for a time period of between 2 to 30 seconds before displaying information for another medical device. The visual alarm alerts corresponding to higher severity alarm conditions may be shown for longer durations than alerts of for lower severity alarm conditions. Also, the type of alarm condition may further dictate the display length of time for visual alarm alerts or other information from a particular medical device. Additionally, the processor 34 may also or alternatively display on the display 36 the number of medical devices communicating information indicative of alarm conditions to the relay module 30a and/or show a description of such devices.

In addition, it is possible for the display 36 to display the alerts in different foreground or backlight colors, such as green backlight for normal operation or red backlight for alarm situations, to use color representing the respective severities of alarm conditions. It is further possible for the colors to correspond to specific alarm conditions (e.g., low glucose level) and/or general groups of conditions (e.g., heart conditions). The display may alternatively or in addition incorporate, for example, a multi-colored light-emitting diode array to display the status of the medical devices.

The display 36 may also be used to display non-alarm related information including, for example, internal power supply charge level or status, software version, software download status, relay module network status, handshake status and signal strength of the received WLAN or WPAN 16, and/or WWAN signals. Displayed information for the strength of respective monitored signals and other may be displayed alone or in a combination with the alerts. The signal strength information could be depicted by, for example, by sequential display segments such as, for example, more than one series of different sized light-emitting diodes (LEDs) that would advantageously enable simultaneous display of at least two different network signal strengths for viewing by the caregiver.

As with the display of externally generated information indicative of alarm conditions, it is possible for alerts for internally generated information indicative of an alarm condition by the relay module 30a to also be displayed by display 36. For example, alerts representative of information during start-up or current status of the relay module 30a and/or current communication or connection status with the WLAN or WPAN 16 and WWAN may be shown on the display elements 36. In another embodiment, the processor 34 may cause the display 36 to include information associated with the charge level of a battery (not shown) contained within the relay module 30a, whether by remaining minutes and/or hours of life or other graphical depictions.

Relay module 30a may preferably be provided as a small physical enclosure (not shown) optionally provided with an integral power plug and power supply circuit, such that the relay module 30a may be directly plugged into and supported by a conventional wall outlet providing commercial A/C power. Relay module 30a may also preferably include a battery back-up circuit (not shown) to provide uninterrupted power in the event of A/C power outage of short duration. Battery back-up may also be advantageous, for example, for using the relay module 30a in an ambulatory mode that enables the patient to move within and potentially at a distance from the facility 20, for example, with a medical device 10 that is a portable feeding device. In this configuration, for example, the medical device 10, the interface circuit 15 and relay module 30 may be conveniently carried in a patient-wearable backpack.

Various embodiments of a relay device 30 or 30a are shown in FIGS. 3A-3D. However, the relay device 30 or 30a is not limited to the specific configurations shown. For example, a relay device 3030a may include some or all of the components or features described with respect to any or all of FIGS. 3A, 3B, 3C, and 3D. A relay device 30 or 30a may also include additional features not shown in the figures.

FIGS. 3E-3G respectively illustrate top, front and side views of a configuration 370 for the relay module 30a. Configuration 370 includes a housing 370a, which is shown in FIGS. 3E-3H configured essentially as a rectangular box or prism. It should however be noted that the housing may alternatively be configured in any of a variety of three-dimensional shapes having a sufficient interior volume for housing the associated circuits, having a sufficient area 370c on a front panel 370b of the housing 370a for locating a control panel 380 (as further illustrated in FIG. 3H), and having a sufficient area on a rear panel 370d for providing a receptacle support 370e and power plug 370f for supportably plugging the module configuration 370 into a conventional power outlet. The power plug 370f may also be provided in a modular and replaceably removable configuration enabling power plugs 370f to be configured according to a variety of international standards to be easily provided to the configuration 370.

FIG. 3H illustrates a control panel 380 of module configuration 370 that may constitute a portion of the one or more display elements. The control panel 380 preferably includes, for example, a power switch 380a for powering and/or de-powering the module configuration 370 after it has been plugged into the conventional wall outlet or equipped with a charged battery back-up subsystem. In addition, the control panel 380 preferably includes an alarm switch 380b which allows a user to mute and/or de-mute an audible alarm (for example, a conventional buzzer, not shown) which is coupled to an alarm circuit (not shown) that is configured to issue an alarm when A/C power to the module configuration 370 has been interrupted. The control panel 380 also includes an A/C power indicator 380c which may preferably be provided as one or more light-emitting diode (LED) indicator segments which are activated when A/C power has been provided to the module configuration 370. Optionally, the indicator 380c may be intermittently activated when A/C power is lost (for example, by means of back-up battery power) to signal the loss of A/C power.

The control panel 380 of FIG. 3H also includes a battery indicator 380d to indicate a status of the subsystem battery back-up circuit. For example, and as illustrated in FIG. 3H, the battery indicator 380d may preferably include indicator segments 380h which may be selectively activated to indicate a capacity of the back-up battery. Indicator segments 380h may also be preferably provided as LED segments, or as one or more multicolor LEDs for which color is indicative of capacity. If implemented as individual segments 380h, the segments 380h may, for example, be activated to indicate that the back-up battery is fully charged, and ones of the segments 380h may be progressively deactivated (for example, proceeding downwardly from an uppermost one of the segments 380h) as battery power is drawn down. In the event that remaining battery power is insufficient to operate the module configuration 370, each of the segments 380h may be deactivated. Alternatively, the indicator segments 380h may be provided as one or more multicolor LED segments (for example, red, yellow, and green). In operation, it is possible for all LED segments 380h to be illuminated as green indicating a full backup battery charge and then progressively, sequentially deactivated as battery charge levels are reduced to a first low power threshold. Then, the LED segments 380h may progressively, sequentially be illuminated red as power is further diminished so that all LED segments are illuminated red when battery power is no longer sufficient to power the module configuration 370.

As further illustrated in FIG. 3H, the control panel 380 may further include a relay module network indicator 380e to indicate a status of the portion of the WLAN or WPAN network 16. Similarly to the A/C power indicator 380c, used to provide communications between the WLAN/WPAN network relay module 30a and its associated interface circuits 15 and medical devices 10. This relay module network status indicator 380e is preferably backlit with one or more multi-color LEDs to indicate a relative “health” of the associated portion of the network (for example, using “green” to indicate a healthy (e.g., level of accessibility) network, “yellow” to indicate a network having one or more issues but still operable, and “red” to indicate a network that is inoperative and indicating an alarm condition). Optionally, the indicator element 380e may be intermittently or periodically activated when the WLAN/WPAN network portion of the WLAN or WPAN network 16 that provides communications between the relay module 30a and its associated interface circuits 15 and medical devices 10 has relatively poor communications between these devices, or is unavailable to support such communications. In addition, an audible alarm (for example, a conventional buzzer, bell or audible sound generator and associated loudspeaker, not shown) may be initiated under such conditions.

Indicator elements 380f may also be provided, for example, in an array to indicate the status is active or accessible, and either de-activated or intermittently activated when the WLAN/WPAN network status is inactive or inaccessible. The indicator elements may preferably be provided with multi-color LEDs 380g capable, for example, of illuminating a green segment for a healthy a communications path, a yellow segment for operative communication path with issues, and a red segment to indicate a communications path that is inoperative. Alternatively, individual red, yellow and green LEDS may be used in place of the multi-color LEDs. Alternatively or in addition, one or more of elements 380f, 380g may each comprise a single bi-color LED.

A WWAN indicator 380j may preferably be provided to indicate a status of access to the WWAN network, (using, for example, “green” to indicate a healthy network, “yellow” to indicate a network having one or more issues but still operable, and “red” to indicate a network that is inoperative and indicating an alarm condition). As depicted in FIG. 3H, the indicator 380j includes indicator elements 380f, 380g for indicating the WWAN network status. In this configuration, for example, the indicator element 380f may be configured with a green LED indicator element that is activated when the WWAN network status is active or accessible, and the indicator 380g may be configured with a red LED indicator element that is activated when the WWAN network is inactive or inaccessible (for example, may preferably be backlit with one or more multicolor LEDs. Optionally, the indicator element 380j may be intermittently or periodically activated, for example, when a signal strength of the WWAN network available to the module configuration 370 is insufficient to support communications. Optionally, the indicator element 380f may be intermittently too low to support communications, or is unavailable to support such communications. In addition, the audible alarm may be initiated under such conditions.

Finally, the control panel may include a WLAN/WPAN indicator 380i to indicate an overall health of the entire WLAN/WPAN (or at least of the portion available to provide an alternate path for the relay module 30a to the WWAN network). The WLAN/WPAN indicator 380i may preferably indicate an overall status of the WLAN/WPAN (using “green” to indicate a healthy network, “yellow” to indicate a network having one or more issues but still operable, and “red” to indicate a network that is inoperative and indicating an alarm condition). As depicted in FIG. 3H, the indicator 380i may preferably be backlit with one or more multicolor LEDs. Optionally, the indicator element 380i may be intermittently or periodically activated when the signal strength of the WWANWLAN network is marginally sufficient, too low, or insufficient to support communications. In addition, the audible alarm may be initiated under such conditions.

As previously indicated, the alarm switch 380b may be configured to allow a user to mute and/or un-mute one or more of the audible alarms entirely, or for a specified time period (similarly to a conventional clock alarm “snooze function) indicators of the module configuration 370 such as indicators 380a-380j may preferably be electrically connected to the input-output circuit 36 depicted in FIG. 3A, for example.

In addition, it is possible for the wireless relay module 30a to employ, for example, hardware or software to implement an International Telecommunication Standardization Sector (ITU-T) H.323 codec to enable voice and/or video communications between a caregiver located proximate the wireless relay module and a remote technician. In such an embodiment, the wireless relay module control panel 38 may optionally include microphone and speaker elements (not shown) for enabling the module configuration 37 to be operated in a voice communication mode to allow for voice communication, for example, between an operator, caregiver, and/or a help desk technician in event of a trouble condition reported by one of the medical devices 10. Alternatively or in addition, the control panel 380 may include one or more of a camera element (not shown) and/or a display element (not shown) coupled to the codec to be operated in a visual communication mode. For example, the camera element may be used to transfer images from displays of one or more medical devices 10 to one of the remote monitoring devices 61, 62 and 63 of FIG. 1.

FIG. 4A presents a flow diagram 400 illustrating a method of operation for the architecture according to FIG. 1A and relay module 30, 30a components of FIGS. 2 and 3A-3H, relating to the transmission of medical device data obtained from a medical device 10 to the access point 40. First, at step 402 of the method 400, the medical device data is received at a first one of the relay modules 30a from one of the interface circuits 15 and/or other relay modules 30, 30a over the wireless relay network 16. At step 404, the processor 34 of the one relay module 30a determines whether the WWAN is accessible by that relay module 30a.

The determination of step 404 may be carried out in a variety of manners. For example, the processor 34 may interrogate the status module 32b of the transceiver 32 at the time of or after the receipt of the medical device data to determine a status parameter indicative of access for the transceiver 32 to the WWAN (for example, access for transceiver 37 to the WWAN may be determined as the result of the transceiver 32 detecting an access signal of the WWAN having adequate signal strength for maintaining data communication at a desired quality level). Alternatively, the processor 34 may interrogate the status module 32b at a different time including, for example, at system start-up and/or periodically (for example, hourly), and maintain a status indicator such as in the buffer 35 or another storage element to be retrieved at the time of receipt of the medical device data. As yet another alternative, the relay module 30, 30a may be assigned a predetermined, fixed role within the network 16. For example, relay modules 30a in the network 16 may be assigned a data routing assignments by a controller or controlling relay module or modules which may be preselected from among the relay modules 30, 30a. By definition, the WWAN status for relay module 30 that does not possess WWAN access capability shall have a fixed status of “WWAN inaccessible.”

If, as provided for in step 404, the status module 32b indicates that the WWAN is accessible by the transceiver 32, the processor 34 will proceed to step 406 to instruct the data processing circuit 33 of the one relay module 30 (or 30a) to retrieve the medical device data from the buffer 35 or 35a (as necessary) and forward the medical device data to the transceiver 32 for transmission to the access point 40 over the WWAN.

Alternatively, in step 404, the status module 32b may indicate that the WWAN is not accessible by the transceiver 32. For example, if the one relay module 30a is located on a basement floor of the building in an area that is substantially shielded with respect to WWAN signals, the WWAN may not be accessible to the one relay module 30a. In this event, at step 408, the processor 34 determines whether a second relay module 30a is accessible via the WLAN or WPAN. Again, this determination may be made in a variety of manners including by instructing the transceiver 31 to send a handshake signal transmission directed to a second relay module 30a and to listen for a reply, or by retrieving a stored status indicator for the second relay module 30a.

If the second relay module 30a is accessible, then the processor 34 instructs the data processing circuit 33 of the one relay module 30a to retrieve the medical device data from the buffer 35 or 35a (as necessary) and forward the medical device data to the transceiver 31 for transmission to the second relay module 30a over the WLAN or WPAN at step 410. Alternatively, if the second relay module 30a is inaccessible in step 408, this portion of the process 400 may preferably be repeated to search for a further relay module 30a that is accessible. Alternatively, or in the event that no other relay module 30a is available, the processor 34 of the one relay module 30a may preferably issue an alarm notification at step 412. Such an alarm notification may, for example, include one or more of local visual and audio alarms as directed by processor 34 via the input/output circuit 36 of the one relay module 30a, alarm messages directed by the processor 34 to another accessible WPAN, WLAN or WWAN via one or more of the transceivers 31, 32, and/or alarm messages generated by the inbound web server 41 of the access point 40. These notifications may be displayed or otherwise executed after a specified time period has been exceeded, for example, during which a handshake signal of the relay module 30a is due but not received, at the inbound web server 41 from the wireless relay module 30a.

For example, FIG. 4B depicts a method of operation 400b for an embodiment of relay module 30a. Methods 400 and 400b include substantially identical steps except method 400b substitutes steps 404b and 406b for steps 404 and 406 of method 400. These substituted steps 404b and 406b are similar to the corresponding steps 404 and 406 expanded to utilize the additional transceivers 37 and 38 of FIG. 3B, for example.

After medical device data is received over a WLAN or PLAN network by transceivers 31 or 37 in step 402, the relay module 30a determines if any WWAN is accessible by transceivers 32 or 38 (e.g. in step 404b). If no WWAN is accessible the method 400b then continues to step 408 and performs substantially the same operations as described with respect to steps 408, 410 and 412 in FIG. 4. Otherwise, if a WWAN is determined accessible in step 404b, the method 400b proceeds to step 406b. In step 406b, the method 400b transmits the medical data over the available WWAN via transceiver 32 or 38 to the appropriate access point.

Moreover, to the extent to that in step 404b there are more than one WWAN accessible, then in step 406b the controller 33 may determine which one of the accessible WWANs the medical data should be transmitted over by either of transceivers 32 or 38. Such determination can be made by many different criteria or rules including, for example, based upon signal strength, cost, time of day, day of week or preferences of a network manager or other user.

Referring now to FIG. 4C and FIG. 4D, As previously described with reference to the control panel 38 of the relay module configuration 370 of FIGS. 3E-3H, the relay module 30a is preferably provided with a relay module network indicator 380e to indicate a status of the portion of the WLAN or WPAN network 16 of FIGS. 1, 2 used to provide communications between the relay module 30a and its associated interface circuits 15 and medical devices 10. FIG. 4C presents a flow diagram illustrating a method of operation 420 for generating status information that may be used by network indicator 380e of FIG. 3H.

At steps 421, 422 of FIG. 4C, the processor 34 is instructed to retrieve a current module performance measure or history, for example, from the memory 35b for each medical device 15 accessible to the relay module 30a via the WLAN/WPAN network 16. Performance measures may, for example, include a measured signal strength, noise, bit rate, error rate, packet discard rate, occupancy, availability and the like as are conventionally measured for WLAN/WPAN networks. See, e.g., Pinto, WMM—Wireless Mesh Monitoring, Technical Report, INESC-ID, 2009, which is incorporated by reference in its entirety herein for all purposes. Measured performance may in addition take certain environmental information into account. For example, relatively elevated ambient operating temperature of the relay module 30a, and the like, which may lead to possible corruption of data from the medical device caused by such elevated ambient temperature.

At step 423, if the performance history is not sufficiently current (for example, as indicated by timestamp data) and/or missing, the processor 34 at step 424 employs conventional means in the transceiver 31 (for example, via status module 31b) to obtain current performance measures by transmitting a request to and receiving current performance data from the interface circuit 15 of the associated medical device 10, and preferably stores the current performance measures as part of the performance history in the memory 35b. Currency may preferably be determined according to system performance, regulatory and/or other requirements for individual performance measures in prescribed time intervals (for example, for an interval older than 5 seconds, older than 1 minute, older than the most recent each hour, or the like), which may be stored in the memory 35b for retrieval and reference by the processor 34.

After determining at steps 423 and 425 that current performance data has been obtained for each medical device accessible to the relay module 30a, the processor 34 at step 426 determines a current module status as a function of the current performance data and the performance history. For example, if the current performance data indicate that each medical device 10 is currently accessible to the relay module 30a, the module performance history indicates that the medical devices have been consistently accessible to the relay module 30a for a predetermined time (for example, over a period of several hours), and throughput and/or occupancy are within predetermined limits, the processor 34 may determine that the wireless relay network 16 is “healthy” (indicated, for example, at step 427 by illuminating a green LED segment of indicator 38e).

If the current performance data indicate that each medical device 10 is currently accessible to the relay module 30a, but one or more of the devices 10 have a recent performance history where one or more of throughput and/or occupancy were outside of the predetermined limits, the processor 34 may determine a status of “partially accessible” (indicated, for example, at step 427 by illuminating a yellow LED segment of indicator 38e). If one or more of the medical devices 10 are presently inaccessible to the relay module 30a, the processor 34 may determine a status of “inaccessible” (indicated, for example, at step 427 by illuminating a red LED segment of indicator 380e). At step 428, it may be determined by the processor 34 for example in view of “partially accessible” or “inaccessible” statuses that an alarm condition has been generated, causing the processor 34 to present an alarm (for example, by causing the yellow or red LED segments to be illuminated in a blinking fashion, and/or by providing one or more audible alarms as previously described. As an alternative to displaying display status information at step 427, the processor 34 may cause the transceiver 31 to transmit the status information to one or more of the medical devices 10, or may cause the transceiver 32 to transmit the status information to a device in communication with the WWAN.

With further reference to FIG. 1, FIG. 3, and FIGS. 3A-3H; FIG. 4D presents a flow diagram illustrating a method of operation 440 for generating the status information indicated by WWAN indicator 380j of FIG. 3H. At steps 441, 442 of FIG. 4D, the processor 34 retrieves a WWAN performance history, for example, from the memory 35b as to the status of the WWAN network 44. Performance measures may, for example, include a measured signal strength, noise, bit rate, error rate, call set up time, dropped call rate, occupancy and network availability and the like as are conventionally measured for WWAN/cellular networks for example, via the status module 32b. (See, e.g., Mike P. Wittie, et al., MIST: Cellular Data Network Measurement for Mobile Applications, Broadband Communications, Networks and Systems Fourth International Conference, IEEE, 2007, which is incorporated by reference in its entirety herein for all purposes). At step 443, if the performance history is not sufficiently current (for example, as indicated by timestamp data), the processor 34 at step 444 employs conventional means in the transceiver 32 to obtain current performance measures by transmitting a request to and receiving data from the access point 40 of FIG. 1, and preferably stores the current performance measures as part of the performance history in the memory 35b. Alternatively, if the access point 40 and/or another device in communication with the WWAN 44 collects performance measurement data for the WWAN, the transceiver 32 may transmit a request to the access point 40 and/or other device to retrieve the performance data.

After determining at step 443 that the WWAN performance data is current, the processor 34 at step 445 determines a current WWAN status as a function of the current performance data and the performance history. For example, if the current performance data indicate that the WWAN 44 is currently accessible to the relay module 30a, the module performance history indicates that the WWAN 44 has been accessible to the relay module 30a for a predetermined time (for example, several hours), and throughput and/or occupancy are within predetermined limits, the processor 34 may determine that the WWAN 44 is “healthy” (indicated, for example, at step 446 by illuminating a green LED segment of the WWAN indicator 38j).

If the current performance data indicate that the WWAN 44 is currently accessible to the relay module 30a, but has a history where one or more of throughput and/or occupancy was outside of the predetermined limits, the processor 34 may determine a status of “partially accessible” (indicated, for example, at step 446 by illuminating a yellow LED segment of the WWAN indicator 38j).

If the WWAN 44 is presently inaccessible to the relay module 30a, the processor 34 may determine a status of “inaccessible” (indicated, for example, at step 446 by illuminating a red LED segment of the WWAN indicator 38j). At step 447, which may be performed before or concurrently with step 446, it may be determined by the processor 34 for example in view of “partially accessible” or “inaccessible” statuses that an alarm condition has been generated, causing the processor 34 to present an alarm (for example, by causing the yellow or red LED segments to be illuminated in a blinking fashion, and/or by providing one or more audible alarms as previously described. As an alternative or in addition to displaying display status information at step 446, the processor 34 may cause the transceiver 31 to transmit the status information to one or more of the medical devices 10, or may cause the transceiver 32 to transmit the status information to a device in communication with the WWAN.

FIG. 4E presents a flow diagram illustrating a method of operation 460 for generating the status information that may be used by WLAN/WPAN indicator 380i of FIG. 3H to indicate an overall health of the entire WLAN/WPAN (or at least of the portion available to provide an alternate path for the relay module 30a to the WWAN network). At steps 461, 462 and 464 of FIG. 4E, the processor 34 retrieves current module performance history from the memory 35b for communications with each other relay module that is accessible to the relay module 30a via the WLAN/WPAN network 16 (“neighbor module”).

As previously described, performance measures may, for example, include a measured signal strength, noise, bit rate, error rate, occupancy, availability, path usage and the like as are conventionally measured for WLAN/WPAN networks (using, for example, the status module 31b). In addition, at step 463, the processor operates the transceiver 31 to request that each neighbor module provide a WWAN status (prepared, for example, according to the method described with reference to FIG. 4D).

At step 465, if the performance history relative to the neighbor modules is not sufficiently current (for example, as indicated by timestamp data) and/or missing, the processor 34 at step 466 employs conventional means in the transceiver 31 to obtain current performance measures by transmitting data to and receiving data from the neighbor modules, and preferably stores the current performance measures as part of the performance history in the memory 35b. In addition, current performance measures may be obtained with respect to other neighboring devices, for example, having known or discernible performance (for example, network “beacons”).

After determining at step 467 that current performance data has been obtained for each neighbor module accessible to the rely module 30a, the processor 34 at step 468 determines a current module status as a function of the current neighbor module performance data (including neighbor module WWAN status) and the neighbor module performance history. For example, if the current performance data indicate that each neighbor module 30a is currently accessible to the relay module 30a and has a WWAN status of “accessible”, the module performance history indicates that the neighbor modules 30a have been accessible to the relay module 30a for a predetermined period of time, and throughput and/or occupancy are within predetermined limits, the processor 34 may determine a status of “fully accessible” (indicated, for example, at step 469 by illuminating a green LED segment of WLAN/WPAN indicator 380i).

If the current performance data indicate that each neighbor module 30a is currently accessible to the relay module 30a, but one or more of the neighbor modules 20a have a recent performance history where WWAN status was inaccessible, the processor 34 may determine a status of “partially accessible” (indicated, for example, at step 469 by illuminating a yellow LED segment of WLAN/WPAN indicator 380i). If at least two of the neighbor modules 30a are not presently accessible to the relay module 30a, the processor 34 may determine a status of “inaccessible” (indicated, for example, at step 469 by illuminating a red LED segment of WLAN/WPAN indicator 38i). At step 470, it may be determined by the processor 34 for example in view of “partially accessible” or “inaccessible” statuses that an alarm condition has been generated, causing the processor 34 to present an alarm (for example, by causing the yellow or red LED segments to be illuminated in a blinking fashion, and/or by providing one or more audible alarms as previously described. As an alternative to displaying display status information at step 469, the processor 34 may cause the transceiver 31 to transmit the status information to one or more of the medical devices 10, or may cause the transceiver 32 to transmit the status information to a device in communication with the WWAN.

FIG. 4F presents a flow diagram 413 illustrating a method of operation for emergency dialing. In accordance with the flow diagram 413, the processor 34 of the relay module 30a of FIG. 3 determines whether to transmit over the facility-oriented wireless network or the WWAN and makes a determination based on the medical device data whether an emergency condition exists as represented by step 414. If such a condition exists then, in step 415, the processor 34 transmits a message to the phone device 39a to activate it and also initiate a connection in step 416 (e.g., phone call, etc.) with an emergency responder, such as 911, relatives/friends, caregivers, or police authorities. When the call is received by the emergency responder, an automated voice message is preferably transmitted to the emergency responder by the signal generator 39b indicating the emergency condition and location of the condition. If an emergency condition does not exist in step 414, in step 417 then the medical device data is stored for further analysis by the monitoring unit 37b.

FIG. 4G presents a flow diagram 418 illustrating how a location signal may be generated. A determination is made in step 474 by the processor 34 as to whether GPS location data was received as a component of the medical device data received from a medical device. If yes, in step 476, the processor 34 provides the location data for transmission with emergency condition data to the emergency responder. If that location data is not available, at step 478 a location device 38 of the relay module 30a is instructed by the processor 34 to generate location data of the relay module 30a. At step 480, the processor 34 provides the location data for transmission with emergency condition data to the emergency responder as a component of the message transmitted by the phone device 39a.

FIG. 4H presents a table as may be stored for example in memory 35b by the relay module 30a for determining whether an emergency condition exists. As illustrated, the table 481 includes codes 482 to indicate predetermined emergency conditions, descriptions 486 for the emergency conditions, harm times 488 defining an elapsed time until the emergency condition becomes harmful, priorities 490 for triage purposes, related codes 492 to the coded emergency condition, and physiological data 494 used to identify the emergency condition. For example, as shown in line 1 of the table of FIG. 4H, a code value 482 of “2” is assigned to the description 486 “Significant fever condition,” which is assigned an unattended harm time 488 of “10 minutes” and an immediate priority of 490 of “5.” A related condition 492 indicates that this condition in related to a code value 482 of “7,” which corresponds to the description 486 “Vital signs decreasing.” The code value 2 in addition corresponds to physiological conditions 494 (“Temp.≧103”). ****

FIG. 5 presents a flow diagram illustrating a method of operation 500 for the architecture according to FIG. 1, relating to the transmission of a message from the access point 40 to be received by one of the medical devices 10. This enables the access point 40, for example, to communicate with medical devices in order to download new firmware or software, to respond to error messages initiated by the medical devices (for example, to re-set a device or remove it from service, or to run device diagnostics), and to operate the medical device (for example, to adjust a flow rate on a feeding pump).

At step 502 of the method 500, the message is received at the first one of the relay modules 30a from the access point 40 via the WWAN. At step 504, the one relay module 30 determines whether the message is intended to reach one of the interface circuits 15 and/or other relay modules 30, 30a located in the facility 20. This may be accomplished, for example, by maintaining a list of active devices 15 and modules 30, 30a in the buffer 35 or in a manner otherwise accessible to the one relay module 30a, or coding an identifier of the device 15 or module 30, 30a to include an identity of the facility 20 that is stored in the buffer 35 or is otherwise identifiable to the one relay module 30 or 30a. In the alternative, the received message may include a device identifier such as a serial number or an assigned identifier. Such a received message would then be broadcasted to all or a subset of interface circuits 15 in the facility and each interface circuit 15 determines if it was the intended recipient and should act upon or ignore the message.

If the one relay module 30a determines at step 506 that the interface circuit 15 or module 30, 30a is not located in the facility, the one relay module 30a may preferably proceed to discard the message at step 508, and/or alternatively alert the access point 40 with a non-delivery message. If the interface circuit 15 is located in the facility 20, the one relay module 30a determines at step 510 whether the interface circuit 15 or relay module 30, 30a accessible to the one relay device 30a via the WLAN or WPAN (for example, by consulting a list stored in the buffer 35 or that is otherwise accessible to the one relay module 30a, or by instructing the transceiver 31 to send a handshake or test transmission directed to the interface circuit 15 and to listen for a reply).

If the one relay module 30a determines at step 512 that the device 15 or relay module 30, 30a is accessible, then at step 514, it transmits the message via network 16 to that device or relay module via the transceiver 31, or to relay module 30, 30a via the transceiver 31. In this case, the message may again be broadcasted to all devices 15 and modules 30, 30a in communication with the one relay module 30a, and each device 15 or module 30, 30a may decide to act on or ignore the message (for example, by matching to an associated device ID or other identifier in the message). If the one relay module 30a alternatively determines at step 512 that the device or relay module is not accessible, then it proceeds at step 516 to determine whether a second relay module 30, 30a is accessible via the WLAN or WPAN (for example, by instructing the transceiver 31 to send a handshake transmission directed to the second relay module and to listen for a reply). If the second relay module 30, 30a is available, then the one relay module 30 forwards the message to the transceiver 31 for transmission to the second relay module 30, 30a over the WLAN or WPAN. If the second relay module 30, 30a is inaccessible, then this portion of the process 500 may preferably be repeated to search for a third relay module 30, 30a that is accessible. Alternatively, or in the event that no other relay module 30, 30a is available, the one relay module 30 may preferably issue an alarm notification at step 522, preferably in one of the same manners described above in reference to the methods described in conjunction with FIGS. 6A-6D below. The processor 34 may also issue alarm notifications upon failing to receive a handshake signal from other medical devices 10 and/or relay modules 30,30a.

FIG. 6A depicts a flow diagram 600 representing an alarm alert and display process. In accordance with the flow diagram 600, at step 602 the processor 34 of the relay module 30a receives information such as medical device data from a medical device, other rely module or internally generated by the relay module. Then, the method 600, in step 604, determines whether the information obtained in step 602 is indicative of an alarm condition or an alarm condition is otherwise present. If no alarm condition is detected at step 604, then method 600 reverts back to step 602. If, in step 604, an alarm condition is detected based on the obtained information by step 602, the method 600 proceeds to step 606.

In step 606, the processor 34 produces an alarm alert by transmitting signals representing an alert to be displayed to the display 36 and/or transmits signals representing speech or other audible information (for an audible alarm) to the speaker. Then, the method 600 proceeds to step 608. In step 608, it is determined whether the module 30a receives medical device data or other information instructing the module to mute or disable the audible alarm or an input signal is otherwise received requesting to mute the sound or disable the audible alarm. If such input signal is received then, in step 612, the processor 34 mutes the speaker, i.e., disable the audible alarm. However, in step 608, if no such input signal is received then the method 600 proceeds to step 610.

In step 610, the processor 34 determines whether a user-actuatable switch associated with the input/output circuit 38, e.g., a mute switch of the relay module 30a, has been activated. If such a switch has been activated then the method 600 proceeds to step 612 and the speaker is muted to disable the emitted audible alarm. After the speaker is muted, the method 600 returns to step 602 and starts the process again. However, if in step 610, it is determined that the mute switch has not been activated then the method 600 proceeds to step 614 where the processor again determines whether the alarm condition is still present based upon, for example, newly received medical device data. If the alarm condition is no longer present, the method 600 proceeds to step 612 and the audible alarm is disabled. However, if in step 614 the alarm condition is still present then the method 600 reverts back to step 602 and the audible alert is produced, i.e., continued.

In an alternative embodiment, if in step 614 the alarm condition is present for a particular period of time (either fixed in duration or based upon the particular alarm condition), then in step 606 the emitted audible alarm may advantageously be changed or upgraded in decibel level, pitch, type of sound, duty cycle or speech command to draw greater attention and response to the alarm condition by potential responders. In addition to, or in the alternative to, this change in emitted audible alarm in response to the determination in step 614 that the alarm condition is present for a particular period of time then the relay module may transmit a signal to other nearby or remote relay module(s) to alert other potential responders of the alarm condition.

It should be understood that the method of 600 may operate with information received from plurality of medical devices or other wireless relay modules, and may provide the intermittent displaying of respective alarm alerts for particular time intervals or employ different foreground or background colors based upon the type or severity of the alarm condition.

FIG. 6B depicts a flow diagram representing a alarm alert and display process 600a. Some of the steps in process 600a may be the same as or similar to steps in process 600.

In accordance with the flow diagram 600a, at step 602a the processor 34 of the relay module 30a of FIG. 3 receives information such as medical device data from a medical device, another relay module or internally generated by the relay module. Then, the method 600a, in step 604a, determines whether the information obtained in step 602a is indicative of an alarm condition or an alarm condition is otherwise present. If no alarm condition is detected at step 604a, then method 600a reverts back to step 602a. If, in step 604a, an alarm condition is detected based on the obtained information by step 602a, the method 600a proceeds to step 606a.

In step 606a, the processor 34 produces an audible and visual alarm alert by transmitting signals representing an alert to be displayed to the display 36 and/or transmits signals representing speech or other audible information (for an audible alarm) to the speaker. Alternatively and/or in addition, the processor 34 may transmit the alarm alert to a medical device 10 via the transceiver 31, and/or to the access point 40 via the transceiver 32. Then, the method 600a proceeds to step 608a.

In step 608a, it is determined whether the module 30a receives medical device data or other information instructing the module to mute or disable the audible alarm or an input signal is otherwise received requesting to mute the sound or disable the audible alarm. If such input signal is received then, in step 612a, the processor 34 mutes the speaker to disable the audible alarm. However, in step 608a, if no such input signal is received then the method 600a proceeds to step 610a.

In step 610a, the processor 34 determines whether a user-actuatable switch associated with the input/output circuit 38, e.g., a mute switch of the relay module 30a, has been activated. If such a switch has been activated then the method 600a proceeds to step 612a and the speaker is muted to disable the emitted audible alarm. The method 600a then proceeds at step 616a to determine whether a mute timer has expired after a predetermined time interval (for example, 5 minutes). If so the mute signal is cleared and/or the mute switch is released at step 618a, and the method 600a returns to step 606a to produce each of the audible and visual alerts.

If in step 610a, it is determined that the mute switch has not been activated, then the method 600a proceeds to step 614a where the processor again determines whether the alarm condition is still present based upon, for example, newly received medical device data. If the alarm condition is no longer present, the method 600a proceeds to step 602a and the alarm is disabled. However, if in step 614a the alarm condition is still present, the method proceeds at step 423 to check a condition timer to determine whether the alarm condition has been present for a particular period of time (either fixed in duration for example of five minutes, or for a variable duration based upon the particular alarm condition). If the condition timer has expired in step 423, then in step 620a the emitted audible alarm may advantageously be changed or upgraded in decibel level, pitch, type of sound, duty cycle or speech command to draw greater attention and response to the alarm condition by potential responders, and reapplied at step 606a. In addition to, or in the alternative, the relay module 30, 30a at step 620a may transmit a signal to other nearby or remote relay module(s) to alert other potential responders of the alarm condition.

It should be understood that the method of flow diagram 600a may operate with information received from a plurality of medical devices or other wireless relay modules, and may provide the intermittent displaying of respective alarm alerts for particular time intervals or employ different foreground or background colors based upon the type or severity of the alarm condition.

FIG. 6C depicts a flow diagram 600b representing an alarm monitoring process executed by the processor 34 and the power monitoring device 39b with respect to the AC power supply to the relay module 30a. At step 602b, the processor 34 interrogates the power monitoring device 39b to determine whether the external AC power supply is providing a “normal” voltage (for example, 120 VAC, 60 Hz). If the external AC power supply is providing a normal voltage, the processor engages a timer 604b to operate for a predetermined period of time (for example, 2 minutes) and then returns to step 602b. If the external AC power supply is not providing a normal voltage (for example, a voltage less than 105 VAC, including 0 VAC resulting from an external AC power disconnect), the processor 34 causes a power alarm message to be transmitted at step 606b. At step 608b, the processor determines whether an audible portion of the alarm resulting from the transmitted alarm message has been muted (for example, by activating the mute switch of the relay module 30a). If yes, the processor 34 transmits a message to clear the alarm at step 610b, engages a timer to operate for a second predetermined period (for example, 5 minutes), and then returns to step 602b. If not, the processor 34 engages a timer 614b to operate for another predetermined time period (for example, 3 minutes), and then returns to step 602b. Alternatively, at step 608b, the processor 34 may clear the muted condition rather than clearing the alarm, and release the alarm only if a normal voltage is detected as step 602b.

FIG. 6C depicts a flow diagram 600c representing an alarm monitoring process executed by the processor 34 and the power monitoring device 39b with respect to the secondary power source 39c to the relay module 30a. At step 642c, the processor 34 interrogates the power monitoring device 39b to determine whether the secondary power source 39c is providing a “normal” voltage (for example, 9 VDC). If the secondary power source 39c is providing a normal voltage, the processor engages a timer 644c to operate for a predetermined period of time (for example, 1 minute) and then returns to step 642c.

If the secondary power source 39c is not providing a normal voltage (for example, a voltage less than 8.5 VDC), the processor 34 interrogates the power monitoring device 39b to at step 646c to determine whether the secondary power source 39c is providing a “low” voltage (for example, between 7 and 8.5 VDC). If yes, the processor causes a low battery alarm message to be transmitted at step 648c. At step 650c, the processor determines whether an audible portion of the alarm resulting from the transmitted alarm message has been muted (for example, by activating the mute switch of the relay module 30a). If yes, the processor 34 transmits a message to clear the alarm at step 652c, and engages a timer 654c to operate for a predetermined period (for example, 1 minute) and returns to step 642c. If not, the processor 34 engages another timer 656c to operate for another predetermined time period (for example, 2 minutes) and then returns to step 642c.

If the processor 34 at step 646c determines that the secondary power source 39c is not providing a “low” voltage (for example, between 7 and 8.5 VDC), the processor 34 concludes at step 658c that the voltage is a “near death” voltage (for example, less than 7 VDC). The processor 34 then begins at step 660c to store medical device data arriving from one or more medical devices 10 via the wireless relay network and/or from the access point 40 via the internet-accessible wireless communications network in the memory 35b, and causes a near death battery alarm message to be transmitted at step 662c. At step 664c, the processor determines whether an audible portion of an alarm resulting from the transmitted alarm message has been muted (for example, by activating the mute switch of the relay module 30a). If yes, the processor 34 transmits a message to clear the alarm at step 666c, and engages a timer 668c to operate for a predetermined period (for example, 1 minute) and returns to step 642c. If not, the processor 34 engages another timer 670c to operate for another predetermined time period (for example, 2 minutes) and then returns to step 642c. If normal battery voltage is detected at step 642c, the processor 34 retrieves any medical device data that was stored in the memory 35b during the period when a “near death” voltage was detected, and transmits the retrieved medical device data to intended destinations via one or more of the wireless relay network and/or the internet-accessible wireless communications network.

FIG. 7A depicts a flow diagram 800 representing a process executed by the wireless relay module to determine whether communications with a particular medical device 10 can be carried out over the wireless relay network 16. The process begins with the processor 34 of the wireless relay module 30a engaging a timer 802 for a predetermined period of time (for example, 5 minutes). After expiration of the timer 802, the processor 34 instructs the transceiver 31 to transmit a “heartbeat” request to the medical device 10 over the wireless relay network. If a response is received by the transceiver 31 to the request, the process concludes at step 808 and the processor once again engages the timer 802.

If no response to the request is received by the transceiver 31, the processor 34 increments a request counter at step 810 and engages another timer 812 for another predetermined period of time (for example, 1 minute). Then, the processor 34 proceeds to resend the heartbeat request at step 814. If a response is received by the transceiver 31 to the resent request, the process concludes at step 808 and the processor again engages the timer 802. If no appropriate response is received, the processor 34 proceeds at step 818 to determine whether the request counter exceeds a predetermined value (for example, a predetermined value of 5). If this value is exceeded, the processor 34 causes at step 820, a heartbeat alarm to be displayed by the display 36 and/or be audibly signaled by the speaker 37, and/or transmits a message via at least one of the transceivers 31, 32 to the access point 40 and/or to another internet-accessible and/or wireless network-accessible recipient. The process then continues at step 808 and the processor once again engages the timer 802. If the predetermined value of the request counter is not exceeded at step 818, the process returns to step 810.

One of skill in the art will readily understand that, in addition to requesting a “heartbeat” from the medical device 10, a variety of other measures may be obtained to determine whether communications with a particular medical device 10 can be carried out over the wireless relay network 16. For example, the processor 34 of the wireless relay module 30a may alternatively instruct the status module 31b associated with the transceiver 31 to determine one of a variety of measures of signal quality for the wireless relay network signals being received from a medical device 10 (for example, including a signal strength or data rate of the transmitted signal).

The architecture disclosed herein for providing networked communications between a series of medical devices and a remote monitoring device provides a number of distinct advantages in comparison to other monitoring systems. By employing wireless relay networks such as ZIGBEE networks based on the IEEE 802.15.4 standard, for wireless communications between the medical devices 10 and relay modules 30, 30a in accordance with one embodiment, power and size requirements can be minimized so that the interface circuits 15 can be easily and inexpensively applied to and/or integrated with the medical devices 10.

By introducing relay modules 30a that are part of the wireless relay mesh networks with the capacity to access off-site monitoring devices via a WWAN, access to and reliance on existing and potentially unreliable LAN facilities at a facility can be avoided. By incorporating relay features into the relay modules 30a that relay communications from a first relay module 30a through a second relay module 30a in the event that WWAN access to the first relay module 30a has been compromised, reliability can be improved and the use of conventional, low-cost cellular transceivers can be enabled in the relay modules 30a for accessing the WWAN.

By limiting the configuration of cellular transceivers to just the relay modules 30a, costs can be further reduced. In addition, providing the relay modules 30a in a compact enclosure facilitates the relay modules 30a to be easily connected to reliable commercial power sources and easily moved when needed to reconfigure the wireless relay networks (e.g. a to a mesh network) according to facilities changes. The portability for ambulatory use that is provided by battery back-up is an additional advantage.

FIG. 7B presents a flow diagram illustrating a method 700A of identifying a patient that is associated with (that is, intends to receive treatment from or provide patient identification information and/or patient medical and/or physiological data to) a medical device 10 (as depicted, for example, in FIG. 1). At step 702A, the process may be initiated, for example, by actuating the synchronization switch 38k on the control panel 38 as illustrated in FIG. 3(e) of a relay module 30a in proximity to the medical device 10. The relay module 30a enters an identification signal reception mode, in which it waits for a first predetermined interval (for example, using a time-out algorithm) at step 704A to receive patient identification data over the facility-oriented wireless network via the interface device 17a of a patient identification device 17. The relay module 30a preferably indicates receipt by presenting an audible or visual signal at the control panel 38, or by broadcasting a receipt signal to the patient identification device 17 over the facility-oriented wireless network.

At step 706A, after receipt of the patient identification information, the relay module 30a waits for a second predetermined interval to receive medical device identification information over the facility-oriented wireless network via the interface circuit 15 of a medical device 10. Once again, the relay module 30a preferably indicates receipt of this medical device data by presenting an audible or visual signal at the control panel 38, or by broadcasting a receipt signal to medical device 10 over the facility-oriented wireless network. It should be understood that the order of receipt of the patient identification data and the medical device identification information (which may be respectively transmitted, for example, by a caregiver operating the patient identification device 17 and the medical device 10) may be inverted. In addition, the inventive process 700A may optionally first require the caregiver to transmit caregiver identification data (for example, via one of the patient identification device 17 or the medical device 10, or via a sensor provided in the relay module 30a) which is validated by comparison to a caregiver identification table maintained for example in the memory 35b of the relay module 30a, or alternatively by forwarding a validation request to the remote monitoring system at the access point 40 over one or more of the facility-oriented wireless network and WWAN via an associated one of the transceivers 31, 32.

At step 708A, upon receipt of each of the patient identification data and the medical device identification data, a verification process is initiated. This process is carried out by the method 700B illustrated in the flow diagram of FIG. 7C.

At step 702B of FIG. 7C, a patient identification directory in the memory 35b of the relay module 30a is interrogated to determine whether a record is present including the received patient identification data and medical device information data, and if so, whether this record includes a “fresh” time stamp indicating that the record is current (for example, if patient identification is verified on a daily basis, a time stamp during the current day). If the time stamp is current, the record is retrieved from the patient identification directory at step 712B, and an acknowledgement status identified is extracted from the record at step 710B.

If the patient identification data and medical device identification data are not present in the patient identification directory, or if the time stamp does not indicate that a record including such data is current, the relay module 30a proceeds to form a data packet including the patient identification information and medical device identification and to encrypt this packet (for example, using a suitable conventional encryption algorithm such as secure sockets layer (SSL) data encryption) at step 704B, and then transmits the encrypted data packet at step 706B for further validation to the remote monitoring system at the access point 40 over one or more of the facility-oriented wireless network and WWAN via an associated one of the transceivers 31, 32. Alternatively, the patient identification information and/or the medical device identification information may be encrypted by one or more of the patient identification information device or the medical device, and steps 702B, 704B and 712B may be omitted.

At step 708B, the relay module receives a reply packet from the remote monitoring system via one of the transceivers 31, 32, and decrypts that packet. At step 710B, the relay module 30a extracts the acknowledgement status identifier from the decrypted packet. At step 714B, the relay module 30a preferably adds a record to the patient identification directory in the memory 35b that includes the patient identification information, the medical device identification information, the acknowledgement status identifier and a current time stamp.

Returning to FIG. 7B, at step 710A, the relay module broadcasts the acknowledgement status identifier (preferably together with at least one of the patient identification data or the medical device identification data) via the transceiver 31 to the medical device 10. Upon receipt of the acknowledgement status identifier, the medical device 10 begins operation and transmits medical device data via an associated interface circuit 15 over the facility-oriented wireless network for receipt by the wireless network 30a at step 712A. The acknowledgement status identifier may preferably be encoded to instruct the medical device 10 to operate with predefined operating parameters. Optionally and alternatively, and before beginning operation, the medical device 10 may transmit a request via the interface circuit 15 to confirm preset operating parameters and/or request additional information. Once the operating parameters are confirmed and operation of the medical device 10 begins, the wireless network 30a may operate according to the previously-described processes 400, 500 of FIGS. 4, 5.

FIG. 8 illustrates a flow diagram of a method 8200 for registering medical devices 10 with the system 100B of FIG. 1B. The method 8200 begins at step 8202, at which an authorized technician or other personnel having access to one of the remote monitoring devices 67, 73, 75 provides authenticating credentials (for example, a recognized log-in and password) to the outbound web server 43, and the web server responds by transmitting a device set-up screen to the remote monitoring device 67, 73, 75 requesting medical device identifying information and associated patient identifying information.

At step 8204, the outbound web server 43 preferably queries the metadata and application database 46 according to one or more of identifying information for the technician and/or identifying information for the patient to identify an associated patient care database node 60 from a plurality of patient care database nodes for the patient and record a destination address for the associated patient care database node 60 in the metadata and application database 46 in association with the identifying data for the medical device 10 and/or identifying information for the patient. Identifying information for the patient is preferably generated anonymously (for example as a random number), and transmitted at step 8206 to the patient care database node 60 for association with securely-stored patient identifying information. At step 8208 of the method 8200 of FIG. 8, the outbound web server 43 requests that the secure device web server 42 assign an area of the device control database 44 for logging associated medical device data for the medical device 10 as it is received by the device integration server 41, such that it can be later retrieved by the outbound web server 43 upon receiving an authorized request from an authenticated user operating one of the remote monitoring devices 67, 73, 75.

It should be readily understood by one skilled in the art that step 8204 of method 8200 for identifying and storing the address of the patient care database node 60 may be omitted if a single patient care database node is utilized with system 100B of FIG. 1B.

FIG. 9A presents a flow diagram illustrating a method 9300 for retrieving and viewing medical device data on a remote monitoring device 67, 73, 75 for a registered medical device 10 according to the system of FIG. 1B. The method 9300 begins at step 9302 with a first authorized user having access to one of the first remote monitoring devices 67 provides authenticating credentials (for example, a recognized log-in and password) to the outbound web server 43. In addition, in step 9302, a second authorized user having access to one of the second remote monitoring devices 73, 75 likewise provides respective authenticating credentials to the outbound web server 43

At step 9304, based on verification of the authenticating credentials of the first and second authorized users, the outbound web server 43 queries the metadata and applications database 46 to identify the address of patient care database node(s) 60 to which the respective first and second authorized users are entitled to obtain access, and at step 9306, requests data from the patient care database node 60 relating to at least one identified patient for which the first and second user are respectively authorized to view medical device data, including for example a listing of medical devices 10 which are presently associated with the identified patient, and/or status information of the facility-oriented network 17. It should be readily understood that different authenticated users will likely have different levels of sophistication and skill for which a corresponding access level may be associated with their authentication account or status which may further be used, for example, to limit or expand the type and/or extent of medical device data that may be transmitted to the remote monitoring devices for such authenticated users.

At step 9308 of the method 9300 of FIG. 9A, the outbound web server 43 queries the device control database 44 via the secure device web server 42 for status information to determine which of the listed medical devices are presently active according to the data logged by the device control database 44. It should be noted that one or more of a medical device 10, its associated interface device 15, an associated wireless relay module 30 and/or the device integration server 41 may be programmed to provide data from the medical device 10 to the device integration server 41 at predetermined, preset intervals or otherwise, which can then be provided to server 43 in response to inquiries therefrom.

Upon obtaining the status information, the outbound web server 43 prepares respective display pages with encrypted medical device data, according for example to display information retrieved from the metadata and applications database 46, to display listings of medical devices 10 available for monitoring by respective authorized users at the remote monitoring devices 62, 70, 75. FIG. 9B presents a first screen display 9320 to the remote monitoring devices 62, 70, 75 that provides an array of medical devices 10 available for monitoring according to device type. For example, in the screen display 9320 of FIG. 9B, available device types include ventilators 9321, urology devices 9322, energy delivery devices 9323, pulse oximeters 9324, predictive thermometers 9325, tympanic thermometers 9326 and food pumps 9327. Each of the device types 9321-9327 in FIG. 9B is presented with an identifying label (for example, label 9321A) and an identifying image (for example, image 9321B) for ease of recognition.

Once a device type is selected by a user (for example, in response to an associated mouse-over or mouse-click executed by the authorized user), a second screen display 9330 as illustrated by FIG. 9C may preferably be transmitted by the outbound web server 43 for display at the remote monitoring devices 62, 70 or 75. In the display 9330, labels 9337A are provided in association with images 9337B in order to identify individual food pumps (for example, by patient and/or by logical or physical location). Medical devices 10 that are unavailable may for example preferably be depicted with a label 9337A′ (“Off Line”) and an image 9337B′ (depicting the device with a slash or cross applied over the image or shaded or shadowed) that distinguish the unavailable medical devices 10 from available medical devices 10.

Once an individual device is selected by the first or second user (for example, once again, in response to an associated mouse-over or mouse-click executed by the authorized user), a third screen display 9340 as illustrated by FIG. 9D may preferably transmitted by the outbound web server 43 for display at the corresponding remote monitoring device 62, 70, 75. In the display 9340, for example, device information of the medical device 10 (in this case, a food pump) is displayed in a screen 9347A preferably recreating a current screen generated and displayed by the medical device 10. In addition, the screen display 9340 includes any of a panel 9347B providing identifying information for the medical device 10 (in this case, a pump location), a panel 9347C for displaying a message indicating a current error condition of the pump, and an icon button 9347D for selecting an alternate “status” mode of the screen display 9340. The screen display 9340 also includes a control icon button 9347E for selecting a system set-up screen display, and a control icon button 9347F for enabling device control from the remote monitoring device 62. For example, upon selecting the control icon 9347F, the screen display 9340 may preferably be refreshed to include the medical devices screen 9347A and one or more operable buttons that mimic the appearance of control buttons on the medical device. The control button features are described in greater detail below in relation to FIGS. 10B and 10C.

It should be readily understood that computer screen images 9320, 9330 and 9340 and corresponding navigation depicted by FIGS. 9B, 9C and 9D are for illustration purposes only and that many other user screen images displays and interface tools may be utilized, for example, computer screens that depict accessible medical devices by other means than device type as illustrated in FIG. 9B. For example, as a suitable alternative to the screen image 9340 of FIG. 9D that conveys information from a single medical device, it is possible to implement displays that provide information from multiple medical devices. In addition, it should be readily understood that the outbound web server 43 will preferably be operable to prepare display pages with encrypted medical device data for display on any of a wide variety of display devices (including, for example, workstations, personal computers, tablet devices including tablet computers, and display-based mobile devices including personal digital assistants, smartphones, portable game systems and the like.

It should also be readily understood that the computer screen images to be available to first and second users of the first and second remote monitoring devices may be different depending upon whether such user is a clinician, nurse, patient relative or other caregiver, i.e., dependent on level of entitlement of the particular authorized user. For example, a display for a clinician at a first remote monitoring device 62 may enable the clinician to adjust the settings of a subject medical device 10, in contrast to a display for a second remote monitoring device 70, 75 used by a patient relative, which depicts only fundamental information from the medical device data with no option for the patient relative to adjust the medical device settings via the second remote monitoring device 70, 75. Likewise, different encryption methods or formats may be employed for medical device data transmitted to the first remote monitoring device 62 than the second remote monitoring device 70, 75.

FIG. 10A presents a flow diagram illustrating a method 1000 for issuing a command to a medical device 10 via the system 100 according to FIG. 1. The method 1000 begins at step 1002 with an authorized user adjusts an operating parameter, such as a clinician (also referred to as a “authorized clinician” or “user” herein) logging into the outbound web server 43 using a first remote monitoring device 62 and navigating to the device screen display 9340 of FIG. 9D (for example, as described above with reference to FIGS. 9A-9D). At step 1004, the clinician proceeds to select the “Enable Full Control” button 9347F of FIG. 9D to initiate an operational command directed to the medical device 10, and is preferably provided with a request for authentication pertaining in particular to the patient associated with the medical device 10. At step 1006, patient authentication information provided by the clinician is forwarded by the outbound web server 43 to a patient care database node 60 according to a patient care database node address stored by the metadata and applications database 46 in association with the clinician, and the clinician is authenticated for the patient by the outbound web server 43 upon receipt of an authentication confirmed message from the patient care database node 60.

Upon receipt of the patient authentication, a control request is forwarded by the outbound web server 43 at step 1008 to the secure device web server 42 to be logged in the information record of the device control database 44 that is associated with the medical device 10 (and optionally, with an anonymous ID for the patient). At step 1010, the secure device web server forwards the control request, such as an encrypted control request, to the device integration server 41, which transmits an associated device control command over the secure WWAN 52 for receipt by an associated wireless relay module 30 at step 1012. The wireless relay module 30 wirelessly communicates the command to the medical device 10 via an associated device interface 15, and awaits a reply confirming execution of the command transmitted by the device interface 15.

At step 1014, the device integration server 41 receives an update message from the wireless relay module 30 via the secure WWAN 52 which confirms that the command was executed by the medical device 10. At step 1016, the device integration server 41 forwards the update message to the secure device web server 42 to be logged in the information record of the device control database 44 that is associated with the medical device 10. Optionally, and preferably, the secure device web server 42 forwards information pertaining to the update message to the outbound web server 43, and the outbound web server 43 prepares an updated display screen that is securely transmitted to the remote monitoring device 62 to indicate that the command has been executed.

Alternatively, at step 1004, the authenticated clinician may select the “System Setup” control icon button 9347E to perform a command other than an operational command directed to the medical device 10. FIG. 10B illustrates a display screen 1050 that is presented to the clinician upon selecting the control icon button 9347E. The display screen 1050 includes a number of icon buttons that may be selected by the clinician (for example, as the result of a mouse-over or mouse-click initiated by the clinician) to select a specific setup command. For example, icon button 1051 may be selected to initiate a command for providing identification information of the medical device 10. Icon button 1052 may be selected to provide text paging in response to an alert condition, as is further described herein. Icon button 1053 may be selected to initiate a software or firmware download for updating the medical device 10.

Icon button 1054 may be selected to initiate a diagnostic test of the medical device 10. FIG. 10C illustrates a display screen 1060 that may be displayed to the clinician upon selection of the icon button 1054. Via the display screen 1060 of FIG. 10C, the clinician may select one or more of (including a progression of) a series of diagnostic tests 1061 directed to components of the medical device (for example, including power components, memory components, alarm components and the like). Alternatively and/or in addition, the clinician may select one or more of a series of performance statistics 1062 to be gathered and displayed (for example, including various device error statistics such as feed error, rotor error and flush error rates for a food pump). In addition, perhaps most usefully before issuing a software and/or firmware download command, the clinician may select a version number test 1063 to obtain version identifying information for the software and/or firmware (preferably including, for example, a software and/or firmware download history). Optionally, processes for performing the diagnostic tests 1061, preparing the performance statistics 1062 and identifying the software and/or firmware version number 1063 may run automatically without specifically being selected by the clinician, with a complete reporting of all results on the display screen.

In a similar manner to that performed by the method of FIG. 10A, it is possible to issue a bandwidth priority command or instruction to a relay module, such as relay module 30 of FIG. 1, for the relay module to grant priority for relaying information received from a particular medical device relative to other medical devices that may send or receive communications via this relay module. For example, it would be advantageous to provide greater bandwidth priority to a critical care device such as a ventilator supporting the breathing function of a patient relative to a weight scale or thermometer. It is also possible to a number of bandwidth priority levels assignable to respective medical devices based upon, for example, the critical nature of the data or function provided by such devices.

Referring again to FIG. 10B, icon button 1055 may be selected to enable the clinician to specify data transfer rates, priorities and other parameters relating to the wireless transceiver of the interface device associated with the medical device. Icon button 1056 may be selected to provide the clinician with the an alarm history, event history and other information as has been logged for example for the medical device in the device control database 44 of FIG. 1.

It should be readily understood that the method 1000 for remotely issuing a command to a medical device 10 was described with respect to a user of a first remote monitoring device 62 and not a user of the second remote monitoring 70, 75 because as described for example throughout this application, it is assumed that the user of the first remote monitoring device 62 is a clinician, technician or other highly-skilled healthcare professionals, while the user of the second remote monitoring device 70, 75 may be a patient relative or caregiver of lesser skill. Nevertheless, the method 1000 is likewise useable to enable a user of the second monitoring device 70, 75 to also control particular settings of the medical device 10.

FIG. 11A presents a flow diagram illustrating a method 1100 for recognizing and reporting an alert condition according to medical device data (including the status of the facility-oriented network 17) logged via the system 100 according to FIG. 1. The method 1100 begins at step 1102 with the transmission of an alert message by a wireless relay module 30 over the secure WAN 52 to the device integration server 41. In this case, the wireless relay module 30 is configured to analyze (such as by detecting flag or status information or comparing message data to information stored in an associated database) a message type of a message transmitted by an associated medical device 10 to determine that the message is an alert message, and to transmit the message to the device integration server 41 upon determining that the message is an alert message (for example, as a priority message). Alternatively, the wireless relay module 30 may simply queue all messages for transmission to the device integration server 41 in order upon receipt, and rely upon the device integration server 41 to analyze an associated message type to determine that a message is an alert message.

Upon determining that the transmitted message is an alert message, the device integration server 41 proceed, at step 1103, to log the message in the device control database 44, and at step 1104, invokes a text messaging application that retrieves text messaging numbers associated with identifying information of the medical device 10 and/or anonymous patient identifying information. The determination of whether the transmitted message is an alert message may be carried out by, for example, detecting an alert flag or trigger identifier in the message or scanning the message for other information indicative of an alert condition. The text messaging application may preferably retrieve the text messaging numbers by querying the metadata and applications database 46 to identify the address of an associated patient care database node 60, and either making a direct request or instructing the outbound web server 43 to request the text messaging numbers from the associated patient care database node 60.

At step 1106, the device integration server 41 sends one or more messages including the retrieved text messaging numbers and text message information according to the alert message to one or more wireless relay modules 30 over the secure WWAN 52. At step 1108, the one or more wireless relay modules 30 transmit the text message information addressed to the text messaging numbers over one or more of the secure WWAN 52 and/or the facility-oriented wireless network 17 to complete the method 1100.

FIG. 11B illustrates a “Text Paging” 1052 screen display 1150 that may be invoked, for example, by using the method 1000 of FIG. 10A for issuing a command to a medical device 10. Specifically, and with particular reference to FIGS. 9D and 10B, the text paging screen 1150 is displayed at the first remote monitoring device 62 of an authenticated clinician upon the clinician's selection of the “System Setup” icon button 9347e of the screen display 9340, and thereafter upon the clinician's selection go the “Text Paging” icon button of the screen display 1050. Likewise, it is possible for the paging screen 1150 of FIG. 11B to be displayed on a second remote monitoring device 70, 75 for completion by an authorized user, such as a patient relative or other caregiver. As illustrated in FIG. 11B, the “Text Paging” screen display 1150 include a listing of one or more names 1151 of individuals responsible for responding to alert messages of at least two types: “Error Messages” 1153, which may for example indicate a malfunction of the medical device 10, and/or “Info Messages” 1154, which may for example indicate a significant patient health condition (for example, a patient respiration rate below a preset minimum rate specified for a ventilator device 9321 of FIG. 9B).

The information retrieved by the outbound web server 43 to prepare this display is preferable retrieved from the patient care database node 60, by providing on one or more of identifying information for the medical device 10 and/or anonymous patient identifying information stored in the device control database 44. Upon recognizing an alert message for the medical device 10, the information provided on the “Text Paging” screen display may be retrieved by the device integration server 41 by querying the metadata and applications server 46 to retrieve address information for the patient care database node 60, and forwarding a text paging information request to the patient care database node 60 based upon one or more of identifying information for the medical device 10 and/or anonymous patient identifying information stored in the device control database 44. The recognition of whether the received message from the medical device 10 is an alert message may be carried out by, for example, detecting an alert flag or trigger identifier in the message or scanning the message for other information indicative of an alert condition.

It should be readily understood that the use of communicating alert messages using text messaging in FIGS. 11A and 11B is for ease of illustration purposes only and that such alerts may be communicated in other ways including email, audio messages via telephone calls, as well as any other wired and/or wireless text, audio, or multimedia based communication services receivable by, for example, by a smart phone or computer tablet software application or “App.”

FIG. 12 shows an illustrative computer system 1200 suitable for implementing server and computer components (for example, including device integration server 41, secure device web server 42, outbound web server 43, and secure patient web server 64). The computer system 1200 as described herein may comprise, for example, a personal computer running the WINDOWS operating system, or a server computer running, WINDOWS Server, LINUX or another UNIX-based operating system. Alternatively, the computer system 1200 described herein may comprise a mobile device, tablet devices or computers, or information appliance running, for example, an operating system in the group including Symbian, Android, Apple iOS, Blackberry, Microsoft Windows Phone, Linux, Palm/HP WebOS, BADA, MAEMO and MEEGO. The above-described methods carried out by the server and computer components may be implemented on the computer system 1200 as stored program control instructions directed to control application software.

Computer system 1200 includes processor 1210, memory 1220, storage device 1230 and input/output devices 1240. One of the input/output devices 1240 may preferably include a display 1245. Some or all of the components 1210, 1220, 1230 and 1240 may be interconnected by a system bus 1250. Processor 1210 may be single or multi-threaded, and may have one or more cores. Processor 1210 executes instructions which, in the disclosed embodiments, are the steps described, for example, in one or more of FIG. 8, 9A, 10A or 11A. These instructions may be stored in one or more of memory 1220 or in storage device 1230. Information may be received and output using one or input/output devices 1240. Memory 1220 may store information and may comprise a computer-readable medium, such as volatile or non-volatile memory. Storage device 1230 may provide storage for system 1200 including for the example, the previously described database, and may be a computer-readable medium. In various aspects, storage device 1230 may be one or more of a flash memory device, a floppy disk drive, a hard disk device, and optical disk device, and/or a tape device.

Input devices 1240 may provide input/output operations for system 1200. Input/output devices 1240 may include one or more of a keyboard, a pointing device, and/or microphone. Input/output devices 1240 may further include a display unit for displaying graphical user interfaces, a speaker and a printer and any of a number of other serial devices (for example, configured as Universal Serial Bus (USB)-based devices

Claims

1. A process for providing communications between a medical device to be used by a patient and a remote monitoring device via an internet-accessible wireless communications network, said process comprising: obtaining identification information identifying the patient;obtaining identification information identifying the medical device transmitting each of the patient identification information and the medical device identification information to the remote monitoring device via the internet-accessible wireless communications network;receiving an acknowledgement status from the remote monitoring device via the internet-accessible wireless communications network; andtransmitting data corresponding to an output of at least one sensor of the medical device for said patient by the medical device via the internet-accessible wireless communications network when the received acknowledgement status represents a particular status.

2. The process of claim 1, wherein said particular status represents an authorization of use of the medical device by the patient based upon a pre-authorization record for the patient.

3. The process of claim 1, further comprising encrypting the patient identification information prior to transmitting the patient identification information to the remote monitoring device.

4. The process of claim 1, further comprising encrypting the medical device identification information prior to transmitting the medical device information to the remote monitoring device.

5. The process of claim 1, wherein transmitting the patient identification information to the remote monitoring device comprises: receiving the patient identification information at the medical device; andtransmitting the patient identification information from the medical device via the internet-accessible wireless communications network to the remote monitoring device.

6. The process of claim 5, wherein the medical device performs said transmitting the medical device identification information to the remote monitoring device.

7. The process of claim 6, wherein the patient identification information and the medical device identification information are transmitted by the medical device to the remote monitoring device in a single information block.

8. The process of claim 1, wherein obtaining the patient identification information comprises reading the patient identification information by a patient identification information reader.

9. The process of claim 8, further comprising coupling the patient identification information reader to the medical device.

10. The process of claim 8, further comprising transmitting the patient identification information from the patient identification information reader to the medical device via a wireless relay network.

11. The process of claim 8, further comprising transmitting the patient identification information from the patient identification information reader to a wireless relay module via a wireless relay network.

12. The process of claim 10, further comprising providing wireless bandwidth priority for the patient identification information reader by the medical device.

13. The process of claim 11, further comprising providing wireless bandwidth priority for the patient identification information reader by the relay module.

14. The process of claim 8, wherein obtaining the patient identification information comprises reading bar-coded reader patient identification information.

15. The process of claim 8, wherein obtaining the patient identification information comprises reading a radio frequency identification (RFID).

16. The process of claim 8, wherein obtaining the patient identification information comprises obtaining one or more sources of identification information from one or more of fingerprints, retinal scans, vein-pattern scans and optical images.

17. The process of claim 8, wherein the patient identification information reader comprises a device selected from one or more of smartphones, tablet computers, personal digital assistants (PDAs), cell phones and pagers.

18. The process of claim 1, wherein one or more of transmitting the patient identification information or transmitting the medical device identification information to the remote device comprises transmitting the identification information via a wireless relay module.

19. The process of claim 18, further comprising: storing one or more of the patient identification information and the medical device identification information by the wireless relay module.

20. The process of claim 19, wherein the wireless relay module transmits the patient identification information and the medical device identification information together in a single information block.

21. The process of claim 18, further comprising transmitting one or more of the patient identification information or the medical device identification information via the internet-accessible wireless communications network from the wireless relay module to the remote monitoring device.

22. The process of claim 21, wherein the wireless relay module transmits the patient identification information or medical device identification information to at least one other wireless relay module and the at least one other wireless relay module forwards the identification information via the internet-accessible wireless communications network to the remote monitoring device.

23. The process of claim 1, wherein said particular status represents an authorized use of the medical device by the patient obtained in response to a confirmation query conducted by the remote monitoring device.

24. The process of claim 1, further comprising transmitting a confirmation query request to the remote monitoring device via the internet-accessible wireless communications network.

25. The process of claim 24, wherein the confirmation query request comprises authorization identification information.

26. The process of claim 18, further comprising: transmitting a prompt for the medical device identification information by the wireless relay module to the medical device; andtransmitting a prompt for the patient identification information by the wireless relay module to one on the medical device or to a patient identification device.

27. The process of claim 26, wherein the patient identification information and the medical device identification information is transmitted by the wireless relay module in a single information block.

28. The process of claim 26, further comprising receiving the medical device identification information from the medical device at the wireless relay module, and wherein transmitting the prompt for the patient identification information by the wireless relay module occurs after receiving the medical device information by the wireless relay module.

29. The process of claim 26, further comprising receiving the patient identification information from the medical device or the patient identification device by the wireless relay module, and wherein transmitting the medical device identification information and the patient identification information by the wireless relay device module occurs after receiving the medical device identification information and receiving the patient identification information by the wireless relay module.

30. The process of claim 29, wherein transmitting the medical device identification information and the patient identification information by the wireless relay module is performed after determining that the value of an indicator of an elapsed time at the wireless relay module between transmitting the prompt for the patient identification and receiving the patient identification information is within a predetermined time-out period.