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

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

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

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.

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.