ISO/IEEE 11073 Personal Health Data (PHD) Standards

ISO/IEEE 11073 Personal Health Data (PHD) standards are a group of standards addressing the interoperability of personal health devices (PHDs) such as weighing scales, blood pressure monitors, blood glucose monitors and the like. The standards draw upon earlier IEEE11073 standards work, but differ from this earlier work due to an emphasis on devices for personal use (rather than hospital use) and a simpler communications model.

Background

Demographics changes (the rapidly aging population in many industrialised countries) and an increase in chronic diseases (such as diabetes and heart disease) has led many to ask how technology can be used to ease the burden on health care professionals and provide useful tools to the elderly and infirm – and in particular how technology can help people cope with their conditions within their own homes. This is leading to the development of "personal health devices" which allow people to monitor their own conditions within their own homes and provide the information that such devices obtain to health care professionals and other carers.

Concern that incompatible systems will slow the roll-out of useful personal health devices has prompted moves towards ensuring interoperability. The Continua Alliance is a group of companies and bodies seeking to promote the growth of this personal health market. They are working with the IEEE Standards Association, and the IEEE-EMBS affiliated 11073 Personal Health Data Working Group is formulating standards for data formats and communications to ensure device interoperability.

In the words of IEEE 11073-20601-2008, that standard:

...addresses a need for an openly defined, independent standard for converting the information profile [of personal health devices] into an interoperable transmission format so the information can be exchanged to and from personal telehealth devices and compute engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes).

Up to date information on the IEEE 11073 group may be found on 11073.org.

Previous standards

The IEEE 11073 Personal Health Device standards[1] family is based around a single "framework" standard:

and a number of "device specialization" standards - the following exist at present:

IEEE 11073-20601 is the framework standard which defines the generic data types, message types and communication model. This supports any number of (relatively small) "device specialization" standards (such as the IEEE 11073-10408 standard for thermometers) which need only define the data model for that particular type of personal health device.

This modular approach makes it relatively easy to add support for a new type of device. More device specialization standards are in the course of preparation, including:

Revisions to existing standards:

Architectural overview

Architectural decisions include:

System model

The overall IEEE 11073 system model is divided into three principal components, each of which is treated separately in IEEE 11073-20601, and each of which are treated in more detail later in this article:

Detail

Agents and managers

The IEEE 11073 PHD standards has the concept of "agents" and "managers". Agents and managers may operate in staggered architectures with multiple layers of agents as well as of managers.

All communications between agents and managers is preferably mobile and autonomous, as the carrying patient of nurse is a mobile subject himself. When the agents transmit their data to more capable managers then the data can be processed and displayed on the managers, and then perhaps transferred through the Intranet to people's carers and to health care professionals. A transfer via Internet is technically viable, however of lesser level of security and protection of privacy for data.

The standards assume that each agent communicates with a single manager at a time. A manager could communicate with more than one agent. Communications is bi-directional to enable transaction security. The manager may be able to maintain its own copy of the transmitted agent's objects (data), however a layered server architecture provides for legally secure archiving.

Transport independence

The IEEE 11073 PHD standards define messages that travel between agent and manager but not how those messages should be moved.

Three transports were defined:

Bluetooth Health Device Profile
USB Personal Healthcare Device Class
ZigBee Health Care Profile

Others may be defined in the future.

Object oriented

The IEEE 11073 family of standards use the object-oriented systems management paradigm. Data (measurement, state, and so on) are modeled in the form of information objects that are accessed and manipulated using an object access service protocol. Note that this does not mean that Agents or Managers must be implemented using object oriented programming languages.

This approach ensures flexibility and is what allows new device specialisation standards to be added easily: all Agents are instances of a "Medical Device System" object, and contain an appropriate mix of other objects pre-defined by the IEEE 11073-20601 framework standard.

Self-describing and extensible

An agent may either implement one or more standard configurations, or may implement an extended (custom) configuration. When an agent first associates with a manager it states its configuration. Usually the manager will already have knowledge of the object model of agents with this configuration code - either because it was given this knowledge at birth, or because it has previously associated with this Agent and has already learned its object model. If the manager does not have knowledge of this configuration it asks the agent to describe its characteristics (by listing its objects).

