In this article, we will talk a bit about the IEEE 11073 standard, conceived for personal health devices. And about the Antidote library, an open-source implementation of IEEE standard by Signove.

Well, to begin with, what is a "personal health device" (PHD)? It is a type of medical apparatus that patients (and potentially healthy persons too) use by themselves, in the course of their normal lives: house, work, etc.

It sounds scary but PHDs are already ubiquitous. Almost everybody has a scale, a thermometer or a blood pressure measurer at home. A fair percentage of diabetics have a glucosimeter. And so on.

The PHD class includes those "health & fitness" devices, in the wake of sport fad: pedometers, heart rate monitors, you know.

Such devices allow people to monitor their medical conditions and/or general health without the need of frequent medical appointments or trips to the hospital. This means closer monitoring with less cost; this is very important taking into consideration that human population is inexorably growing older in average.

Twenty years ago, domestic scales and blood pressure cuffs were all mechanical. Today, most if not all of them are electronic. The next step is add connectivity features to current devices, so they can send data to computers or cell phones, and from there to the doctor or the hospital. This vídeo shows a Bluetooth-enabled blood pressure in action.

As should be obvious, it is best that all those devices follow the same data protocol. That's where IEEE 11073 enters.

IEEE 11073:20601

As a friend said, the IEEE 11073 standard is "long-winded". Most of us come from TCP/IP background and are used to concise, informal and clarifying style of RFC documents; the IEEE documents feel intimidating, unnecessarily long and difficult to read.

Anyway, it is not my intention here to evaluate the IEEE standard. I am not qualified to do that, and having one standard is better than having none (or several :P). Big Macs are not the best sandwich but everybody ends up eating a lot of them.

The basis of everything in IEEE is ASN.1 "language", a platform-neutral form of describing types, structures and protocol messages. In order to actually send data over the wire, an encoding rule must be adopted. In the case of IEEE 11073, encoding rule is MDER, which supports only a subset of ASN.1.

Right above ASN.1, we have PHD types; it is a collection of data types, simple and compound, built using the MDER-supported subset of ASN.1. For example, FLOAT is a PHD-defined type: 32-bit floating-point, 24-bit mantissa, 8-bit exponent. It is analog to, but quite different from, the "normal" floating-point that we use in programming (IEEE 754).

On top of IEEE 11073 food chain, we have DIM -- Domain Information Model, a tree of medical information. It is said to be object-oriented because there are data "classes". A given medical data set (or "object") contains no more, no less data than specified by the class it belongs, so the application knows exactly what to expect and how to interpret it.

A DIM class may be extended. For example, the manufacturer XPTO wants its scale to send fat mass percentage along weight. This satisfies the enhanced scale and the IEEE applications that are interested only in weight data. IEEE protocol has provisions to "teach" new sub-classes, or unknown classes, to the counterpart, so connecting to an unknown device should never "break" an older application.

By the way, the set of classes and constants necessary to support a given device class is called a specialization, and it is specified in a separate document e.g. 11073:10404 standard is the oximeter specialization.

Continua Alliance and Bluetooth HDP

Continua Alliance is a non-profit organization that promotes these concepts of remote health monitoring, improved life quality in face of chronic diseases etc.

One of Continua activities is exactly the promotion of standards, as well as certification against them. IEEE 11073 is the adopted standard for session/application protoocol.

Since IEEE is transport-agnostic, Continua also chooses transport technologies that a) are inexpensive, and b) easy to connect to existing computers and/or cell phones. Currently, Continua has selected three transports: Bluetooth, USB and Zigbee. Others may be adopted in the future.

Bluetooth supports medical devices through HDP (Health Device Profile). This means that, in order to connect to e.g. an oximeter or blood cuff, the computer's Bluetooth stack must implement HDP.

BlueZ (Linux Bluetooth stack) does implement HDP since version 4.81. If your Linux distribution packages an older BlueZ, you can always install the newest version from sources.

But BlueZ and HDP just supply the transport layer. We still need software the implements IEEE 11073 standard. For that, we have Antidote.

Antidote

Antidote is an implementation of IEEE 11073:20601, and has been developed by Signove Tecnologia. At the moment, it seems to be the only open-source implementation of this standard. License is LGPL.

The library is written in C and it has very few external dependencies. Even though it has been tested mostly in Linux, there are no architectural impediments to port it to any other platform.

The "bridges" between IEEE stack, transport technology and application are provided by transport plug-ins, which concentrate and bear all platform dependencies.

For example, the BlueZ HDP plug-in (included with Antidote sources) depends on a lot of things: Linux, BlueZ, D-Bus and demands a GLib main loop (which implies that application uses GLib too). A Qt application would need a different plug-in, because Qt main loop is different. (It is not terribly difficult to write a new plug-in, though.)

Another kind of Antidote "plug-in" is the data codec. Its function is basically save the application from having to manipulate DIM classes and PHD types directly, converting them to XML, JSON etc., depending on the particular plug-in.

The library has unit tests, several kinds of documentation (Doxygen, wiki, introductory texts), an example application (see next topic). On top of that, it is an actively-developed product.

The com.signove.health service

Bundled in the library source code (and compiled along with it), Antidote brings a complete example application: a D-Bus service for medical devices.

Implementing this service served two purposes. The first one is, naturally, a degree of self-documentation and self-testing. The prospective developer can look into the code and interact with the running app using Python scripts, D-Feet or anything else.

The second purpose is propose a very easy way to handle medical devices, using a D-Bus API, even freeing the application from linking to Antidote lib.

Besides being simpler (albeit less powerful than using Antidote directly), the application may be written in any language or framework. The only requisite is D-Bus support. Another advantage of a "broker" is centralization: avoids automatically potential conflicts e.g. two applications trying to use HDP at the same time.

This service has been used "for real", and may well become a widely-used standard by itself.