OPENHEALTH

The OpenHealth FLOSS Implementation of the ISO/IEEE 11073-20601 Standard

Santiago Carot-Nemesio, Jos

e Antonio Santos-Cadenas, Pedro de-las-Heras-Quir

os and Jorge Bustos

GSyC/Libresoft, Rey Juan Carlos University, Tulipan S/N, M

ostoles, Madrid, Spain

Keywords:

FLOSS, ISO/IEEE 11073-20601, Personal health, Android, Bluetooth, MCAP, HDP, Continua health alliance.

Abstract:

The OpenHealth project aims to provide the ﬁrst complete Free/Libre Open Source Software (FLOSS) im-

plementation of the ISO/IEEE 11073-20601 personal health standards over Bluetooth transport. A manager

has been implemented in Java, tested both in Linux desktops and on the Android platform against thermome-

ter agents. The MCAP and HDP Bluetooth proﬁles have also been implemented in BlueZ, the offcial Linux

Bluetooth protocol stack. This implementation has been successfully tested with a Nonin Onyx II 9560 pulse

oximeter, the ﬁrst medical device that implements the HDP Bluetooth proﬁle and the ISO/IEEE 11073 data

protocol.

1 INTRODUCTION

The OpenHealth Assistant project (Andago Ingenier

ıa

S.L., 2009) being developed by Andago Ingenier

ıa

and the GSyC/LibreSoft research group at Rey Juan

Carlos University aims to deploy a full socio-sanitary

platform to fulﬁll the needs of current public health

assistance services. Figure 1 shows a diagram of the

architecture of that project.

The Manager (GSyC/Libresoft Research Group,

2009) described in this paper

is one of the compo-

nents of this project, aimed at managing and recollect-

ing vital measures sent from medical devices (agents)

connected through body area networks (BAN) such as

Bluetooth, and providing support for sending the re-

ceived measures from the manager application to the

hospital backofﬁce or to online personal health record

applications in an interoperable and standard way.

The ISO/IEEE 11073-20601 (Institute of Elec-

trical and Electronics Engineers Inc., 2008c) be-

longs to the ISO/IEEE 11073 family of standards

for device communication. It deﬁnes a common ab-

stract communication model based on agents and a

manager to transmit transport-independent personal

health data. The new standardized Bluetooth Health

Device Proﬁle (Bluetooth Special Interest Group

This work has been partially funded by the Catedra In-

ternet del Futuro Andago-URJC and by the Spanish Min-

istry of Industry’s Plan Avanza

Figure 1: OpenHealth Assistant Platform.

Inc., 2008a) (HDP) in combination with the IEEE

11073-20601 speciﬁcation provides a robust, stan-

dards based framework to allow interoperability be-

tween Bluetooth Health Devices. Figure 2 represents

the protocol model used by this proﬁle.

Advances in mobile computing bring us the possi-

bility to improve socio-sanitary assistance by running

the manager on smartphones, tablets, subnotebooks,

505

Carot-Nemesio S., Antonio Santos Cadenas J., de-las-Heras-Quiros P. and Bustos J. (2010).

OPENHEALTH - The OpenHealth FLOSS Implementation of the ISO/IEEE 11073-20601 Standard.

In Proceedings of the Third International Conference on Health Informatics, pages 505-511

DOI: 10.5220/0002766705050511

 SciTePress

Figure 2: Protocol Model.

etc. These are adequate devices for hosting a man-

ager due to their diminishing prices, their widespread

usage, their small form factor and their multiple com-

munication channels.

The wireless communication model for the

ISO/IEEE 11073 family uses the new MCAP and

HDP Bluetooth speciﬁcations. HDP and MCAP pro-

ﬁles require new developments in lower layers of the

Bluetooth stack, speciﬁcally in L2CAP, that are not

available in current commercial Bluetooth stacks.

We decided to implement HDP/MCAP for the

Linux kernel, with the aim to facilitate the inclusion

of this code in multiple mobile platforms that use this

