ISO/IEEE 11073
Bereich	Medizinische Informatik
Titel	Kommunikation patientennaher medizinischer Geräte (diverse Teile)
Kurzbeschreibung:	Datenaustausch zwischen medizinischen Geräten
Teile	Siehe Veröffentlichte Normen
Letzte Ausgabe	Siehe Veröffentlichte Normen
Nationale Normen	EN ISO 11073, DIN EN ISO 11073, ÖNORM EN ISO 11073, SN EN ISO 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.

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

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.

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

#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 */

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

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.

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.

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.

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.

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.

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.

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.

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

Dieser Layer kontrolliert den Verbindungsaufbau auf Sessionebene.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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