Wireless and Healthcare: the Perspective of a Long Journey.

So far, by writing this blog I have approached for the first time a new eHealth ecosystem and I have blogged about wireless technologies that are being implemented every day more.
I started form analyzing the simple word “eHealth” and I ended up discovering a whole new endless wireless world. I discovered that eHealth is a tangible reality, I realized that power consumption is the key consideration for selecting a wireless standard for medical devices and I understood the relevance that Bluetooth technology has gained through the years. On the other hand I discovered that no matter how brilliant your wireless technology is, long implementation cycles, government regulations, interoperability and standardization can slow down the entire process. Furthermore if we consider the healthcare scenario, these problems are even more accentuated since choosing a wireless technology for a wireless health system needs to consider a variety of requirements. It’s not simply deciding a wireless standard for a communication, but it’s the selection of a robust wireless technology that will assure efficiency, correct monitoring/surveillance and principally will not increase life risks of users. It needs to support different connections topologies such as LAN, PAN and WAN if you want to ensure that interoperability is present. The wireless technology should also be easily accessible by users thus, ubiquity is another key feature that should be considered in the process. From what I wrote until now one thing is obvious to me: Bluetooth is the answer. To achieve a good number of users, to reduce the growing costs of healthcare, eHealth needs a widespread of mass devices. According to IMS Research [1] in 2012 over 35% of smartphones will be shipped with dual-mode Bluetooth low energy and two thirds of the 821 million smartphones shipped in 2013 will include Bluetooth Smart Ready (Bluetooth 4.0). Today no other wireless technology can take this place, particularly in the eHealth sector. That’s why the world around Continua’s Alliance keeps on changing with the technology advancements. The decision to select Bluetooth Smart in the 2012 Deign Guidelines didn’t come by chance but was the final result of the collaboration with the Bluetooth Special Interest Group to make Bluetooth Smart devices “Continua-oriented”. Continua is focusing on compatibility to ensure interoperability between devices that use different versions of guidelines, but at the same time is always directed towards innovative wireless solutions. For Continua Alliance moving from using Classic Bluetooth to the latest Bluetooth Smart was a direct consequence of the medical industry requirements: ultra low power consumption. Therefore technically speaking the solution is not hard to find. The problem is more related to regulations placed on medical devices and excessive costs of certification; this will probably slow down the full adoption of the Bluetooth technology, while will consolidate the support of the Classic Bluetooth. Additional acceptance problems are deriving for the smartphone system; while Apple and Microsoft have decided to support Bluetooth 4.0 technology, Google with the Android 4.0 platform[1], doesn’t seem to agree. This decision can affect the adoption of Bluetooth Smart Devices in a long term since except from the Apple iPhone 4S, all smartphones that are inclusive of the Bluetooth Smart Ready are using Android platform. Finally, security can also be an obstacle to Bluetooth technology for eHealth systems. A lot of improvements in terms of security have been done in the version 4.0 of Bluetooth [3], but also here, for example the protection against hacking is automatically available only for the latest version of Bluetooth. Considering the relevance that Bluetooth technology is having for the eHealth sector, a coherent approach is needed to protect data and to prevent from misuse of medical records.

Since Bluetooth technology was adopted all the effort was oriented to increase data rates, but today we understood that is exactly the opposite, that is low data rates, that is going to make this technology important. Of course, problems are still evident in the eHealth sector but don’t tell me that ultra low power, smart wireless technology that creates an impressive range of new healthcare markets isn’t enough for eHealth standardization.

References:
[1] http://imsresearch.com/press-release/Bluetooth_Smart_To_Be_the_Wireless_Technology_Most_Used_in_Consumer_Medical_Devices_by_2016&cat_id=188&from=
[2] http://imsresearch.com/press-release/Is_the_Google_Platform_Delaying_the_Bluetooth_Smart_Train&cat_id=188&from=
[3] "Analysis of Bluetooth Threats And v4.0 Security Features " , International Conference on Communication Computing and Applications (ICCCA 2012), 23rd - 24th February 2012, PSNA College of engineering, Dindigul, IEEE Xplore

The risks of Standardization and IP Protection.

The Continua Health Alliance has been working on creating a network of standards, drawing on the IEEE for standardized data formats and wired wireless standards groups to define the connectivity level over which the data can be transported. Their choice of wireless standard is the BL LE, which is already present in the majority of smartphones. Despite the technical reasons that make the Bluetooth Low Energy a good candidate for the eHealth systems, it is obvious that Continua ended up by selecting this standard simply because it is the one that manufacturers include mostly in their handsets.

