ISO/IEEE 11073
# ISO/IEEE 11073

Die Normenfamilie ISO/IEEE 11073 definiert die Bestandteile eines Systems, mit dem es möglich ist, Vitaldaten zwischen unterschiedlichen medizinischen Geräten auszutauschen, auszuwerten und die Geräte fernzusteuern. Die Teile 10101, 10201, 20101, 30200 und 30300 liegen auch als DIN-Normen DIN EN ISO 11073 vor.

## Veröffentlichte Normen

| 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 analyser |
| ISO/IEEE 11073-10424:2016 | Health informatics – Personal health device communication – Part 10424: Device specialization – Sleep apnoea 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 – Independant 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 |

Dabei sind die relevanten Kernnormen:

* ISO/IEEE 11073-10101
* ISO/IEEE 11073-10201
* ISO/IEEE 11073-20101 und
* ISO/IEEE 11073-30200

## Entwürfe (Drafts)

Neben den veröffentlichten Normen sind derzeit eine große Anzahl (ca. 20) Drafts zur Erweiterung des Standards, vor allem für gerätespezifische Profile, vorgesehen. Diese Entwürfe stammen in ihrer aktuellen Version aus dem Jahr 2008.

## Übersicht über die Kernnormen

### ISO/IEEE 11073-10101 Nomenclature

Innerhalb dieser Norm werden Nomenklaturcodes festgelegt mit denen sich später, im Zusammenhang mit dem sogenannten OID-Code, Objekte und Attribute eindeutig identifizieren lassen. Die Nomenklatur ist dabei in sogenannte Partitionen unterteilt, die eine funktionale bzw. inhaltliche Abgrenzung der Codes ermöglichen. Programmatisch werden diese Codes als Konstanten definiert und können über ein Pseudonym im Programm genutzt werden. Beispiel in C++:

Die programmatische Umsetzung dieser Norm ist simpel, da sie nur aus diesen Definitionen besteht.

### ISO/IEEE 11073-10201 Domain Information Model

Diese Norm ist das „Herzstück“ von VITAL. In ihr werden Objekte zur Vitaldatenübertragung und ihre Anordnung in einem Domain Information Model definiert. Weiterhin legt diese Norm ein Service Model zur Kommunikation fest. Eine weitergehende Dokumentation dieser Norm befindet sich in den Punkten 3 und 4 dieses Dokuments.

### ISO/IEEE 11073-20101 Base Standard

Diese Norm legt die allgemeinen Grundlagen für die Übertragung und den Aufbau von Objekten und ihren Attributen. Sie unterteilt sich in das Communication Model und das Information Model. Dabei beschreibt das Communication Model die Layer 5 bis 7 des OSI-7Schicht-Modells und das Information Model die Modellierung, Formatierung und die Syntax zur Übertragungscodierung der Objekte. Auf diese Modelle wird in den Punkten 3 und 5 dieses Dokuments eingegangen.

## Agent/Manager-Prinzip

Alle in den einzelnen Standards definierten Teile sind dazu ausgelegt, eine Kommunikation nach diesem Prinzip zu ermöglichen. Die grundsätzliche Idee dabei ist, zwei oder mehr medizinische Geräte zu einem System zusammenzufassen, so dass sich die Komponenten gegenseitig verstehen und beeinflussen können.

Dabei ist der Agent der Teil des Prinzips, welcher an dem bzw. den medizinischen Geräten angeschlossen ist. Er ist der Daten-Provider. Der Manager hält eine Kopie der Daten des Agents, reagiert auf Update-Events desselben oder löst Events auf dem Agent aus. In den meisten Anwendungsfällen wird der Manager im weitesten Sinne ein Remote-Monitor zum Anzeigen der Daten sein. Aber auch eine Steuerung des Agents durch den Manager ist möglich. Wie in der oberen Abbildung zu sehen, sind Agent und Manager in der gleichen Struktur aufgebaut. Dies ermöglicht es einem Agent auch als Manager tätig zu sein und umgekehrt. Neben der reinen Agent-Manager Anwendung sind somit auch Hybrid-Systeme über mehrere Stufen denkbar.

Im Weiteren werden die einzelnen Module und ihre Funktionsweisen anhand der obigen Abbildung erläutert.

### Agent Application Process(es)

Dieses Modul stellt das Interface zwischen einem proprietären (evtl. nativen) Protokoll und der VITAL-Objektwelt her. Das Interface ist nicht innerhalb des Standards definiert und kann damit frei implementiert werden.