The use of standard configurations, and the exchange of object models when an Agent with a new configuration appears for the first time, significantly reduces the exchange of data required when an Agent associates with a Manager.

ASN.1 representation of data

Each object, and all of its attributes, are formally defined using Abstract Syntax Notation One (ASN.1). ASN.1 provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques.

ASN.1 objects are converted into binary data streams using Medical Device Encoding Rules (MDER) which is a subset of Basic Encoding Rules (BER). The use of MDER allows agents to store predefined transmission templates ("canned messages") and modify just the fixed location, varying parts before sending.

System model in more detail

The overall IEEE 11073 system model is divided into three principal components: the Domain Information Model (DIM), the service model, and the communications model. These three models work together to represent data, define data access and command methodologies, and communicate the data from an Agent to a Manager. They are considered in turn.

Domain Information Model

The IEEE 11073 standards represent the agent as a set of objects (in the object-oriented programming sense of the word).

Each object has one or more attributes. Attributes describe measurement data that are communicated to a Manager as well as elements that control behavior and report on the status of the Agent. As well as attributes, the objects can possess methods (such as GET and SET) by which the Manager can interact with the Agent. And the Agent can generate Events - typically to inform the Manager that some data has changed.

The IEEE 11073-20601 defines these classes (which are instantiated as objects):

For each object there are a range of attributes – some mandatory and some optional. These attributes include timestamps, descriptive strings, validity and units.

The figure below (based on one from the IEEE 11073-20601 standard) shows the IEEE 11073 Personal Health Device Domain Information Model, expressed as a UML class diagram. The MDS object (and the objects that it contains) belongs to the Agent, but the Manager is able to build its own representation by interrogating the Agent.

So in summary, an Agent is represented as an MDS object, containing one or more Metric or PM-Store objects (representing data) and capable of generating Events through Scanner objects.

The figure below shows a practical example of this: the Domain Information Model of the weighing scales defined by IEEE 11073-10415. This shows that every weighing scales has an MDS object and a Body Weight numeric object. It has optional body weight and body mass index numeric objects.

Each object, and all of its attributes, are formally defined using Abstract Syntax Notation One (ASN.1).

Service Model

The "Service Model" is all about the messages that pass between the Agent and the Manager. The standard defines the messages and when they can occur.

Message types are:

The Service Model defines flexible and efficient ways in which an Agent may pass a Manager configuration information. In this way the Manager can build its own picture of the objects possessed by the Agent.

It is important to note that Agents are able to describe themselves during the association (or "discovery") stage. An Agent announces that it has a standard configuration, that is likely to be known by the Manager, or a non-standard configuration. In either case, the Manager may ask the Agent to describe all of its objects (and thus its capabilities) during a configuration process. Agents can be as simple or as complex as the application demands. In this way the Manager builds a map of all of the Agent's objects. This provides a plug and play capability.

The Service Model also defines flexible and efficient ways in which an Agent may pass a Manager measurement data values.

Communication Model

The communication model supports the topology of one or more Agents communicating over point-to-point connections to a single Manager. The IEEE 11073 standards are transport-independent and assume that a transport layer (such as Bluetooth or ZigBee) can be established between an Agent and a Manager by some mechanism that is outside the scope of the standards.

For each point-to-point connection, the dynamic system behavior is defined by a connection state machine. The connection state machine defines the states and sub-states an Agent and Manager pair passes through, including states related to connection, association, and operation. The communication model also defines in detail the entry, exit, and error conditions for the respective states including various operating procedures for measurement data transmission.

Another function of the communication model is to convert the abstract data modeling (ASN.1 representations of objects) used in the DIM into a "transfer syntax". A transformation process known as the Medical Device Encoding Rules (MDER) takes the data contained in an object and encodes it into a binary message to be sent using the communication model. (Other encoding rules can optionally be used.) After transmission the messages can be unambiguously decoded and the objects and their data extracted.

Note that the MDER rules are a subset of the BER rules. This MDER-encoded ASN.1 representation of objects is similar in concept to using XML as a machine-independent method of exchanging data (indeed, the XER transfer syntax transfers ASN.1 objects in XML). However the differences are that MDER messages are much smaller than the equivalent XML messages, and much simpler for machines to convert to and from internal data structures.

Examples of Message Exchanges

This section shows some of the exchanges that occur between Agent and Manager. The exchanges, illustrated by UML sequence diagrams, are:

Association Request - Agent is not Recognised

The UML sequence diagram below shows messages that would typically pass between a weighing scale PHD Agent and an IEEE 11073 Manager (such as a mobile phone or PC). The weighing scales are switched on for the first time and the Agent (scales) sends an association request (identifying the device as an IEEE 11073 PHD device), but in this example the Manager does not recognise the Agent.

So the Agent sends a configuration report containing details of all of the objects it contains and their static attributes (of the Body Weight, Body Height and Body Mass Index objects, in this case). The Manager also requests details of the (top-level) MDS object. All this data would typically be stored for future reference.

The Agent then sends measurement data (in a Confirmed Event Report), then disconnects from the Manager.

Association Request - Agent is Recognised

The next UML sequence diagram shows the weighing scales in operation for a second time. In this case the Manager does recognise the Agent, so uses the configuration data that it previously stored (or that it obtained by some other route).

The Agent then sends measurement data (in a Confirmed Event Report), then disconnects from the Manager.

Scanner Report

The Scanner object class is a powerful construct that enables efficient grouping of several metrics into a single message payload. Think of scanners as objects within the PHD that monitor parameters and send notifications to the manager as required. A scanner can report measurements from several other objects in a single message. There are two types of scanner: episodic (which sends a notification when some event occurs) and periodic (which send notifications at regular intervals).

Not all Agents have Scanner objects: weighing scales don't but pulse oximeters can do.

In the context of a pulse oximeter, an episodic scanner could be implemented to send an event report to the manager on every heart beat. A periodic scanner could be implemented to send an event report containing trend data every five seconds, say. As with the other objects, the data contained within the scanner event reports are specified in the configuration phase – the agent has considerable flexibility in defining the data it will send, yet any configuration will be intelligible to the manager.

The scanner event reports are designed to be very efficient in terms of bandwidth – the parameters to be returned in each event report have been defined during configuration, so each report need only identify the object and pass the data values. The agent can specify whether or not it requires an acknowledgment from the manager. The manager can enable and disable scanners (so has control over whether the event reports are sent or not).

The following UML sequence diagram describes the operation of a scanner object. The manager uses a SET command to start the scanner (and later to stop it). In between times the agent loops, sending event reports containing measurements. Depending on the configuration, these event reports can optionally require an acknowledgment. The scanner would in general run for several minutes or several hours, while the patient was being monitored.

The sequence diagrams for episodic and periodic scanners look the same.

Accessing the Persistent Metric Store

The next UML sequence diagram describes the operation of the Persistent Metric Store (PM-Store).

The PM-Store provides a flexible way of implementing simple file systems. Not all Agents have Persistent Metric Store objects: weighing scales don't but pulse oximeters can.

In this case one (or more) PM-Store objects are used to store time-stamped SpO2 and pulse rate measurements. The actual data is contained in one or more PM-Segment objects – in this case each PM-Segment object contains data from one continuous monitoring session. The PM-Store objects are simple enough that data can be stored very efficiently, but flexible enough to allow them to be used to store practically any kind of data that devices can measure. As with all IEEE 11073 objects, the Agent reports the configuration of the PM-Store and PM-Segment objects during the configuration phase, so the Manager need not have prior knowledge of the data formats.

The Agent fills PM-Segment elements with measurement data. The Manager interrogates the Agent to find out what data is stored, and then, for each PM-Segment object of interest, instructs the Agent to start sending the data. The Agent can divide the PM-Segment data into chunks of manageable size, and sends them in succession as event reports.

When the Manager has safely retrieved the data from the agent it may clear the PM-Segments for re-use.

References

  1. ↑ For published standards search for '11073' at IEEE, http://shop.ieee.org/ieeestore or ISO, http://www.iso.org/iso/search.htm?qt=11073&searchSubmit=Search&sort=rel&type=simple&published=true (ISO store catalogue). ISO and CEN standards may be purchased from your national standards organisation or bookstore (e.g. AFNOR, BSI, DIN, JIS, UNI, etc.).
IEEE; ISO; or CEN
Published standards may be purchased from your national standards organisation (e.g. AFNOR, BSI, DIN, JIS, KATS, etc.) or bookstore.


This article is issued from Wikipedia - version of the 9/20/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.