Part 1

The Health Device Profile along with the IEEE 11073 protocol is enabling a number of specific medical devices to communicate data via multiple logical channels carried by a single master radio channel for compatible device communication.

Profiles play a central role in the Bluetooth Specification. They define the entire protocol stack, usually including the application layer. They therefore allow interoperability of Bluetooth devices on the application level. They also enable the features of a device to be limited to those necessary for the specific application, thus allowing small, energy-efficient designs.

The transmission of medical data via Bluetooth was not standardized for a long time. In general, the widely disseminated Bluetooth Serial Port Profile (SPP) has been used up to now. This ensured a certain amount of interoperability on the transport level, at least. However, SPP is merely a serial cable replacement and does not address the transported data. In the past this resulted in devices by different manufacturers that used different data transmission methods. As a result, every device manufacturer developed their own data protocol and then had to ensure that it could be understood by the receiver.

For this reason, the Bluetooth SIG—the association of Bluetooth manufacturers—developed the Health Device Profile. Although profiles have previously been developed with the use conditions of certain sectors in mind, the Health Device Profile is the first truly sector-specific profile. The use cases for the Health Device Profile correspond mainly to various types of patient monitoring.

With the Health Device Profile a few enhancements were introduced that are relevant to the transmission of medical data. These include exact time synchronization of multiple Bluetooth-connected sensors required for long-term measurements. Another new feature is the ability to transmit different medical data in parallel over one Bluetooth interface. This is necessary when several sensors record measured values simultaneously. Improved error correction and resending of erroneous data have also been introduced.

The biggest difference, however, is the introduction of a protocol that describes the structure of the medical data itself. The so-called IEEE 11073 protocol replaces the former proprietary data protocols of manufacturers, thereby enabling unprecedented interoperability on the application level. Device manufacturers can now concentrate on their own devices and do not have to provide a receiver for them. This protocol is a mandatory component of every HDP implementation.

Until now, the Health Device Profile has not been very widely disseminated. This might change in the near future as an HDP implementation is part of the Android 4.0 platform, which will allow suitably equipped Android smartphones and tablets to accept data from HDP-capable devices.

IEEE 11073

While the Health Device Profile was specified by the Medical Working Group of the Bluetooth SIG itself, the data protocol is provided in the IEEE 11073 specification.

IEEE 11073 specifies a data exchange format for medical devices. This format is independent of the transmission technology and can be used over different networks such as Bluetooth, USB and ZigBee. It defines the method used to pack and label medical data so that the receiver can assign and display it. The protocol is based on binary data formats and includes time stamping and formatting specifications. The standard includes so-called device specializations, similar to the Bluetooth profiles, in which individual devices are defined. The following device specializations are currently included:

• ISO/IEEE Std 11073-10404, Pulse oximeter
• ISO/IEEE Std 11073-10407, Blood pressure monitor
• ISO/IEEE Std 11073-10408, Thermometer
• ISO/IEEE Std 11073-10415, Weighing scale
• ISO/IEEE Std 11073-10417, Glucose meter
• ISO/IEEE Std 11073-10421, Peak expiratory flow
• ISO/IEEE Std 11073-10441, Cardiovascular fitness and activity monitor
• ISO/IEEE Std 11073-10442, Strength fitness equipment
• ISO/IEEE Std 11073-10471, Independent living activity hub
• ISO/IEEE Std 11073-10472, Medication monitor

The Health Device Profile is based on the Multi-Channel Adaptation Protocol (MCAP) and a Bluetooth stack that supports the enhanced Logical Link Control and Adaptation Protocol (eL2CAP) and exchanges IEEE 11073 data packets containing medical user data in a defined manner over one or more data channels. eL2CAP is an enhanced version of the L2CAP protocol that enables multiplexing of multiple logical data channels via a single radio connection. The enhancements in eL2CAP include the introduction of an additional error correction layer (Enhanced Retransmission Mode, ERTM) and support for streaming data transfer.

The eL2CAP Specification is included as an addendum to the Bluetooth 2.0 Core Specification and as an optional feature in the Bluetooth 3.0 Specification. Support of eL2CAP is essential for HDP implementation. MCAP is used in an HDP implementation to control the establishment and disconnection of eL2CAP data channels in HDP in a defined manner. To this end, when a connection is made, one eL2CAP channel is established as the MCAP control channel. Use of this channel is limited exclusively to the MCAP protocol.

MCAP then uses this control channel to control the establishment of additional eL2CAP channels for defined “end points” (MDEP), which can then be used for the actual IEEE 11073 data transmission. In doing so, each end point maps a defined IEEE device specialization. Thus, for example, an HDP device can display the appropriate measurement values via an “IEEE 11073-404 Pulse Oximeter” end point and provide a data channel for this end point. Several such end points with different functionality are also possible.

In summary, the structure of an HDP connection is described in Bluetooth terminology as shown in Figure 1.

Figure 1: Structure of an HDP connection

The same connection is described in IEEE 11073 terminology as shown in Figure 2.

Figure 2: Structure of an HDP connection with IEEE 11073

Once a data channel has been established for IEEE 11073 data transmission, it can be used for transmission of IEEE 11073 packets (Figure 3).