kernel, such as Nokia/Maemo, Android, Intel/Moblin.

The ofﬁcial Linux Bluetooth protocol stack (Bluez,

2009) was a good choice. Developments made by

other members of the BlueZ project in parallel with

our project made it possible to use the L2CAP special

transmission modes that HDP/MCAP requires.

This paper describes a Java based Free/Libre Open

Source (FLOSS) implementation of the ISO/IEEE

11073-20601, as well as a FLOSS implementation of

the HDP/MCAP Bluetooth proﬁles, that allows us to

run a manager on Android devices. Both of them are

available in the project’s website

. We decided to tar-

get speciﬁcally the Android platform because it ful-

ﬁlls all our requirements: it is Open Source, based on

a Linux kernel, and it is a mobile platform available

in multiple devices.

Figure 3 shows a diagram of the architecture of

the stack we have implemented. Parts of it will be

described in sections 2, 3 and 4.

Section 2 describes the Java based ISO/IEEE

11073-20601 we have implemented. Then, section 3

details the Android Manager Service, which is a layer

on top of the manager designed for the Android OS,

implemented as an Android service that enables other

Android applications to control the behavior of the

agents connected to the manager. Finally, in section 4

we ﬁrst introduce the HDP and MCAP Bluetooth

speciﬁcations which have been recently adopted by

Continua Health Alliance for the wireless transmis-

http://openhealth.morfeo-project.org/lng/en

Figure 3: Android Manager Service + ISO/IEEE 11073-

20601 Manager + BlueZ (HDP/MCAP) architecure.

sion of standard data records in compliance with the

ISO/IEEE 11073 standard, and then we detail our par-

ticular implementation of HDP/MCAP for the BlueZ

Linux Bluetooth stack. The JNI/D-BUS interface is

the only component shown in ﬁgure 3 that has not yet

been ﬁnished. The bottommost 2 layers shown in the

ﬁgure, L2CAP and HCI, have not been implemented

by us.

Experimental tests and results are reviewed in sec-

tion 5. The paper concludes reviewing related work,

future work and conclusions.

2 MANAGER IMPLEMENTATION

The Manager is the main software component of the

architecture. It plays the sink role to collect the data

sent from one or more agent systems, and it manages

the communication process in order to ensure that the

personal data exchange occurs according with the op-

timized data exchange protocol.

All protocols deﬁned under ISO/IEEE 11073-

20601 use abstract syntax to provide an speciﬁcation

of the structure of data items without reference or re-

quirement for a speciﬁc implementation technology

for medical devices communication. ASN.1 (Inter-

national Telecommunication Union, 2002), together

with speciﬁc ASN.1 encoding rules, facilitates the ex-

change of structured data by describing data struc-

tures in a way that is independent of machine archi-

tecture and implementation language.

The ISO/IEEE 11073-20601 uses optimized en-

coding rules for ASN.1 known as Medical Devices

Encoding Rules (MDER). MDER was speciﬁed in

ISO/IEEE 11073-20101 (Institute of Electrical and

HEALTHINF 2010 - International Conference on Health Informatics

506

Figure 4: Manager architecture.

Electronics Engineers Inc., 2004) to minimize band-

width in transferences of dynamic personal health

data between agents and managers.

The lack of Open Source implementations of med-

ical encoding rules for ASN.1 motivated us to ex-

tend the GNU/LGPL BinaryNotes (Abdurakhmanov,

2008) ASN.1 framework for Java, implementing the

support for the new encoder and decoder rules for

medical devices on this framework. Although MDER

is mandatory by both the agent and manager, devices

can optionally establish other encoding rules beyond

MDER, such as PER and XER. BinaryNotes provides

native support for BER, PER and DER. The Manager

uses the BinaryNotes libraries to code the applications

protocol data unit (APDUs) using the above encod-

ing rules in addition to the MDER rules that we im-

plemented. Other closed source implementations of

ISO/IEEE 11073-20601 managers only provide sup-

port for medical devices encoding rules.

Figure 4 illustrates the main components in-

