34

Kapitel 3. Methodik

Die Analyse der im Kapitel 2 Aufgabenstellung gestellten Anforderungen ergab, daß der Kern der Lösung in der Erhaltung der Semantik der Informationen liegen muß. Das ist die wichtigste Anforderung, die bisher wenig beachtet wurde. Die übrigen Anforderungen wie Sicherheit, Plattformunabhängigkeit, etc. sind in der Regel allgemein bekannt. Sie lassen sich mit einigem Bemühen unter Zuhilfenahme von vorhandenen technischen und/oder organisatorischen Hilfsmitteln ohne weiteres erfüllen.

Da die Semantik der Informationen in erster Linie vom Sende- und Empfängersystem, also den beteiligten Subsystemen, abhängt, müssen alle Anstrengungen darauf konzentriert sein, eine optimale Art und Weise der Kommunikation zu finden. Ausgehend von diesem Kerngedanken wird ein Lösungsrahmen festgelegt. Anschließend wird die Philosophie des Zielsystems definiert. Darauf aufbauend wird die beim Entwurf verwendete Philosophie spezifiziert. Dies bildet die Vorgabe für die Konzeptionsarbeiten, deren Ergebnisse sich im Kapitel 4 Ergebnisse in einer speziellen Lösung niederschlagen.

3.1. Lösungsrahmen

Da der Schwerpunkt der vorliegenden Arbeit im Austausch medizinischer Informationen liegt, spielen die medizinischen Subsysteme die Hauptrolle. Diese werden jedoch auf unterschiedlichste Art und Weise beschafft und eingesetzt. Man kann hier keine Vorschrift erlassen, wie ein Subsystem konstruiert werden muß. Ferner muß in einem großen Universitätsklinikum, in dem führende medizinische Forschungen betrieben werden, immer damit gerechnet werden, daß nicht nur neue, sondern auch neuartige medizinische Software eingesetzt wird, die nicht in den eventuell vom Klinikum vorgegebenen Rahmen paßt. Adelhard, K., et al. hat 1995 ein Konzept veröffentlicht, das eine Integration von neuen Methoden und Konzepten zuließ [2] . Walker, A. stellte ebenfalls fest, daß jedes Subsystem seine Eigenheiten besitzt [84] .

Ein Standard für medizinischen Informationsaustausch muß die Existenz solcher Software berücksichtigen und sich daher auf den Informationsaustausch beschränken. Dieser Standard darf das innere Verhalten der Subsysteme nicht vorschreiben. Für die Funktionsfähigkeit eines auf diesem Standard basierenden Systems muß einzig die Fähigkeit, Informationen auf semantischer Ebene auszutauschen, entscheiden, ob ein Subsystem angeschlossen wird.

Die Hauptstrategie bei der Entwicklung eines solchen Standards muß aus diesen Gründen darin bestehen, daß die weiterhin autonom arbeitenden Subsysteme kommunikationsfähiger werden. Hierbei ist es unerheblich, wie ein Subsystem kommunikationsfähiger gemacht wird. Es kann von Hause aus, beispielsweise durch eine Neukonzeption (nativ) oder einfach durch den Einsatz eines Adapters (adaptiv) die Kommunikationsfähigkeit erhalten.

Weiterhin darf der Standard nicht versuchen, alles zu regeln. Er sollte lediglich einen Rahmen für die Kommunikation zur Verfügung stellen. Wie die Daten schließlich interpretiert werden, müssen die Subsysteme untereinander ausmachen. Somit kann der Standard beispielsweise von der Entwicklung anderer Standards wie HL7, DICOM, SNOMED, etc. , die mit sehr hohem Aufwand von sehr vielen Fachleuten erarbeitet worden sind, abgekoppelt werden. Beispielsweise können sich zwei

35

Subsysteme im Rahmen des Standards verständigen und reine HL7-Daten oder DICOM-Bilder austauschen.

Zusammengefaßt läßt sich die Lösungsstrategie durch folgende Punkte beschreiben:

• Die Subsysteme kommunizieren miteinander auf eine tolerantere Art und Weise. Wenn beispielsweise zwei Subsysteme miteinander Daten austauschen und dabei eventuelle Inkompatibilitäten feststellen, müssen sie versuchen, die möglicherweise vom Empfänger benötigten Informationen auf einer niedrigere Semantikebene zu übertragen.
• Diese Toleranz in der Kommunikation muß über verschiedene Grenzen hinweg funktionieren. Es sind erstens die Grenze zwischen den medizinischen Fachbereichen wie Geburtshilfe/Pathologie oder Geburtshilfe/Neonatologie, zweitens die Diskrepanz zwischen den Systemplattformen und drittens die zwischen den verschiedenen Sprachen zu beachten.
• Im ersten Schritt ist damit zu rechnen, daß die meisten Subsysteme keine native Fähigkeit zu kommunizieren mit sich bringen. In diesem Fall wird das Subsystem einfach durch die sogenannte Verpackungstechnik (Wrapping) dazu fähig gemacht.

3.2. Systemphilosophie

Die Systemphilosophie bestimmt, in welche Richtung die Architektur des Systems und des Standards gehen sollen und ob das System z. B. monolithisch oder verteilt sein soll. Die Systemphilosophie basiert auf folgenden Prinzipien:

• Der Standard beschränkt sich auf den Austausch der medizinischen Daten zwischen den medizinischen Subsystemen bzw. zwischen einem medizinischen Subsystem und einem administrativen Subsystem.
• Der Standard legt ein Netz fest. An jedem Knoten des Netzes wird ein medizinisches Subsystem über einen sogenannten virtuellen Befundtreiber angeschlossen. Administrative Informationen werden über HL7 ausgetauscht.
• An vorhandenen Subsystemen wird, abgesehen vom Anschluß eines virtuellen Befundtreibers, nichts geändert. Jedes Subsystem kann sehr proprietär sein. Wenn es jedoch über den Treiber an das Netz angeschlossen werden kann, so ist es aus der Sicht des Netzes ein Lieferant von Informationen für das Netz, also für die restlichen Netzbenutzer. Es kann ebenfalls Informationen aus dem Netz beziehen und dem lokalen Anwender zur Verfügung stellen. Jedes Subsystem ist für den Teil verantwortlich, für den es konstruiert worden ist.
• Es entsteht somit ein Netz von kooperierenden Subsystemen, das sogenannte virtuelle Befundsystem.
• Die medizinische Semantik wird durch zwei Maßnahmen gewährleistet. Die erste besagt, daß der verantwortliche Knoten für die Interpretation und Darstellung des Inhaltes sorgt, denn er ist der Knoten, der mit der Semantik des betroffenen Objekts am besten umgehen kann. Die zweite Maßnahme umfaßt die Definition eines medizinischen Kontextes. Jeder Knoten stellt seinen Kontext zur Verfügung. Wird ein Objekt aus einem bestimmten Kontext in einen anderen importiert, so kann an Hand der Kontexte geprüft werden, ob ein Austausch ohne Semantikverlust vorgenommen werden kann. Wenn nicht, werden die Informationen als reiner Text bzw. reine Graphik übertragen.

36

• Das vorhandene Netzwerk wird benutzt. Standardprotokoll ist HTML/XML in einer Internet-Struktur: TCP/IP, Domain Name Service.
• Das Konzept ist objekt-orientiert, so daß die Objekte eine Reihe von standardisierten Operationen selbst bieten, mit denen ein Client das Objekt erzeugen, manipulieren und wieder löschen kann. Jedes Objekt ist weltweit eineindeutig identifizierbar. Hierfür wird das DNS-Konzept (Domain Name Service) erweitert und das allgemeine Objektkonzept entwickelt [3] .
• Der größte Teil der notwendigen Software wird nur einmal entwickelt und kann dann in allen Einrichtungen durch Anpassung in Betrieb genommen werden. In den jeweiligen Einrichtungen muß lediglich die Anpassung in Form des virtuellen Befundtreibers für den Anschluß des Subsystems vorgenommen werden.
• Im ersten Schritt wird davon ausgegangen, daß die medizinischen Subsysteme Informationen für ein virtuelles Befundsystem liefern. Eine Veränderung der medizinischen Subsysteme durch das virtuelle Befundsystem wird erst im nächsten Schritt geplant und ist nicht Teil dieser Arbeit.

3.3. Entwurfsphilosophie