### MDIB (Medical Data Information Base)

Die MDIB kann man entfernt mit einer objektorientierten Datenbank vergleichen. MMOs (Managed Medical Objects) werden in Form eines DIM (Domain Information Models) innerhalb der MDIB hierarchisch in einer Baumstruktur angeordnet. Die MMOs sind innerhalb der Norm definiert, auch die Anordnung im DIM steht fest. Die Implementierung der MDIB mit ihren benötigten Funktionen unterliegt nicht dem Standard.

### ACSE (Association Control Service Element)

Dieses Modul unterliegt den Standards ISO/IEC 15953 und ISO/IEC 15954. Es verfügt über Services, die den Verbindungsaufbau und -abbau kontrollieren. Es wird also nur eine mögliche Verbindung bzw. ihr Zustand ausgehandelt. Über dieses Modul werden keine MMOs übertragen.

### CMDISE (Common Medical Device Information Service Element)

Dieses Modul stellt Services bereit, die den Datenaustausch von MMOs (Managed Medical Objects) zwischen Agent/Manager-Systemen ermöglichen. Dieser Datenaustausch gestaltet sich dabei hochdynamisch. Über die Services CREATE, UPDATE, DELETE können Objekte erzeugt, verändert oder gelöscht werden. Über Reports die bis zum einzelnen Objektattribut detailliert definiert werden können, ist es möglich über diese Services komplexe Operationen im Agent oder Manager auszulösen.

### Presentation Layer (nicht im Bild)

Dieser Layer übernimmt die Kodierung der Objektdaten vor. Kodiert werden Objekte, Gruppen von Objektattributen oder einzelne Attribute in ASN.1 Repräsentation bzw. der Spezialisierung MDER (Medical Device Encoding Rules).

### Session Layer (nicht im Bild)

Dieser Layer kontrolliert den Verbindungsaufbau auf Sessionebene.

## DIM (Domain Information Model)

Der zentrale Kern der Norm ist das sogenannte Domain Information Model. In diesem Modell werden Objekte und ihre Abhängigkeiten definiert die Vitaldaten enthalten. Weiterhin enthält das Modell Objekte, die zusätzliche Services rund um die Vitaldatenobjekte enthalten.

Zur inhaltlichen Gliederung der Objekte wurden diese in Packages unterteilt.

### Medical Package

Dies ist das zentrale Paket für die Abbildung von Vitaldaten im Standard. In ihm sind Objekte definiert in denen Vitaldaten unterschiedlichster Art gespeichert werden können. Als Beispiel sei das RealTimeSampleArray genannt, das für die Verwaltung von z. B. EKG-Daten genutzt werden kann.

### Alert Package

Dieses relativ kleine Paket wurde innerhalb des Medical Package angelegt. Es dient zum Setzen und Verwalten von Alarmen bzw. Alarmparametern an Objekten aus dem Medical Package.

### System Package

Mit Objekten dieses Package kann eine Repräsentation eines medizinischen Gerätes erreicht werden. Zu ihm gehören konkrete Ableitungen des abstrakten MDS-Objektes (Medical Device System). Eine dieser konkreten Ableitungen bildet immer das Rootobjekt eines DIM-Trees. Zur weiteren Veranschaulichung dieses Packages seien das Battery und das Clock Objekt genannt. Letzteres kann zur Zeit-Synchronisation der Daten eines Medical Device benutzt werden.

### Control Package

Im Control Package werden Objekte zur Remotekontrolle eines medizinischen Gerätes definiert. Dabei gibt es Objekte, die nur die Art und Weise einer Messung beeinflussen (z. B. das SetRangeOperation Objekt) und Objekte die direkt zur Steuerung des Gerätes genutzt werden können (z. B. das ActivateOperation Objekt).

### Extended Services Package

Anders als der Name vermuten lässt, werden in diesem Paket durchaus grundlegende und immer notwendige Objekte definiert. Dieses Package besteht aus sogenannten Scanner Objekten in unterschiedlichsten Ableitungen. Sinn dieser Objekte ist es, Daten in anderen Objekten zu scannen und Event-Reports zu generieren, die dann versendet werden können. Dabei verfügen diese Objekte über unterschiedlichste Attribute (z. B. Scanintervall), was einen breiten Einsatz der Objekte im DIM ermöglicht. Als Beispiel sei hier das FastPeriCfgScanner Objekt (Fast Periodic Configurable Scanner) genannt, das speziell auf die Anforderungen der Realtime-Datenübertragung von z. B. EKG-Daten aus einem RealTimeSampleArray zugeschnitten wurde.