The work of the GSM Association will certainly increase the role that mobile phones are going to play in the broadband structure. As a consequence, this will increase in terms of billions the number of broadband mobile phones that will include the Bluetooth Smart technology. The deeper meaning of this forecast is that clearly, the technology selection for a wireless health product will be impersonally made by product manufacturers since the market will ask for healthcare devices that have something to connect to. The role of regulators is limiting the manufacturers, as we already saw when considering the role of the FDA, but what can be considered a real risk in terms of costs for healthcare manufacturers, is the selection of a standard that is strictly connected with Intellectual Property disputes. The conflicts connected with the Intellectual Property can constitute a real risk for the system. In a public document, the Bluetooth SIG mentions that from the IP viewpoint, wireless standards are not equal. As the importance of wireless standards starts to increase, the concerns connected to Intellectual Property starts to increase exponentially, as already happened with patent trolls attacking ZigBee and Wi-Fi. The principal problem is that most people not consider Intellectual Property rights when undergoing through a standardization process [1]. There is the stupid conjecture that if a standard is selected, then as long as you have the right to use it there are no related IP problems. Not even the standards bodies, such as ETSI and IEEE give any IP assurance, which means that a lot of companies have been taken to court, only because of their ignorance. This lack of knowledge can cost to a company millions of dollars. Therefore, for the eHealth system is important to understand that the existence of a standard does not give to a company a free right to automatically possess  the IP within it. If we consider the two standards selected by Continua Health Alliance, Bluetooth Low Energy and ZigBee, they both impose to the company that uses the standard in their product to sign a member agreement, which contains a clause of IP ownership. To be more precise, this is connected with the concept of Necessary Claims; once the company decides to signup because has the necessity of that specific technology, it also gives up the right to claim for the violation of any IPR the company itself might own, which is used by other companies developing the standard. For example, in the Bluetooth technology you cannot ask for a fee for anyone using your IPR as complement of the standard, and this license is defined as RANDZ (Reasonable and Non Discriminatory- Zero cost). When considering the ZigBee technology the situation is different, because in theory it is possible to charge a fee for other ZigBee companies, and this is defined as a RAND license (Reasonable and Non Discriminatory).

Is this a good approach for Intellectual Property rights? I think it has a double- sided result: on one side, companies agree to not sue each other, but on the other side they give away part of the value of their IP. Basically, the problem is that is quite hard for industries to estimate the value that the IP use can have as a competitive tool. When a company signs this sort of agreement, it is also signing up to legally provide the future use of its IP that might be extremely valuable in the future. This means that a company with a conservative approach to IP, can prefer to take a conservative position and not sign. Before a standard is finalized, most of the standards groups do an IP evaluation to understand if there can be any problems from patents owned from outside the standard body. But of course none of the standards organizations give immunity to risks. When approaching to a standard, how can a company analyze the risks?

The first thing to do when selecting a standard is to look at how much that standard covers. Besides the largest adoption on smartphones, one of the major reasons behind the adoption of Bluetooth as a standard by Continua, is the fact that the Bluetooth specifications are very exhaustive starting from the radio specification going through the application profile. This means that all elements of the standard are included in the ember IP agreement. Instead, ZigBee agreement provides no IP cover for  the specifications, since it use external standards like the IEEE 802.15.4 for the radio and baseband layer. The main idea is that a standard can only offer IP protection for the parts it own.

 

Standards and IP protection

The more companies one can get to sign for the IP license, the more protection is ensured from prosecutors. Bluetooth is extremely good in convincing companies to sign the IP license, as they have over 13,000 members. Z-Wave is a standard created exactly to cover the full range from radio to application. The reason why this standard has not the same popularity of Bluetooth, is connected to the fact that only one company is the owner of the Z-Wave IP. Additionally, this standard can’t count on the security of having 13.000 contributing members for its IP, which instead Bluetooth has. Standards like Z-Wave haven’t contributed to the market enough to make it worth suing or attacking them with patent trolls. Also the presence of a standard in the market is essential to determinate possible risks; Continua is very well aware of this and since Bluetooth has been around longer than other standards, it ensures that the standard is safer and has more members. As a conclusion we can state that more recent standards are more risky. The Bluetooth Low Energy, despite being considered a recent standard, is a rather straightforward process, because it is a company-based standard that can count on the security and wide membership of a standard like Bluetooth. This is a key attribute for the selection of the BL LE technology as de facto standard for the health devices by Continua Alliance. Surely, the question that organizations specifying the standards, such as Continua Health Alliance, need to investigate is whether they are conscious of the risks they take when selecting a specific standard.

