ISO/IEEE 11073 Personal Health Device (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 IEEEStandards 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).
Previous standards
The IEEE 11073 Personal Health Device standards[1] family is based around a single "framework" standard:
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,[when?] including:
IEEE Std 11073-10417 - Device specialization - Glucose Meter (revision)
IEEE Std 11073-10441 - Device specialization - Cardiovascular fitness and activity monitor (revision to add 3D accelerometer / physical activity monitor data)
Architectural overview
Architectural decisions include:
A point-to-point connection is made between "agent" and a "manager".
Transport agnostic (to facilitate porting to new communications channels).
Object-oriented philosophy (to facilitate code re-use and simplify the introduction of new devices).
Agents are self-describing (so Managers can understand the characteristics of the Agents).
Extensible (to encompass new types of agent, and custom specializations of already-defined agents)
ASN.1 used to represent data structures and messages (to simplify parsing of messages).
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:
The Domain Information Model represents an agent as a set of objects. Each object has one or more attributes. Attributes describe measurement and status data that are communicated to a manager.
The service model provides commands such as Get, Set, Action, and Event Report that are sent between the agent and manager to exchange data from the DIM.
The communication model establishes a state machine for the Agent and the Manager, including states related to connection, association, and operation. The communication model also converts the abstract data modeling used in the Domain Information Model into a binary message format for transfer using the communication model
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.
The agents are the personal health devices and are generally small, inexpensive battery-powered devices that lack much in the way of displays and other user interfaces.
The managers are typically small computers or smart phones with greater computing resources and required routing capabilities to convey information autonomously from delivering source to named class of sink.
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.
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):
Medical Device System (MDS) – each Agent has one MDS object, which identifies it and reports its status. The attributes of the MDS object identify it to the Manager, represent the time and status, and provide other information. The MDS then contains zero or more of some of the objects represented by the classes below.
Metric Class is the base class for all objects representing measurements, status and context data. However, the Metric Class is never instantiated itself: rather, it is used as the base class for the Numeric, Real-Time Sample Array and Enumeration classes.
For each object there are a range of attributes – some mandatory and some optional. These attributes include timestamps, descriptive strings, validity and units.
Numeric – represent a single measurement. The standard defines two forms of floating point data suitable for real-world measurements – one contained in 32 bits and the other in 16 bits. A Numeric object may return data in either format, and either as the data value itself (if the context allows the type of measurement to be inferred) or together with units and status information. Arrays are possible, as well as single values.
Real-Time Sample Array – represents continuous samples or waveforms. A RTSA object contains information about the interval between samples, the number of samples, the resolution and the scale and offset applied to each data value.
Enumeration – represents status information (codes) or annotations (text). For example, these objects can be used to report information about falls, location of people about the home, or smoke alarm conditions.
Persistent Metric Store – represents (in a hierarchical fashion) large quantities of data that have been acquired by an Agent. Each PM-Store object contains metadata (data about the data) and zero or more PM-Segments that contain the data.
PM-Segment – each PM-Segment object contains metadata (data about the data) and zero or more entries: each entry containing one or more elements which contain the measurements. There is considerable flexibility with respect to the data that can be stored.
Scanner – scanner objects can observe measurements that are being made in the Agent and generate "events" to report to the Manager. The events can be regular reports, or reports triggered by abnormal readings that merit an alarm. As with the Metric class, the scanner objects are represented by a hierarchy of classes. The Scanner class is never instantiated itself: rather, it is used as the base class for the Configurable Scanner class, which in turn is the base class for two classes which are actually instantiated:
Configurable Scanner – never instantiated itself - base class for:
Episodic Configurable Scanner – these objects are used to send reports of data or events that are not separated by fixed time intervals.
Periodic Configurable Scanner – these objects are used to send reports of data or events that are separated by fixed time intervals.
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:
Messages relating to setting up and breaking down an "association" between an Agent and a Manager.
Messages whereby the Manager can access information in the Domain Information Model (DIM) of the Agent – either to read some attribute of the Agent, or to control some aspect of its behaviour.
Messages sent from the Agent to the Manager containing data. These are called "Events". Event messages can be initiated by the Manager or the Agent, and are used both to report configuration information and to transfer measurements.
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:
An Agent associating for the first time with a Manager that does not recognise its configuration.
An Agent associating with a Manager that already understands its configuration.
A Manager initialises a Scanner object in an agent. The Agent sends data as events occur.
Accessing the Persistent Metric Store to read data that has been stored previously.
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.