Die Entwurfsphilosophie bestimmt die Eckpunkte des Systementwurfs. Beispielsweise soll hier der Systementwurf objekt-orientiert erfolgen. Die Hauptphilosophie des Entwurfs ist die Objektorientierung. Bereits 1989 hat Barsalou, T., ein Konzept veröffentlicht, das die Modellierung von Objekten in relationalen Datenbanken beinhaltete [5] . Neben diesem objekt-orientierten Konzept umfaßt die Entwurfsphilosophie folgende Teilkonzepte:

• ein allgemeines Objektkonzept,
• einen medizinischen Kontext,
• einen virtuellen Namensraum und
• ein Transaktionskonzept.

3.4. Das allgemeine Objektkonzept

3.4.1. Motivation

Im vorangegangenen Abschnitt ist ein Überblick über die wichtigsten Objekte des Konzepts gegeben worden. Dort wurden ihre Merkmale - ihre Semantik - erläutert. Diese Objekte haben voraussichtlich sehr viele verschiedene Eigenschaften. Ein Versuch, diese Eigenschaften in einer Datenbank oder in einer Objektstruktur zu strukturieren, scheint kein gangbarer Weg zu sein. Ein Beleg hierfür sind die langjährigen und schwierigen Standardisierungsbemühungen in HL7, DICOM, SNOMED, etc. Hinzu kommen die laufenden Änderungen, die in diesen langwierigen Prozessen integriert werden müssen.

Aus diesem Grund muß ein Objektkonzept entwickelt werden, das einen einfachen Mechanismus für die Handhabung und Änderungen von umfangreichen Merkmalen besitzt.

Das so definierte Objektkonzept bringt folgende Vorteile:

• Eine autonome Existenz von Objekten in den Subsystemen ist möglich. Dies erlaubt die getrennte Entwicklung von Knoten.
• Änderungen an einem Objekt im Netz können durchgeführt werden, ohne daß an benachbarten Subsystemen Update- bzw. Upgrade-Arbeiten gemacht werden müssen.

37

• Die heute vornehmlich verwendeten Programmierwerkzeuge unterstützen das Objektkonzept von Hause aus. Die auf der PC- und UNIX-Plattform verbreitete Programmiersprache C++ - und zunehmend auch Java - ist beispielsweise objekt-orientiert.

3.4.2. Unterschied zum herkömmlichen Objektkonzept

Der Kerngedanke hierbei ist der folgende. Alle Informationen, die im Rahmen des Konzepts verwendet werden sollen, sind entweder ein Objekt oder ein Attribut eines Objekts. Ein Objekt ist eine Menge, deren Elemente Attribute sind. Ein Attribut kann wiederum ein Objekt sein (s. unten).

Objekt

Attribut 1

Attribut 2

Attribut x

Attribut n

(beliebig fortsetzbar)

Ein kleines Beispiel verdeutlicht den Unterschied zwischen diesem allgemeinen und dem herkömmlichen Objektkonzept. Wir betrachten im folgenden das Objekt Patient. Im herkömmlichen Konzept würde ein Entwurf wie folgt aussehen:

Patient

Familienname = Mustermann

Vorname = Angelika

Geburtsname = Testmann

Geburtsort = Deutschland

Geburtsdatum = 1.1.1900

Nationalität = DE

Das Objekt Patient im allgemeinen Objektkonzept würde wie folgt konstruiert sein:

Object: Class = Patient

Attribute: Name = Familienname; Type = Text; Value = Mustermann

Attribute: Name = Vorname; Type = Text; Value = Angelika

Attribute: Name = Geburtsname; Type = Text; Value = Testmann

Attribute: Name = Geburtsort; Type = Text; Value = Deutschland

Attribute: Name = Geburtsdatum; Type = ShortDate; Value = 1.1.1900

Attribute: Name = Nationalität; Type = NationalCode; Value = DE

Aus den 6 verschiedenen Attributen (Familienname bis Nationalität) sind 6 Einträge von einem Typ Attribute geworden. Ein Empfängersystem würde mit der zweiten Varianten weniger Probleme haben, selbst wenn aus Empfängersicht unbekannte bzw. unbrauchbare Attribute vorkommen. Das System kann beispielsweise ein Attribut leichter überlesen bzw. ignorieren.