tegrated in the OpenHealth Manager implementa-

tion, corresponding with the main components of

ISO/IEEE 11073-20601.

The Domain Information Model (DIM) consti-

tutes the central core of the manager implementation.

It deﬁnes a set of classes for modeling agents like ob-

jects containing data sources as vital signs, events and

alert reports, etc. It deﬁnes their relationships and the

methods that a manager can use to control the behav-

ior of the agent system.

The personal health device service model deﬁnes

the mechanism for data exchange services. These ser-

vices are mapped to messages coded using ASN.1 that

are exchanged between agent and manager.

Finally, the communication model is implemented

through a ﬁnite state machine (FSM) to synchronize

the messages exchanged on Agent-Manager peer con-

nections over different conditions. Although current

implementation only provides support for the ther-

mometer agent specialization (Institute of Electrical

and Electronics Engineers Inc., 2008b) in the basic

FSM interaction, we expect to provide support to

pulse oximeters (Institute of Electrical and Electron-

ics Engineers Inc., 2008a) too in the near future.

To keep transport independence-media at the data

exchange protocol level, we have incorporated to the

current manager design an abstract communication

model based on virtual channels. A virtual channel

can manage simultaneous channels at the same time

with each Agent-Manager peer connection. Further-

more, a channel in a virtual channel can be either TCP,

RFCOMM or HDP, thus providing a common com-

munication interface to the manager application for

sending and receiving APDUs from/to the agent sys-

tem.

3 ANDROID MANAGER SERVICE

Android applications are written in Java, what makes

it easy to integrate the manager on a device run-

ning Android OS or other Java virtual machine. The

Android Manager Service provides an API that en-

ables programmers to develop new manager applica-

tions in Android by using the services speciﬁed in

the ISO/IEEE 11073-20601 standard in a highly ab-

stracted way.

The service mechanism provided by Android al-

lows to run applications in background for an indeﬁ-

nite period of time, running in parallel with other ba-

sic system services. This feature brings us the possi-

bility to integrate the Java manager described in sec-

tion 2 in Android as an Android service, waiting in

background for agent connections. Furthermore, it’s

possible in Android to connect external applications

to a service, what facilitates the programming of ap-

plications that interact with agents.

Figure 5 shows the Android Manager Service

architecture. The Android Manager Service ex-

poses notiﬁcations about internal events received

from agents through transports such as Bluetooth, and

it provides an action service interface to manage the

state of current agents connected with the Manager.

Because the Android Manager Service is designed

for mobile devices, we try to minimize the energy

consumption by avoiding polling be made from ex-

ternal applications. All communications from/to the

Manager Service is done using a callback service.

The Manager API is deﬁned using AIDL (Android

Interface Deﬁnition Language) to generate code that

enables two processes on an Android-powered device

to communicate by using inter-process communica-

tion (IPC). The AIDL IPC mechanism is interface-

OPENHEALTH - The OpenHealth FLOSS Implementation of the ISO/IEEE 11073-20601 Standard

507

Figure 5: Android Manager Service Architecture.

based, similar to COM or CORBA, but lighter. It uses

a proxy class to pass values between the client and the

implementation.

Applications use the Manager callback service to

get notiﬁcations about generic events in the manager

such as new agent connections and disconnections.

When applications want to know the detailed state

of a certain agent, they register with the agent call-

back service. Later, applications will get notiﬁcations

about the agent state changes and will receive notiﬁ-

cations about measures sent from agents.

The Action Service provides an interface to the

application layer that enables applications to invoke

services speciﬁed in the Domain Information Model

deﬁned in ISO/IEEE 11073-20601. Applications use

the Action Service to gain access to GET and SET

methods over PHD-DIM classes and to send events to

control the behavior of the agent system.

An Android service executes the code of the

manager in a thread running in background, wait-

ing for agent connections. The manager thread uses

the Component Event/Action Controller to exchange

events between agents and applications. Applica-

tions send events to control the ﬁnite state machine

of the agents (we call these external events). The

