Wireless Relay Module For Remote Monitoring Systems
Systems and methods for communication include one or more wireless relay devices having a first receiver capable of wirelessly receiving medical device data over a wireless relay network from at least one network device, a first transmitter capable of wirelessly transmitting data over an internet-accessible wireless communications network and a second transmitter capable of wirelessly transmitting medical device data to a second medical device or a wireless relay module over the wireless relay network. Patient identification information can be obtained and/or communicated.
Latest Covidien LP Patents:
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.
FIELDThe 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.
BACKGROUNDIn 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.
SUMMARYThe 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.
The subject of this disclosure will become more readily apparent from the Detailed Description, which proceeds with reference to the drawings, in which:
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
As illustrated in
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
Associated with each medical device 10 is an interface circuit 15 that includes a transceiver having one or more of a transmitter and/or a receiver for respectively transmitting and receiving signals in a facility-oriented wireless network 17 such as, for example, a Low-Rate Wireless Personal Area Networks or “LR-WPAN,” ZIGBEE network or another low-power personal area network such as a low power Bluetooth network, existing or presently under development or consideration. See, e.g., Houda Labiod et al., Wi-Fi, Bluetooth, Zigbee and WiMax, Springer 2010, which is incorporated by reference herein in its entirety. It should be understood that interface circuit 15 may be contained within or disposed external to medical device 10.
Also provided within the patient facility 20 are one or more relay modules 30a. Each relay module 30a may include a first transceiver for receiving signals from and transmitting signals to the interface circuits 15 in the facility-oriented wireless network 17, and further include a second transceiver for wirelessly transmitting signals to and receiving signals from an access point 40 via a wireless wide-area network (“WWAN”) 52. Suitable WWANs include, for example, networks based on a Global System for Mobile Communications (GSM) or Code Division Multiple Access (CDMA) cellular network or associated with the 2G, 3G, 3G Long Term Evolution, 4G, WiMAX cellular wireless standards of the International Telecommunication Union Radiocommunication Sector (ITU-R). See, e.g., Vijay Garg, Wireless Communications & Networking, Morgan Kaufmann 2007, which is incorporated by reference herein in its entirety. For compliance with HIPAA regulations, communications over each of the facility-oriented wireless network and WWAN are preferably conducted securely using, for example, a Secure Sockets Layer (SSL) protocol or a Transport Layer Security (TLS) protocol or other cryptographic protocols.
As illustrated in
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
In addition, and as will be further described herein, the device integration server 41 of
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
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
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
In
Each of the relay modules 30, 30a includes at least one transceiver configured to communicate with other relay modules 30, 30a in the wireless relay network 16. Relay modules 30a also may include at least a second transceiver for communicating over the WWAN with the access point 40. As further described in greater detail with regard to
As shown in
In the illustrated wireless relay network 16, each of the interface circuits 15 includes a communications interface such as, for example, a wired or wireless communications interface, to an associated medical device 10. In addition, each of the relay modules 30, 30a includes at least one transceiver configured to communicate with other relay modules 30, 30a in the wireless relay network 16. Relay modules 30a further include at least a second transceiver for communicating over the WWAN with the access point 40.
Each of the transceivers 31, 32 will typically include a mesh network transmitter (e.g. a ZIGBEE transmitter) for transmitting medical device data over one of the mesh network 16 or the WWAN, and a received for receiving medical device data transmitted over one of the mesh network 16 or the WWAN.
In accordance with IEEE 802.14.15, if the network 16 is a ZIGBEE mesh network then there is little risk that communications from more than one medical device will contend for simultaneous access to the network 16. The network 16 operates with a protocol in which a transmitting device checks for energy on a wireless bus component of the network 16. If the bus is in use, the transmitting device waits a preselected amount of time before checking again, and only proceeds to transfer data when the energy level suggests that no other transmission is actively underway on the wireless bus. Nevertheless, for circumstances in which data packets transmitted by the medical devices 10 arrive at a relay module 30, 30a at nearly at the same time, there may be a need to manage an order of delivery by the relay module 30.
The representative ZIGBEE mesh network 16 provides the advantages of being self-configurable when one or more interface circuits 15 and/or relay modules 30, 30a are added to the network, and self-healing when one or more interface circuits 15 and/or relay modules 30, 30a are removed from or otherwise disabled in the network. Sub-groupings of the interface circuits 15 and relay modules 30, 30a may be provided in a defined geographic space (for example, on an individual floor or within a region of a floor in a multi-floor home or care facility).
Referring to
Each rely module 30, 30a is capable of communicating with a number of medical devices 10 over a period of time. It is possible that communications with some of the medical devices 10 are more time-critical with regard to patient safety than other. For example, consider communications with medical devices 10 including each of a thermometer, a feeding pump and a ventilator. In this case, communications with the ventilator would likely be most time-critical among the three medical devices, while communications with the thermometer might be least time-critical among the three medical devices.
According to an embodiment, the processor 34 is configured to determine whether the received medical device data indicates an emergency condition. This determination may be performed by the processor 34 in a number of ways. For example, the processor 34 may compare a condition code in the received medical device data to a condition table located in memory 35b that, for example, includes one or more of corresponding codes for the emergency condition, a description of the emergency condition, symptoms of the emergency condition, an estimate of a future time at which the emergency condition may become harmful (or emergency condition harm time), rankings and/or weights for the emergency condition, related emergency conditions, physiological data (e.g., vital signs, blood pressure, pulse oximetry, ECG, temperature, glucose levels, respiration rate, weight, etc.) indicative of the medical condition, and so on. One form of the possible table is described with reference to
Longer term data storage may preferably be provided by a memory 35b, for example storing instructions for the controller 34, data encryption/decryption software for one of more of the data processing circuit 33 and/or controller 34, a patient identification directory identifying patients using each of the medical devices 10, and the like.
The data in the condition table may be initially entered and/or periodically refreshed from a master store or central repository of emergency condition data, for example, maintained by a designated relay module 30, 30a or other device accessible over one of the available networks. Associated emergency condition data may be periodically transmitted on a scheduled or as-needed basis, for example, from the access point 40 to each of the relay modules 30, 30a. Additionally, polling may be carried out, for example, by the central repository to determine whether any of the relay modules has been provided with emergency condition data not available in the central repository. This emergency condition data may then periodically be transmitted to the central repository, and the central repository may in turn transmit the data to the other modules that may be missing such data. In this way, the exchange of information between the central repository and the relay modules is bidirectional, thus ensuring all modules and the central repository are synchronized with the same emergency condition data. To avoid conflicts, emergency condition data may be time stamped or provided with another indicator of data currency. If a central repository is not used, the modules may exchange emergency condition information between themselves to ensure each module is synchronized. Other embodiments are possible, for example, using multiple central repositories according to conditions monitored, geographic location, and the like.
According to one embodiment, rankings and/or weights may be applied by the processor 34 to assign priority to different emergency conditions and/or perform a triage. For example, the processor 34 on receipt of multiple pieces of medical device data from different transceivers located in the same geographic location or a number of different geographic locations could determine that one medical device requires more immediate medical attention than the others. The priority analysis may also be performed, for example, using the emergency condition harm times.
For example, consider a data packet from a ventilator indicating disconnection from a comatose patient, with possible fatality. In this case, the ventilator should be assigned priority for transmitting to one or more of remote monitoring devices 61, 62 and 63 (as shown in
With reference to FIGS. 3 and 3A-3D, the processor 34 may be configured to read the priority nibble from each received data packet, and to instruct the data processing circuit 33 to place the data packet at a logical position in the buffer element 35 based upon the priority designation. For example, critical-priority data packets (for example, data packets including an indication of a life threatening condition) for the ventilator would be positioned for first retrieval and transmission by the relay module 30, 30a, and other data packets are positioned in order according to their priority.
In addition, under circumstances where urgent commands may need to be transmitted by one of the remote monitoring devices 61, 62 and 63 anticipated based on an urgent data packet (for example, a data packet including an alarm) from the ventilator, the wireless relay module 30, 30a may in addition discontinue reception of any new medical device information from other medical devices until the urgent commands are relayed and an associated alarm condition has been terminated or released.
In one embodiment, it is possible that the medical device data analyzed by the processor 34 may not match any of the emergency conditions in the table and/or database because there is a misspelling and/or the medical condition is known by other names and/or represents a new medical condition. In this scenario, the processor 34 may, for example, perform a similarity analysis between the medical device data received and the symptoms and/or physiological data in the table and/or database (see, e.g., the disclosure herein supra in reference to
According to another embodiment, in order to make processing more efficient, the processor 34 may compare the medical device data received at the transceiver to a list of prior determined emergency conditions and determine if there is a match or approximate match based on conventional interpolation and/or extrapolation techniques. In another embodiment, the processor 34 may also parse the medical device data to find a code which indicates that an emergency condition exists. Alternatively, the processor 34 may search a table and/or database located in a central repository to determine if the medical device data received indicates an emergency condition. In a another embodiment, the processor 34 in a relay module 30 and/or 30a may query a processor 34 in another device (not the central repository) to determine if that other device knows whether the medical device data includes emergency condition data representing an emergency condition.
Once an emergency condition is determined and an alarm condition is activated by the processor 34 of the relay module 30a, a message may be transmitted to an access point 40 by the relay module 30a (as shown in
A monitoring unit 37b (see e.g.
Upon making a determination that an emergency condition exists, the processor 34 may transmit a message to a phone device 39a (discussed below and shown in
The prerecorded or dynamic message described above may in addition include other relevant patient data to further allow the emergency responders to assess the situation. For example, a patient table stored at the relay module (or alternatively/in addition at the centralized location) may identify care givers of the patient, other present conditions of the patient, previous medical history (e.g., allergic to certain drugs, such as morphine), and additional relevant patient information. Preferably, storage and use of the data in the patient table would conform to HIPAA requirements. As an alternative to these voice messages, the signal generator 39b may transmit medical condition information in the form of a text message to the emergency responder. For example, a text message may be sent over one of a Short Message Service (also known as “SMS”) and/or Multimedia Messaging Service (also known as “MMS”).
The phone device 39a above could be connected via one or more of wireless relay network or internet-accessible wireless network to initiate the call over a voice over internet protocol (VoIP) network, a Public Switched Telephone Network (PSTN), or the like.
The call to the emergency responders may be unsuccessful for a variety of reasons (for example, associated E911 circuits may be busy or otherwise unavailable). In this situation, the processor 34 and/or phone device 39a may detect a non-response from the E911 circuits and transmit a non-response message to one or more of the medical device, the access point 40, and/or one or more other designated devices to indicate the unsuccessful call. In addition, the processor 34 may periodically perform self-diagnostics on the relay module 30a to confirm that each of the components of the modules 30a that is used to detect the emergency condition and make the emergency call is operational Of course while a single processor 34 is described, multiple processors 34 may be used in as appropriate.
The location of the medical device may be determined in a variety of ways well-known in the art. For example, location information may be provided to the processor 34 from a global positioning system signal (“GPS”) that is received and interpreted by the medical device located in the medical device data received, a GPS chip in the location device 38 (see e.g.
As discussed above, location information may be included in the medical condition data received by one of the relay modules 30, 30a to identify the location of the one or medical devices 10. Alternatively, the relay modules' location may also be determined using a conventional GPS receiver provided in the location device 38. In the latter case, at least an approximate or “zone” location of the one or more medical devices would be provided by the location information for the relay module 30a.
As an alternative to GPS-based location, each of the relay modules 30a may for example transmit and receive signals via the internet-accessible wireless communication network to two or more cell towers, beacons or other radio devices at fixed, known locations in order to determine a location of the relay module according to known geometric methods. Such techniques for determining location (for example, including triangulation form cell towers) are well known in the art. See, e.g., Shu Wang et at Location-Based Technologies for Mobiles: Technologies and Standards, presentation at IEEE ICC Beijing 2008, IEEE, 2008, which is incorporated by reference herein in its entirety, for all purposes. In one embodiment, triangulation may be carried out using other relay modules positioned at fixed, known locations in a facility.
The data processing circuit 33 may be further configured to retrieve data from the buffer element 35a under the direction of the processor 34 and provide the retrieved data to a selected one of the transceiver 31 or transceiver 32 for transmission. In order to make a selection, the processor 34 is configured to communicate with respective status modules 31b, 32b of the transceivers 31, 32 in order to determine a communications status of each of the transceivers 31, 32.
Added components to the relay module 30a in 3B that are not present in
Each of the transceivers 31, 32, 37 and 38 is in communication with data processing circuit 33, which is configured to operate under the control of processor 34 to accept data received by the transceivers 31, 32, 37 and 38 and store the received data in buffer element 35. In addition, the data processing circuit 33 is further configured to retrieve data from buffer element 35 under the direction of processor 34 and provide the retrieved data to a selected one of the transceivers 31, 32, 37 or 38 for transmission. Further embodiments can for example involve one or more processors 34 configured to accept medical device data from mesh network 16 and to send the medical device data through the WWAN without storing the medical device data in the relay module 30a. In order to make a selection, the processor 34 is configured to communicate with respective status modules 31b, 32b, 37b and 38b of respective transceivers 31, 32, 37 or 38 in order to determine a communications status of the transceivers 31, 32, 37 or 38. It should be understood that the data processing circuit 3 and processor 34 may be implemented as separate integrated circuits or chip sets or their functions may be combined and implemented on single integrated circuits or chip set
The processor 34 is also preferably in communication with an input/output circuit 36, which provides signals to one or more display elements of the relay module 30a, for example, for indicating a start-up or current status of the relay module 30a, including communication or connection status with the WLAN or WPAN networks and WWANs networks. Input/output circuit 36 may also be configured to provide signals to indicate an A/C power loss, and or to be responsive to signals provided by one or more input devices provided in proximity to the one or more display elements.
A control panel useable for the module 30a of
The processor 34 is also preferably in communication with a memory 35b for storing an operating program of the processor 34 and/or data stored by and/or retrieved by the processor 34. The processor 34 is also in communication with an input/output circuit 36, which provides signals to one or more display elements (not shown) of the relay module 30a, for example, for indicating a start-up or current status of the relay module 30a, including communication or connection status with the WLAN or WPAN network 16 and WWAN. The input/output circuit 37a may also be configured to provide signals to indicate an A/C power loss, and or to be responsive to signals provided by one or more input devices provided in proximity to the one or more display elements. The input/output circuit 37a may also be connected to user buttons, dials or input mechanisms and devices of module 30a. The input/output circuit 37a is further usable for providing alarm signals to indicate, for example, A/C power loss or loss of accessibility to the WWAN.
Relay module 30a may preferably be provided as a small physical enclosure with an integral power plug and power supply circuit, such that the relay module 30a may be directly plugged into and supported by a conventional wall outlet providing commercial A/C power. Relay module 30a may also preferably include a battery back-up circuit (not shown) to provide uninterrupted power in the event of A/C power outage, an A/C power outage of short duration as well as for ambulatory use of the relay module. Alternatively, relay module 30a may be provided with rechargeable and/or replaceable battery power as a primary power source for ambulatory use. It should be readily understood by one skilled in the art that processor 34 and devices 37a-39b are shown as separate and distinct devices in
Battery back-up may also be advantageous, for example, for using the relay module 30a in an ambulatory mode that enables the patient to move within and potentially at a distance from the facility 20, for example, with a medical device 10 that is a portable feeding device. In this configuration, for example, the medical device 10, the interface circuit 15 and relay module 30 may be conveniently carried in a mobile platform such as any patient-wearable backpack, vehicle, or other transport vessel.
The relay module 30a configuration of
The particular type or brand of speech codec selected for the codec 105 is not necessarily critical as long as it is compatible and/or interoperable with the speech codec of the corresponding remote monitoring device. Suitable codecs for the speech codec 105 include, for example, fixed rate codecs such as voice-over-Internet-protocol (VoIP) codecs in compliance with the ITU standard H.323 recommended protocol. Speech coding standards in accordance with VoIP include ITU standards G.711 (PCM), G.723.1 (MP-MLQ & ACELP), G.729 (CSACELP), GSM-FR; or Adaptable Multi-Rate (AMR) standards such the European Telecommunication Standard Institute (ETSI) and Third Generation Partnership Project (3GPP) IMT-2000. Alternatively, it is possible to employ codecs useable for transmitting encoded speech signals over a mobile telephone network.
The configuration of the relay module 30a of
Conversely, digitized and encoded speech signals representing speech of the clinician or technician transmitted by the remote monitoring device are received by the module 30a wherein the processor 34 supplies such signals to the codec 105 which decodes the signals and converts the decoded signals to analog signals that are supplied to the speaker 37.
Although the implementation of the codec 105 and microphone 110 has been described with regard to exchanging VoIP signals, it should be readily understood that any method of communicating speech signals may be employed including, for example, utilizing a cellular or mobile telephone codec or modem for codec 105 to transmit and receive speech signals, e.g., CDMA- or GSM-compliant speech signals over a mobile telephone network. Further, it is possible for the codec 105 to be implemented as hardware and/or software in a single chip, chip set or as part of the processor 34.
In an alternative embodiment, it is possible to implement speech detection and/or recognition functionality into the codec 105 or processor 34 to enable the relay module 30a to identify specific command words to initiate the carrying out of a corresponding responsive/interactive action. For example, such speech recognition functionality may be triggered by processing signals supplied by the microphone 110 to identify terms “Help”, “Emergency” or “Call 911.” Upon detecting such trigger terms, the processor 34 initiates the process of dialing an emergency response service such as “911,” with or without using synthesized or recorded speech to request confirmation from the caregiver to place such a call and initiate communication between the caregiver and the emergency response service. The dialing may be performed by hardware or software implemented in the processor 34, codec 105 or other components coupled to the processor 34. The speech recognition functionality may alternatively or additionally transmit a text message or other text or audio-visual correspondence to the emergency response service based upon identified spoken works or commands by the caregiver.
It should be readily understood that the relay module 30a of
Referring also to
In this case, the processor 34 may preferably transmit a “lost device” alarm message via at least one of the transceivers 31, 32 to the access point 40 and/or to any other Internet-accessible and/or wireless network-accessible recipients. In addition, in order to conserve power and or bandwidth of the wireless relay module 30a, the processor 34 may suspend all other measurements made to determine communications health with the medical device 10 (for example, heartbeat requests and signal quality measurements) until it has been determined that the medical device 10 is back within the geo-fence.
One of skill in the art will also readily understand that the elements used by the wireless relay module 30a to determine whether communications with a particular medical device 10 can be transmitted and/or received over the wireless relay network may be replicated in the medical device 10, such that the medical device 10 may determine whether communications with a particular wireless relay module 301 can be carried out over the wireless relay network, and to issue a visual and/or audible alarm at the medical device 10 when communications with the wireless relay module 30a cannot be carried out. This feature would be particularly useful, for example, to a patient in an ambulatory setting as a means for learning that he/she has exited the geo-fence.
It is possible for the relay module 30 to have a substantially similar configuration as the relay module 30a but excluding the transceiver for communicating over the WWAN with the access point 40.
The relay module 30a of
The processor 34 may be a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM), and non-volatile storage. Other hardware, conventional and/or custom, may also be implemented in one or more configurations.
In an embodiment, the medical device data received by one of the transceivers 31, 32 from the one or more medical devices 10 may include, for example, information indicative of an alarm condition. In addition to the types of medical device data previously provided herein, the received information may include, for example, at least one of medical device description, medical device identification (e.g., unique device number), medical device location (e.g., device/patient room number), patient identification (e.g., patient identification number), alarm type, alarm error code, and/or alarm severity. Methods in which an alarm condition may be determined include predetermined codes, look-up table(s) and or algorithms for identifying alarm conditions based on processing the received information.
In addition to information indicative of an alarm condition contained in the medical device data received from one or more medical devices 10, it is also possible to receive the alarm indication from another relay module and/or as a result of an indication internally generated in the relay module 30a itself. For example, the relay module 30a could receive such information from another relay module when the other relay module malfunctions. In this way, it is assured that the relay module 30a provides the necessary redundancy for another relay module. Additionally, it is further possible for such information to be transmitted to the relay module 30a from the other relay module when the information is indicative of a high severity alarm condition, e.g., a significant medical emergency, such as emergency 911. Such redundancy will enable a sufficient number of caregivers to be notified of the emergency condition through multiple relay modules to facilitate a prompt response.
In another implementation, the relay module 30a may be notified if another relay module is experiencing numerous alert conditions associated with other modules or medical devices and communicate the alarm information to caregivers. If this occurs, the other relay module may, for example, divert the information indicative of an alarm to the relay module 30a using the WLAN or WPAN 16. The particular relay module 30a selected to receive the alarm information from the other relay module may be based on many factors such as, for example, relay module location, relay module availability, number of caregivers at a given location and/or floor, defined master/slave relationships among the relay modules 30a, and the like.
In another embodiment, it is possible that the information indicative of an alarm condition is received at the relay module 30a, but for some reason, such as a malfunction and/or data transmission bottleneck, the alarm is not communicated audibly and/or visually to the caregivers. To prevent this occurrence, the relay module 30a can be configured to transmit a message back to the one or more medical devices 10 confirming that an alarm was presented to the caregiver. If the message is not received within a predetermined amount of time by the one or more medical devices 10, then one or more medical devices 10 may attempt to communicate with other relay modules to ensure the alarm is addressed. Similar factors, e.g., location, availability, number of caregivers, etc., as described above may be used to select the other relay module(s) for providing alerts for the one or more medical devices.
In a further embodiment, the relay module 30a may internally generate its own alarm and/or device signals in relation to the relay module 30a, for example, the current status of the relay module 30a (e.g., external AC power loss) and/or current communication or connection status (e.g., status with the WLAN or WPAN 16 or WWAN).
After identifying that received data is indicative of an alarm condition, the processor 34 may transmit a message containing alarm information including, for example, at least one of medical device description, medical device identification, medical device location, patient identification, alarm type, alarm error code, and/or alarm severity, to a display 36 attached to the relay module 30a. In this way, an alarm alert may mirror an alarm alert emitted by the originating medical device. The particular type of display chosen for use with the relay module 30a is not necessarily critical. Accordingly, it is possible for display 36 to be a monochrome or color dot matrix, LCD, LED or other display device. Alternatively and/or in addition, the processor 34 may transmit the message containing alarm information to a medical device 10 via the transceiver 31, and/or to the access point 40 via the transceiver 32.
In addition, the processor 34 may also employ a speaker 37, such as a loudspeaker, coupled to the relay module 30a to emit an audible alert indicative of the alarm condition. It is possible for the audible alert based on the alarm condition to be at least one of volume, pitch, tone, type, audible sequence or duty cycle, or recorded sound to indicate the type, urgency or severity of the alarm condition. It is advantageous for an alarm indicating a life-threatening emergency to be more attention-getting, e.g., loud siren, than alarms for less significant conditions that may be addressed by, for example, beeps or calmer tones.
It is also possible for the emitted audible alerts to be spoken words, commands, tones or other sounds. In this way, if the alert emitted from the one or more medical devices 10 is not directly addressed, then the relay module 30a alarm sounds should alert any caregivers located outside of the patient's room. The processor 34 may also cause a signal to be transmitted by, for example, the first transceiver 31 over the WLAN or WPAN 16 to one or more devices including, for example, PDAs, cell phones, pagers, and tablets. In addition, the alarm information may be transmitted over the WWAN using the second transceiver 32 to the one or more devices.
In addition, an input/output circuit 38 may be electrically connected to, for example, user-actuatable buttons, dials or input mechanisms associated with the relay module 30a. Using these buttons, dials, or input mechanisms, the audible alerts produced by the relay module 30a may be muted, i.e., disabled, or volumes substantially reduced. The muting or volume reduction may alternatively be in response to the relay module 30a receiving a signal from the originating medical device transmitting the information, such as in response to a caregiver acknowledging that the emergency condition is being addressed by entering the proper inputs to the originating medical device. Such acknowledgements may preferably take the form of corresponding acknowledgement codes each associated with a particular alarm condition. Even with the audible alerts muted or otherwise disabled, it may be advantageous to continue displaying the alerts on the display 36. The display 36 may continue to display alerts until likewise the alert condition is extinguished or confirmation from a caregiver at the originating medical device or the relay module 30a is received.
In accordance with another embodiment, the processor 34 may control the display 36 to alternate or cycle displayed information intermittently with information from a single medical device or multiple medical devices. For instance, the processor 34 may cause a visual alarm alert indicating an alarm condition (based upon a portion of medical device data) from a first medical device to be shown on the display 36, for example, for a time period of between 2 to 30 seconds before displaying information for another medical device. The visual alarm alerts corresponding to higher severity alarm conditions may be shown for longer durations than alerts of for lower severity alarm conditions. Also, the type of alarm condition may further dictate the display length of time for visual alarm alerts or other information from a particular medical device. Additionally, the processor 34 may also or alternatively display on the display 36 the number of medical devices communicating information indicative of alarm conditions to the relay module 30a and/or show a description of such devices.
In addition, it is possible for the display 36 to display the alerts in different foreground or backlight colors, such as green backlight for normal operation or red backlight for alarm situations, to use color representing the respective severities of alarm conditions. It is further possible for the colors to correspond to specific alarm conditions (e.g., low glucose level) and/or general groups of conditions (e.g., heart conditions). The display may alternatively or in addition incorporate, for example, a multi-colored light-emitting diode array to display the status of the medical devices.
The display 36 may also be used to display non-alarm related information including, for example, internal power supply charge level or status, software version, software download status, relay module network status, handshake status and signal strength of the received WLAN or WPAN 16, and/or WWAN signals. Displayed information for the strength of respective monitored signals and other may be displayed alone or in a combination with the alerts. The signal strength information could be depicted by, for example, by sequential display segments such as, for example, more than one series of different sized light-emitting diodes (LEDs) that would advantageously enable simultaneous display of at least two different network signal strengths for viewing by the caregiver.
As with the display of externally generated information indicative of alarm conditions, it is possible for alerts for internally generated information indicative of an alarm condition by the relay module 30a to also be displayed by display 36. For example, alerts representative of information during start-up or current status of the relay module 30a and/or current communication or connection status with the WLAN or WPAN 16 and WWAN may be shown on the display elements 36. In another embodiment, the processor 34 may cause the display 36 to include information associated with the charge level of a battery (not shown) contained within the relay module 30a, whether by remaining minutes and/or hours of life or other graphical depictions.
Relay module 30a may preferably be provided as a small physical enclosure (not shown) optionally provided with an integral power plug and power supply circuit, such that the relay module 30a may be directly plugged into and supported by a conventional wall outlet providing commercial A/C power. Relay module 30a may also preferably include a battery back-up circuit (not shown) to provide uninterrupted power in the event of A/C power outage of short duration. Battery back-up may also be advantageous, for example, for using the relay module 30a in an ambulatory mode that enables the patient to move within and potentially at a distance from the facility 20, for example, with a medical device 10 that is a portable feeding device. In this configuration, for example, the medical device 10, the interface circuit 15 and relay module 30 may be conveniently carried in a patient-wearable backpack.
Various embodiments of a relay device 30 or 30a are shown in
The control panel 380 of
As further illustrated in
Indicator elements 380f may also be provided, for example, in an array to indicate the status is active or accessible, and either de-activated or intermittently activated when the WLAN/WPAN network status is inactive or inaccessible. The indicator elements may preferably be provided with multi-color LEDs 380g capable, for example, of illuminating a green segment for a healthy a communications path, a yellow segment for operative communication path with issues, and a red segment to indicate a communications path that is inoperative. Alternatively, individual red, yellow and green LEDS may be used in place of the multi-color LEDs. Alternatively or in addition, one or more of elements 380f, 380g may each comprise a single bi-color LED.
A WWAN indicator 380j may preferably be provided to indicate a status of access to the WWAN network, (using, for example, “green” to indicate a healthy network, “yellow” to indicate a network having one or more issues but still operable, and “red” to indicate a network that is inoperative and indicating an alarm condition). As depicted in
Finally, the control panel may include a WLAN/WPAN indicator 380i to indicate an overall health of the entire WLAN/WPAN (or at least of the portion available to provide an alternate path for the relay module 30a to the WWAN network). The WLAN/WPAN indicator 380i may preferably indicate an overall status of the WLAN/WPAN (using “green” to indicate a healthy network, “yellow” to indicate a network having one or more issues but still operable, and “red” to indicate a network that is inoperative and indicating an alarm condition). As depicted in
As previously indicated, the alarm switch 380b may be configured to allow a user to mute and/or un-mute one or more of the audible alarms entirely, or for a specified time period (similarly to a conventional clock alarm “snooze function) indicators of the module configuration 370 such as indicators 380a-380j may preferably be electrically connected to the input-output circuit 36 depicted in
In addition, it is possible for the wireless relay module 30a to employ, for example, hardware or software to implement an International Telecommunication Standardization Sector (ITU-T) H.323 codec to enable voice and/or video communications between a caregiver located proximate the wireless relay module and a remote technician. In such an embodiment, the wireless relay module control panel 38 may optionally include microphone and speaker elements (not shown) for enabling the module configuration 37 to be operated in a voice communication mode to allow for voice communication, for example, between an operator, caregiver, and/or a help desk technician in event of a trouble condition reported by one of the medical devices 10. Alternatively or in addition, the control panel 380 may include one or more of a camera element (not shown) and/or a display element (not shown) coupled to the codec to be operated in a visual communication mode. For example, the camera element may be used to transfer images from displays of one or more medical devices 10 to one of the remote monitoring devices 61, 62 and 63 of
The determination of step 404 may be carried out in a variety of manners. For example, the processor 34 may interrogate the status module 32b of the transceiver 32 at the time of or after the receipt of the medical device data to determine a status parameter indicative of access for the transceiver 32 to the WWAN (for example, access for transceiver 37 to the WWAN may be determined as the result of the transceiver 32 detecting an access signal of the WWAN having adequate signal strength for maintaining data communication at a desired quality level). Alternatively, the processor 34 may interrogate the status module 32b at a different time including, for example, at system start-up and/or periodically (for example, hourly), and maintain a status indicator such as in the buffer 35 or another storage element to be retrieved at the time of receipt of the medical device data. As yet another alternative, the relay module 30, 30a may be assigned a predetermined, fixed role within the network 16. For example, relay modules 30a in the network 16 may be assigned a data routing assignments by a controller or controlling relay module or modules which may be preselected from among the relay modules 30, 30a. By definition, the WWAN status for relay module 30 that does not possess WWAN access capability shall have a fixed status of “WWAN inaccessible.”
If, as provided for in step 404, the status module 32b indicates that the WWAN is accessible by the transceiver 32, the processor 34 will proceed to step 406 to instruct the data processing circuit 33 of the one relay module 30 (or 30a) to retrieve the medical device data from the buffer 35 or 35a (as necessary) and forward the medical device data to the transceiver 32 for transmission to the access point 40 over the WWAN.
Alternatively, in step 404, the status module 32b may indicate that the WWAN is not accessible by the transceiver 32. For example, if the one relay module 30a is located on a basement floor of the building in an area that is substantially shielded with respect to WWAN signals, the WWAN may not be accessible to the one relay module 30a. In this event, at step 408, the processor 34 determines whether a second relay module 30a is accessible via the WLAN or WPAN. Again, this determination may be made in a variety of manners including by instructing the transceiver 31 to send a handshake signal transmission directed to a second relay module 30a and to listen for a reply, or by retrieving a stored status indicator for the second relay module 30a.
If the second relay module 30a is accessible, then the processor 34 instructs the data processing circuit 33 of the one relay module 30a to retrieve the medical device data from the buffer 35 or 35a (as necessary) and forward the medical device data to the transceiver 31 for transmission to the second relay module 30a over the WLAN or WPAN at step 410. Alternatively, if the second relay module 30a is inaccessible in step 408, this portion of the process 400 may preferably be repeated to search for a further relay module 30a that is accessible. Alternatively, or in the event that no other relay module 30a is available, the processor 34 of the one relay module 30a may preferably issue an alarm notification at step 412. Such an alarm notification may, for example, include one or more of local visual and audio alarms as directed by processor 34 via the input/output circuit 36 of the one relay module 30a, alarm messages directed by the processor 34 to another accessible WPAN, WLAN or WWAN via one or more of the transceivers 31, 32, and/or alarm messages generated by the inbound web server 41 of the access point 40. These notifications may be displayed or otherwise executed after a specified time period has been exceeded, for example, during which a handshake signal of the relay module 30a is due but not received, at the inbound web server 41 from the wireless relay module 30a.
For example,
After medical device data is received over a WLAN or PLAN network by transceivers 31 or 37 in step 402, the relay module 30a determines if any WWAN is accessible by transceivers 32 or 38 (e.g. in step 404b). If no WWAN is accessible the method 400b then continues to step 408 and performs substantially the same operations as described with respect to steps 408, 410 and 412 in
Moreover, to the extent to that in step 404b there are more than one WWAN accessible, then in step 406b the controller 33 may determine which one of the accessible WWANs the medical data should be transmitted over by either of transceivers 32 or 38. Such determination can be made by many different criteria or rules including, for example, based upon signal strength, cost, time of day, day of week or preferences of a network manager or other user.
Referring now to
At steps 421, 422 of
At step 423, if the performance history is not sufficiently current (for example, as indicated by timestamp data) and/or missing, the processor 34 at step 424 employs conventional means in the transceiver 31 (for example, via status module 31b) to obtain current performance measures by transmitting a request to and receiving current performance data from the interface circuit 15 of the associated medical device 10, and preferably stores the current performance measures as part of the performance history in the memory 35b. Currency may preferably be determined according to system performance, regulatory and/or other requirements for individual performance measures in prescribed time intervals (for example, for an interval older than 5 seconds, older than 1 minute, older than the most recent each hour, or the like), which may be stored in the memory 35b for retrieval and reference by the processor 34.
After determining at steps 423 and 425 that current performance data has been obtained for each medical device accessible to the relay module 30a, the processor 34 at step 426 determines a current module status as a function of the current performance data and the performance history. For example, if the current performance data indicate that each medical device 10 is currently accessible to the relay module 30a, the module performance history indicates that the medical devices have been consistently accessible to the relay module 30a for a predetermined time (for example, over a period of several hours), and throughput and/or occupancy are within predetermined limits, the processor 34 may determine that the wireless relay network 16 is “healthy” (indicated, for example, at step 427 by illuminating a green LED segment of indicator 38e).
If the current performance data indicate that each medical device 10 is currently accessible to the relay module 30a, but one or more of the devices 10 have a recent performance history where one or more of throughput and/or occupancy were outside of the predetermined limits, the processor 34 may determine a status of “partially accessible” (indicated, for example, at step 427 by illuminating a yellow LED segment of indicator 38 e). If one or more of the medical devices 10 are presently inaccessible to the relay module 30a, the processor 34 may determine a status of “inaccessible” (indicated, for example, at step 427 by illuminating a red LED segment of indicator 380e). At step 428, it may be determined by the processor 34 for example in view of “partially accessible” or “inaccessible” statuses that an alarm condition has been generated, causing the processor 34 to present an alarm (for example, by causing the yellow or red LED segments to be illuminated in a blinking fashion, and/or by providing one or more audible alarms as previously described. As an alternative to displaying display status information at step 427, the processor 34 may cause the transceiver 31 to transmit the status information to one or more of the medical devices 10, or may cause the transceiver 32 to transmit the status information to a device in communication with the WWAN.
With further reference to
After determining at step 443 that the WWAN performance data is current, the processor 34 at step 445 determines a current WWAN status as a function of the current performance data and the performance history. For example, if the current performance data indicate that the WWAN 44 is currently accessible to the relay module 30a, the module performance history indicates that the WWAN 44 has been accessible to the relay module 30a for a predetermined time (for example, several hours), and throughput and/or occupancy are within predetermined limits, the processor 34 may determine that the WWAN 44 is “healthy” (indicated, for example, at step 446 by illuminating a green LED segment of the WWAN indicator 38j).
If the current performance data indicate that the WWAN 44 is currently accessible to the relay module 30a, but has a history where one or more of throughput and/or occupancy was outside of the predetermined limits, the processor 34 may determine a status of “partially accessible” (indicated, for example, at step 446 by illuminating a yellow LED segment of the WWAN indicator 38j).
If the WWAN 44 is presently inaccessible to the relay module 30a, the processor 34 may determine a status of “inaccessible” (indicated, for example, at step 446 by illuminating a red LED segment of the WWAN indicator 38j). At step 447, which may be performed before or concurrently with step 446, it may be determined by the processor 34 for example in view of “partially accessible” or “inaccessible” statuses that an alarm condition has been generated, causing the processor 34 to present an alarm (for example, by causing the yellow or red LED segments to be illuminated in a blinking fashion, and/or by providing one or more audible alarms as previously described. As an alternative or in addition to displaying display status information at step 446, the processor 34 may cause the transceiver 31 to transmit the status information to one or more of the medical devices 10, or may cause the transceiver 32 to transmit the status information to a device in communication with the WWAN.
As previously described, performance measures may, for example, include a measured signal strength, noise, bit rate, error rate, occupancy, availability, path usage and the like as are conventionally measured for WLAN/WPAN networks (using, for example, the status module 31b). In addition, at step 463, the processor operates the transceiver 31 to request that each neighbor module provide a WWAN status (prepared, for example, according to the method described with reference to
At step 465, if the performance history relative to the neighbor modules is not sufficiently current (for example, as indicated by timestamp data) and/or missing, the processor 34 at step 466 employs conventional means in the transceiver 31 to obtain current performance measures by transmitting data to and receiving data from the neighbor modules, and preferably stores the current performance measures as part of the performance history in the memory 35b. In addition, current performance measures may be obtained with respect to other neighboring devices, for example, having known or discernible performance (for example, network “beacons”).
After determining at step 467 that current performance data has been obtained for each neighbor module accessible to the rely module 30a, the processor 34 at step 468 determines a current module status as a function of the current neighbor module performance data (including neighbor module WWAN status) and the neighbor module performance history. For example, if the current performance data indicate that each neighbor module 30a is currently accessible to the relay module 30a and has a WWAN status of “accessible”, the module performance history indicates that the neighbor modules 30a have been accessible to the relay module 30a for a predetermined period of time, and throughput and/or occupancy are within predetermined limits, the processor 34 may determine a status of “fully accessible” (indicated, for example, at step 469 by illuminating a green LED segment of WLAN/WPAN indicator 380i).
If the current performance data indicate that each neighbor module 30a is currently accessible to the relay module 30a, but one or more of the neighbor modules 20a have a recent performance history where WWAN status was inaccessible, the processor 34 may determine a status of “partially accessible” (indicated, for example, at step 469 by illuminating a yellow LED segment of WLAN/WPAN indicator 380i). If at least two of the neighbor modules 30a are not presently accessible to the relay module 30a, the processor 34 may determine a status of “inaccessible” (indicated, for example, at step 469 by illuminating a red LED segment of WLAN/WPAN indicator 38i). At step 470, it may be determined by the processor 34 for example in view of “partially accessible” or “inaccessible” statuses that an alarm condition has been generated, causing the processor 34 to present an alarm (for example, by causing the yellow or red LED segments to be illuminated in a blinking fashion, and/or by providing one or more audible alarms as previously described. As an alternative to displaying display status information at step 469, the processor 34 may cause the transceiver 31 to transmit the status information to one or more of the medical devices 10, or may cause the transceiver 32 to transmit the status information to a device in communication with the WWAN.
At step 502 of the method 500, the message is received at the first one of the relay modules 30a from the access point 40 via the WWAN. At step 504, the one relay module 30 determines whether the message is intended to reach one of the interface circuits 15 and/or other relay modules 30, 30a located in the facility 20. This may be accomplished, for example, by maintaining a list of active devices 15 and modules 30, 30a in the buffer 35 or in a manner otherwise accessible to the one relay module 30a, or coding an identifier of the device 15 or module 30, 30a to include an identity of the facility 20 that is stored in the buffer 35 or is otherwise identifiable to the one relay module 30 or 30a. In the alternative, the received message may include a device identifier such as a serial number or an assigned identifier. Such a received message would then be broadcasted to all or a subset of interface circuits 15 in the facility and each interface circuit 15 determines if it was the intended recipient and should act upon or ignore the message.
If the one relay module 30a determines at step 506 that the interface circuit 15 or module 30, 30a is not located in the facility, the one relay module 30a may preferably proceed to discard the message at step 508, and/or alternatively alert the access point 40 with a non-delivery message. If the interface circuit 15 is located in the facility 20, the one relay module 30a determines at step 510 whether the interface circuit 15 or relay module 30, 30a accessible to the one relay device 30a via the WLAN or WPAN (for example, by consulting a list stored in the buffer 35 or that is otherwise accessible to the one relay module 30a, or by instructing the transceiver 31 to send a handshake or test transmission directed to the interface circuit 15 and to listen for a reply).
If the one relay module 30a determines at step 512 that the device 15 or relay module 30, 30a is accessible, then at step 514, it transmits the message via network 16 to that device or relay module via the transceiver 31, or to relay module 30, 30a via the transceiver 31. In this case, the message may again be broadcasted to all devices 15 and modules 30, 30a in communication with the one relay module 30a, and each device 15 or module 30, 30a may decide to act on or ignore the message (for example, by matching to an associated device ID or other identifier in the message). If the one relay module 30a alternatively determines at step 512 that the device or relay module is not accessible, then it proceeds at step 516 to determine whether a second relay module 30, 30a is accessible via the WLAN or WPAN (for example, by instructing the transceiver 31 to send a handshake transmission directed to the second relay module and to listen for a reply). If the second relay module 30, 30a is available, then the one relay module 30 forwards the message to the transceiver 31 for transmission to the second relay module 30, 30a over the WLAN or WPAN. If the second relay module 30, 30a is inaccessible, then this portion of the process 500 may preferably be repeated to search for a third relay module 30, 30a that is accessible. Alternatively, or in the event that no other relay module 30, 30a is available, the one relay module 30 may preferably issue an alarm notification at step 522, preferably in one of the same manners described above in reference to the methods described in conjunction with
In step 606, the processor 34 produces an alarm alert by transmitting signals representing an alert to be displayed to the display 36 and/or transmits signals representing speech or other audible information (for an audible alarm) to the speaker. Then, the method 600 proceeds to step 608. In step 608, it is determined whether the module 30a receives medical device data or other information instructing the module to mute or disable the audible alarm or an input signal is otherwise received requesting to mute the sound or disable the audible alarm. If such input signal is received then, in step 612, the processor 34 mutes the speaker, i.e., disable the audible alarm. However, in step 608, if no such input signal is received then the method 600 proceeds to step 610.
In step 610, the processor 34 determines whether a user-actuatable switch associated with the input/output circuit 38, e.g., a mute switch of the relay module 30a, has been activated. If such a switch has been activated then the method 600 proceeds to step 612 and the speaker is muted to disable the emitted audible alarm. After the speaker is muted, the method 600 returns to step 602 and starts the process again. However, if in step 610, it is determined that the mute switch has not been activated then the method 600 proceeds to step 614 where the processor again determines whether the alarm condition is still present based upon, for example, newly received medical device data. If the alarm condition is no longer present, the method 600 proceeds to step 612 and the audible alarm is disabled. However, if in step 614 the alarm condition is still present then the method 600 reverts back to step 602 and the audible alert is produced, i.e., continued.
In an alternative embodiment, if in step 614 the alarm condition is present for a particular period of time (either fixed in duration or based upon the particular alarm condition), then in step 606 the emitted audible alarm may advantageously be changed or upgraded in decibel level, pitch, type of sound, duty cycle or speech command to draw greater attention and response to the alarm condition by potential responders. In addition to, or in the alternative to, this change in emitted audible alarm in response to the determination in step 614 that the alarm condition is present for a particular period of time then the relay module may transmit a signal to other nearby or remote relay module(s) to alert other potential responders of the alarm condition.
It should be understood that the method of 600 may operate with information received from plurality of medical devices or other wireless relay modules, and may provide the intermittent displaying of respective alarm alerts for particular time intervals or employ different foreground or background colors based upon the type or severity of the alarm condition.
In accordance with the flow diagram 600a, at step 602a the processor 34 of the relay module 30a of
In step 606a, the processor 34 produces an audible and visual alarm alert by transmitting signals representing an alert to be displayed to the display 36 and/or transmits signals representing speech or other audible information (for an audible alarm) to the speaker. Alternatively and/or in addition, the processor 34 may transmit the alarm alert to a medical device 10 via the transceiver 31, and/or to the access point 40 via the transceiver 32. Then, the method 600a proceeds to step 608a.
In step 608a, it is determined whether the module 30a receives medical device data or other information instructing the module to mute or disable the audible alarm or an input signal is otherwise received requesting to mute the sound or disable the audible alarm. If such input signal is received then, in step 612a, the processor 34 mutes the speaker to disable the audible alarm. However, in step 608a, if no such input signal is received then the method 600a proceeds to step 610a.
In step 610a, the processor 34 determines whether a user-actuatable switch associated with the input/output circuit 38, e.g., a mute switch of the relay module 30a, has been activated. If such a switch has been activated then the method 600a proceeds to step 612a and the speaker is muted to disable the emitted audible alarm. The method 600a then proceeds at step 616a to determine whether a mute timer has expired after a predetermined time interval (for example, 5 minutes). If so the mute signal is cleared and/or the mute switch is released at step 618a, and the method 600a returns to step 606a to produce each of the audible and visual alerts.
If in step 610a, it is determined that the mute switch has not been activated, then the method 600a proceeds to step 614a where the processor again determines whether the alarm condition is still present based upon, for example, newly received medical device data. If the alarm condition is no longer present, the method 600a proceeds to step 602a and the alarm is disabled. However, if in step 614a the alarm condition is still present, the method proceeds at step 423 to check a condition timer to determine whether the alarm condition has been present for a particular period of time (either fixed in duration for example of five minutes, or for a variable duration based upon the particular alarm condition). If the condition timer has expired in step 423, then in step 620a the emitted audible alarm may advantageously be changed or upgraded in decibel level, pitch, type of sound, duty cycle or speech command to draw greater attention and response to the alarm condition by potential responders, and reapplied at step 606a. In addition to, or in the alternative, the relay module 30, 30a at step 620a may transmit a signal to other nearby or remote relay module(s) to alert other potential responders of the alarm condition.
It should be understood that the method of flow diagram 600a may operate with information received from a plurality of medical devices or other wireless relay modules, and may provide the intermittent displaying of respective alarm alerts for particular time intervals or employ different foreground or background colors based upon the type or severity of the alarm condition.
If the secondary power source 39c is not providing a normal voltage (for example, a voltage less than 8.5 VDC), the processor 34 interrogates the power monitoring device 39b to at step 646c to determine whether the secondary power source 39c is providing a “low” voltage (for example, between 7 and 8.5 VDC). If yes, the processor causes a low battery alarm message to be transmitted at step 648c. At step 650c, the processor determines whether an audible portion of the alarm resulting from the transmitted alarm message has been muted (for example, by activating the mute switch of the relay module 30a). If yes, the processor 34 transmits a message to clear the alarm at step 652c, and engages a timer 654c to operate for a predetermined period (for example, 1 minute) and returns to step 642c. If not, the processor 34 engages another timer 656c to operate for another predetermined time period (for example, 2 minutes) and then returns to step 642c.
If the processor 34 at step 646c determines that the secondary power source 39c is not providing a “low” voltage (for example, between 7 and 8.5 VDC), the processor 34 concludes at step 658c that the voltage is a “near death” voltage (for example, less than 7 VDC). The processor 34 then begins at step 660c to store medical device data arriving from one or more medical devices 10 via the wireless relay network and/or from the access point 40 via the internet-accessible wireless communications network in the memory 35b, and causes a near death battery alarm message to be transmitted at step 662c. At step 664c, the processor determines whether an audible portion of an alarm resulting from the transmitted alarm message has been muted (for example, by activating the mute switch of the relay module 30a). If yes, the processor 34 transmits a message to clear the alarm at step 666c, and engages a timer 668c to operate for a predetermined period (for example, 1 minute) and returns to step 642c. If not, the processor 34 engages another timer 670c to operate for another predetermined time period (for example, 2 minutes) and then returns to step 642c. If normal battery voltage is detected at step 642c, the processor 34 retrieves any medical device data that was stored in the memory 35b during the period when a “near death” voltage was detected, and transmits the retrieved medical device data to intended destinations via one or more of the wireless relay network and/or the internet-accessible wireless communications network.
If no response to the request is received by the transceiver 31, the processor 34 increments a request counter at step 810 and engages another timer 812 for another predetermined period of time (for example, 1 minute). Then, the processor 34 proceeds to resend the heartbeat request at step 814. If a response is received by the transceiver 31 to the resent request, the process concludes at step 808 and the processor again engages the timer 802. If no appropriate response is received, the processor 34 proceeds at step 818 to determine whether the request counter exceeds a predetermined value (for example, a predetermined value of 5). If this value is exceeded, the processor 34 causes at step 820, a heartbeat alarm to be displayed by the display 36 and/or be audibly signaled by the speaker 37, and/or transmits a message via at least one of the transceivers 31, 32 to the access point 40 and/or to another internet-accessible and/or wireless network-accessible recipient. The process then continues at step 808 and the processor once again engages the timer 802. If the predetermined value of the request counter is not exceeded at step 818, the process returns to step 810.
One of skill in the art will readily understand that, in addition to requesting a “heartbeat” from the medical device 10, a variety of other measures may be obtained to determine whether communications with a particular medical device 10 can be carried out over the wireless relay network 16. For example, the processor 34 of the wireless relay module 30a may alternatively instruct the status module 31b associated with the transceiver 31 to determine one of a variety of measures of signal quality for the wireless relay network signals being received from a medical device 10 (for example, including a signal strength or data rate of the transmitted signal).
The architecture disclosed herein for providing networked communications between a series of medical devices and a remote monitoring device provides a number of distinct advantages in comparison to other monitoring systems. By employing wireless relay networks such as ZIGBEE networks based on the IEEE 802.15.4 standard, for wireless communications between the medical devices 10 and relay modules 30, 30a in accordance with one embodiment, power and size requirements can be minimized so that the interface circuits 15 can be easily and inexpensively applied to and/or integrated with the medical devices 10.
By introducing relay modules 30a that are part of the wireless relay mesh networks with the capacity to access off-site monitoring devices via a WWAN, access to and reliance on existing and potentially unreliable LAN facilities at a facility can be avoided. By incorporating relay features into the relay modules 30a that relay communications from a first relay module 30a through a second relay module 30a in the event that WWAN access to the first relay module 30a has been compromised, reliability can be improved and the use of conventional, low-cost cellular transceivers can be enabled in the relay modules 30a for accessing the WWAN.
By limiting the configuration of cellular transceivers to just the relay modules 30a, costs can be further reduced. In addition, providing the relay modules 30a in a compact enclosure facilitates the relay modules 30a to be easily connected to reliable commercial power sources and easily moved when needed to reconfigure the wireless relay networks (e.g. a to a mesh network) according to facilities changes. The portability for ambulatory use that is provided by battery back-up is an additional advantage.
At step 706A, after receipt of the patient identification information, the relay module 30a waits for a second predetermined interval to receive medical device identification information over the facility-oriented wireless network via the interface circuit 15 of a medical device 10. Once again, the relay module 30a preferably indicates receipt of this medical device data by presenting an audible or visual signal at the control panel 38, or by broadcasting a receipt signal to medical device 10 over the facility-oriented wireless network. It should be understood that the order of receipt of the patient identification data and the medical device identification information (which may be respectively transmitted, for example, by a caregiver operating the patient identification device 17 and the medical device 10) may be inverted. In addition, the inventive process 700A may optionally first require the caregiver to transmit caregiver identification data (for example, via one of the patient identification device 17 or the medical device 10, or via a sensor provided in the relay module 30a) which is validated by comparison to a caregiver identification table maintained for example in the memory 35b of the relay module 30a, or alternatively by forwarding a validation request to the remote monitoring system at the access point 40 over one or more of the facility-oriented wireless network and WWAN via an associated one of the transceivers 31, 32.
At step 708A, upon receipt of each of the patient identification data and the medical device identification data, a verification process is initiated. This process is carried out by the method 700B illustrated in the flow diagram of
At step 702B of
If the patient identification data and medical device identification data are not present in the patient identification directory, or if the time stamp does not indicate that a record including such data is current, the relay module 30a proceeds to form a data packet including the patient identification information and medical device identification and to encrypt this packet (for example, using a suitable conventional encryption algorithm such as secure sockets layer (SSL) data encryption) at step 704B, and then transmits the encrypted data packet at step 706B for further validation to the remote monitoring system at the access point 40 over one or more of the facility-oriented wireless network and WWAN via an associated one of the transceivers 31, 32. Alternatively, the patient identification information and/or the medical device identification information may be encrypted by one or more of the patient identification information device or the medical device, and steps 702B, 704B and 712B may be omitted.
At step 708B, the relay module receives a reply packet from the remote monitoring system via one of the transceivers 31, 32, and decrypts that packet. At step 710B, the relay module 30a extracts the acknowledgement status identifier from the decrypted packet. At step 714B, the relay module 30a preferably adds a record to the patient identification directory in the memory 35b that includes the patient identification information, the medical device identification information, the acknowledgement status identifier and a current time stamp.
Returning to
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
It should be readily understood by one skilled in the art that step 8204 of method 8200 for identifying and storing the address of the patient care database node 60 may be omitted if a single patient care database node is utilized with system 100B of
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
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.
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
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
It should be readily understood that computer screen images 9320, 9330 and 9340 and corresponding navigation depicted by
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.
Upon receipt of the patient authentication, a control request is forwarded by the outbound web server 43 at step 1008 to the secure device web server 42 to be logged in the information record of the device control database 44 that is associated with the medical device 10 (and optionally, with an anonymous ID for the patient). At step 1010, the secure device web server forwards the control request, such as an encrypted control request, to the device integration server 41, which transmits an associated device control command over the secure WWAN 52 for receipt by an associated wireless relay module 30 at step 1012. The wireless relay module 30 wirelessly communicates the command to the medical device 10 via an associated device interface 15, and awaits a reply confirming execution of the command transmitted by the device interface 15.
At step 1014, the device integration server 41 receives an update message from the wireless relay module 30 via the secure WWAN 52 which confirms that the command was executed by the medical device 10. At step 1016, the device integration server 41 forwards the update message to the secure device web server 42 to be logged in the information record of the device control database 44 that is associated with the medical device 10. Optionally, and preferably, the secure device web server 42 forwards information pertaining to the update message to the outbound web server 43, and the outbound web server 43 prepares an updated display screen that is securely transmitted to the remote monitoring device 62 to indicate that the command has been executed.
Alternatively, at step 1004, the authenticated clinician may select the “System Setup” control icon button 9347E to perform a command other than an operational command directed to the medical device 10.
Icon button 1054 may be selected to initiate a diagnostic test of the medical device 10.
In a similar manner to that performed by the method of
Referring again to
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.
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.
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
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
Input devices 1240 may provide input/output operations for system 1200. Input/output devices 1240 may include one or more of a keyboard, a pointing device, and/or microphone. Input/output devices 1240 may further include a display unit for displaying graphical user interfaces, a speaker and a printer and any of a number of other serial devices (for example, configured as Universal Serial Bus (USB)-based devices
Claims
1. A process for providing communications between a medical device to be used by a patient and a remote monitoring device via an internet-accessible wireless communications network, said process comprising:
- obtaining identification information identifying the patient;
- obtaining identification information identifying the medical device transmitting each of the patient identification information and the medical device identification information to the remote monitoring device via the internet-accessible wireless communications network;
- receiving an acknowledgement status from the remote monitoring device via the internet-accessible wireless communications network; 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.
2. The process of claim 1, wherein said particular status represents an authorization of use of the medical device by the patient based upon a pre-authorization record for the patient.
3. The process of claim 1, further comprising encrypting the patient identification information prior to transmitting the patient identification information to the remote monitoring device.
4. The process of claim 1, further comprising encrypting the medical device identification information prior to transmitting the medical device information to the remote monitoring device.
5. The process of claim 1, wherein transmitting the patient identification information to the remote monitoring device comprises:
- receiving the patient identification information at the medical device; and
- transmitting the patient identification information from the medical device via the internet-accessible wireless communications network to the remote monitoring device.
6. The process of claim 5, wherein the medical device performs said transmitting the medical device identification information to the remote monitoring device.
7. The process of claim 6, wherein the patient identification information and the medical device identification information are transmitted by the medical device to the remote monitoring device in a single information block.
8. The process of claim 1, wherein obtaining the patient identification information comprises reading the patient identification information by a patient identification information reader.
9. The process of claim 8, further comprising coupling the patient identification information reader to the medical device.
10. The process of claim 8, further comprising transmitting the patient identification information from the patient identification information reader to the medical device via a wireless relay network.
11. The process of claim 8, further comprising transmitting the patient identification information from the patient identification information reader to a wireless relay module via a wireless relay network.
12. The process of claim 10, further comprising providing wireless bandwidth priority for the patient identification information reader by the medical device.
13. The process of claim 11, further comprising providing wireless bandwidth priority for the patient identification information reader by the relay module.
14. The process of claim 8, wherein obtaining the patient identification information comprises reading bar-coded reader patient identification information.
15. The process of claim 8, wherein obtaining the patient identification information comprises reading a radio frequency identification (RFID).
16. The process of claim 8, wherein obtaining the patient identification information comprises obtaining one or more sources of identification information from one or more of fingerprints, retinal scans, vein-pattern scans and optical images.
17. The process of claim 8, wherein the patient identification information reader comprises a device selected from one or more of smartphones, tablet computers, personal digital assistants (PDAs), cell phones and pagers.
18. The process of claim 1, wherein one or more of transmitting the patient identification information or transmitting the medical device identification information to the remote device comprises transmitting the identification information via a wireless relay module.
19. The process of claim 18, further comprising:
- storing one or more of the patient identification information and the medical device identification information by the wireless relay module.
20. The process of claim 19, wherein the wireless relay module transmits the patient identification information and the medical device identification information together in a single information block.
21. The process of claim 18, further comprising transmitting one or more of the patient identification information or the medical device identification information via the internet-accessible wireless communications network from the wireless relay module to the remote monitoring device.
22. The process of claim 21, wherein the wireless relay module transmits the patient identification information or medical device identification information to at least one other wireless relay module and the at least one other wireless relay module forwards the identification information via the internet-accessible wireless communications network to the remote monitoring device.
23. The process of claim 1, wherein said particular status represents an authorized use of the medical device by the patient obtained in response to a confirmation query conducted by the remote monitoring device.
24. The process of claim 1, further comprising transmitting a confirmation query request to the remote monitoring device via the internet-accessible wireless communications network.
25. The process of claim 24, wherein the confirmation query request comprises authorization identification information.
26. The process of claim 18, further comprising:
- transmitting a prompt for the medical device identification information by the wireless relay module to the medical device; and
- transmitting a prompt for the patient identification information by the wireless relay module to one on the medical device or to a patient identification device.
27. The process of claim 26, wherein the patient identification information and the medical device identification information is transmitted by the wireless relay module in a single information block.
28. The process of claim 26, further comprising receiving the medical device identification information from the medical device at the wireless relay module, and wherein transmitting the prompt for the patient identification information by the wireless relay module occurs after receiving the medical device information by the wireless relay module.
29. The process of claim 26, further comprising receiving the patient identification information from the medical device or the patient identification device by the wireless relay module, and wherein transmitting the medical device identification information and the patient identification information by the wireless relay device module occurs after receiving the medical device identification information and receiving the patient identification information by the wireless relay module.
30. The process of claim 29, wherein transmitting the medical device identification information and the patient identification information by the wireless relay module is performed after determining that the value of an indicator of an elapsed time at the wireless relay module between transmitting the prompt for the patient identification and receiving the patient identification information is within a predetermined time-out period.
Type: Application
Filed: Aug 18, 2014
Publication Date: Mar 12, 2015
Applicant: Covidien LP (Mansfield, MA)
Inventors: Joel D. Wiesner (St. Peters, MO), Kenneth M. Breitweiser (Brighton, IL), Robert B. Gaines (Lake St. Louis, MO)
Application Number: 14/462,025
International Classification: H04Q 9/00 (20060101); A61M 5/142 (20060101);