Die Attribute eines Objekts werden auf eine einheitliche Art und Weise beschrieben. Somit hat das allgemeine Objektkonzept nur ein einziges Syntaxelement. Diese Konstruktion birgt folgende Vorteile:

• Sie erfüllt die Anforderung nach minimaler Syntax, da das Objekt nur aus einer Liste von Attributen besteht, gleichgültig, welchen Typs die Attribute sind.
• Die Tabellen von relationalen Datenbanken, die diese Objekte speichern sollen, können auf eine einheitliche Art und Weise aufgebaut werden. Sie haben immer die gleiche Anzahl von Spalten. In jeder Tabelle hat jede Spalte immer die gleiche Bedeutung. Die Software läßt sich damit erheblich vereinfachen. Sie kann einmal entwickelt und für alle Knoten eingesetzt werden. Die Software, die die Attribute formal bearbeitet, wird Attribute-Engine genannt. Sie stellt einen Rahmen, ein Frame-Work für das System dar.

---

38

• Die Semantik eines Objekts wird durch die Semantik der einzelnen Attribute bestimmt. Da die Liste der Attribute nicht begrenzt ist, kann hier jedes beliebige Attribut an das Objekt angehängt werden.
• Die Erweiterung eines Objekts um weitere Attribute erfolgt nur durch Hinzufügen einiger Zeilen in der Tabelle. Das bereitet der jetzigen Generation von Datenbanksystemen keinerlei Schwierigkeit.
• Somit ist die Forderung nach maximaler Semantik für den inneren Aufbau eines Objekts erfüllt. Die Forderung, daß die Semantik bei der Übertragung nicht verlorengehen darf, wird durch die Einführung des medizinischen und des Darstellungskontextes gewährleistet.

3.5. Syntax der Objektbeschreibung

Die Syntax der Objektbeschreibung basiert auf dem HTML/SGML-Standard. Im folgenden wird sie an Hand der Metaspezifikation festgelegt, wobei der Zeilenumbruch keine syntaktische Bedeutung hat. Er dient lediglich der Übersichtlichkeit.

Bei den kursiv zwischen den Spitzenklammern geschriebenen Texten handelt es sich um die zu beschreibenden Elemente. Die fettgedruckten, nicht-kursiv geschriebenen Texte sind Syntaxzeichen.

<object> ::=  <OBJECT
                 TYPE = <object_type>
                 INTERNAL-ID = <object_internal_ID>
                 EXTERNAL-ID = <object_external_ID>
                 CODEBASE = <code_base_URL>>
                 {<attribute>}
                 </OBJECT>

<attribute> ::= <ATTR
                   NAME = <attribute_name>
                   TYPE = <attribute_type>
                   VALUE = <attribute_value>
                   [UNIT = <attribute_unit>]
                   >

Ein Objekt besteht syntaktisch aus zwei Teilen, dem Objekt-Header und dem Objekt-Body. Im Header ist die Identifikation des Objekts gespeichert. Im Body sind alle anderen Objektinhalte enthalten, die durch Attribute beschrieben werden. Streng genommen läßt sich die Identifikation im Objekt-Header auch als Attribut deklarieren. In der Praxis wird ein getrennter Header die Verarbeitung beschleunigen. Zugunsten der Performance wird hier ein ”Stilbruch” begangen, in dem die wichtigsten Informationen über das Objekt im Header angesiedelt und damit eine schnelle Identifikation ermöglicht, ohne daß alle Attribute durchsucht werden müssen.

Ein Objekt wird durch die Type-ID <object_type>, und die globale ID eindeutig identifiziert. Die globale ID wird durch die interne ID <object_internal_ID> und die externe ID <object_external_ID> beschrieben. Welches Applet das Objekt primär behandeln soll, wird durch die URL-Angabe CODEBASE festgelegt.

Jedes Objektattribut wird durch ein Tupel, bestehend aus Name, Type, Value und Unit festgelegt. Sie sind beliebig wiederholbar, wobei die Einheitsangabe optional ist. Objektattribute sind beliebig schachtelbar, so daß jede Konstruktion auch rekursiv möglich ist. Ein Attribut kann beispielsweise wieder ein Objekt sein.

39

Somit kann sowohl die Forderung nach minimaler Syntax als auch die Forderung nach maximaler Semantik erfüllt werden.