References:
[1] Nick Hunn, "Essentials of Short Range Wireless", Cambridge University Press, 8 Jul.2010

Bluetooth and Zigbee: Two New Low Power Radio Standards. Technology and Adaptability.

After the Version1.0 Design Guideline was published in early 2009, Continua simplified any possible decision by selecting for the transport level of the PAN Interface the Bluetooth Health Device Profile for wireless communications and USB Personal Healthcare Devices for wired communication while for enabling data format interoperability the ISO/IEEE 11073 Personal Health Device family of standards was selected. After the first Version of Guidelines other updated versions were published and Continua’s 2012 Design Guidelines is currently undergoing to Interoperability testing since it will be released publicly by the end of 2012. Before analyzing the latest solutions picked in the new version of the Guidelines, I will first try to define the reasons behind the selection of Bluetooth as a predominant technology for eHealth devices, considering the key factors in the decision process.
Bluetooth is the only wireless technology included in Continua’s design guidelines. With the cooperation of Continua Health Alliance and IEEE 11073 Personal Health Devices Group the Bluetooth SIG created the Health Device Profile.

 

Continua Health Alliance PAN and LAN interfaces.

The Bluetooth wireless technology was chosen after analyzing other outstanding wireless technologies in a process that took almost 10 months of review. According to a recent market study developed by In-Stat during 2013 circa 2 billion of Bluetooth devices will be shipped worldwide , and considering also that today there are more than 40 million Bluetooth enabled healthcare devices, Bluetooth technology has to be considered for half of the ICs delivered worldwide for health devices by 2015; thus, it is not premature to assume that Bluetooth technology is already the de facto wireless standard for health devices. In the updated Version 1.5 Design Guidelines, Continua selected for the Personal Area Network (PAN) interface the Bluetooth Low Energy (BLE) standard and its health device profiles. Considering that the benefits of a healthy lifestyle and the independent monitoring of chronic diseases will increase the market for wireless health devices, the selection of the Bluetooth technology hasn’t come as a random solution, but was decided after thoroughly understanding the benefits of this technology. There are a variety of key factors that lead to the selection of Bluetooth Low Energy: between these factors, indeed the fact that Continua has always supported the selection of Bluetooth Low Energy in health care applications has been a predominant element. So why did Continua selected exactly the Bluetooth technology for wireless connectivity of personal health care devices? After months of research and analysis of a variety of low power technologies such as Sensium, ANT+, BodyLAN and Z-Wave, in late 2009 Continua announces the selection of two new low power radio standards: Bluetooth Low Energy wireless technology for low power mobile devices for monitoring a user’s health or fitness level, and ZigBee was instead selected for low power sensors in a variety of settings to promote independent living.
The differentiation between the selected technologies was made in terms ease of use between a list of devices that we have around us all day and we carry everywhere (PAN), such as a mobile phone or a tablet, and devices that are constrained to stay within a building, either a home or medical structure (LAN); Bluetooth Low Energy was selected for PAN (Personal Area Devices), while ZigBee was selected for LAN (Local Area Network).

The selected standards are relatively similar in terms complexity, but BLE have a longer battery life due to its faster data rate, the use of short packet overhead, excellent resistance to interference, reduced number of packet exchanges for a short connect time and power optimization, while Zigbee by using as a modulation scheme the Direct Sequence Spread Spectrum (DSSS) with orthogonal coding, has a better reliability and benefits from a longer range and a mesh like clustered star networking structure. While for most of the people outside the standardization groups this decision can look quite insignificant, it does have some relevant implications when considering that a medical device manufacturer cannot be able to decide which of these two wireless standards to choose. If we are developing a wireless connected healthcare system, it is important to not have confused manufacturers about which of two incompatible standards to use, because this can clearly lead to a delay in availability and implementation. The differentiation between PAN and WAN devices is going to disappear for consumer medical devices, since everything will be oriented towards mobile devices. For example, the implementation of smaller, mobile and personal medical devices is already happening in the sports and fitness devices sector. And that leads us to eliminate the distinction between PAN and WAN interfaces, because the medical devices simply become the things that we carry with us, without a reference of place or location. This simplification brings us to the dilemma of the device manufacturers that need to select one of the two technologies to go with.

Bluetooth Low Energy Devices