Figure 3: Data transmission with IEEE packets

The segmentation and retransmission (SAR) functionality in eL2CAP is used here in order to transmit complete IEEE packets including packet headers. For this purpose, an IEEE application data unit (APDU), which describes a complete IEEE data packet, is transmitted as an eL2CAP service data unit (SDU). The eL2CAP-SDU can be segmented into individual protocol data unit (PDU) packets for this transmission and then reassembled again on the receiver side using the SAR functionality. HDP is thus logically not realized on a byte stream transport layer but rather on a secure packet transmission layer (ERTM) that transmits complete packets.

This effort is made in order to meet the requirements of IEEE 11073 regarding transport characteristics. Among other things, these requirements call for secure data transmission of complete IEEE-APDUs up to 63 Kbytes in size. Incidentally, this amount comes from the fact that the otherwise usual 64 Kbytes has been accepted as the maximum packet size of the lower level transport layers and these layers are granted 1 Kbyte as protocol overhead. The design of IEEE 11073 took into consideration diverse requirements regarding data integrity, uniqueness and usability in the medical and clinical environments so that internationally approvable implementations are possible.

The measurement data source is called “source” in Bluetooth HDP and “agent” in IEEE 11073, while the data sink is called “sink” in Bluetooth HDP and “manager” in IEEE 11073. The required behavior of the data source and data sink are practically identical up to this point, as both sides establish and terminate connections and data channels and transmit data packets. That changes on the IEEE 11073 protocol level, as the roles are distributed asymmetrically here. The basic assumption here is that the IEEE agent is the “simple” measurement device that has a very specific limited functionality that it communicates to the manager prior to actual data transmission. The IEEE manager on the other hand is the “complex” device that can exchange data with all possible agents. The manager should therefore be generic because the IEEE 11073 protocol is structured to be essentially self-describing using the ASN.1 specification language.

Thus, the protocol allows a generic implementation approach in which the IEEE manager application processes the medical measurement data (e.g., displays, saves, or forwards data) without having to understand or interpret it in the functional sense. For example, body temperature measurements consist of a numerical value and unit and are shown as a measurement value with unit symbol on a display, further processed as trend curves, or saved in databases without a generic IEEE manager implementation having to know what a temperature is or what it signifies. Of course, this approach also applies to all other existing and future device specializations of IEEE 11073.

Implementation/Practical Experience

In view of the complex specification, an HDP implementation project will probably go through several phases:

“Does it have to be so complicated?”

followed by:

“Okay, it’s actually not so complicated, and in the end the structure will produce a well-thought-out solution.”

and then:

“The devil is in the details.”

and finally:

“It took a while but now I truly understand how all of this works together.”

The “Does it have to be so complicated?” phase of an HDP implementation occurs as the various specifications are being acquired. In the eL2CAP chapter of the Bluetooth Core Specification and the IEEE specifications, in particular, it seems that mechanisms that are actually quite simple can only be described in an understandable way with great difficulty. The specifications use formal speech that in some cases deviates far from natural speech and can produce artificial, difficult-to-understand and unwieldy sentences. There is definitely a reason for this, but those without experience performing such tasks must work ahead to “The devil is in the details” phase to recognize this.

Once the actual implementation starts, the “Okay, it’s actually not so complicated, and in the end the structure will produce a well-thought-out solution” phase arrives relatively soon and can last until the first test runs. “The devil is in the details” phase kicks in as soon as the first design- or development-related test runs take place. Here is where the specifications start to be examined again, this time with a very keen eye. It is now apparent that there is definitely a good reason for many of the complicated definitions that initially seemed unnecessary. It is also now clear whether or not the theoretical preparations made for the implementation were adequate. If so, the existing implementation can be fine-tuned. If not, it is advisable to start over. Successful navigation beyond this point brings you to the “It took a while but now I truly understand how all of this works together” phase, where there is still some necessary fine-tuning left to do.

Anyone that has had the experience of developing communication protocols based on specifications is familiar with this process in principle. The reason for this process is not necessarily poor theoretical preparation, but rather it can also be the fact that it may be impossible to link all of the hidden details of a complicated specification until its actual implementation. The message here is that the difficulty of the HDP implementation task should not be underestimated, owing to the different protocols involved and the often inherent level of complexity of these protocol layers. Incorrect decisions during system design can result in unnecessarily high demands on system resources (CPU, RAM, Flash). Once the HDP implementation is finished, however, the very generic and well-conceived system approach behind HDP ensures that the result will be suitable for universal use in the home setting as well as in medical and clinical environments.

This broad application range can be attributed to the fact that the individual specifications were developed by groups of technical experts including representatives of companies active in the respective sectors. These experts spent several years debating with each other about the various details and requirements. The list of companies that collaborated on the specifications includes Stollmann, which actively participated in the Bluetooth SIG MED Working Group and the IEEE 11073 Working Group.

Stollmann E+V, Hamburg, Germany. +49 (040) 89088-0. [www.stollmann.de].

Don’t miss Part 2 of this article, which will drill down further into special design considerations and integration details. Coming in the next issue of MEDS!