Beispiel

<OBJECT TYPE=”Patient” INTERNAL-ID =”x.x.x.x:3031/4711” EXTERNAL-
ID=”4711@us.prenatal.ufk.charite.hu-berlin.de” CODEBASE=”ufk-science.charite.hu-
berlin.de/prenatal-ultrasound/patient.exe>
<ATTR NAME=”FirstName” TYPE=”Text” VALUE=”Angelika” >
<ATTR NAME=”Name” TYPE=”Text” VALUE=”Mustermann”>
<ATTR NAME=”Birthday” TYPE=”ShortDate” VALUE=”01.01.1953”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=” P 27.0”>
<ATTR NAME=”Diagnosis” TYPE=Text” VALUE=” singuläre Umbilikalarterie”>
<ATTR NAME=”Object” TYPE=”Reference” VALUE=”9876543421”>
<ATTR NAME=”Histology” TYPE=”Img” VALUE=”http://www.ufk.prenatal.charite.de/prenatal-
db/images/1111111.tif”>
</OBJECT>

3.6. Der medizinische Kontext

3.6.1. Zweck des medizinischen Kontextes

Jedes Subsystem behandelt ein anderes medizinisches Fachgebiet, hat in der Regel andere Ziele, nutzt deshalb andere Methoden und andere Terminologie. Diese Unterschiede müssen beim Datenaustausch berücksichtigt werden. Beispielsweise fokussiert der Geburtshelfer bei der Betrachtung des Ultraschallbildes einer Schwangeren auf mögliche Herz- und Lungenanomalien des Fetus. Der Urologe kann beim gleichen Bild seinen Blick auf die zusammengequetschte Harnblase konzentrieren. Die Untersuchungsverfahren der beiden Mediziner unterscheiden sich ebenfalls.

Beim Zusammenführen bzw. Austauschen dieser Informationen sorgt der medizinische Kontext verantwortlich für die korrekte Übertragung und Interpretation. Beim Versenden von Informationen von einem Subsystem zum anderen wird der medizinische Kontext des Sendesystems mitgeschickt. Beim Empfangen werden die Informationen an Hand des Quellkontextes und des Zielkontextes interpretiert. Man reißt somit die Daten nicht aus dem Zusammenhang und sie verlieren nicht ihre Bedeutung. Zudem wird ihre Bedeutung auch nicht verfälscht.

Das Konzept des medizinischen Kontextes basiert auf einem vielfach für hardware-unabhängige Gerätetreiber verwendeten Konzept. Hier wird ein sogenannter Device-Context verwendet, mit dessen Hilfe die Fähigkeiten eines Geräts auf einem hohen Abstraktionsniveau beschrieben werden.

Um den modifizierten Kontext zu bewahren, muß man für jedes Subsystem einen Kontext spezifizieren, der das Arbeitsgebiet des betroffenen Subsystems beschreibt. Der Kontext muß Informationen über die Patientengruppe enthalten, mit der das Subsystem arbeitet, über die Methoden, die im Subsystem benutzt werden, über die physikalischen Randbedingungen (constrains), die im Subsystem gelten, sowie weitere Parameter für die Systembeschreibung wie Organe, Funktionssysteme, etc. Ein Diagnosesystem für die pränatale Diagnostik kann beispielsweise mit folgendem Parametersatz versehen sein:

Patient:	Weiblich
Alter:	zwischen 10 und 50
Organ:	Plazenta, Vagina, Fetus, etc.
Methoden:	2D-Sono, 3D-Farbdoppler.

In der Fetalpathologie wird der Kontext z. B. folgende Einträge haben:

Patient1:

Weiblich

40 Alter:	zwischen 10 und 50
Organe:	Plazenta
Methoden:	Makroskopie, Mikroskopie, etc.
Patient2:	Fetus
Alter:	zwischen 10 und 45 Schwangerschaftswochen
Organe:	Alle
Methoden:	Makroskopie, Mikroskopie, etc.

Es ist hier ersichtlich, daß der Fetus bei der pränatalen Diagnostik nicht als Patient fungiert, bei der Fetalpathologie wird es jedoch als eigenständiger ”Patient” betrachtet. Ebenfalls wechselt die Methode von Sonographie in Makroskopie und Mikroskopie.

