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.

Author:Mazujinn Donris
Language:English (Spanish)
Published (Last):26 September 2006
PDF File Size:18.18 Mb
ePub File Size:20.70 Mb
Price:Free* [*Free Regsitration Required]

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.

System model[ edit ] The overall IEEE system model is divided into three principal components, each of which is treated separately in IEEE , 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[ edit ] Agents and managers[ edit ] The IEEE 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. 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. Transport independence[ edit ] The IEEE PHD standards define messages that travel between agent and manager but not how those messages should be moved. 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 framework standard.

Self-describing and extensible[ edit ] 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.

The use of MDER allows agents to store predefined transmission templates "canned messages" and modify just the fixed location, varying parts before sending. 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[ edit ] The IEEE standards represent the agent as a set of objects in the object-oriented programming sense of the word. 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. And the Agent can generate Events - typically to inform the Manager that some data has changed. 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.

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 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.

It has optional body weight and body mass index numeric objects. 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. 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[ edit ] The communication model supports the topology of one or more Agents communicating over point-to-point connections to a single Manager. The IEEE 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. 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.

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[ edit ] 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. The weighing scales are switched on for the first time and the Agent scales sends an association request identifying the device as an IEEE 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[ edit ] 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. Scanner Report[ edit ] 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.


ISO/IEEE 11073-10418:2014

Pb - Health informatics -- Point-of-care medical device communication -- Part Nomenclature Amendment 2: Additional definitions The scope of this standard is to define a nomenclature for communication of information from point-of-care medical devices. Primary emphasis is placed on acute care medical devices and patient vital signs information. The nomenclature also supports concepts in an object oriented information model that is for medical device communications. Devices within the scope of this nomenclature are implantable devices such as pacemakers, defibrillators, devices for cardiac re-synchronization therapy, and implantable cardiac monitors. This nomenclature defines the terms necessary to convey a clinically relevant summary of the information obtained during a device interrogation.


ISO/IEEE 11073 Personal Health Data (PHD) Standards

Base standard[ edit ] The common background for assembly and transmission of objects and their attributes are defined in this standard. The communication model describes the layers 5 to 7 of the OSI 7-layer model. The information model defines the modeling, formatting and the syntax for transmission coding of the objects. The arrangement of two or more medical devices as a system, so that the components are possible to understand and to interact, are the basic idea of this principle. The agent is the part of the principle that is connected to the medical devices.


ISO/IEEE 11073-20702:2018



ISO/IEEE 11073


Related Articles