Event/Action Controller component is in charge of

Figure 6: BlueZ Architecture.

delivering the external events by redirecting invoca-

tions to the appropriate agent. On the other hand,

events triggered by agents (we call these internal

events) are delivered to the applications registered for

these particular events.

4 THE BLUETOOTH HEALTH

DEVICE PROFILE

IMPLEMENTATION

ISO/IEEE 11073 protocols can use several transports

to send and receive personal health data. In this

section we describe our implementation of the HDP,

MCAP and DI Bluetooth protocol proﬁles. Figure 6

shows a block diagram of the bluetooth stack archi-

tecture, including the new components implemented

by us that were not previously present in BlueZ.

The Bluetooth stack includes the Multichannel

Adaptation Protocol (MCAP) (Bluetooth Special In-

terest Group Inc., 2008b), the Health Device Pro-

ﬁle (HDP) and the Device Identiﬁcation Proﬁle

(DI) (Bluetooth Special Interest Group Inc., 2007).

None of them were implemented in BlueZ until to-

day.

MCAP is a versatile L2CAP-based protocol that

provides a simpliﬁed way to use and manage mul-

tiple data channels. The protocol supports different

channel conﬁgurations depending on the application

or transmission needs such as for example stream-

ming or reliable modes.

HDP is a proﬁle that simpliﬁes the use of MCAP

and announces to other devices the supported features

and proﬁles as well as the channels used for each pro-

ﬁle. For these announcements it uses the Service Dis-

covery Application Proﬁle (SDP) (Bluetooth Special

Interest Group Inc., 2001). This way, the devices can

discover the manager in order to connect with it, or

HEALTHINF 2010 - International Conference on Health Informatics

508

alternatively the manager can initiate a connection to

a device, if it is needed, without having any previous

information about the device.

DI speciﬁes a method by which Bluetooth devices

share information that may be used by another device

to ﬁnd icons or associated software, such as for ex-

ample speciﬁc drivers. All this information is also

published in the SDP record.

4.1 MCAP Impementation

Our MCAP implementation is compliant with the

Bluetooth Special Interest Group speciﬁcation, sup-

porting all the obligatory features and some of the op-

tional, such as channel reconnection. The only op-

tional feature not supported by current implementa-

tion is the clock synchronization protocol.

MCAP speciﬁcation requires the enhanced re-

transmission and streamming modes from L2CAP.

None of them was supported by BlueZ when we be-

gan our MCAP implementation, but they have re-

cently been developed in parallel with our work by

BlueZ developers (Padovan, 2009), what has allowed

us to test test our MCAP+HDP implementation.

The system architecture is designed to announce

to the upper layer all the events occurred during the

protocol execution using callbacks. This behaviour

allows the HDP layer to receive all the events in

real time, not needing to do polling or other CPU-

intensive operations, what renders the implementation

more efﬁcient.

MCAP implementation is multithreaded. Once

the MCAP session is opened, a new thread is

launched, waiting for new connections. This thread

also controls all the actions which are part of the

protocol, such as the connection of new data chan-

nels, disconnections, reconnections, etc. The main

thread listens the sockets where new connections are

received and also serves control commands. This ar-

chitecture allows the system to continue working nor-

mally while MCAP is running.

4.2 HDP Impementation

The current HDP implementation simpliﬁes the use of

MCAP by the user. It also registers all the necessary

information on the SDP record. It uses both, callbacks

and accept functions to notify the events to the user,

depending on the role of the current HDP execution

(source or sink).

The implementation completely hides the MCAP

control channels mechanism, providing an abstraction

model based on a notiﬁcation service which notiﬁes

new MCAP Communication Links (MCL) like new

available remote devices. Of course, the creation of

new MCL’s is made possible by providing the blue-

tooth address of the remote devices. This action will

create a new MCL that will allow applications to re-

quest new data channels.

The API provides mechanisms to start data chan-

nel connections to a previously connected device.

Connections can also be received from remote de-

vices. Depending on the HDP role of the device, it