3.6.2. Struktur des medizinischen Kontextes

Die Struktur eines medizinischen Kontextes ist ähnlich wie die eines Objekts. Ein medizinischer Kontext ist ebenfalls eine Menge, deren Elemente Attribute sind. Diese beschreiben den medizinischen Kontext und somit das medizinische Subsystem. Hierbei lassen sich die Attribute in Gruppen zusammenfassen. Eine Gruppe von Gruppen ist ebenfalls möglich.

Einige Schlüsselwörter mit vordefinierter Bedeutung sind:

VALUE= ”don’t care”	Das Attribut muß vorhanden sein, dessen Wert spielt jedoch keine Rolle
MATCH=”yes”	Das Attribut wird zum Matchen benötigt
MATCH=”no”	Das Attribut wird zum Matchen nicht verwendet

3.6.3. Kontextwechsel

Der Übergang von einem Subsystem zum anderen wird durch den Kontextwechsel begleitet. Beim Kontextwechsel wissen die Subsysteme anhand der Parameter, wie das gleiche Attribut nun anders interpretiert und dargestellt werden muß, um im neuen Kontext einen Sinn zu geben. Diese Arbeitsweise ist semantik-orientiert.

Wird ein Objekt von einem Empfängersystem erneut weitergegeben, so wird der Originalkontext mitgegeben.

3.6.4. Eigenschaften medizinischer Kontexte

Es sei x ein Objekt aus dem Sendesystem mit dem medizinischen Kontext md1. Das im Empfängersystem mit dem medizinischen Kontext md2 ankommende Objekt sei x’. Die Transformation f wandelt Objekt x in x’ um:

Die Transformation f soll folgende Eigenschaften aufweisen:

Identische Transformation

Verlustfreie und verlustbehaftete Transformation

Um festzustellen, ob eine Transformation verlustfrei ist, kann eine Loop-Transformation Ln (x) vorgenommen werden.

41

oder

Eine Transformation ist verlustfrei, wenn nach einer beliebigen Anzahl von Loops folgendes gilt:

Ist eine Transformation verlustbehaftet, so gilt:

Nach einer beliebigen Anzahl von Loops muß das Objekt vollständig im Ursprungsobjekt enthalten sein oder:

Asymptotisches Verhalten

Nach einer beliebigen Anzahl von Loops darf das Objekt nicht verschwinden, sondern muß gegen eine Asymptote streben. Diese Asymptote ist die Untergrenze in der Erhaltung der Semantik. Ist eine Transformation verlustbehaftet, so müssen die Attribute in Primitiva (z. B. ASCII-Text) umgewandelt werden, falls das Empfängersystem diese nicht behandeln kann. Da jedes Subsystem die Primitiva behandeln können muß, dürfen sie nicht verlorengehen.

Da ein Objekt als eine Menge von Attributen definiert ist, kann für jedes Objekt die Mächtigkeit m (x) bestimmt werden. Für die Transformation medizinischer Kontexte wird gefordert:

3.6.5. Kontext-Matching

Mit dem medizinischen Kontext und dem damit verbundenen Verhalten können die Subsysteme die von einem anderen Subsystem geschickten Informationen auf eine einheitliche Art und Weise filtern. Dies geschieht an Hand der oben beschriebenen Transformation. Sie bedient sich des folgenden Matching-Algorithmus’.

Das Matching wird einfach durch eine Durchschnittsbildung vorgenommen. Es seien md1 der medizinische Kontext des Senders und md2 der des Empfängers. Die Menge md wird durch die Operation:

gewonnen. Ist md eine leere Menge, so hat der Empfänger keine Gemeinsamkeit mit dem Sender. Der Empfänger benötigt keine Information vom Sender. Ist md dagegen nicht leer, so kann der Empfänger md verwenden, um die in md enthaltenen Objekte und deren Attribute beim Anfordern der Information zu filtern.

Eine dynamische Generierung und/oder Anpassung von medizinischen Kontexten zur Laufzeit, beispielsweise für temporäre statistische Studien, ist ebenso denkbar wie erforderlich.

42

3.6.6. Syntax der Kontextbeschreibung