### Communication Package

Die Objekte dieses Packages enthalten Informationen die eine grundlegende Kommunikation ermöglichen sollen. Dieses Package wurde so offen gestaltet, dass unterschiedliche Kommunikationsprofile und Schnittstellen zu den proprietären Device Interfaces aufgebaut werden können. Anmerkung des Autors: Aus geschichtlicher Sicht, die Norm wurde erstmals Anfang der 90er Jahre entwickelt, ist dieses Package durchaus überarbeitungswürdig. Aus meiner Sicht ist dieses Package entwickelt worden, um eine direkte Kommunikation zwischen zwei Endgeräten, unter Einbindung der damals am häufigsten auftretenden RS232 Schnittstelle zu ermöglichen.

### Archival Package

Mit den Objekten des Archival Package lassen sich patientenbezogene Daten in einem Online- oder in einem Offline-Archiv speichern. Zum Beispiel lassen sich über das Patient Archive Objekt Vitaldaten, demographische Daten und Behandlungsdaten eines Patienten, in einem Objekt speichern.

### Patient Package

Das Patient Package enthält nur ein Objekt, das Patient Demographics Objekt. Es enthält patientenbezogene Daten. Es kann an ein MDS Objekt, oder eines der Archiv Objekte angedockt werden, um den Bezug von anonymen Daten zum Patienten herzustellen.

## Kommunikationsmodell

Da der komplette Kommunikationsvorgang recht komplex ist, wird in diesem Short Summary nur grundsätzlich darauf eingegangen. Detaillierte Informationen sind in der entsprechenden Norm festgelegt und können dort nachgelesen werden.

### Finite State Machine (FSM)

Die Finite State Machine regelt die Synchronisation eines Agent-Manager-Systems über verschiedene Zustände. Ein kompletter Roundtrip einer Session startet mit dem Disconnected-State, geht über mehrere Stufen zum Initialized-State, in welchem der eigentliche Datenaustausch stattfinden kann und endet im Disconnected-State.

### MDIB Initialisierung

Während der Association Phase wird der Status Configuring erreicht. In diesem Zustand tauschen Agent und Manager erstmals Objektdaten aus. Dabei wird ein MDS Create Event in Form eines Reports ausgelöst, der im Manager dazu führt, dass eine Kopie de MDS-Root-Objektes aus der Agent-MDIB in der Manager MDIB angelegt wird. Anschließend wird im Agent ein Context Scanner Objekt erzeugt. Dieses Objekt generiert einen Report, der als Inhalt die komplette Repräsentation der Agent-MDIB enthält. Der Manager wertet diesen Report aus und bildet die MDIB des Agents ab. Zu diesem Zeitpunkt hält der Manager eine exakte Kopie der Agent-MDIB. Beide befinden sich jetzt im Status Configured.

### Datenaustausch über Services

CMDISE bietet den GET-Service um Daten die von einem Manager angefordert wurden zu liefern. Der GET-Service im Agent bekommt dabei eine Liste von Attribut-IDs übergeben, die eindeutige Werte innerhalb der Agent-MDIB identifizieren. Im Agent wird ein Report erzeugt, der die gewünschten Werte enthält. Dieser Report wird zurück an den Manager gesendet.

### Datenaustausch über Scanner

Zusätzliche Objekte in einer MDIB können über den CREATE-Service des CMDISE erzeugt werden. Der Manager fordert also den Agent über diesen Service auf, ein Scanner-Objekt im Agent anzulegen und auf einen oder mehrere Werte zu fixieren. Optional kann z. B. noch das Scanintervall, in welchem die Daten zu liefern sind, gewählt werden. Der Agent erzeugt das Scanner Objekt in seiner MDIB und teilt dies dem Manager über eine Response Message mit. Der Manager legt darauf eine Kopie des Scanner Objektes in seiner MDIB an. Die Aktualisierung der Daten vom Agent zum Manager erfolgt nun automatisiert über das Scanner Objekt. Über den DELETE-Service von CMDISE kann diese Scanner Objekt, wie alle anderen Objekte auch, wieder entfernt werden.

## Glossar

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