waits for a new connection calling to an accept func-

tion (source role) or the new connections are automat-

icaly notiﬁed when they are received (sink role).

Our HDP implementation also manages the cre-

ation of new data channels and controls the correct

conﬁguration of them before the connections are no-

tiﬁed to the user. A check is made to know if the data

channel uses reliable or streamming mode depending

on the conﬁguration parameters that were previously

negotiated.

HDP also takes care of the correct registering in

the SDP record of all the necessary information, such

as the PSM where the MCAP proﬁle is waiting for

connections, the supported devices and protocols, etc.

5 EXPERIMENTAL RESULTS

The implementation described in the previous sec-

tions has been tested in order to check its correct be-

havior and compliance with the standards.

A ﬁrst test tried to determine if the manager imple-

mentation was Continua compilant. This test was run

by Andago Ingenier

ıa personnel. The test consisted

on a communication between our ISO/IEEE 11073-

20601 manager and a simulated thermomether agent

provided by the Continua Enabling Software Library

(CESL), through a TCP connection. This test was

very satisfactory because the response of the man-

ager was completely correct including: the MDER

encondig library, the manager state machine transi-

tions and the APDUs exchanged between manager

and agent.

Once the integration of the manager in Android

was done, the work effort shifted to the wireless com-

munication. In this area we developed an emulation

of a thermomether agent running on Android, using

Bluetooth RFCOMM communications to exchange

data with our manager. We also developed an adap-

tation of our manager to Bluetooth RFCOMM. This

way we were able to run both, the manager and the

agent, in a couple of Android devices. The communi-

cation carried out correctly. Figure 7 shows the man-

ager and an agent running on Android devices.

In the latest devolopment stage the MCAP and

OPENHEALTH - The OpenHealth FLOSS Implementation of the ISO/IEEE 11073-20601 Standard

509

Figure 7: Communication through a RFCOMM connection.

Agent (right), manager application (left).

HDP implementation were implemented. The ﬁrst

test of these modules intended to communicate two

Linux desktop computers using multiple MCAP data

channels. Then we tried the same communication

model but using HDP. Finally we tested the imple-

mentation between a computer and a Nonin Onyx

II 9560 Pulse oximeter (Nonin Medical Inc., 2009).

These tests were all satisfactory. We ensured that the

MCAP commands were correctly interpreted accord-

ing to the MCL state machine transitions. The HDP

implementation was also tested, comﬁrming that the

SDP record was correctly registered and that the com-

munication management done by HDP was also per-

forming the correct actions. Figure 8 shows the Nonin

Onyx II 9560 pulse oximeter communicating with the

computer.

6 RELATED WORK

As far as we know, this is the ﬁrst Java FLOSS im-

plementation of ISO/IEEE 11073-20601 that will run

on and HDP enabled Bluetooth stack. Also, this is

the ﬁrst FLOSS HDP/MCAP Bluetooth available im-

plementation. In private communications, members

of the Bluetooth community have told us that sev-

eral companies have said to be working on Open

Source implementations of either the manager or the

HDP/MCAP Bluetooth stack for Linux OS, but as far

as we know, no code providing both parts (manager

and HDP Bluetooth support) has been publicly re-

leased, nor papers describing it have been published.

Mindtree (Mindtree, 2009) corporation an-

nounced and demonstrated on october 2009 a closed

source manager running on Android, on top of its

closed source HDP enhanced Bluetooth stack.

Figure 8: Communication between a Nonin Onyx II

9560 pulse oximeter and a Linux computer using our

HDP/MCAP implementation.

7 CONCLUSIONS AND FUTURE

WORK

The ISO/IEEE 11073-20601 Open Source manager

we have implemented has been tested with the ther-

mometer agents provided by the Continua Health Al-

liance CESL (Lamprey Networks, 2009) reference

implementation, and with our own implementation of

thermometer agents.

On the other hand, the MCAP/HDP implementa-

tion has already been tested with Nonin Onyx II 9560

pulse oximeters implementing HDP.