Die Syntax der Kontextbeschreibung basiert auf dem HTML/SGML-Standard. Im folgenden wird sie an Hand der Metaspezifikation festgelegt, wobei der Zeilenumbruch keine syntaktische Bedeutung hat. Er dient lediglich der Übersichtlichkeit.

Bei den kursiv zwischen den Spitzenklammern geschriebenen Texten handelt es sich um die zu beschreibenden Elemente. Die fettgedruckten, nicht-kursiv geschriebenen Texte sind Syntaxzeichen.

Der medizinische Kontext ist eine einfache Liste von Attributen, die auch gruppiert werden können. Bis auf den Parameter MATCH sind alle anderen bereits in der Objektbeschreibung bekannt. MATCH gibt an, ob die Gruppe bzw. das Attribut beim Kontext-Matching verwendet werden soll. Beispielsweise wird das Attribut Patient immer, das Attribut Organ oft, das Attribut Methode in der Regel jedoch nicht zum Matchen verwendet.

<medical context ::=	<MEDICALCONTEXT
	NAME = <object_type>
	INTERNAL-ID = <object_internal_ID>
	EXTERNAL-ID = <object_external_ID>
	CODEBASE = <code_base_URL>>
	{<group>}
	{<attribute>}
	</MEDICALCONTEXT >
<group> ::=	<GROUP
	NAME = <object_type>]
	[INTERNAL-ID = <object_internal_ID>]
	[EXTERNAL-ID = <object_external_ID>]
	[CODEBASE = <code_base_URL>>]
	[MATCH = ”yes” | ”no”]
	{<group>}
	{<attribute>}
	</GROUP>
<attribute> ::=	<ATTR
	NAME = <attribute_name>
	TYPE = <attribute_type>
	VALUE = <attribute_value>
	[UNIT = <attribute_unit>]
	[MATCH = ”yes” | ”no”]
	>

Beispiel

<MEDICALCONTEXT NAME=”Prenatal-US” INTERNAL-ID =”x.x.x.x:3031” EXTERNAL-ID=”@us.prenatal.ufk.charite.hu-berlin.de” CODEBASE=”ufk-science.charite.hu-berlin.de/data/reference-server/prenatalcontext/md.exe>

<GROUP NAME=”Patient” MATCH=”yes”>

<ATTR NAME=”Sex” TYPE=”Text” VALUE=”female”>

<ATTR NAME=”Sex” TYPE=” SNOMED V3.3” VALUE=” T-D0AA0”>

<ATTR NAME=”MaxAge” TYPE=”Integer” VALUE=”50”>

<ATTR NAME=”MinAge” TYPE=”Integer” VALUE=”10”> ....

</GROUP>

43

<GROUP NAME=”ListOfOrganes”>

<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Placenta”>

<ATTR NAME=”Organe” TYPE=”SNOMED V3.3” VALUE=”T-F1100”>

<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Fetus”>

<ATTR NAME=”Organe” TYPE=”SNOMED V3.3” VALUE=”T-F5000”>

<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Uterus”> <ATTR NAME=”Organe” TYPE=”SNOMED V3.3” VALUE=”T-83000”> ...

</GROUP>

<GROUP NAME=”ListOfProcedures” MATCH=”no”>

<ATTR NAME=”Procedure” TYPE=”Text” VALUE=” Ultrasonography, NOS”>

<ATTR NAME=”Procedure” TYPE=”SNOMED V3.3” VALUE=”P5-B0000”>

<ATTR NAME=”Procedure” TYPE=”Text” VALUE=” Diagnostic Doppler ultrasonography, NOS”>

<ATTR NAME=”Procedure” TYPE=”SNOMED V3.3” VALUE=”P5-B0110”>

<ATTR NAME=”Procedure” TYPE=”Text” VALUE=” Invasive medical procedure, NOS”>

<ATTR NAME=”Procedure” TYPE=”SNOMED V3.3” VALUE=” P2-00020”> ...

</GROUP>

<GROUP NAME=”ListOfDiagnosis” MATCH=”no”>

<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=”CELLULAR AND SUBCELLULAR ABNORMALITIES”>

<ATTR NAME=”Diagnosis” TYPE=” SNOMED V3.3” VALUE=”M-20000”>

<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=” 759.9”>

<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=”CONGENITAL ANOMALIES”>

<ATTR NAME=”Diagnosis” TYPE=” SNOMED V3.3” VALUE=”M-60000”>

