ISO/IEEE 11073

The family of standards ISO / IEEE 11073 defines the components of a system with which it is possible to exchange vital data between different medical devices, evaluate and remotely control the devices. The parts 10101, 10201, 20101, 30200 and 30300 are also known as DIN standards DIN EN ISO 11073.

4.1 Agent Application Process (es)
4.2 MDIB ( Medical Data Information Base)
4.3 ACSE ( Association Control Service Element)
4.4 CMDISE (Common Medical Device Information Service Element )
4.5 Presentation Layer ( not in picture)
4.6 Session Layer ( not in picture)

5.1 Medical Package
5.2 Alert Package
5.3 System Package
5.4 Control Package
5.5 Extended Services Package
5.6 Communication Package
5.7 Archival Package
5.8 Patient Package

6.1 Finite State Machine (FSM )
6.2 MDIB initialization
6.3 Data exchange via services
6.4 Data exchange via scanner

Published standards

E = Draft

Here are the relevant core standards:

ISO / IEEE 11073-10101
ISO / IEEE 11073-10201
ISO / IEEE 11073-20101 and
ISO / IEEE 11073-30200

Drafts ( drafts )

In addition to the published standards are currently a large number ( about 20 ) Drafts for the extension of the standard, especially for device-specific profiles are provided. These designs come in their latest version made in 2008.

Overview of the core standards

ISO / IEEE 11073-10101 nomenclature

Within this standard nomenclature codes are defined which can be identified in connection with the so-called OID code, objects and attributes clearly later. The nomenclature is divided into so-called partitions, which allow a functional or substantive definition of the codes. Programmatically, these codes are defined as constants and can be used via an alias in the program. Example in C :

# define MDC_PART_OBJ 1 / * Definition for the partition Object Infrastructure * / # define MDC_MOC_VMS_MDS_SIMP 37 / * Defines the object Simple System Medical Device * / The programmatic implementation of this standard is simple, since it consists only of these definitions.

ISO / IEEE 11073-10201 Domain Information Model

This standard is the "heart " of VITAL. In their objects to vital data transmission and their arrangement are defined in a domain information model. Furthermore, this standard specifies a service model for communication. A more detailed documentation of this standard can be found in sections 3 and 4 of this document.

ISO / IEEE 11073-20101 standard base

This standard specifies the general principles for the transfer and the creation of objects and their attributes. It is divided into the Communication Model and the Domain Model. Here, the communication model describes the layers 5-7 of the OSI model and the information 7Schicht model to model, and formatting the syntax for transmitting the coding objects. On these models, this document will be discussed in sections 3 and 5.

Agent / Manager - principle

All parts defined in different standards are designed to allow communication in accordance with this principle. The basic idea is to combine two or more medical devices to a system, so that can understand and influence the components are mutually exclusive.

It is the agent of the part of the principle, which is at the or connected medical devices. It is the data provider. The manager keeps a copy of data of the agent responds to the update events of the same or triggers events on the Agent. In most applications, the Manager is in the broadest sense be a remote monitor to display the data. But even a control of the agent by the manager is possible. As seen in the figure above, agent and manager are built in the same structure. This allows an agent to act as the manager and vice versa. Besides the pure Agent Manager application also hybrid systems through several stages are therefore conceivable.

In addition, the individual modules and their functions are also discussed with reference to the figure above.

Agent Application Process (es)

This module provides the interface between a proprietary (possibly native ) protocol and the VITAL - object world. The interface is not defined within the standard, and can be implemented so freely.

MDIB ( Medical Data Information Base)

The MDIB can be compared removed with an object oriented database. MMOs ( Managed Medical Objects) are arranged in the form of DIM ( Domain Information Models ) within the MDIB hierarchically in a tree structure. The MMOs are defined within the norm, even the arrangement of the DIM is fixed. The implementation of the MDIB with their required functions not subject to the standard.

ACSE ( Association Control Service Element)

This module is subject to the standards ISO / IEC 15953 and ISO / IEC 15954th It features services that control the connection establishment and termination. It is therefore only one possible connection or her condition negotiated. This module does not MMOs are transferred.

CMDISE (Common Medical Device Information Service Element )

This module provides services that enable the exchange of data from MMOs ( Managed Medical Objects) between the agent / manager systems. This data exchange turns out this highly dynamic. About the Services CREATE, UPDATE, DELETE, objects can be created, changed or deleted. About reports that can be defined in detail by the single object attribute, it complex operations in the agent or manager is possible via these services trigger.

