Patent Publication Number: US-2015070187-A1

Title: Wireless Relay Module For Remote Monitoring Systems

Description:
RELATED APPLICATIONS 
     This application is a continuation of co-pending U.S. patent application Ser. No. 14/308,881 filed Jun. 19, 2014, which is a continuation of U.S. patent application Ser. No. 13/241,620 filed Sep. 23, 2011, now. U.S. Pat. No. 8,798,527 which is a continuation-in-part of co-pending U.S. patent application Ser. No. 13/006,769 filed Jan. 14, 2011. 
     This application is also a continuation of co-pending U.S. patent application Ser. No. 13/352,575 filed Jan. 18, 2012, which is a continuation-in-part of U.S. patent application Ser. No. 13/241,620 filed Sep. 23, 2011 now. U.S. Pat. No. 8,798,527 which is a continuation-in-part of co-pending U.S. patent application Ser. No. 13/006,769 filed Jan. 14, 2011. 
     This application is also a continuation of co-pending U.S. patent application Ser. No. 13/352,575 filed Jan. 18, 2012, which is a continuation-in-part of co-pending U.S. patent application Ser. No. 13/006,769 filed Jan. 14, 2011. 
     This application is also a continuation of co-pending U.S. patent application Ser. No. 13/334,447 filed Dec. 22, 2011, which is a continuation-in-part of co-pending U.S. patent application Ser. No. 13/006,769 filed Jan. 14, 2011. 
     This application is also a continuation of co-pending U.S. patent application Ser. No. 13/334,459 filed Dec. 22, 2011, which is a continuation-in-part of co-pending U.S. patent application Ser. No. 13/006,769 filed Jan. 14, 2011. 
     This application is also a continuation application of co-pending U.S. patent application Ser. No. 13/353,565 filed Jan. 19, 2012, which is a continuation-in-part of co-pending U.S. patent application Ser. No. 13/334,463 filed Dec. 22, 2011 and a continuation-in-part of application of co-pending U.S. patent application Ser. No. 13/006,769 filed Jan. 14, 2011. 
     This application is also a continuation application of co-pending U.S. patent application Ser. No. 13/352,608 filed Jan. 18, 2012, which is a continuation application of U.S. patent application Ser. No. 13/037,886 filed Mar. 1, 2011 now U.S. Pat. No. 8,694,600. 
     This application is also a continuation application of co-pending U.S. patent application Ser. No. 14/154,285 filed Jan. 14, 2014, which is a continuation of U.S. patent application Ser. No. 13/037,886 filed Mar. 1, 2011 now U.S. Pat. No. 8,694,600. 
     This application is also a continuation of co-pending U.S. patent application Ser. No. 13/006,769 filed Jan. 14, 2011. 
     This application is also a continuation of co-pending U.S. patent application Ser. No. 13/006,784 filed Jan. 14, 2011. 
     This application is also a continuation of co-pending U.S. patent application Ser. No. 13/334,463 filed Dec. 22, 2011. 
     All patent applications listed in this section and listed in this document are hereby incorporated herein by reference in their entireties. 
    
    
     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  30   a  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  100 B 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  30   a . Each relay module  30   a  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 &amp; 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  30   a  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  30   a , 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  100 C may further include one or more wireless patient identification devices  17  in communication with one or more of the relay modules  30   a  and/or medical devices  10  in proximity to the patient identification device  17  via the interface circuits  15  and  17   a  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&#39;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  30   a  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  30   a , a pouch  72  for housing a power and charging circuit  39   d  for providing power to the relay module  30   a , and a power cord  39   e  for supplying power from the power and charging circuit  39   d  to the relay module  30   a . As depicted, the power and charging circuit  39   d  includes a battery compartment  39   f , and a charging circuit (not shown) and a power cord  39   g  for providing external commercial AC power to the power and charging circuit  39   d  in order to charge batteries in the battery compartment  39   f . 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 ,  30   a  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 ,  30   a  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 ,  30   a  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 ,  30   a  includes at least one transceiver configured to communicate with other relay modules  30 ,  30   a  in the wireless relay network  16 . Relay modules  30   a  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  30   a  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  30   a , as depicted in  FIG. 3A  for example, corresponds to relay modules  30  or  30   a  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  30   a  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  30   a  and/or medical devices  10  in proximity to the patient identification device  17  via the interface circuits  15  and  17   a  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&#39;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 ,  30   a  includes at least one transceiver configured to communicate with other relay modules  30 ,  30   a  in the wireless relay network  16 . Relay modules  30   a  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 ,  30   a  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 ,  30   a  are added to the network, and self-healing when one or more interface circuits  15  and/or relay modules  30 ,  30   a  are removed from or otherwise disabled in the network. Sub-groupings of the interface circuits  15  and relay modules  30 ,  30   a  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  30   a  are shown. The relay module  30   a  of  FIG. 3A  includes a first transceiver  31  for wirelessly communicating with interface circuits  15  and other relay modules  30 ,  30   a  in the WLAN or WPAN network  16  of  FIG. 2A  via an antenna  31   a . A transceiver as contemplated in this description may include a receiver and/or transmitter. The relay module  30   a  further includes a second transceiver  32  for wirelessly communicating with the access point  40  over the WWAN via an antenna  32   a . 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 ,  30   a  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  35   b  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  35   b , 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 ,  30   a  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 ,  30   a . 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  3 A- 3 D, 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 ,  30   a , 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 ,  30   a  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  30   a  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  30   a , a message may be transmitted to an access point  40  by the relay module  30   a  (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  37   b  (see e.g.  FIG. 3B ) may also be associated with the processor  34 , and responsible for identifying trends in emergency conditions. The monitoring unit  37   b  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  37   b  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  39   a  (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  39   b  (which is coupled to the phone device  39   a  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  39   b  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  39   b  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  39   a  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  39   a  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  30   a  to confirm that each of the components of the modules  30   a  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 ,  30   a  to identify the location of the one or medical devices  10 . Alternatively, the relay modules&#39; 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  30   a.    
     As an alternative to GPS-based location, each of the relay modules  30   a  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  35   a  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  31   b ,  32   b  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  30   a  to the configuration of relay module  30   a  depicted in  FIG. 3A . The relay module  30   a  shown in  FIG. 3B  may be the same as or similar to the relay module  30   a  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  30   a  includes transceiver  31  for wirelessly communicating with interface circuits  15  (shown in  FIGS. 1 and 2 ) and other relay modules  30 ,  30   a  in a particular WLAN or WPAN network  16  (shown in  FIG. 2 ) via antenna  31   a . The relay module  30   a  further includes a transceiver  32  for wirelessly communicating with the access point  40  over a particular WWAN (shown in  FIG. 2 ) via an antenna  32   a.    
     Added components to the relay module  30   a  in  3 B that are not present in  FIG. 3A  include an additional transceiver  37 , similar to transceiver  31 , for wirelessly communicating via antenna  37   a  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  30   a  in  FIG. 3A  includes yet a further transceiver  38 , similar to transceiver  32 , for wirelessly communicating via antenna  38   a  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  30   a . In order to make a selection, the processor  34  is configured to communicate with respective status modules  31   b ,  32   b ,  37   b  and  38   b  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  30   a , for example, for indicating a start-up or current status of the relay module  30   a , 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  30   a  of  FIG. 3B  may be substantially similar to the control panel  380  depicted in  FIG. 3H  with corresponding multiple indicators  380   e  for indicating the status of the different WLAN or WPAN networks, and/or multiple indicators  380   j  for indicating the status of the different WWANs. The control panel  380  may include a synchronization switch  380   k  (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  35   b  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  30   a , for example, for indicating a start-up or current status of the relay module  30   a , including communication or connection status with the WLAN or WPAN network  16  and WWAN. The input/output circuit  37   a  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  37   a  may also be connected to user buttons, dials or input mechanisms and devices of module  30   a . The input/output circuit  37   a  is further usable for providing alarm signals to indicate, for example, A/C power loss or loss of accessibility to the WWAN. 
     Relay module  30   a  may preferably be provided as a small physical enclosure with an integral power plug and power supply circuit, such that the relay module  30   a  may be directly plugged into and supported by a conventional wall outlet providing commercial A/C power. Relay module  30   a  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  30   a  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  37   a - 39   b  are shown as separate and distinct devices in  FIG. 3  for illustration purposes only and that the functionality of devices  34  and  37   a - 39   b  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  30   a  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  30   a  configuration of  FIG. 3B  may be operated in a substantially similar manner to the relay module  30   a  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  30   a  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  30   a  that enables voice communication and interaction between a caregiver proximate the relay module  30   a  and a clinician or technician at the remote monitoring device. The identical components in the  FIGS. 3A ,  3 B, and  3 C are like numbered including, for example, the first and second transceivers  31  and  32 , data processing circuit  33 , processor  34  and data buffer  35   a . The relay module  30   a  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 &amp; 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  30   a  of  FIG. 3C  enables a patient or caregiver proximate the relay module  30   a  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  30   a  of  FIG. 3C , speech uttered by the caregiver proximate the relay module  30   a  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  30   a  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  30   a  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  30   a  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  39   a  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  30   a  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  30   a  (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  30   a , 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  30   a  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  30   a  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  30   a  but excluding the transceiver for communicating over the WWAN with the access point  40 . 
     The relay module  30   a  of  FIG. 3D  further preferably includes a location device  39   a  including, for example, a conventional global positioning system signal (“GPS”) chip for determining a GPS location of the relay module  30   a . In addition, the relay module  30   a  of  FIG. 3  includes a power monitoring device  39   b  for monitoring a voltage level of a external AC power source (not shown) providing power to the relay module  30   a , and a secondary power source  39   c  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  30   a , 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 , 30   a  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  30   a  itself. For example, the relay module  30   a  could receive such information from another relay module when the other relay module malfunctions. In this way, it is assured that the relay module  30   a  provides the necessary redundancy for another relay module. Additionally, it is further possible for such information to be transmitted to the relay module  30   a  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  30   a  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  30   a  using the WLAN or WPAN  16 . The particular relay module  30   a  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  30   a , and the like. 
     In another embodiment, it is possible that the information indicative of an alarm condition is received at the relay module  30   a , 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  30   a  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  30   a  may internally generate its own alarm and/or device signals in relation to the relay module  30   a , for example, the current status of the relay module  30   a  (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  30   a . 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  30   a  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  30   a  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  30   a  alarm sounds should alert any caregivers located outside of the patient&#39;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  30   a . Using these buttons, dials, or input mechanisms, the audible alerts produced by the relay module  30   a  may be muted, i.e., disabled, or volumes substantially reduced. The muting or volume reduction may alternatively be in response to the relay module  30   a  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  30   a  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  30   a  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  30   a  to also be displayed by display  36 . For example, alerts representative of information during start-up or current status of the relay module  30   a  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  30   a , whether by remaining minutes and/or hours of life or other graphical depictions. 
     Relay module  30   a  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  30   a  may be directly plugged into and supported by a conventional wall outlet providing commercial A/C power. Relay module  30   a  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  30   a  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  30   a  are shown in  FIGS. 3A-3D . However, the relay device  30  or  30   a  is not limited to the specific configurations shown. For example, a relay device  30   30   a  may include some or all of the components or features described with respect to any or all of  FIGS. 3A ,  3 B,  3 C, and  3 D. A relay device  30  or  30   a  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  30   a . Configuration  370  includes a housing  370   a , 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  370   c  on a front panel  370   b  of the housing  370   a  for locating a control panel  380  (as further illustrated in  FIG. 3H ), and having a sufficient area on a rear panel  370   d  for providing a receptacle support  370   e  and power plug  370   f  for supportably plugging the module configuration  370  into a conventional power outlet. The power plug  370   f  may also be provided in a modular and replaceably removable configuration enabling power plugs  370   f  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  380   a  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  380   b  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  380   c  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  380   c  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  380   d  to indicate a status of the subsystem battery back-up circuit. For example, and as illustrated in  FIG. 3H , the battery indicator  380   d  may preferably include indicator segments  380   h  which may be selectively activated to indicate a capacity of the back-up battery. Indicator segments  380   h  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  380   h , the segments  380   h  may, for example, be activated to indicate that the back-up battery is fully charged, and ones of the segments  380   h  may be progressively deactivated (for example, proceeding downwardly from an uppermost one of the segments  380   h ) 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  380   h  may be deactivated. Alternatively, the indicator segments  380   h  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  380   h  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  380   h  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  380   e  to indicate a status of the portion of the WLAN or WPAN network  16 . Similarly to the A/C power indicator  380   c , used to provide communications between the WLAN/WPAN network relay module  30   a  and its associated interface circuits  15  and medical devices  10 . This relay module network status indicator  380   e  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  380   e  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  30   a  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  380   f  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  380   g  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  380   f ,  380   g  may each comprise a single bi-color LED. 
     A WWAN indicator  380   j  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  380   j  includes indicator elements  380   f ,  380   g  for indicating the WWAN network status. In this configuration, for example, the indicator element  380   f  may be configured with a green LED indicator element that is activated when the WWAN network status is active or accessible, and the indicator  380   g  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  380   j  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  380   f  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  380   i  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  30   a  to the WWAN network). The WLAN/WPAN indicator  380   i  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  380   i  may preferably be backlit with one or more multicolor LEDs. Optionally, the indicator element  380   i  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  380   b  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  380   a - 380   j  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  30   a  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 ,  30   a  components of FIGS.  2  and  3 A- 3 H, 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  30   a  from one of the interface circuits  15  and/or other relay modules  30 ,  30   a  over the wireless relay network  16 . At step  404 , the processor  34  of the one relay module  30   a  determines whether the WWAN is accessible by that relay module  30   a.    
     The determination of step  404  may be carried out in a variety of manners. For example, the processor  34  may interrogate the status module  32   b  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  32   b  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 ,  30   a  may be assigned a predetermined, fixed role within the network  16 . For example, relay modules  30   a  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 ,  30   a . 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  32   b  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  30   a ) to retrieve the medical device data from the buffer  35  or  35   a  (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  32   b  may indicate that the WWAN is not accessible by the transceiver  32 . For example, if the one relay module  30   a  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  30   a . In this event, at step  408 , the processor  34  determines whether a second relay module  30   a  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  30   a  and to listen for a reply, or by retrieving a stored status indicator for the second relay module  30   a.    
     If the second relay module  30   a  is accessible, then the processor  34  instructs the data processing circuit  33  of the one relay module  30   a  to retrieve the medical device data from the buffer  35  or  35   a  (as necessary) and forward the medical device data to the transceiver  31  for transmission to the second relay module  30   a  over the WLAN or WPAN at step  410 . Alternatively, if the second relay module  30   a  is inaccessible in step  408 , this portion of the process  400  may preferably be repeated to search for a further relay module  30   a  that is accessible. Alternatively, or in the event that no other relay module  30   a  is available, the processor  34  of the one relay module  30   a  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  30   a , 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  30   a  is due but not received, at the inbound web server  41  from the wireless relay module  30   a.    
     For example,  FIG. 4B  depicts a method of operation  400   b  for an embodiment of relay module  30   a . Methods  400  and  400   b  include substantially identical steps except method  400   b  substitutes steps  404   b  and  406   b  for steps  404  and  406  of method  400 . These substituted steps  404   b  and  406   b  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  30   a  determines if any WWAN is accessible by transceivers  32  or  38  (e.g. in step  404   b ). If no WWAN is accessible the method  400   b  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  404   b , the method  400   b  proceeds to step  406   b . In step  406   b , the method  400   b  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  404   b  there are more than one WWAN accessible, then in step  406   b  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  30   a  is preferably provided with a relay module network indicator  380   e  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  30   a  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  380   e  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  35   b  for each medical device  15  accessible to the relay module  30   a  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  30   a , 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  31   b ) 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  35   b . 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  35   b  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  30   a , 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  30   a , the module performance history indicates that the medical devices have been consistently accessible to the relay module  30   a  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  38   e ). 
     If the current performance data indicate that each medical device  10  is currently accessible to the relay module  30   a , 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  38   e ). If one or more of the medical devices  10  are presently inaccessible to the relay module  30   a , the processor  34  may determine a status of “inaccessible” (indicated, for example, at step  427  by illuminating a red LED segment of indicator  380   e ). 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  380   j  of  FIG. 3H . At steps  441 ,  442  of  FIG. 4D , the processor  34  retrieves a WWAN performance history, for example, from the memory  35   b  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  32   b . (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  35   b . 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  30   a , the module performance history indicates that the WWAN  44  has been accessible to the relay module  30   a  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  38   j ). 
     If the current performance data indicate that the WWAN  44  is currently accessible to the relay module  30   a , 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  38   j ). 
     If the WWAN  44  is presently inaccessible to the relay module  30   a , 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  38   j ). 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  380   i  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  30   a  to the WWAN network). At steps  461 ,  462  and  464  of  FIG. 4E , the processor  34  retrieves current module performance history from the memory  35   b  for communications with each other relay module that is accessible to the relay module  30   a  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  31   b ). 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  35   b . 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  30   a , 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  30   a  is currently accessible to the relay module  30   a  and has a WWAN status of “accessible”, the module performance history indicates that the neighbor modules  30   a  have been accessible to the relay module  30   a  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  380   i ). 
     If the current performance data indicate that each neighbor module  30   a  is currently accessible to the relay module  30   a , but one or more of the neighbor modules  20   a  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  380   i ). If at least two of the neighbor modules  30   a  are not presently accessible to the relay module  30   a , 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  38   i ). 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  30   a  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  39   a  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  39   b  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  37   b.    
       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  30   a  is instructed by the processor  34  to generate location data of the relay module  30   a . 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  39   a.    
       FIG. 4H  presents a table as may be stored for example in memory  35   b  by the relay module  30   a  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  30   a  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 ,  30   a  located in the facility  20 . This may be accomplished, for example, by maintaining a list of active devices  15  and modules  30 ,  30   a  in the buffer  35  or in a manner otherwise accessible to the one relay module  30   a , or coding an identifier of the device  15  or module  30 ,  30   a  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  30   a . 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  30   a  determines at step  506  that the interface circuit  15  or module  30 ,  30   a  is not located in the facility, the one relay module  30   a  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  30   a  determines at step  510  whether the interface circuit  15  or relay module  30 ,  30   a  accessible to the one relay device  30   a  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  30   a , 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  30   a  determines at step  512  that the device  15  or relay module  30 ,  30   a  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 ,  30   a  via the transceiver  31 . In this case, the message may again be broadcasted to all devices  15  and modules  30 ,  30   a  in communication with the one relay module  30   a , and each device  15  or module  30 ,  30   a  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  30   a  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 ,  30   a  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 ,  30   a  is available, then the one relay module  30  forwards the message to the transceiver  31  for transmission to the second relay module  30 ,  30   a  over the WLAN or WPAN. If the second relay module  30 ,  30   a  is inaccessible, then this portion of the process  500  may preferably be repeated to search for a third relay module  30 ,  30   a  that is accessible. Alternatively, or in the event that no other relay module  30 ,  30   a  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 , 30   a.    
       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  30   a  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  30   a  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  30   a , 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  600   a . Some of the steps in process  600   a  may be the same as or similar to steps in process  600 . 
     In accordance with the flow diagram  600   a , at step  602   a  the processor  34  of the relay module  30   a  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  600   a , in step  604   a , determines whether the information obtained in step  602   a  is indicative of an alarm condition or an alarm condition is otherwise present. If no alarm condition is detected at step  604   a , then method  600   a  reverts back to step  602   a . If, in step  604   a , an alarm condition is detected based on the obtained information by step  602   a , the method  600   a  proceeds to step  606   a.    
     In step  606   a , 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  600   a  proceeds to step  608   a.    
     In step  608   a , it is determined whether the module  30   a  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   a , the processor  34  mutes the speaker to disable the audible alarm. However, in step  608   a , if no such input signal is received then the method  600   a  proceeds to step  610   a.    
     In step  610   a , 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  30   a , has been activated. If such a switch has been activated then the method  600   a  proceeds to step  612   a  and the speaker is muted to disable the emitted audible alarm. The method  600   a  then proceeds at step  616   a  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  618   a , and the method  600   a  returns to step  606   a  to produce each of the audible and visual alerts. 
     If in step  610   a , it is determined that the mute switch has not been activated, then the method  600   a  proceeds to step  614   a  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   a  proceeds to step  602   a  and the alarm is disabled. However, if in step  614   a  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  620   a  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  606   a . In addition to, or in the alternative, the relay module  30 ,  30   a  at step  620   a  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  600   a  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  600   b  representing an alarm monitoring process executed by the processor  34  and the power monitoring device  39   b  with respect to the AC power supply to the relay module  30   a . At step  602   b , the processor  34  interrogates the power monitoring device  39   b  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  604   b  to operate for a predetermined period of time (for example, 2 minutes) and then returns to step  602   b . 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  606   b . At step  608   b , 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  30   a ). If yes, the processor  34  transmits a message to clear the alarm at step  610   b , engages a timer to operate for a second predetermined period (for example, 5 minutes), and then returns to step  602   b . If not, the processor  34  engages a timer  614   b  to operate for another predetermined time period (for example, 3 minutes), and then returns to step  602   b . Alternatively, at step  608   b , 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  602   b.    
       FIG. 6C  depicts a flow diagram  600   c  representing an alarm monitoring process executed by the processor  34  and the power monitoring device  39   b  with respect to the secondary power source  39   c  to the relay module  30   a . At step  642   c , the processor  34  interrogates the power monitoring device  39   b  to determine whether the secondary power source  39   c  is providing a “normal” voltage (for example, 9 VDC). If the secondary power source  39   c  is providing a normal voltage, the processor engages a timer  644   c  to operate for a predetermined period of time (for example, 1 minute) and then returns to step  642   c.    
     If the secondary power source  39   c  is not providing a normal voltage (for example, a voltage less than 8.5 VDC), the processor  34  interrogates the power monitoring device  39   b  to at step  646   c  to determine whether the secondary power source  39   c  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  648   c . At step  650   c , 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  30   a ). If yes, the processor  34  transmits a message to clear the alarm at step  652   c , and engages a timer  654   c  to operate for a predetermined period (for example, 1 minute) and returns to step  642   c . If not, the processor  34  engages another timer  656   c  to operate for another predetermined time period (for example, 2 minutes) and then returns to step  642   c.    
     If the processor  34  at step  646   c  determines that the secondary power source  39   c  is not providing a “low” voltage (for example, between 7 and 8.5 VDC), the processor  34  concludes at step  658   c  that the voltage is a “near death” voltage (for example, less than 7 VDC). The processor  34  then begins at step  660   c  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  35   b , and causes a near death battery alarm message to be transmitted at step  662   c . At step  664   c , 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  30   a ). If yes, the processor  34  transmits a message to clear the alarm at step  666   c , and engages a timer  668   c  to operate for a predetermined period (for example, 1 minute) and returns to step  642   c . If not, the processor  34  engages another timer  670   c  to operate for another predetermined time period (for example, 2 minutes) and then returns to step  642   c . If normal battery voltage is detected at step  642   c , the processor  34  retrieves any medical device data that was stored in the memory  35   b  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  30   a  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  30   a  may alternatively instruct the status module  31   b  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 ,  30   a  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  30   a  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  30   a  that relay communications from a first relay module  30   a  through a second relay module  30   a  in the event that WWAN access to the first relay module  30   a  has been compromised, reliability can be improved and the use of conventional, low-cost cellular transceivers can be enabled in the relay modules  30   a  for accessing the WWAN. 
     By limiting the configuration of cellular transceivers to just the relay modules  30   a , costs can be further reduced. In addition, providing the relay modules  30   a  in a compact enclosure facilitates the relay modules  30   a  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  700 A 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  702 A, the process may be initiated, for example, by actuating the synchronization switch  38   k  on the control panel  38  as illustrated in  FIG. 3(   e ) of a relay module  30   a  in proximity to the medical device  10 . The relay module  30   a  enters an identification signal reception mode, in which it waits for a first predetermined interval (for example, using a time-out algorithm) at step  704 A to receive patient identification data over the facility-oriented wireless network via the interface device  17   a  of a patient identification device  17 . The relay module  30   a  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  706 A, after receipt of the patient identification information, the relay module  30   a  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  30   a  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  700 A 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  30   a ) which is validated by comparison to a caregiver identification table maintained for example in the memory  35   b  of the relay module  30   a , 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  708 A, 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  700 B illustrated in the flow diagram of  FIG. 7C . 
     At step  702 B of  FIG. 7C , a patient identification directory in the memory  35   b  of the relay module  30   a  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  712 B, and an acknowledgement status identified is extracted from the record at step  710 B. 
     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  30   a  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  704 B, and then transmits the encrypted data packet at step  706 B 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  702 B,  704 B and  712 B may be omitted. 
     At step  708 B, 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  710 B, the relay module  30   a  extracts the acknowledgement status identifier from the decrypted packet. At step  714 B, the relay module  30   a  preferably adds a record to the patient identification directory in the memory  35   b  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  710 A, 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  30   a  at step  712 A. 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  30   a  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  100 B 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  100 B 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  9321 A) and an identifying image (for example, image  9321 B) 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  9337 A are provided in association with images  9337 B 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  9337 A′ (“Off Line”) and an image  9337 B′ (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  9347 A preferably recreating a current screen generated and displayed by the medical device  10 . In addition, the screen display  9340  includes any of a panel  9347 B providing identifying information for the medical device  10  (in this case, a pump location), a panel  9347 C for displaying a message indicating a current error condition of the pump, and an icon button  9347 D for selecting an alternate “status” mode of the screen display  9340 . The screen display  9340  also includes a control icon button  9347 E for selecting a system set-up screen display, and a control icon button  9347 F for enabling device control from the remote monitoring device  62 . For example, upon selecting the control icon  9347 F, the screen display  9340  may preferably be refreshed to include the medical devices screen  9347 A 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 ,  9 C and  9 D 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  9347 F 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  9347 E 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  9347 E. 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&#39;s selection of the “System Setup” icon button  9347   e  of the screen display  9340 , and thereafter upon the clinician&#39;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 ,  9 A,  10 A or  11 A. 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