Although both interfaces were selected in the Version 1.5 Design Guidelines, this dual interface vision is a possible barrier to the spread of a wide number of eHealth systems, since the lack of specifications in terms of interoperability can be a real problem for the possible user. In terms of costs, having both BLE and Zigbee on the same device [1] doesn’t mean that the costs will double since both the solutions have many similarities: specifically, BLE has a Gaussian Minimum Shift Keying (GMSK) [2] modulation scheme and Zigbee is based on Offset QPSK (O-QPSK) [3], and this makes possible to support both standards in a device simply using a reconfigurable transceiver with a digital IF sub-sampling architecture on the receiver side. Now, everyone knows that Bluetooth is in their mobile phones and over half of the world's population owns a mobile phone, so it is obvious I think, that the Bluetooth was the dominator in this dilemma. This is connected with technical reasons but mainly is related to an ease of use, because Bluetooth provides the "scale". Bluetooth oriented medical devices can easily be connected with smart phones, without additional device, while Zigbee oriented medical devices have the requirement of an additional adaptor that can plug into a tablet or phone. Bluetooth Low Energy is designed for light and peripheral data exchange and results to be different from the Bluetooth that is used in medical devices, since it has the added value of being able to talk to the next generation of smart phones. It is also true that wireless technologies has to be in a certain way, adapted to the application they are intended for, and the choice is not simply between Bluetooth and Zigbee but is between Bluetooth Low Energy standard and Zigbee, thus the ability that has BLE to be provided in mobile phones and even more to be provided in the new generation of smart phones is the key advantage. The problem of having two alternatives is that the medical device manufacturers have to make a decision of which to add to their products, considering that adding both the standards in not a possible solution since it would be too expensive as an option. Without a regulation, the market will decide what technology to adopt. The situation that Continua Alliance had to face while working on the Version 1.5 Design Guidelines was clearly to have two alternatives in the eHealth system; my idea is that adaptation is a very predominant factor in life and principally in technology and the ability to connect to a cellphone will be the dominant decision. If we consider the features of each of the proposed wireless technologies, it is clear that each standard has good features, mainly Bluetooth Low energy has the mobile phone connection, and Bluetooth has a higher bandwidth but it is difficult to understand what ZigBee really offers in the eHealth market since the prospect of connecting a device with a mobile phone is a powerful tool for health devices. Let’s see now if the progress has followed adaptation.

References:
[1] http://ebinder.blogger.idv.tw/archives/633
[2] http://electronicdesign.com/article/communications/bluetooth-low-energy-set-to-storm-the-wireless-market
[3] http://webpages.uncc.edu/~jmconrad/ECGR6185-2007-01/notes/IEEE_ZigBee.pdf

Guidelines Evolution and Reference Architecture.

By exploiting existing industry standards to have interoperable building blocks, Continua is providing guidelines and certifications that will allow multiple vendors to reduce differentiation and cut market costs. The publication of the Continua Health Alliance Version 1.0 Design Guidelines was announced in 2007, and was modeled primarily on connectivity standards. After the announcement, it took almost two years and the collaboration of more than 175 member companies to release the official Version 1 Design Guidelines in February 2009. The First Version Guideline was a major milestone since it was based on the specifications and standards that Continua selected following on their interoperability vision. In order to achieve the required interoperability, also further requirements and constraints were specified in this version, making possible the reduction of the available choices in the underlying standard: this was done by adding some specifications not mentioned previously. The function of these guidelines is primarily to give a design specification tool for companies than intend to certify their devices with the Continua logo. The Version 1.0 Design Guidelines deals with the interfaces necessary for realizing the entire eHealth process, starting from collecting health data to the accumulation of information on the databases of healthcare structures. Since Continua only focuses on interoperability and does not suggest any specification, the interest for Continua’s guidelines is based on the definition of the interfaces essential for connecting between different components of a personal eHealth system, thus, LAN, PAN, WAN, and the electronic or personal health record network xHRN.
These Interfaces are the principal elements to be considered for interoperability goals, and form the basis of Continua Certification process.
The interfaces considered for the Version 1.0 were the PAN Interface (Personal Area Network) between PAN devices and AHD (Application Hosting Devices), and the xHRN Interface (Health Record Network) between WAN (Wide Area Network) devices and health record devices to export medical personal data. The Continua Reference Architecture including the connections and interfaces to be tested in Version 1.0 are shown in the following figure:

Continua Reference Architecture and V1 interfaces to be tested