Presentation Layer ( not in picture)

This layer takes over before the coding of the object data. Encoded objects, groups of object attributes or individual attributes in ASN.1 representation or specialization Mder ( Medical Device Encoding Rules).

Session Layer ( not in picture)

This layer controls the connection session level.

DIM (Domain Information Model)

The central core of the standard is the so-called Domain Information Model. In this model, objects and their dependencies defined the vital data. Furthermore, the model includes objects that provide additional services related to the vital data objects.

For text semantics of the objects they have been divided into packages.

Medical package

This is the main package for the mapping of vital data in the standard. In it, objects are defined in which vital data of various types can be stored. An example is the Real Time Sample array named that can be used for the administration of, for example EKG data.

Alert package

This relatively small package was created within the Medical Package. It is used to set and manage alarms and alarm parameters of objects from the Medical Package.

System package

This package with objects, a representation of a medical device can be achieved. It includes concrete derivations of abstract MDS object ( Medical Device System). One of these concrete leads is always the root object of a DIM - Trees. To further illustrate this package the Battery and the Clock object can be mentioned. The latter can be used for time synchronization of data of a Medical Device.

Control package

In the Control Package objects are defined for the remote control of a medical device. There are objects that affect only the way a measurement ( eg the SetRangeOperation object) and objects that can be used directly to control the device (eg the ActivateOperation object).

Extended Services Package

Unlike the name suggests, quite basic and always necessary objects are defined in this package. This package consists of so-called scanner objects in a variety of derivatives. Meaning of these objects is to scan data in other objects and generate event reports that can then be sent. In this case, these objects have a wide variety of attributes ( such as scan interval ), which allows a wide application of the objects in the DIM. As an example we mention the FastPeriCfgScanner object (Fast Periodic Configurable Scanner ), which was specifically tailored to the requirements of real-time data transmission, for example, ECG data from a real-time sample array.

Communication Package

The modules in this package contain information intended to enable basic communication. This package was designed so open that different communication profiles and interfaces can be built to proprietary device interfaces. Author's Note: From historical point of view, the standard was first developed in the early 90s, this package is quite of revision. From my perspective, this package has been developed to enable direct communication between two terminals, with the involvement of the then most commonly occurring RS232 interface.

Archival package

With the objects of the Archival Package can be patient-related data in an online or an offline archive store. For example, can be on the patient object archives vital data, demographic data and treatment data of a patient, save in an object.

Patient package

The patient package contains only one object, the patient Demographics object. It contains patient-related data. It can be connected to an MDS object or one of the archive objects are docked to establish a relationship of anonymous patient data.

Communication model

Since the entire communication process is quite complex, Summary is only generally entered into it in this short. Detailed information is set out in the relevant standard and can be found there.

Finite State Machine (FSM )

The finite state machine controls the synchronization of a agent-manager system through different states. A complete round-trip one session starts with the Disconnected state, goes through several stages to the Initialized state, can in which the actual data exchange takes place and ends in the Disconnected state.

MDIB initialization

During the phase of the Association Status Configuring is achieved. In this state, agent and manager exchange for the first time from object data. Here, a MDS Create Event is triggered in the form of a report that leads to the Manager that a copy of MDS root object from the agent MDIB in the Manager MDIB is created. A context is then generated scanner object in the agent. This object generates a report that contains content than the complete representation of the agent MDIB. The manager evaluates this report and reflects the MDIB the agent. At this time, the manager maintains an exact copy of the agent MDIB. Both are now in the Configured state.

Data exchange via Services

CMDISE provides the GET service to data that were requested by a manager to deliver. The GET service in the agent gets to passed, identify the unique values within the Agent MDIB a list of attribute IDs. In Agent, a report is generated that contains the desired values. This report is sent back to the manager.

Data exchange via scanner

Additional objects in a MDIB can be created via the CREATE Service of CMDISE. So the manager calls on the agent using this service to create a scanner object in the agent and to fixate on one or more values . Optionally, for example, yet the scanning interval in which the data are to be delivered, to be chosen. The agent generates the scanner object in its MDIB and inform the manager of a Response Message with. The manager went on to a copy of the scanner object in its MDIB. The data are updated by the agent to the manager is now automated via the scanner object. About the DELETE service CMDISE this scanner object, like all other objects can also be removed again.

Glossary

310102