Successful end-to-end data systems are typically comprised of a collection of dovetailing technologies managed by a comprehensive set of global standards that make interoperability possible at the product level.
The strict regulations, rigorous certification programs and institutional conservatism that characterize the medical and personal health market sectors make them particularly amenable to adopting standards. Standardization is also very useful for design engineers whose mission is to produce a single product that can be used throughout the world.
Figure 1 shows one concept of an end-to-end delivery and analysis system for moving patient data collected by sensors to the health care provider’s servers. This is the monitor aspect of the eHealth domain, which has gained wide acceptance as a partial answer to spiraling health care costs.
Personal Health Devices (PHDs) shown at the left of Figure 1 collect physiological, independent living and health and fitness data, which is then transported through gateways and over wired and wireless networks until it reaches the servers where healthcare professionals can access it.
PHDs have been available for many years but the product interoperability necessary for eHealth applications has been elusive because an end-to-end set of standards was not in place. In addition, the standards for the connectivity technology were lacking.
That has changed with the creation of the ISO/IEEE 11073 series of standards that carries the umbrella title “Health informatics—Personal health device communication.” Many have already been approved on the IEEE Standards Board. In a significant recent development, the U.S. Food and Drug Administration (FDA) officially included several of them in its recommended list of standards for supporting medical device interoperability.
Table 1 provides several of the ISO/IEEE PHD standards, organized in groups according to major use or domain. Standards shown in the pink cells have been included in the FDA recommended list. The full name of the standard, for example weighing scale, is ISO/IEEE 11073-10415 but for brevity only the suffix number of the standard is shown in the table.
The standards have been written to be as lightweight possible by limiting functionality to a level that was agreed necessary for a basic standard device. Yet they are comprehensive in the sense that they allow a complete set of information to be provided in advanced products with extended functionalities.
Object Oriented Paradigm
The ISO/IEEE 11073 standards are based on an object modelling of the device to describe the data and functionalities although it is not essential to use an object–oriented programming language to implement the PHD software. They define two device types: Agents and Managers.
- Agents are PHD software components that provide interfacing functionality to the sensor.
- Managers typically receive data from multiple agents and generally manage the communications process.
Agents are typically low-cost consumer products with limited hardware capabilities. They often run on small batteries and need to be designed for power efficiency. Managers typically have higher performance hardware, connect to multiple agents and often use wall power or larger batteries.
An agent will self-describe its configuration when it associates with a manager; it is plug and play. However, if the manager is aware of the configuration of a standard agent or familiar with the agent from a previous association, then the agent may omit sending its configuration for transmission efficiency.
ISO/IEEE 11073 attempts to simplify the device models by defining a restricted set of classes for its object models, as shown in Table 2. In the object-orientated programming paradigm, the definition of the data objects is known as the Domain Information Model (DIM). Because of the many possible PHD configurations, some attributes are mandatory and some are optional.
Service and Communication Models
In addition to the domain information model, the ISO/IEEE 11073 also includes a service model, which describes interactions with objects and attributes, and a communication model, which describes a connection state machine and details the communication characteristics. Together, the three models: (1) represent PHD data; (2) define its data access and command methodologies; and, (3) communicate the data from an agent to a manager.
The Service Model defines message types such as how to set up and break down a session. Its basic function is to define ways for an agent to pass configuration information to a manager. Seven message types are separated into two categories:
- Association service
- Association request/response
- Release request/response
- Abort
- Object access service
- Get
- Set
- Event report
- Actions (methods)
The communication model enables multiple agents to communicate with a single manager over connection-oriented links. ISO/IEEE 11073 is transport-independent. A connection state machine creates a means for a successful interaction with various transport technologies such as USB, Bluetooth and ZigBee.
The communication model also defines a process known as the Medical Device Encoding Rules (MDER) for the conversion of ASN.1 representations of objects into a binary message. After transmission, the messages can be unambiguously decoded and the objects and their data extracted.
Device Profiles
The family of ISO/IEEE 11073 standards uses the device profile concept to provide a well-defined description of a specific device and data transmission profiles to ensure interoperability between devices based on the same communication technology.
PHDs themselves typically use wireless links and communicate with gateways over PANs such as Bluetooth or ZigBee. Measurement values are most frequently transferred in PHD from agent to manager, which then sends the data over a long-range connection (e.g., wireless WAN) to transfer the data to a health services provider. The short-range exchange can also occur over a cabled connection such as USB to a laptop or PC.
The advantage to the approach is that the standards encompass interoperability across multiple monitoring domains (health, independent living, health and fitness), and allow multi-modal monitoring on a common platform. This is further enhanced by the plug and play characteristic that means new sensors can be added to a platform without need to upgrade software in managers.