The Continua End-to-End (E2E) Architecture gives a clear overview of the general distributed-systems structure, highlighting possible topology constraints. The structure is based on five device classes and four network interfaces that are the the principal elements to investigate for interoperability. The network interfaces are subject of certification and testing processes and are responsible of connecting the devices to a reference topology. In order to have a better understanding of  the possible selected standards and interfaces, it is necessary to analyze first the Continua Reference Architecture.
The Peripheral Area Network Interface (PAN) describes the connection between PAN devices such as sensors (for example a heart-rate monitor) or actuators( for example an output text) and an application hosting device (AHD) , such as a mobile phones, tablets , PC. Continua has developed standards for the two layers of the PAN interface; for the lower layers or transport level component comprising the open-systems interconnection layers 1-4, Continua has selected the Bluetooth Health Device Profile for a Wireless communication and USB for wired communications. In the above level is the data level or upper-layer component comprising the classic OSI layers 5-7, for which Continua has selected to use the ISO/IEEE 11073-20601 Optimized Exchange Protocol to enable data exchange and interoperability.
The Local Area Network (LAN) is the Interface between a LAN device and an application hosting device. This device has a proxy function, thus collects and shares the PAN devices information. If we consider a Lan device it is important to underline that it can be seen both as a sensor or as and actuator; this has the direct consequence that the LAN interface upper layers and the PAN interface upper layers can maintain the same data model, the ISO/IEEE 11073-20601 model. The fact to have the same data model in the upper layers of the both PAN and Lan Interfaces is very important for assuring the required interoperability feature.
The Wide Area Networ (WAN) is the Interface between a variety of WAN devices and an application-hosting device. The function of a WAN device is to collect the information, thus acting as a managed-network-based service. The upper layers have a device data model compatible with the LAN Interface data model, thus to make sure an interoperable and exchangeable data model.
Untill this point we have analyzed Interfaces where the data exchange is made possible between an application hosting device and a Continua’s device. The Electronic and Personal Health Records Network (xHRN) is the connection between WAN devices and electronic or personal health records. Typically a xHRN interface is necessary for creating the connection between different companies offering a sevice such as weight loss or chronic disease management for example, and the electronic health records which traditionally come from the healthcare provider domain, such as a hospital where the doctor has all the available electronic data for keeping track of their patients. The Personal Health Records platforms (PHR) such as Google Health and Microsoft HealthValut, allow a patient to access and store their own health data and have control of their data. The merit of the xHRN Interface is to allow data exchange between electronic health records and personal health records promoting in this way data sharing between different parts of the process. For making possible a communication between WAN devices and xHR systems Continua selected the Integrating the Healthcare (IHE) and Cross-Enterprise Document Reliable Interchange (XDR) profile. For having a reliable data encoding the Health Level 7 (HL7) and the Personal Monitoring (PHM) document formats were adopted.

In its Version1.0 Guidelines, Continua selected to focus in two specific interfaces, namely the Personal Area Network (PAN) interface and Electronic or Personal Health Record Network (xHRN) interface. The decision to focus on the PAN and xHRN interfaces was taken by Continua, considering which were the highest priority interfaces to work on, and also considering the necessity to show visible results in a limited amount of time. Based on the interoperability goal, for its Version 1.0 several standards in the PAN interface have been selected and then constrained to meet Continua Guidelines for certification. In addition, the PAN interface for devices was focused on wireless protocols that need to be energy or battery efficient. In the seek of interoperability in the Version 1.0 several standards in the PAN and device data exchange have been developed. In this version of particular note is the expansion of IEEE 11073 which is supposed to have a prescriptive approach which ensures that devices from different manufacturers can be used by the same application. Precisely Continua prescribes in the Version1 eight PAN devices  as it is shown in the following figure:

Overview of Continua Interface Standards
Source: Continua Health Alliance

In addition to the currently released Design Guidelines are even more oriented towards interoperability and data sharing since they also incorporate Wide Area Network (WAN) interface to link a hub device or health appliance with servers. Continua selected ZigBee and Bluetooth Low Energy (BLE) for the updated Design Guidelines. The choice to select ZigBee wireless technology as a Continua’s low power local area network (LAN) standard was due to the fact that this wireless protocol works efficiently for multiple sensing and controlling in a variety of settings both professional and familiar offering secure wireless connectivity and it coexists with other wireless technologies.
The recent Version 2011 of Design Guidelines “Adrenaline” were made freely available to the public just recently during April 2012, in order to promote creativity and integration among systems developers. In the 2010 and 2011 Design Guidelines, the standards used for transporting data were Zigbee, Bluetooth, Bluetooth Low Energy and USB : let’s see now the reasons that led to the selection of some standards and if in the newest Version the standardization process has evolved by selecting new technology.