This article expresses the author's opinion at the time of writing. There are no guarantees of correctness, originality or current relevance. Copying the whole article is forbidden. Transcription of selected parts is allowed provided that author and this source are mentioned.
Well, to begin with, what is a "personal health device" (PHD)? It is a type of medical apparatus that patients (and healthy persons) use without professional help, 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 meter at home. A fair percentage of diabetics have a glucosimeter. Many fitness apparatus have podometers and heart rate sensors. The PHD class includes those "health & fitness" devices that are undeniably popular.
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 costs. Cost is a major issue, given that the 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 to current devices, so they can send data to computers or cell phones, and from there to the doctor or to the hospital. This video shows a Bluetooth-enabled blood pressure in action.
As should be obvious, it is desirable that all devices use a common data protocol. That's where IEEE 11073 fits in.
As a friend said, the IEEE 11073 standard is "long-winded". Most of us come from a 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 critique 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 the ASN.1 "language", a platform-neutral way of describing types, structures and protocol messages. But ASN.1 is above the physical representation of these elements. In order to actually send them over the wire, an encoding rule must be adopted. In the case of IEEE 11073, the encoding rule is MDER. (MDER supports only a subset of ASN.1.)
On top of 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. The exponent is a power of ten. It is quite different from the "normal" floating-point that we use in programming (IEEE 754).
On top of the IEEE 11073 stack, 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 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 the IEEE 11073 standard. For that, we have Antidote.
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 (so the application must use GLib too). A Qt application would need a different plug-in, because Qt has its own main loop. (But writing a new plug-in is not difficult.)
Another kind of Antidote "plug-in" is the data codec. Its mission is to save the application from having to manipulate DIM classes and PHD types directly. The application gets data in digestible formats like 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.
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 an easy way to handle medical devices, using a D-Bus API, removing Antidote as a library dependency for your app.
Besides being simpler (if 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 conflicts like 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.