As work in progress we are integrating the

ISO/IEEE 11073-20601 code with the HDP/MCAP

BlueZ enabled stack, and testing it on Android de-

vices from which we manage the Nonin pulse oxime-

ters. We have begun developing a D-Bus (freedesk-

top.org, 2009) interface for HDP/MCAP in order to

ensure an easy interoperability with Linux desktop

applications using BlueZ. The D-Bus interface will

facilitate the interoperability between HDP/MCAP

and the ISO/IEEE 11073-20601 manager because D-

Bus is accessible directly using Java through a JNI

interface.

Alongside our partner Andago Ingenier

ıa, mem-

ber of the Continua Health Alliance, we are exploring

both, the Continua Health Alliance Certiﬁcation pro-

gram and the Bluetooth qualiﬁcation tests.

As of today, stack vendors have not updated stacks

with HDP/MCAP proﬁles. No current mobile phone

Bluetooth stack (including the Windows stack) im-

plements it. Our work on HDP/MCAP, alongside

the work done in parallel by BlueZ developers im-

plementing enhanced retransmission and streamming

HEALTHINF 2010 - International Conference on Health Informatics

510

modes for L2CAP, could potentially have a positive

impact on the industry, as ours would be the ﬁrst

Open Source reference implementation of ISO/IEEE

11073-20601 over HDP/MCAP bluetooth transport

that could be freely used to test new devices appearing

on the market.

The ﬁrst medical device that implements the HDP

Bluetooth proﬁle and the ISO/IEEE 11073 data pro-

tocol is the Nonin Onyx II 9560 pulse oximeter, an-

nounced in June 2009, and only recently available in

the market. This device is the one we are using for

testing our implementation. The rate of appearance

of new devices on the market is slow because there

are no ISO/IEEE 11073 / HDP stacks available. On

the other hand, developers of stacks are awaiting the

appearance on the market of new devices. We expect

to be contributing in part to solve this deadlock situa-

tion with our Open Source stack.

REFERENCES

Abdurakhmanov, A. G. (2008). Binary notes.

http://bnotes.sourceforge.net/.

Andago Ingenier

ıa S.L. (2009). Open health assistant.

http://openhealthassistant.andago.com/inicio.

Bluetooth Special Interest Group Inc. (2001). Service dis-

covery application proﬁle.

Bluetooth Special Interest Group Inc. (2007). Device iden-

tiﬁcation proﬁle (di) 1.3.

Bluetooth Special Interest Group Inc. (2008a). Health de-

vice proﬁle.

Bluetooth Special Interest Group Inc. (2008b). Multi-

channel adaptation protocol.

Bluez (2009). Bluez project. http://www.bluez.org/.

freedesktop.org (2009). D-bus.

http://www.freedesktop.org/wiki/Software/dbus.

GSyC/Libresoft Research Group (2009). Openhealth

project. http://openhealth.morfeo-project.org.

Institute of Electrical and Electronics Engineers Inc. (2004).

Part 20101: Application proﬁles base standard.

Institute of Electrical and Electronics Engineers Inc.

(2008a). Part 10404: Device specialization pulse

oximeter.

Institute of Electrical and Electronics Engineers Inc.

(2008b). Part 10408: Device specialization ther-

mometer.

Institute of Electrical and Electronics Engineers Inc.

(2008c). Part 20601: Application proﬁle optimized

exchange protocol.

International Telecommunication Union (2002). Itu-t rec-

ommendation x.680. http://www.itu.int.

Lamprey Networks (2009). Continua enabling software li-

brary. http://www.lampreynetworks.com/.

Mindtree (2009). Mindtree announcement.

http://tinyurl.com/yha2fhq.

Nonin Medical Inc. (2009). 9560 Onyx II.

http://www.nonin.com.

Padovan, G. F. (2009). Streaming and enhanced retransmis-

sion modes for bluez project. http://www.bluez.org/.

OPENHEALTH - The OpenHealth FLOSS Implementation of the ISO/IEEE 11073-20601 Standard

511