ISO / IEEE 11073
DIN EN ISO 11073 | |
---|---|
Area | Medical informatics |
title | Communication of near-patient medical devices (various parts) |
Brief description: | Data exchange between medical devices |
Latest edition | 2006 |
ISO | ISO / IEEE 11073 |
The ISO / IEEE 11073 family of standards defines the components of a system with which it is possible to exchange and evaluate vital data between different medical devices and to control the devices remotely. Parts 10101, 10201, 20101, 30200 and 30300 are also available as DIN standards DIN EN ISO 11073.
Published standards
IEEE 11073-00101-2008 | Health informatics - PoC medical device communication - Part 00101: Guide - Guidelines for the use of RF wireless technology |
ISO / IEEE 11073-00103: 2015 | Health informatics - Personal health device communication - Part 00103: Overview |
ISO / IEEE 11073-10101: 2004 ISO / IEEE 11073-10101: 2004 / Amd.1: 2017 |
Health informatics - Point-of-care medical device communication - Part 10101: Nomenclature |
ISO / IEEE 11073-10102: 2014 | Health informatics - Point-of-care medical device communication - Part 10102: Nomenclature - Annotated ECG |
ISO / IEEE 11073-10103: 2014 | Health informatics - Point-of-care medical device communication - Part 10103: Nomenclature - Implantable device, cardiac |
ISO / IEEE 11073-10201: 2004 | Health informatics - Point-of-care medical device communication - Part 10201: Domain information model |
IEEE 11073-10207-2017 | IEEE Approved Draft Standard for Domain Information & Service Model for Service-Oriented Point-of-Care Medical Device Communication |
ISO / IEEE 11073-10404: 2010 | Health informatics - Personal health device communication - Part 10404: Device specialization - Pulse oximeter |
ISO / IEEE 11073-10406: 2012 | Health informatics - Personal health device communication - Part 10406: Device specialization - Basic electrocardiograph (ECG) (1-to 3-lead ECG) |
ISO / IEEE 11073-10407: 2010 | Health informatics - Personal health device communication - Part 10407: Device specialization - Blood pressure monitor |
ISO / IEEE 11073-10408: 2010 | Health informatics - Personal health device communication - Part 10408: Device specialization - Thermometer |
ISO / IEEE 11073-10415: 2010 | Health informatics - Personal health device communication - Part 10415: Device specialization - Weighing scale |
ISO / IEEE 11073-10417: 2017 | Health informatics - Personal health device communication - Part 10417: Device specialization - Glucose meter |
ISO / IEEE 11073-10418: 2014 ISO / IEEE 11073-10418: 2014 / Cor.1: 2016 |
Health informatics - Personal health device communication - Part 10418: Device specialization - International Normalized Ratio (INR) monitor |
ISO / IEEE 11073-10419: 2016 | Health informatics - Personal health device communication - Part 10419: Device specialization - Insulin pump |
ISO / IEEE 11073-10420: 2012 | Health informatics - Personal health device communication - Part 10420: Device specialization - Body composition analyzer |
ISO / IEEE 11073-10421: 2012 | Health informatics - Personal health device communication - Part 10421: Device specialization - Peak expiratory flow monitor (peak flow) |
ISO / IEEE 11073-10422: 2017 | Health informatics - Personal health device communication - Part 10422: Device specialization - Urine analyzer |
ISO / IEEE 11073-10424: 2016 | Health informatics - Personal health device communication - Part 10424: Device specialization - Sleep apnea breathing therapy equipment (SABTE) |
ISO / IEEE 11073-10425: 2016 | Health informatics - Personal health device communication - Part 10425: Device specialization - Continuous glucose monitor (CGM) |
IEEE 11073-10427-2016 | Health informatics - Personal health device communication - Part 10427: Device specialization - Power Status Monitor of Personal Health Devices |
ISO / IEEE 11073-10441: 2015 | Health informatics - Personal health device communication - Part 10441: Device specialization - Cardiovascular fitness and activity monitor |
ISO / IEEE 11073-10442: 2015 | Health informatics - Personal health device communication - Part 10442: Device specialization - Strength fitness equipment |
ISO / IEEE 11073-10471: 2010 | Health informatics - Personal health device communication - Part 10471: Device specialization - Independent living activity hub |
ISO / IEEE 11073-10472: 2012 | Health Informatics - Personal health device communication - Part 10472: Device specialization - Medication monitor |
ISO / IEEE 11073-20101: 2004 | Health informatics - Point-of-care medical device communication - Part 20101: Application profiles - Base standard |
ISO / IEEE 11073-20601: 2010 ISO / IEEE 11073-20601: 2010 / Amd 1: 2015 ISO / IEEE 11073-20601: 2016 / Cor.1: 2016 |
Health informatics - Personal health device communication - Part 20601: Application profile - Optimized exchange protocol |
IEEE 11073-20702-2016 | Health informatics - Point-of-care medical device communication - Part 20702: Medical Devices Communication Profile for Web Services |
ISO / IEEE 11073-30200: 2004 ISO / IEEE 11073-30200: 2004 / Amd.1: 2015 |
Health informatics - Point-of-care medical device communication - Part 30200: Transport profile - Cable connected |
ISO / IEEE 11073-30300: 2004 | Health informatics - Point-of-care medical device communication - Part 30300: Transport profile - Infrared wireless |
ISO / IEEE 11073-30400: 2012 | Health informatics - Point-of-care medical device communication - Part 30400: Interface profile - Cabled Ethernet |
The relevant core standards are:
- ISO / IEEE 11073-10101
- ISO / IEEE 11073-10201
- ISO / IEEE 11073-20101 and
- ISO / IEEE 11073-30200
Drafts
In addition to the published standards, a large number (approx. 20) drafts are currently planned to expand the standard, especially for device-specific profiles. The current version of these drafts dates from 2008.
Overview of the core standards
ISO / IEEE 11073-10101 Nomenclature
Within this standard, nomenclature codes are defined with which objects and attributes can later be clearly identified in connection with the so-called OID code . The nomenclature is divided into so-called partitions, which enable the functional or content-related delimitation of the codes. These codes are programmatically defined as constants and can be used in the program via a pseudonym.
Example in C ++:
#define MDC_PART_OBJ 1 /* Definition für die Partition Object Infrastructure */ #define MDC_MOC_VMS_MDS_SIMP 37 /* Definiert das Objekt Simple Medical Device System */
The programmatic implementation of this standard is simple as it consists only of these definitions.
ISO / IEEE 11073-10201 Domain Information Model
This standard is the "heart" of VITAL. It defines objects for transferring vital data and their arrangement in a domain information model. Furthermore, this standard defines a service model for communication. Further documentation of this standard can be found in points 3 and 4 of this document.
ISO / IEEE 11073-20101 Base Standard
This standard lays the general basis for the transfer and structure of objects and their attributes. It is divided into the Communication Model and the Information Model. The communication model describes layers 5 to 7 of the OSI 7 -layer model and the information model describes the modeling, formatting and syntax for the transmission coding of the objects. These models are discussed in points 3 and 5 of this document.
Agent / manager principle
All parts defined in the individual standards are designed to enable communication based on this principle. The basic idea is to combine two or more medical devices into one system so that the components can understand and influence each other.
The agent is the part of the principle that is connected to the medical device or devices. He is the data provider. The manager keeps a copy of the agent's data, reacts to update events of the same or triggers events on the agent. In most use cases, the manager will, in the broadest sense, be a remote monitor for viewing the data. However, the agent can also be controlled by the manager. As can be seen in the figure above, the agent and manager are structured in the same structure. This enables an agent to act as a manager and vice versa. In addition to the pure agent manager application, hybrid systems over several levels are also conceivable.
In the following, the individual modules and how they work are explained using the illustration above.
Agent Application Process (es)
This module creates the interface between a proprietary (possibly native) protocol and the VITAL object world. The interface is not defined within the standard and can therefore be freely implemented.
MDIB (Medical Data Information Base)
The MDIB can be compared remotely with an object-oriented database. MMOs (Managed Medical Objects) are hierarchically arranged in a tree structure in the form of a DIM (Domain Information Model) within the MDIB. The MMOs are defined within the standard, and the arrangement in the DIM is also fixed. The implementation of the MDIB with its required functions is not subject to the standard.
ACSE (Association Control Service Element)
This module is subject to the ISO / IEC 15953 and ISO / IEC 15954 standards. It has services that control connection establishment and termination. So only one possible connection or its status is negotiated. No MMOs are transmitted via this module.
CMDISE (Common Medical Device Information Service Element)
This module provides services that enable the data exchange of MMOs (Managed Medical Objects) between agent / manager systems. This data exchange is highly dynamic. Objects can be created, changed or deleted using the CREATE, UPDATE, DELETE services. Using reports that can be defined in detail down to the individual object attribute, it is possible to use these services to trigger complex operations in the agent or manager.
Presentation Layer (not in the picture)
This layer takes over the coding of the object data. Objects, groups of object attributes or individual attributes are coded in ASN.1 representation or the specialization MDER (Medical Device Encoding Rules).
Session Layer (not in the picture)
This layer controls the connection establishment at 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 are defined which contain vital data. The model also contains objects that contain additional services related to vital data objects.
In order to structure the objects in terms of content, they were divided into packages.
Medical Package
This is the central package for mapping vital data in the standard. Objects are defined in it in which vital data of various kinds can be stored. An example is the RealTimeSampleArray, which is used for managing z. B. ECG data can be used.
Alert Package
This relatively small package was created within the Medical Package. It is used to set and manage alarms or alarm parameters on objects from the medical package.
System Package
A representation of a medical device can be achieved with objects of this package. It includes specific derivations of the abstract MDS object (Medical Device System). One of these concrete derivations always forms the root object of a DIM tree. To further illustrate this package, the battery and the clock object are mentioned. The latter can be used to time-synchronize the data of a medical device.
Control Package
Objects for remote control of a medical device are defined in the control package. There are objects that only influence the type of measurement (e.g. the SetRangeOperation object) and objects that can be used directly to control the device (e.g. the ActivateOperation object).
Extended Services Package
Contrary to what the name suggests, this package defines fundamental and always necessary objects. This package consists of so-called scanner objects in a wide variety of derivatives. The purpose of these objects is to scan data in other objects and to generate event reports that can then be sent. These objects have a wide range of attributes (e.g. scan interval), which enables the objects to be used widely in the DIM. One example is the FastPeriCfgScanner object (Fast Periodic Configurable Scanner), which is specially designed for the requirements of real-time data transmission from e.g. B. ECG data was cut from a RealTimeSampleArray.
Communication Package
The objects of this package contain information that should enable basic communication. This package was designed so openly that different communication profiles and interfaces to the proprietary device interfaces can be set up. Author's note: From a historical point of view, the standard was first developed in the early 1990s, this package is definitely worth revising. From my point of view, this package was developed to enable direct communication between two end devices, including the RS232 interface that was most common at the time.
Archival Package
With the objects of the Archival Package, patient-related data can be saved in an online or in an offline archive. For example, vital data, demographic data and treatment data of a patient can be saved in one object via the Patient Archive object.
Patient Package
The Patient Package contains only one object, the Patient Demographics object. It contains patient-related data. It can be docked to an MDS object or one of the archive objects in order to establish anonymous data on the patient.
Communication model
Since the entire communication process is quite complex, this short summary only deals with it in principle. Detailed information is specified in the relevant standard and can be read there.
Finite State Machine (FSM)
The finite state machine regulates the synchronization of an agent-manager system via various states. A complete round trip of a session starts with the disconnected state, goes over several stages to the initialized state, in which the actual data exchange can take place, and ends in the disconnected state.
MDIB initialization
The status configuring is reached during the association phase. In this state, the agent and manager exchange object data for the first time. An MDS create event is triggered in the form of a report, which in the manager causes a copy of the MDS root object from the agent MDIB to be created in the manager MDIB. A context scanner object is then created in the agent. This object generates a report which contains the complete representation of the agent MDIB as content. The manager evaluates this report and maps the agent's MDIB. At this point, the manager keeps an exact copy of the agent MDIB. Both are now in the Configured status.
Data exchange via services
CMDISE offers the GET service to deliver data that has been requested by a manager. The GET service in the agent receives a list of attribute IDs that identify unique values within the agent MDIB. A report is generated in the agent containing the required values. This report is sent back to the manager.
Data exchange via scanner
Additional objects in an MDIB can be created using the CREATE service of the CMDISE. The manager requests the agent via this service to create a scanner object in the agent and to fix it to one or more values. Optionally z. B. the scan interval in which the data are to be delivered can be selected. The agent creates the scanner object in its MDIB and informs the manager of this via a response message. The manager then creates a copy of the scanner object in its MDIB. The update of the data from the agent to the manager is now done automatically via the scanner object. This scanner object, like all other objects, can be removed again via the DELETE service from CMDISE.
glossary
ACSE | Association Control Service Element |
ASN.1 | Abstract Syntax Notation One |
CMDISE | Common Medical Device Information Service Element |
DIM | Domain Information Model |
FSM | Finite State Machine |
MDER | Medical Device Encoding Rules |
MDIB | Medical Data Information Base |
MDS | Medical Device System |
MMO | Managed Medical Object |