<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=” 759.9”> ...

</GROUP>

</MEDICALCONTEXT>

3.6.7. Beispiel einer Transformation

Wir verwenden die in Abschnitt 4.7.4 und 4.7.3 angegebenen Beispiele für medizinische Kontexte der Fetalautopsie md1 und des Pränatalultraschalls md2, wobei hier die Inhalte und die Schreibweise der Einfachheit halber nur verkürzt wiedergegeben werden.

Ein Befund x aus der Fetalautopsie soll in der pränatalen Diagnostik angezeigt werden:

Es gilt nun, eine Transformation f durchzuführen:

Zunächst wird die Schnittmenge berechnet:

Da die Schnittmenge nicht leer ist, kann der Pränatalultraschallknoten davon ausgehen, daß die in md enthaltenen Objekte mit seinen eigenen Methoden behandelt werden können. Das sind die Einträge Patient=”female” und Organe=”Fetus”. Anschließend wird x’ aus x gefiltert:

44

Das Objekt x wird im Pränatalultraschallkontext vollständig übernommen. Eine Umkehrtransformation

würde wieder x liefern. Dieses Beispiel funktioniert jedoch nur, wenn die implizite Festlegung gilt, daß beim Matching ein Objekt Organe mit einem Objekt Patient gematcht werden kann. Dies ist zwar semantisch korrekt, da ein zu behandelndes Organ der ganze Körper sein kann, ist formal ohne die implizite Festlegung jedoch falsch. In diesem Fall würde sich eine leere Schnittmenge ergeben und das Empfängersystem Pränatalultraschall kann sich entscheiden, ob die Daten jetzt als reiner Text dargestellt werden sollen, falls ja, würde die Transformation f als Ergebnis x’ wie folgt liefern:

Das Objekt x’ wird dann mit den Standardattributen vom Typ Text dargestellt. Für eine maschinelle Weiterverarbeitung mag diese Reintextform nicht geeignet sein, für einen Arzt enthält dieser Text genauso viel Inhalt wie die codierte Form.

3.7. Der virtuelle Namensraum

Das Finden eines Objekts läuft im virtuellen Befundsystem an Hand der globalen ID ab (s. Abschnitt 4.4.1 Objekt-Identifikation ). Der Referenzknoten verwaltet die im virtuellen Befundsystem vertretenen Subsysteme, die mit der System-ID eineindeutig identifiziert werden können. Der Referenzknoten verwendet das DNS-Konzept, um die Auflösung nach Netzwerkadresse durchzuführen bzw. den Namen eines Objekts an Hand der Adresse herauszufinden.

Der vom virtuellen Befundsystem bekannte Namensraum ist somit eine echte Untermenge des Internet-Namenraums. Sind im Internet mehrere virtuelle Befundsysteme installiert, so braucht der Administrator nur bei dem jeweiligen Referenzknoten die Adresse des Partners - also des Namenservers - eingetragen zu haben. Sofort steht allen Anwendern eines Namensraums der gesamte Namensraum des Partners zur Verfügung.

Die Schutzmechanismen für die virtuellen Namensräume basieren hierbei vollständig auf den Schutzmechanismen des Internet, wie Firewall, sowie auf IPV6 basierende virtuelle Netze.

3.8. Das Transaktionskonzept

Das Transaktionskonzept wird sehr einfach gestaltet. Es ist nur eine Hierarchietiefe von 1 erlaubt. Es gibt keine verschachtelte Transaktion. Eine Transaktion wird mit BeginTransaction gestartet und mit EndTransaction beendet. Bei Fehlern wird RollbackTransaction aufgerufen. Bei jedem Start einer Transaktion wird festgelegt, ob und wie lange der Sender auf die Antwort warten soll (synchron/asynchron und Timeout). Bricht eine Verbindung während einer synchronen Transaktion ab, so wird die Transaktion auch abgebrochen. Es wird dann an keinem Subsystem eine Veränderung vorgenommen.

© Die inhaltliche Zusammenstellung und Aufmachung dieser Publikation sowie die elektronische Verarbeitung sind urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung. Das gilt insbesondere für die Vervielfältigung, die Bearbeitung und Einspeicherung und Verarbeitung in elektronische Systeme.