Wireless sensors are intended to operate via short range wireless communications. That's why they're called "body area" networks. Due to power consumption constraints, wireless sensor radios typically don't operate as 802.11 a/b/g/n radios used in enterprise networks. The reference designs from the manufacturers of radios intended for wireless sensors often indicate a range of a few meters and show wireless sensors communicating with a gateway device that aggregates sensor data and then communicates with the enterprise network where the sensor software applications reside.
When asked if they'd prefer their wireless sensors with a patient worn gateway (typically about the size of a deck of cards or smaller) or just the wireless sensors by themselves, most users - patients and caregivers - overwhelmingly chose the sensors-only option. They just got rid of those nasty sensor cables, why would they want some extra box they have to keep track of?
Asking requirements gathering questions on feature trade-offs that aren't supported by the technology is often times a frustrating experience. It is, however, important to identify all market requirements, even the ones you may not be able to meet with current technology. Let's look at how we might solve this conundrum.
There are two basic ways to implement gateway devices: 1) a patient worn gateway that travels with the patient, and 2) stationary gateways that must be located wherever wireless sensor data is intended to be received.
Patient worn gateways must be battery powered, made of materials resistant to disinfectants, survive the inevitable drops (repeatedly) and provide one or more methods for attaching to the patient. Patient worn gateways may be either disposable or reusable. Reusable patient worn gateways must have replaceable batteries or be rechargeable, with a recharging system, of course. Mobile health applications targeting ambulatory markets often rely on cell phones or smart phones to serve as gateways.
Stationary gateways must be installed in locations where they can provide appropriate wireless coverage for the planned locations through which wireless sensors are expetected to pass. Power and Ethernet, or power-over-Ethernet, must be run to each gateway. Alternatively, stationary gateways can use Wi-Fi to connect to the enterprise network, perhaps reducing installation costs. Stationary gateways must be mounted where they will not be subject to being hit and damaged by rolling cabinets, gurneys or wheel chairs, or designed with sufficient robustness to shrug off such collisions - or be sufficiently low cost as to be replaced with little financial consequence.
Patients move around. They are transferred between units, ambulate post surgery and are sent to other departments for diagnostic testing or to receive therapy. A patient worn gateway connects directly to the enterprise network everywhere the patient goes. This limits the number of gateways required to a maximum of the patients being monitored at any given time.
Stationary gateways need to be placed where you want wireless sensor coverage, much like access points for your wireless enterprise network. If the application is localized somehow and only relevant to the patient room or used with patients that don't move (e.g., ICU or surgery) the number of gateways can be limited to anticipated patient locations. However, if your application is intended to provide continuous patient data regardless of location, gateways may be required to be deployed in all or most of the hospital.
When designing wireless sensor solutions, most people tend to focus on sensor cost (and of course, recurring disposable sensor revenue). However, it is just as important to consider gateway cost and coverage requirements. The above factors and potential architecture design decisions will impact both individual gateway cost and the number of gateways required for various typical installations. All of this must be modeled sufficiently so that optimum design and feature trade-off decisions can be made. Downplaying the impact of certain design or feature choices in an effort to justify the inclusion of certain design or feature choices is ill advised.
For a variety of reasons, mobile health applications targeting consumers or patients in their homes or as they go about their daily lives should be based on Continua selected standards. Continua certification of the resulting products may also be advantageous. Unfortunately, there is no alternative to Continua for wireless sensor based solutions targeting acute and long term care markets. A review of Continua profiles should be made as some may be transferable to acute care solutions. Otherwise, manufacturers targeting acute care markets are on their own.
There are a couple of design approaches for overcoming the stationary gateway conundrum that have potential application in wireless sensor based solutions. The first is using mesh networking technology. This is most commonly implemented via 802.15.4 or ZigBee (which offers additional networking features in addition to those included in the 802.15.4 standard). Mesh networks could be appropriate for both provider organizations like hospitals or long term care, and patient homes. Awarepoint was the first company to widely deploy mesh networks in hospitals. Awarepoint's application is indoor location systems, and the 802.15.4 mesh network is used to both triangulate tag locations and to communicate the resulting tag data to Awarepoint's positioning engine.
Both 802.15.4 and ZigBee have advantages and disadvantages when used in health care provider organizations that are beyond the scope of what will addressed in this blog post. But, there is one issue for which 802.15.4 is a good example: coexistence. Most wireless technologies intended to be used in the ISM band (where 803.15.4 and Wi-Fi are located), are designed to provide both frequency reuse and coexistence of multiple applications using the same air links. As long as all the manufacturers using the same wireless technology stack with the standards, and use certified chip sets, there are few problems.
Manufacturers intending to use 802.15.4 or ZigBee are advised to coordinate with all the other manufacturers using the same or similar technology targeting the same markets. Coexistence testing must be done to ensure all products using the same technology remain safe and effective in the presence of other applications using the same networks or RF frequencies. This level of coordination and coexistence is easy when less than a handful of different systems have to be accommodated. In fact, at this point manufacturers have considerable design latitude in their implementation of the wireless standards. Should a growing number of manufacturers design wireless solutions using 802.15.4 or ZigBee, at some point coexistence between systems could become more challenging and design latitude much more constrained to more narrow interpretations of the standard.
The second design approach that can overcome the gateway conundrum is low power Wi-Fi. When the radio on a wireless sensor connects directly to the enterprise Wi-Fi network, no gateway device is needed. In some circumstances it is now possible to create a wireless sensor with sufficiently low power consumption using Wi-Fi that obviates the need for a gateway. One such supplier of these chips is GainSpan, with a system on chip radio supporting 802.11b and a chip supporting 802.11b/g/n and 802.15.4 (which would make for a great patient worn gateway). A system on chip (called a SoC) is an integrated circuit that includes a radio and CPU with the processing power to drive the radio and an embedded system device like a wireless sensor. The best example of this approach to date is the Sotera Wireless, formerly Triage Wireless, patient worn monitor.
One final factor to address in this post is sensor proliferation. Wireless sensor solutions presently are limited to one sensor. Eventually solutions will come to market that embody multiple sensors that are attached to the patient. A patient monitoring solution where each parameter is a one or more sensors is an example of this. For several reasons, such a scenario will likely result in an increase in patient worn gateways.
Tim: Great info. I am surprised you did not mention the problem of how to associate the data produced by each patient sensor to the right patient or patient ID. This is a difficult problem especially in cases where there are multiple patients and multiple sensors in one area.
Brian
Brian, You’re right that patient context or patient association is a deceptively difficult part of connectivity product design to get right. And the approach is quite different between conventional medical devices and wireless sensors.
The intent of this post was to discuss the role of wireless sensor gateways. But I think a few posts on patient context coming up soon.
The association problem has the corresponding back end disassociation problem, ie telling the system that a sensor is no longer providing data for patient X, even if it is still broadcasting.
And lets not forget the mundane detail of how to prevent the loss of senors that are small and self contained. Or are we assuming that they are “disposable”, which either means that they can’t be used again, they are cheap enough to throw away, or they aren’t cheap but it is just impracticable to try to reuse them.
Patient context can be fiendishly difficult, especially when wireless connectivity is used. Associating wireless sensors with a gateway device and/or directly with a patient can have a lot of variables and alternative workflows that have to be accounted for.
In my experience, most wireless sensor products are disposable. Vendors like the disposable revenue stream, and being disposable does address or remove problems like infection control, recharging, worrying about loosing expensive reusable sensors, etc.
I am new in this and very helpful this to me. Thanks for your contribution.
Can you please tell me what is the difference between execution environment and OSGI?
The OSGI framework is a module system and service platform for the Java programing language. OSGI manages the modules that run in the execution environment and specifies the methods and and classes available in a specific platform. Glassfish, for example uses the OSGI framework.
Thank for the reply. Can you also guide me what is running in Iot or M2M Gateways. for example how data moves from sensor to gateway (Which protocol) and what is the role of execution environement and application it used to send data to cloud.
Erum, I’m afraid that your questions are getting into the actual architecting of a wireless sensor based solution. This unfortunately, is outside the scope of this blog post, and blog comments generally. If you wish to strike up a conversation, please use the form on the Contact page to send me an email.
Cheers
Excellent rundown on this area, as usual. The problem of patient identification uniqueness and affiliation with the sensor data is a truly difficult one to ensure in the wireless environment at times. It also points to how the Master Patient Index of an EHR or some other aggregation application does tend to ‘drive’ the work flow in that the purpose of networking is to transmit or aggregate data somewhere for real-time display or some future application of the data being measured or collected. Rarely is the data only wanted at the point of care. It is interesting to see how technology has made some areas of health care delivery easier and more geographically independent and yet more difficult when trying to maintain a high veracity of the data as it is transmitted and used along the transmission path.