| Nguyen-Dobinsky, Trong-Nghia: Konzeption einer an semantischen Kriterien orientierten Komunikation für medizinische Informationssysteme |
45
Das Ergebnis der vorliegenden Arbeit ist ein Konzept für den Standard zum Austausch medizinischer Informationen, zunächst im Rahmen eines Intranet. Dieses Konzept wird im folgenden AMICI genannt (Architecture for Medical Information Exchange and Communication Interface).
Das Konzept wurde aus der im Kapitel 3 Methodik festgelegten Strategie bzw. Philosophie entwickelt. Das entwickelte Konzept wurde mit Hilfe ausgewählter Subsysteme überprüft. Die Auswahl erfolgt nach folgenden Kriterien:
Die Auswahl fiel auf folgende Subsysteme mit den in Tabelle 4-1 angegebenen Merkmalen:
Tabelle 4-1 Merkmale der untersuchten Subsysteme
|
Name |
Inhalt |
Anwender |
Plattform |
Architektur |
|
Punktionsdatei |
Invasive Untersuchungen in der pränatalen Diagnostik |
Pränatale Diagnostik und Therapie |
DOS |
FoxBase-DB Single User |
|
GebDat |
geburtshilfliche Daten |
Kreißsaal |
Novell/DOS |
dBase-DB Client/Server Multi User |
|
PIA |
Pränatal-Ultraschall, Diagnose, Bilder |
Pränatale Diagnostik und Therapie |
Novell/DOS |
Watcom DB Client/Server Multi User |
|
Autopsy |
Autopsie-Protokolle, Bilder |
Fetalpathologie |
Win3.1/Win95 |
Access-DB Multi User |
|
HL7-Server |
Patienten-Stammdaten |
Tumorzentrum |
Win NT |
SyBase-DB Client/Server Multi User HTML |
Die Untersuchung dieser unterschiedlichen Subsysteme zeigte, daß ein Standard für die Kommunikation zwischen den Einrichtungen in einem größeren Krankenhaus wie der Charité vorgeschlagen werden kann. Er ist technisch ohne weiteres realisierbar. Organisatorisch jedoch muß jede medizinische Einrichtung einige Maßnahmen ergreifen. Wichtige Voraussetzungen hierfür sind erstens die Möglichkeit, auf die von einem kommerziell erworbenen Subsystem verwalteten Daten zuzugreifen und zweitens müssen diese Daten in die vom Konzept vorgeschlagene Semantik umgesetzt werden. Dies kann erreicht werden, indem ein entsprechender virtueller Befundtreiber, ein sogenannter Wrapper, erstellt wird.
46
Im folgenden wird zunächst der Systementwurf mit der Software- und Datenstruktur beschrieben. Hierbei wird auf eine umfassende Darstellung verzichtet. Es wird sich vielmehr auf folgende Kernpunkte des Konzepts konzentriert:
Anschließend wird ein Überblick über die o. g. Subsysteme gegeben, wobei deren architektonischen Merkmale sowie die Art, die Objekte zwischen dem Subsystem und dem AMICI-System zu synchronisieren, im Vordergrund stehen. Im Anschluß hieran wird die Testimplementation beschrieben.
Der Systementwurf wird durch folgende Punkte beschrieben:
Virtuelles Befundsystem
Es wird ein Satz von Software-Werkzeugen entwickelt, die die virtuellen Behandlungen (siehe unten) gemäß den o. g. Anforderungen bearbeiten. Diese Werkzeuge bilden ein virtuelles Befundsystem, das den Charakter eines verteilten, multilateralen und dual-funktionalen Systems hat. Die Dualfunktionalität rührt daher, daß jeder Knoten den anderen sowohl als Client als auch als Server dienen kann. Das virtuelle Befundsystem läßt sich auf einer beliebigen Anzahl von Rechnern installieren. Jede Installation korrespondiert mit einem realen medizinischen Subsystem und liefert einen Beitrag zu einem gesamten virtuellen Befund. Alle Installationen kommunizieren miteinander über ein definiertes Protokoll.
Das System bildet somit ein Netz, bestehend aus Knoten. Jeder Knoten repräsentiert ein Subsystem. Der Knoten stellt ein Subsystem aus der Sicht des virtuellen Befundsystems (siehe unten) dar. Er stellt die Daten des Subsystems dem virtuellen Befundsystem zur Verfügung und gibt die Daten aus dem virtuellen Befundsystem an das angeschlossene Subsystem weiter. Der Knoten kommuniziert nicht direkt mit dem Subsystem. Er bedient sich eines virtuellen Befundviewers (siehe unten).
Die Knoten unterhalten Verbindungen untereinander. Die Subsysteme haben dagegen keine direkte Verbindung zueinander. Die Menge aller Knoten bildet das virtuelle Befundsystem. In Abbildung 4-1 wird das virtuelle Befundsystem grau hinterlegt. Die Knoten sind in der Regel auf einem Anwendungsserver (Unix bzw. Windows NT) installiert. Die Knotensoftware ist in der Regel untereinander identisch. Sie wird nur einmal entwickelt und mehrfach installiert. Lediglich durch die Einstellung der Parameter im medizinischen Kontext unterscheiden sie sich. Software-technisch besteht jeder Knoten aus einem WWW-Server, der einerseits Verbindung zum Browser unterhält, anderseits einen Satz von Applets aktiviert, die den virtuellen Befundviewer ansprechen. Abbildung 4-2 zeigt die schematische software-technische Konstruktion eines Knotens und den Ablauf einer Anfrage vom Browser.
47
Allgemeine virtuelle Befundviewer, die nicht an ein spezielles Subsystem angebunden sind, werden über einen allgemeinen Knoten bedient. Der allgemeine Knoten ist genauso wie jeder andere Knoten konstruiert. Allein der dazugehörige medizinische Kontext - in diesem Fall ist es ein allgemeiner medizinischer Kontext - macht ihn zu einem allgemeinen Knoten. Die Software für einen allgemeinen Knoten muß nicht neu entwickelt werden. Sie ist die Standardknotensoftware. Der virtuelle Befundviewer könnte dann überall die allgemein verfügbare Browser-Software mit einer allgemeinen Startseite sein.
In einem virtuellen Befundsystem existiert mindestens ein Knoten, der die Aufgaben eines Bezugsknotens übernimmt. Dieser Knoten heißt Referenzknoten. Ähnlich wie beim allgemeinen Knoten wird für den Referenzknoten die gleiche Software verwendet. Der Referenz-Client wird in der Regel benutzt, um das System zu installieren und administrieren. Für den Referenzknoten wird ein gesonderter medizinischer Kontext definiert.
Virtueller Befundviewer
Es wird ferner ein Darstellungsprotokoll festgelegt, das auf dem HTML oder gleichwertigem Protokoll basiert, so daß an jedem Arbeitsplatz ein virtueller Befund angezeigt werden kann, an dem ein HTML-fähiger Viewer verfügbar ist. In der Regel wird das ein kommerzieller Internet-Browser sein. In Abbildung 4-1 werden die viruellen Befundviewer in der ersten Ebene dargestellt.
Virtueller Befundtreiber
Die medizinischen Subsysteme werden jeweils über einen sogenannten virtuellen Befundtreiber an das virtuelle Befundsystem angeschlossen. Die Differenzen zwischen dem realen medizinischen Subsystem - dem realen Befundsystem - und dem virtuellen Befundsystem werden durch den virtuellen Befundtreiber überbrückt. In Abbildung 4-1 werden die virtuellen Befundtreiber in der dritten Ebene dargestellt.
In der ersten Version besteht das System aus folgenden Knoten:
Jeder Knoten repräsentiert ein Subsystem. Die ersten fünf Knoten sind durch die vorhandenen Subsysteme begründet. Der allgemeine Knoten ist ein besonderer Knoten, da er nicht auf vorhandenen Subsystemen basiert. Dieser Knoten wird geschaffen, um einen allgemeinen Viewer bieten zu können, ohne daß der Anwender sich auf einen medizinischen Kontext festlegen muß.
48
Abbildung 4-1 Softwarestruktur des Systems
Ein weiterer besonderer Knoten ist der Referenzknoten. Dieser Knoten wird geschaffen, um die Einrichtung, die Installation, den Betrieb, die Administration und die Wartung des Systems vornehmen zu können. Hier werden die Systemdaten wie der Namensraum, die medizinischen Kontexte, die Standardattribute mit den Standardmethoden für alle anderen Knoten bereitgestellt.
Abbildung 4-2 zeigt den schematischen Programmablauf an einem Knoten.
Anfrage vom Client
Jeder Knoten hat in der Regel zwei Zugänge für die Clients.
Ein Standard-Client greift über den HTML/XML-Zugang auf einen WWW-Server zu, der je nach ausgewählter Startseite die gewünschte Funktionalität liefert. Spezielle Anwendungen, für die die jetzige Funktionalität von HTML bzw. die Geschwindigkeit von Standard-WWW-Servern und Internet-Browsern nicht ausreichen, können direkt auf einen Knoten zugreifen. Dies kann mit einem C/C++- oder einem beliebigen Client geschehen.
Die speziellen Clients greifen über die Communication-Layer auf das Knoteninterface zu, das die gesamte Funktionalität eines Knotens bietet, während die Standard-HTML-Clients indirekt über den WWW-Server mit den WWW-Applets auf das Knoteninterface zugreifen.
AMICI-Knoten
Die Anfragen beider Arten von Clients sind in Form von Transaktionen formuliert. Sie werden vom Knoteninterface bearbeitet, das die Aufgaben mittels eines Transaktions-Dispatchers verteilt. Der Dispatcher untersucht die Anfragen und ruft die
49
entsprechenden Objektmethoden mittels eines Object-Handlers auf, um die Anfragen zu bearbeiten.
Treiber und interne Kommunikation
Der Object-Handler verteilt wiederum die ihm zugewiesenen Transaktionen auf den virtuellen Befundtreiber und/oder an die weiteren Knoten. Er sammelt auch deren Antworten und setzt die Attribute-Engine ein, um sie in die richtige Form zu bringen. Diese ruft wiederum das Device Independent Interface (DII) auf, um die von der Attribute-Engine im neutralen Format ausgegebenen Daten in das gewünschte Ausgabeformat zurückzugeben. Zu diesem Zweck bedient sich das DII entsprechender Ausgabetreiber. In diesem Fall ist es ein HTLM/XML-Ausgabetreiber. Für andere Ausgabeformate wie HL7, DICOM, etc. lassen sich mit vertretbarem Aufwand entsprechende Treiber entwickeln.
Antwort an den Client
Um andere Formate zu erzeugen, muß das DII nur den richtigen Treiber laden. Beispielsweise kann dies eine TIFF-Ausgabe oder ein Report in RTF- bzw. WinWord- Format sein. Im Fall von HTML-Clients werden die Ergebnisse an den WWW-Server zurückgegeben, der die HTML-Seite an den Internet-Browser weitergibt.
Abbildung 4-2 Schematische Darstellung des Ablaufes einer Anfrage
Im folgenden werden die Funktionalität und der wesentliche interne Ablauf der Softwarekomponenten beschrieben. Zunächst werden zwei Teilkonzepte für die Realisierung erläutert, die für alle Komponenten gelten. Das sind:
50
AMICI besteht aus mehreren Komponenten, die ständig miteinander kommunizieren. Sie laufen in der Regel auf mehreren Rechnern in mehreren Prozessen und ggf. mehreren Threads. Der Mechanismus für diese Kommunikation wird auf RPC festgelegt. Die Semantik der Kommunikation erfolgt stets nach einem Schema. Eine Komponente bietet ihre Funktionalität über ein sogenanntes API: Application Programming Interface. Das o. g. Schema läuft im API wie folgt ab:
Im Abschnitt 4.2.3 Der virtuelle Befundviewer wird dieses Konzept beispielhaft beschrieben.
Um die Software plattformunabhängig zu gestalten, werden die Teile der Software in Treiber ausgelagert, die möglicherweise von der Hardware, von der Systemsoftware bzw. von bestimmten Standards abhängig sein können. Beispielsweise wird das Communication-Layer eingeführt, um die Abhängigkeit von einem bestimmten Protokoll zu eliminieren. Wird ein neues Protokoll benötigt, so wird einfach ein neuer Treiber erstellt, der dieses neue Protokoll an das Communication-Layer anpaßt. Diese Vorgehensweise ist bereits in der Softwareentwicklung erprobt und birgt daher kaum Risiko für die Realisierung.
Der virtuelle Befundviewer (VRV: Virtual Report Viewer) ist ein Client-Programm, das in der Lage ist, die Anfrage vom Anwender entgegenzunehmen, sie in die virtuelle Anfrage umzuwandeln und die Antwort vom virtuellen Befundsystem in Form eines virtuellen Befundes korrekt anzuzeigen.
In der Regel ist der VRV ein regulärer Internet-Browser. In diesem Fall nimmt der VRV Kontakt mit einem WWW-Server auf und startet die Anwendung durch das Laden einer geeigneten Homepage. In dieser Homepage sind Verweise auf Applets enthalten, die als Java-Applets oder ActiveX-Elemente realisiert sind. Diese greifen wiederum über die AMICI-Client-API auf das External-Communication-Layer (ECL, siehe unten) zu, um die Funktionalität des Knoteninterfaces zu nutzen.
Der VRV kann ebenfalls ein gewöhnliches in C/C++ geschriebenes Client-Programm sein, das die Funktionalität des Knoteninterfaces nutzt, um die virtuellen Befunde aus einer virtuellen Behandlung zu holen und anzuzeigen. Es kann aber auch jedes beliebige Stück Software sein, das in der Lage ist, die o. g. Arbeiten durchzuführen. Diese Clients greifen direkt auf die AMICI-Client-API zu, ohne den Umweg über WWW-Server und Applets zu nehmen. Diese Hybridlösung bietet den Vorteil, daß alle Gelegenheitsanwender über die plattformunabhängige Browser-Technik Zugriff auf alle Anwendungen bekommen. Für Anwender, die AMICI in der Routine einsetzen, werden direkte C/C++-Lösungen angeboten, die z. Z. erhebliche Geschwindigkeitsvorteile bringen.
51
Die Bedienoberfläche eines solchen Clients läßt sich beispielsweise leichter an die Bedürfnisse der Anwender anpassen. Die meisten Browser lassen heutzutage zwar ihre Funktionalität durch sogenannte Plug-Ins erweitern, eine grundsätzlich andere Bedienoberfläche ist in der Regel jedoch nicht ohne weiteres möglich.
Abbildung 4-3 erläutert die Möglichkeiten eines virtuellen Befundviewers, auf das Knoteninterface zuzugreifen. Alle Clients bedienen sich der AMICI-Client-API. Der WWW-Server kann auf dem gleichen Server, auf dem die AMICI-Knotensoftware installiert ist oder auf einer getrennten Maschine laufen. Ein WWW-Server kann ferner durch die Installation mehrerer Homepages als Zugang für mehrere Subsysteme eingesetzt werden.
Abbildung 4-3 Zugang vom virtuellen Befundviewer zum AMICI-Knoten
Die Aufgabe des External Communication-Layer (ECL) ist es, wie der Name sagt, die Verbindung zwischen den Clients und dem Knoteninterface herzustellen und zu unterhalten.
Dieses Layer läuft auf einem Windows NT Server ab Version 4.0 und wird als Service automatisch mit einer für AMICI vordefinierten Servicenummer (z. B. 3010) gestartet. Es startet automatisch das Knoteninterface, das wiederum alle anderen notwendigen Komponenten nacheinander startet.
Dieses Layer bedient in erster Linie die TCP/IP-Anfragen von Clients und läßt sich später bei Bedarf auf andere Protokolle wie IPX/SPX, AppleTalk oder DecNet erweitern. Es ruft die hardware-unabhängige Win32bit-API für Netzwerk WNETxx auf, um die Netzwerkfunktionen zu benutzen. Somit ist das ECL nicht von bestimmter Hardware abhängig.
Bei einer Anfrage eines neuen Clients wird eine neue virtuelle Verbindung angelegt und eine neue Thread im Knoteninterface gestartet, die für diese Verbindung zu
52
ständig ist. Die Clients bedienen sich des ECL-API, um auf die Funktionalität eines Knotens zuzugreifen.
Das Knoteninterface (NI: Node Interface) unterhält die Verbindung zum External- Communication-Layer. Für jede Verbindung wird ein Thread vom Knoteninterface gestartet. Das Knoteninterface arbeitet unabhängig von der Art, wie ein Client gebaut ist. Objekte, die zwischen dem ECL und dem NI ausgetauscht werden, sind Transaktionen der obersten Ebene. Das sind Transaktionen, die auf die ”top-level”-Objekte vom Typ virtuelle Behandlung angewandt werden.
Die Hauptaufgabe des Knoteninterfaces ist die korrekte Handhabung dieser Transaktionen.
Der Transaktionsverteiler (TAD: Transaction Dispatcher) verteilt die vom Knoteninterface erhaltenen Transaktionen auf die Objekte der virtuellen Behandlungen, die durch den Object-Handler behandelt werden. Der TAD leitet bei jeder Anfrage eine BeginTransaction und bei Beendigung der Anfrage eine EndTransaction ein. Alle Aufrufe an den Object-Handler werden zunächst ”probeweise” ausgeführt. Ist die Transaktion erfolgreich zu Ende gelaufen, so wird durch EndTransaction dieser neue Zustand festgeschrieben. Ist dies nicht der Fall, so leitet der TAD ein RollBack ein. Hierbei kann beispielsweise der vor BeginTransaction gesicherte Zustand wiederhergestellt werden. Man kann dies auch durch sogenannte Undos realisieren. Ein CreateObject-Aufruf wird durch die Funktion DeleteObject wieder rückgängig gemacht.
Der Object-Handler bietet in der OH-API einen Rahmen für alle Pflichtmethoden der Objekte. Auf dieser Ebene sind alle Funktionen nicht auf ein spezielles Objekt ausgerichtet. Intern splittet OH die in der API übergebenen Objektmethoden einerseits durch Aufrufe an Unterobjekte, die im ”top-level”-Objekt enthalten sind, andererseits durch Aufrufe an die Attribute-Engine, die die im Objekt enthaltenen Attribute behandelt. Die Ergebnisse der Attribute-Engine werden entweder im Speicher oder in externen Dateien oder durch einen Datenstrom zurückgegeben.
Die Attribute-Engine wird aufgerufen, wenn der Object-Handler (OH) ein Attribut behandeln muß; z. B. wenn OH die Aufgabe bekommt, ein Attribut darzustellen, ruft OH die Attribute-Engine auf. Diese untersucht, ob das Attribut ein Primitivum ist, wenn ja, ruft sie die Funktion DisplayStdAttr auf. Hierbei wird der Display-Context ausgewertet, um eine korrekte Darstellung des Attributs zu gewährleisten. Ist das Attribut kein Primitivum, so ruft die Attribute-Engine das betroffene Objekt mit der Objektmethode DisplayObject auf. Das Objekt kennt nun seine Struktur am besten und fängt wiederum an, seine eigenen Attribute darzustellen. Das Objekt ruft die Attribute-Engine wieder auf, falls es dabei auf die Primitiva trifft. Abbildung 4-4 zeigt das Zusammenspiel zwischen dem Object-Handler und der Attribute-Engine.
53
Abbildung 4-4 Zusammenspiel zwischen Object-Handler und Attribute-Engine
Diese Schnittstelle sorgt für eine geräteunabhängige Ausgabe des Ergebnisses einer Transaktion. Dieses Interface arbeitet gemäß dem allgemeinen Treiber-Konzept (siehe Abschnitt 4.2.2 Das Treiber Konzept ). Ein Beispiel für die Realisierung findet sich im Abschnitt 4.2.11 Der virtuelle Befundtreiber (VRD) .
Hier sind die Ausgabetreiber angesiedelt, die konkrete Ausgabeoperationen auf einem Gerät vornehmen. Diese Treiber arbeiten gemäß dem allgemeinen Treiber-Konzept (siehe Abschnitt 4.2.2 Das Treiber Konzept ). Ein Beispiel für die Realisierung findet sich im Abschnitt 4.2.11 Der virtuelle Befundtreiber (VRD) .
Ein virtueller Befundtreiber (VRD: Virtual Report Driver) ist das Bindeglied zwischen dem medizinischen Subsystem und dem virtuellen Befundsystem. Er muß in der Lage sein, die Anfrage vom virtuellen Befundsystem entgegenzunehmen, sie in das subsystem-spezifische Format umzuwandeln und an das Subsystem weiterzuleiten. Die Antwort vom Subsystem muß der virtuelle Befundtreiber wieder in das Format des virtuellen Befunds zurückverwandeln und an das virtuelle Befundsystem abliefern.
Der Einsatz des VRD erfolgt nach einem Layer-Modell, das aus folgenden Layern besteht:
54
Im folgenden wird der Rumpf eines VRD-Treibers als Vorlage für die Realisierung festgelegt. Die in der Vorlage noch fehlenden Funktionen werden nach diesem Muster realisiert.
THRESULT vrdControl (THDC hDC,
int iFunction,
int iLenInData,
LPVOID* lpInData,
LPVOID* lpOutData)
{
THRESULT status;
if (hDC < (THDC) NULL && iFunction != DRVFUNC_INIT)
return (ER_UNDEFINEDERROR);
status = 0;
switch (iFunction)
{
case DRVFUNC_INIT:
{
LPCSTR lpOutput; // Output port or File name //
LPCSTR lpDriver; // Driver name //
int iOpMode; // Operation mode //
lpDriver = lpInData [0];
lpOutput = lpInData [1];
iOpMode = (int) *((int *) lpInData [2]);
status = vrdInitDevice (iOpMode, lpOutput);
if (status < 0)
return (ER_UNDEFINEDERROR);
}
break;
case DRVFUNC_DELETE:
vrdCloseDevice (hDC);
break;
case DRVFUNC_GETDEVCAPS:
status = vrdInitDevCaps ((LPDOCIOCAPS) &CurrDocIOCaps);
if (status < 0)
return (ER_UNDEFINEDERROR);
memcpy ((LPBYTE) lpOutData [0], (LPBYTE) &CurrDocIOCaps,
sizeof (VRCDEVCAPS));
break;
case DRVFUNC_SETABORTPROC:
{
LPFNABORTPROC lpfnAbortProc;
lpfnAbortProc = lpOutData [0];
status = vrdSetAbortProc (hDC, lpfnAbortProc);
if (status < 0)
return (ER_UNDEFINEDERROR);
}
break;
case DRVFUNC_GETDEVICECAPINT:
{
int iIndex;
LPINT lpiDevCaps;
iIndex = (int) *((LPINT) lpInData [0]);
lpDriver = lpOutData [0];
status = vrdGetDeviceCapInt (hDC, iIndex, lpiDevCaps);
if (status < 0)
return (ER_UNDEFINEDERROR);
}
break;
case DRVFUNC_GETDEVICECAPLONG:
{
int iIndex;
LPLONG lpiDevCaps
iIndex = (LONG) *((LPLONG) lpInData [0]);
lpDriver = lpOutData [0];
sttaus = vrdGetDeviceCapLong (hDC, iIndex, lpiDevCaps);
if (status < 0)
return (ER_UNDEFINEDERROR);
}
break;
case DRVFUNC_GETDEVICECAPDOUBLE:
{
55
int iIndex;
LPDOUBLE lpiDevCaps
iIndex = (double) *((LPDOUBLE) lpInData [0]);
lpDriver= lpOutData [0];
sttaus = vrdGetDeviceCapDouble (hDC, iIndex, lpiDevCaps);
if (status < 0)
return (ER_UNDEFINEDERROR);
}
break;
default:
return (ER_UNDEFINEDERROR);
break;
}
return (status);
}
Im folgenden wird der logische Datenentwurf beschrieben. Auf die Darstellung der physikalischen Datenstruktur wird hier verzichtet, da sie nicht wesentlich zum Verständnis des Konzepts beiträgt.Die AMICI-Daten werden im wesentlichen als relationale Datenbanken (RDB) abgelegt. Hier wird zwischen den AMICI-Daten selbst und den Daten der angeschlossenen medizinischen Subsysteme unterschieden. Die AMICI-Daten sind in erster Linie die Daten der virtuellen Behandlungen, die nur temporär existieren. Sie werden für die Dauer einer Transaktion aus den Daten der Subsysteme erzeugt und nach Beendigung der Aufgaben wieder gelöscht. Außerdem benötigt AMICI auch eigene Daten, die weder vom Subsystem noch vom Client geliefert werden können. Es sind dies beispielsweise die Systemdaten wie Anwender, Namensraum, Subsysteme, medizinische Kontexte, etc.Da es möglich sein muß, von beliebigen Frontends über ODBC auf die AMICI-Datenbanken zuzugreifen und die Daten jederzeit in ein anderes Format zu überführen, können nur Datentypen verwendet werden, die in Standard SQL und ODBC verfügbar bzw. verlustfrei konvertierbar sind.Alle Standbilddaten werden als einzelne TIFF- bzw. JPEG-Dateien abgelegt. Die Audio-Video-Daten werden als einzelne AVI- bzw. MPEG-Dateien gespeichert. Andere Formate sind durch einfaches Hinzufügen von Treibern jeder Zeit bearbeitbar.
Das im Kapitel 3 Methodik beschriebene allgemeine Objektkonzept gibt einen allgemeinen Rahmen, um die medizinischen Informationen zu strukturieren, die im Konzept zwischen den medizinischen Subsystemen ausgetauscht werden sollen. Ein wesentlicher Punkt des allgemeinen Objektkonzepts besagt, daß jedes Objekt eine Menge von Attributen besitzt.Im Rahmen des allgemeinen Objektkonzepts lassen sich beliebige Objekte definieren. Der Begriff Objekt wird hier weit gefaßt. Ein Objekt kann reell (ein Organ) oder immateriell (ein Befund), sachlich (ein Fetus) oder zeitlich (eine Sektion) oder rein logisch (eine Bedingung) sein. Ein Objekt hat immer eine Objekt-Identifikation. Es kann, muß jedoch nicht weitere Objektattribute besitzen. Zwischen den Objekten können Beziehungen aufgebaut werden. Ein Objekt weiß selbst, was der Anwender mit dem Objekt tun kann. Hauptbestandteile eines Objekts sind:
56
Abbildung 4-5 zeigt die allgemeine Struktur eines AMICI-Objekts.
Abbildung 4-5 Allgemeine Struktur eines Objekts
Ferner hat ein Objekt immer einen eindeutigen Zustand. In der Regel befindet sich ein Objekt im Zustand aktiv. Ein Objekt läßt sich auch in einen Wartezustand versetzen. Es hat dann den Zustand passiv. Weitere Zustände, die diese beiden Hauptzustände näher beschreiben und sich beim Feindesign als notwendig erweisen, lassen sich bei Bedarf hinzufügen. Beispielsweise können für den Zustand aktiv folgende Klassifizierungen definiert werden: unknown, initializing, intialized, closing, closed, destroying, destroyed. Passive Zustände können sein: waiting for input, waiting for message. etc.
Eine eindeutige Identifikation eines Objekts ist in einer Intranet/Internet-Umgebung essentiell wichtig für das Funktionieren der Anwendungen. Einerseits dürfen sich die ID’s eines bekannten Objekts mit der Zeit nicht ändern. Andererseits muß jedes Subsystem die notwendigen Änderungen autark vornehmen können. Aus diesem Grund wird die Identifikation eines Objekts wie folgt realisiert. Jedes Objekt läßt sich auf folgende Art und Weise identifizieren:die weltweit eindeutige sogenannte externe ID (globale ID),die interne ID (lokale ID) unddie graphische ID.
Globale Objekt-ID
Die globale Objekt-Identifikation ist ein zusammengesetzter Schlüssel. Sie ist weltweit gültig und besteht aus mehreren Teilen: einer sogenannten lokalen Objekt-ID und einer weltweit einmaligen ID des Subsystems. Die globale Objekt-ID besitzt eine interne und eine externe Darstellung. Die globale Objekt-ID wird systemintern global object ID genannt. Ihre interne Darstellung hat die Form:
57
<internal global object ID> ::= <internal subsystem ID>,
<service ID>,
<local object ID>
<internal subsystem ID> ::= <virtual IP address>
<virtual IP address> ::= byte.byte.byte.byte[.byte]
<service ID> ::= {0|1|2|3|4|5|6|7|8|9}
<local object ID> ::= ”beliebige Subsystem-bezogene Nummer”
Die externe Darstellung einer global Objekt-ID hat die Form:
<external global object ID> ::= <locale object ID>@
<external subsystem ID>:
<service ID>
<external subsystem ID> ::= <external IP address>
<external IP address >::= ”IP Adresse gemäß Internet-Namenskonventionen”
Beispiele für externe globale Objekt-ID:
4711@pia-prenatal.ufk.charite.hu-berlin.de:3030 47110@pia-patho.ifp.charite.hu-berlin.de:3030 1174@hl7.rz.charite.hu-berlin.de:3001
Anmerkungen:
Die virtuelle IP-Adresse ist in der Regel die IP-Adresse des Servers, auf dem das Subsystem installiert ist. Sind auf einem Server mehrere Subsysteme verfügbar, so werden mehrere virtuelle IP-Adressen vergeben, je eine für ein Subsystem.Die Service-ID identifiziert den jeweiligen Dienst. Beispielsweise wird festgelegt, daß der Dienst http die Service-ID 8080 zugewiesen bekommt. Für den virtuellen Befunddienst könnte eine noch nicht anderweitig vergebene Nummer verwendet werden, z. B. 4711.
System-ID
Die System-ID ist der Geltungsbereich der Objekt-ID. Die System-ID ist die weltweit eindeutige Identifikation eines installierten Subsystems, gleichgültig, ob es sich dabei um ein medizinisches oder ein administratives Subsystem handelt. Diese ID wird analog zu den IP-Nummern des Protokolls TCP/IP vergeben. Jedes Subsystem erhält eine solche ID. Besteht ein Subsystem physikalisch aus mehreren Komponenten, wobei jede Komponente logisch eine abgetrennte Aufgabe erfüllt, so kann für jede Komponente eine eigene ID zugewiesen werden.
Lokale Objekt-ID
Eine lokale Objekt-ID ist eine Identifikation, die innerhalb eines Subsystems eineindeutig ist. Diese ID muß den Internet-Namenskonventionen genügen. Beispielsweise sind ”blanks”, Kommata und ”underlines” verboten. Der virtuelle Befundtreiber sorgt für eine richtige Umwandlung zwischen der lokalen Objekt-ID des virtuellen Befundsystems und der internen ID des betroffenen Subsystems.Die lokale Objekt-ID wird systemintern local object ID genannt. Sie wird vom jeweiligen Subsystem vergeben und gilt nur innerhalb des betrachteten Subsystems. Mit dieser Konstruktion wird jede lokale ID zu einer globalen, wenn zusätzlich der Geltungsbereich, also die System-ID, angegeben ist.Beispielsweise kann dem in der pränatalen Diagnostik eingesetzte Befundsystem PIA eine ID wie pia-prenatal.ufk.charite.hu-berlin.de zugewiesen werden. Eine in diesem System gespeicherte Behandlung
hat die lokale ID 4711. Die globale ID der Behandlung wäre:
4711@ pia-prenatal.ufk.charite.hu-berlin.de
58
Natürlich muß systemintern nicht der lange Text ”pia-prenatal.ufk.charite.hu-berlin.de” als Schlüssel verwendet werden. Eine dynamisch verwaltete Tabelle à la Hosts-Datei kann diesen langen Text durch eine 4 Byte lange Nummer ersetzen.Die Vergabe der System-ID basiert auf der Internet-Struktur der Domains. Innerhalb der ”parent”-Domain ”charite.hu-berlin.de” muß ein ID-System als Referenz deklariert werden. Sinnvollerweise wird für die Charité das Schlüsselsystem der zentralen Patientenverwaltung ausgewählt, das mit der Patienten-ID, Aufnahme-ID und Stations-Nummer eine Behandlung identifizieren kann. Z. Z. wird die Patientenverwaltung durch das Modul ISH der Firma SAP übernommen. Die Umrechnung von einem Referenzschlüssel zu einer subsystem-bezogenen, globalen ID erfolgt durch das Subsystem.
Graphische ID
Die graphische ID existiert nur temporär und ist immer abhängig von der gerade verwendeten Darstellung. Die graphische ID wird benutzt, damit der Anwender am virtuellen Befundviewer ein Objekt mit Hilfe eines Zeigergeräts, z. B. einer Maus, identifizieren kann. Sie wird vom Viewer generiert.
Strenggenommen lassen sich alle Daten eines Objekts einheitlich als Attribut realisieren, inklusive der Schlüssel. Da die Schlüssel eine besondere Rolle spielen, werden sie wie im obigen Abschnitt gesondert behandelt.Ein Attribut kann einfach sein. Alle einfachen Attribute müssen vom RPC-Protokoll unterstützt sein, um Daten über die Systemgrenzen hinweg und online austauschen zu können.Die Attribute werden von der sogenannten Attribute-Engine behandelt. Die Attribute-Engine hat zwei primäre Aufgaben. Erstens sorgt sie für die richtige Interpretation der Attribute in Abhängigkeit vom medizinischen und Darstellungskontext. Zweitens führt sie bei der Integration eines einzelnen Attributes in ein Objekt die Integritätsprüfung durch. Die Attribute-Engine und die Kontexte sind näher im Abschnitt 4.2.8 Die Attribute-Engine (AE) beschrieben.Diese Attribute sind die primären Eigenschaften des Objekts. Sie sind unabhängig von der Umwelt. Z. B. ist der Geburtstag eine Ureigenschaft eines Patienten/einer Patientin - gleichgültig, in welcher Systemumgebung diese Eigenschaft betrachtet wird. Lediglich die Darstellung eines Datums kann von der Ländereinstellung und der bevorzugten Form abhängen. Nichtsdestotrotz hängt oft die Entscheidung, ob ein Attribut den Inhalt des Objekts darstellt oder nicht, von der jeweiligen Sicht des Anwenders bzw. der Anwendung ab.
Textdarstellungsattribut (Text Attributes):
Diese Attribute sind keine Ureigenschaft eines Objekts. Sie steuern lediglich die textliche Darstellung eines Attributs. Sie sind nicht zu verwechseln mit dem Textattribut eines graphischen Systems wie CorelDraw! oder Microsoft PowerPoint. Hier legen sie - systemunabhängig - die Vorschrift für die Textdarstellung des Objekts fest, falls es als Text dargestellt werden soll. Sie sind ähnlich wie die Textattribute bei HTML. Es wird nichts über die tatsächliche Größe des Textes ausgesagt. Sie legen vielmehr nur die Wichtigkeit der Darstellung fest.
59
Grafisches Darstellungsattribut (Graphic Attributes):
Analog zum Textdarstellungsattribut legen die graphischen Attribute die gewünschte graphische und bildliche Darstellungsart eines Objekts fest. Die tatsächliche Darstellung hängt vom jeweiligen medizinischen und Darstellungskontext ab.
Includes
Includes sind Objekte, die auf der Betriebssystemebene existieren. Sie können Teil eines Objekts sein oder aber andere Objekte enthalten, die auf einem Massenspeicher gespeichert sind. Includes werden verwendet, um größere binäre Daten abzulegen. Beispielsweise kann eine TIFF-Datei als Include in einem Objekt verwendet werden.
Zwischen den Objekten sind Beziehungen möglich. Die Objektrelationen sind in den Objektattributen beschrieben und werden in der Regel auch wie Attribute behandelt. Somit lassen sich die Objektrelationen mit den Standardwerkzeugen der Attribute-Engine behandeln. Es bedarf keiner gesonderten Softwaremodule. Die Software wird damit klein gehalten.Es sind zwei Arten von Relationen zu unterscheiden. Die strukturellen Relationen legen die formalen Beziehungen zwischen Parent-Child und Sister-Sister fest. Sie werden durch die Methoden Get/SetParent, Get/SetChild und ToFirst/ToPrev/ ToNext/ToLastObject geregelt.Die inhaltlichen Relationen werden dagegen durch die Methode SelectObject und Get/SetRelation abgedeckt.
Die aktiven Eigenschaften eines Objekts sind ausführbar und werden auch Methoden genannt. Jedes Objekt muß mindestens einen Satz von Pflichtmethoden für die Standardbehandlung von Objekten anbieten wie CreateObject, DisplayObjkect, etc.
Die Attribute sind unterteilt in folgende Kategorien:
Basisdatentypen sind Standarddatentypen, die von RPC unterstützt werden. Sie sind ohne Dimension und bilden die Basis für die Primitiva. Jedes Primitivum besteht aus einer Struktur, die den Attributnamen, den Typ des Attributwertes, den Wertebereich und die Dimension des Attributes enthält.
<primitivum> ::= <name> <type-ID> <value type> [<value range>] [<unit>] [<scope>]
Der Name des Attributs <name> wird vom System vergeben. Die Treiber setzen diese Systemnamen in die Namen um, die vom Subsystem interpretiert werden können. Jedes Attribut muß einem Typ zugeordnet sein. Ein Attributtyp kann z. B. Durchmesser, Länge, Gewicht, Diagnose, Therapie, etc. sein. Der Attributtyp <type-
60
ID> wird ebenfalls vom System vergeben. Der Typ des Attributwertes <value type> gibt an, welchen Basistyp der Attributwert besitzt (s. oben). Der Wertebereich <value range> gibt an, in welchem Bereich der Attributwert liegen darf. Der Geltungsbereich <scope> gibt das System an, in dem die Bezeichung bzw. die Einheit verwendet wird. Beispielsweise kann der Scope ”SNOMED V3.3” oder ”local” sein. Die Dimension <unit> gibt schließlich die Einheit des Attributwertes an. <value range>, <unit> und <scope> sind optional.Beim Austausch können die beteiligten Softwarekomponenten an Hand dieser Angaben und ggf. vom medizinischen sowie Darstellungskontext entscheiden, wie ein Attribut umgerechnet und dargestellt werden soll. Die Attribute Engine ist immer in der Lage, Primitiva zu behandeln. Dies garantiert, daß ein virtueller Befund immer angezeigt bzw. ausgedruckt werden kann.Zusammengesetzte Attribute sind Strukturen aus Primitiva. Zusätzlich sind die Zusammenhänge zwischen den Attributen mitgespeichert, so daß eine Darstellungsroutine online prüfen kann, ob die Eingabe noch gültig ist, ohne den Server ansprechen zu müssen. Ein zusammengesetztes Attribut kann wieder ein Objekt sein. Alle Objekte stammen aus einer Klasse und haben die gleiche Struktur. Im folgenden wird die allgemeine Objektstruktur beschrieben.
Objekte gleichartiger Eigenschaften bilden eine Klasse. Eine bestimmte Menge von Objekten einer Klasse bildet ein ObjectSet, analog zum RecordSet der relationalen Datenbanken. Hier wird ein hybrides Konzept gewählt. Einerseits sind durch das ObjectSet Operationen wie bei einer relationalen Datenbank möglich und leicht abbildbar. Andererseits wird durch das Objektkonzept die OO-Verarbeitung ermöglicht.Das Objekt, das zwischen dem medizinischen Subsystem und dem virtuellen Befundsystem ausgetauscht werden soll, ist die virtuelle Behandlung. Sie enthält u. a. zahlreiche Verweise auf andere Objekte, die nicht von medizinischen Systemen verwaltet werden. Das sind die Stammdaten (Anatomie, Syndrome, Normwerte, IDC/ICPM-Codes), die personenbezogenen Daten (Patienten, medizinisches und administratives Personal), Daten über die Einrichtungen (Klinik, Station, Institut, Verwaltungsstelle, Behörde, Praxis). Alle diese Daten werden auch als Objekte gehandhabt (siehe auch unten).Im folgenden werden die Objektklassen aufgelistet, die zum Nucleus des virtuellen Befundsystems gehören und die Merkmale des Konzepts ausprägen. Hierbei handelt es sich beispielsweise um die Klassen Behandlung, Untersuchung, Patient, Diagnose, etc. Andere Objektklassen, die auch wichtig für das Funktionieren eines Systems sind, jedoch nicht zum Wesen des Konzepts gehören, werden nicht zum Nucleus gezählt. Nicht zum Nucleus gehört z. B. die Verwaltung der Systemkomponenten, Helptexte, etc.Der Nucleus wird wiederum in 2 Bereiche unterteilt. Der erste wird Anwendungs- der zweite System-Nucleus genannt. Der Anwendungs-Nucleus enthält Objektklassen, die für die Anwendungen relevant sind. Das sind z. B. Behandlung, Untersuchung, Diagnose, Therapie, etc. Zum System-Nucleus gehören Objektklassen, die für das Funktionieren des Systems lebensnotwendig sind, die jedoch nicht direkt mit den Anwendungen zu tun haben, z. B. Netzwerk-Anschluß, Transaktionen, etc.. Abbildung 4-6 zeigt die Objektklassen, die zum Anwendungs-Nucleus gehören. Anschließend werden die wesentlichen Bestandteile der Datenstruktur kurz erläutert.
61
Abbildung 4-6 Schematische Darstellung der Datenstruktur
Einrichtung
Eine Einrichtung ist jede Organisationseinheit im Sinne des X500-Standards. Beispielsweise bezeichnet ”de” eine Einrichtung. ”ufk.charite.hu-berlin.de” ist ebenfalls eine Bezeichnung der Einrichtung Universitätsfrauenklinik. Die externe Bezeichnung der Einrichtung muß den Internet-Namenskonventionen genügen.
Subsystem
Ein Subsystem im Sinne des Standards ist jedes Softwaresystem, das über einen virtuellen Befundtreib
er Informationen an das System liefert und/oder Informationen vom System bezieht.
Medizinisches Subsystem
Ein medizinisches Subsystem ist ein Subsystem, das für einen Teil der medizinischen Informationen im virtuellen Befundsystem verantwortlich ist. Medizinische Informationen beinhalten auch die Codierung ICD, ICPM der Diagnose bzw. Therapie. In der Regel liefert ein medizinisches Subsystem medizinische Informationen an das System und bezieht administrative Informationen vom System.
Administratives Subsystem
Ein administratives Subsystem ist ein Subsystem, das verantwortlich für einen Teil der administrativen Informationen im virtuellen Befundsystem ist. Administrative Informationen beinhalten die Patientendaten, Krankenkassen, Einweisungsdaten und Daten über die Aufnahme, Verlegung und Entlassung des Patienten/der Patientinnen. Abrechnungsdaten werden hier nicht betrachtet.In der Regel liefert ein medizinisches Subsystem medizinische Informationen an das System und bezieht administrative Informationen vom System.
62
Virtuelle Behandlung
Es wird ein Hauptdatentyp festgelegt. Das ist die ”virtuelle Behandlung”. Eine virtuelle Behandlung, oder einfach Behandlung genannt, ist jeder Vorgang in einem Subsystem, der als Ergebnis einen Befund liefert. Eine Behandlung ist entweder eine ”top-level”- oder Teilbehandlung. Eine top-level-Behandlung hat eine globale Objekt-ID der höchsten Organisationseinheit im virtuellen Befundsystem. Eine Teilbehandlung ist ein Teil einer übergeordneten Behandlung, einer sogenannten parent-Behandlung. Die übergeordnete Behandlung kann eine top-level- oder aber eine Teilbehandlung sein.Alle anderen Informationen wie Patienten, Anamnese, Diagnose, Therapie, etc. sind Attribute der Behandlung. Die Behandlung wird gemäß der Objektorientierung mit einem Satz von Operationen festgelegt.Beispielsweise wird eine top-level-Behandlung in der Charité durch eine eineindeutige z. Z. 12stellige Aufnahme-Nummer identifiziert. Im virtuellen Befundsystem wird eine solche Behandlung z. B. durch folgende globale Objekt-ID bezeichnet:
123456789012@hl7.charite.hu-berlin.de
Die virtuelle Behandlung wird durch einen virtuellen Befund dargestellt. Eine virtuelle Behandlung beginnt mit der Aufnahme und endet mit der Entlassung des Patienten/der Patientin. Alle Vorgänge und Ergebnisse während dieser Zeit lassen sich als Attribute des Objekts virtuelle Behandlung integrieren. Hierzu siehe auch Abbildung 4-6 .
Untersuchungsmaterial
Das Untersuchungsmaterial ist das Objekt einer Behandlung. Es bildet immer eine anatomische Einheit.
Anmerkungen
In den meisten Fällen ist das Untersuchungsmaterial ein Teil des Patienten/der Patientin. Es kann jedoch von einer anderen Person stammen, z. B. einem Fet oder einem Verwandten des Patienten/der Patientin. Es kann auch der ganze Körper eines Menschen sein. Beim Kontextmatching wird diese Tatsache berücksichtigt.
Person
Alle Personen, die irgendwie mit dem virtuellen Befundsystem zu tun haben, werden durch ein Objekt dargestellt. Sie werden lediglich durch ihre Rolle voneinander unterschieden. Beispielsweise kann ein und dieselbse Person einmal die Rolle des medizinischen Personals, einmal die Rolle eines Patienten übernehmen.
Technisch gesehen läßt sich ein Patient optimal durch den zusammengesetzten Schlüssel
<Personalausweis-Nummer>@<Land>
weltweit eindeutig identifizieren. Diese Art steht allerdings heute nicht zur Verfügung. So läßt sich z. B. die Patient-ID durch
<Charité-Patient-Nummer>@charite.hu-berlin.de
ebenfalls weltweit eindeutig identifizieren. Dadurch wird eine mehrfache Speicherung einer Person vermieden. Durch den Abgleich der AMICI-Personendatenbank mit den in den Subsystemen gespeicherten Patientendaten könnten Eingabefehler gefunden und korrigiert werden.
63
Personen werden in folgende Gruppen eingeteilt:
Eine virtuelle Behandlung wird durch einen virtuellen Befund dargestellt. Der Anwender sieht die virtuelle Behandlung durch den virtuellen Befund. In Datenbanksprache stellt der virtuelle Befund ein View auf die virtuelle Behandlung dar. Welche Bestandteile der virtuellen Behandlung im virtuellen Befund angezeigt werden sollen, wird in Vorlagen definiert. Jeder Anwender kann eigene Vorlagen zum Anzeigen von virtuellen Befunden definieren.
Ein virtueller Befund muß nicht real existieren. Es wird bei Bedarf von den Informationen der Subsysteme gebildet. Der Inhalt und das Layout eines virtuellen Befunds läßt sich vom Anwender definieren. Der Inhalt wird von den gewünschten Subsystemen geliefert. Die Darstellung wird durch den medizinischen und den Darstellungskontext gesteuert. Beides kann vom Anwender festgelegt werden. Die Darstellung übernimmt der virtuelle Befundviewer.
Anmerkungen:
Der Begriff virtueller Befund wird hier daher sehr weit gefaßt. Alles, was die Subsysteme liefern, läßt sich in einen virtuellen Befund integrieren. Durch die Definition eines medizinischen Kontextes kann der Anwender quasi die Krankenakte eines Patienten/einer Patientin anzeigen lassen. Alle Behandlungen, die durch die Subsysteme verfügbar gemacht werden können, lassen sich anzeigen.
Darstellungskontext
Bei der Anzeigefunktion wird der Darstellungskontext benötigt, in dem die vom Sendesystem gewünschte Darstellung gespeichert ist. Im Darstellungskontext sind die Darstellungsattribute abstrakt definiert. Hier wird keine physikalische Angabe gemacht. Das Empfängersystem wertet den Darstellungskontext aus und vergleicht ihn mit dem jeweiligen Device Context, um Darstellungsvorschriften für die Darstellungsroutinen zu formulieren.
<OBJECT TYPE=”MedicalContext” INTERNAL-ID =”141.11.11.11” EXTERNAL- ID=”prenatal.ufk.charite.hu-berlin.de” CODEBASE=”ufkscience.prenatal.ufk.charite.hu- berlin.de/data/reference-server/prenatalcontext.exe> <ATTR NAME=”Scope” TYPE=”Text” VALUE=”SNOMED V3.3” > <ATTR NAME=”Language” TYPE=”Text” VALUE=”EN” > <ATTR NAME=”VirtualOrgane” TYPE=”Text” VALUE=”Fetus”> <ATTR NAME=”VirtualOrgane” TYPE=”SNOMED V3.3” VALUE=”T-F5000”> <ATTR NAME=”VirtualProcedure” TYPE=”Text” VALUE=”Ultrasonography”> <ATTR NAME=”VirtualProcedure” TYPE=”SNOMED V3.3” VALUE=”P5-B0000”> <ATTR NAME=”VirtualProcedure” TYPE=”Text” VALUE=”Diagnostic Doppler ultrasonography”> <ATTR NAME=”VirtualProcedure” TYPE=” SNOMED V3.3” VALUE=”P5-B0110”> <ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”Q33.6”> <ATTR NAME=”Diagnosis” TYPE=Text” VALUE=”secundäre Lungenhypoplasie”> <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>
64
Im ersten Schritt ist der Anschluß folgender Subsysteme vorgesehen:
Jedes Subsystem wird zu einem Knoten, wobei ein Windows-NT-Server mehrere Knoten aufnehmen kann. Zu den den Subsystemen zugehörigen Knoten kommen zwei weitere Knoten dazu. Der erste ist der Referenzknoten und hat den medizinischen Kontext ”System”. Der zweite ist ein Knoten für nicht subsystemgebundene, allgemeine Anfragen. Beispielsweise können hier Studenten oder interdisziplinäre Forschungsgruppen nicht-patienten- und nicht-personengebundene Studien vornehmen. Somit sind folgende Knoten notwendig:
Im folgenden werden diese Knoten näher beschrieben.
Die hier zu behandelnde Punktionsdatei enthält primär Informationen zu invasiven Maßnahmen, die in der pränatalen Diagnostik vorgenommen wurden. Diese Maßnahmen werden Zeile für Zeile eingegeben. Das Merkmal der Punktionsdatei ist es, daß die Datenbank keine eigentlichen Schlüssel besitzt. Die Informationen über die Patientin werden in vollem Umfang mit Namen, Vornamen, Geburtsort/Geburtsdatum und Adresse gespeichert.
Der virtuelle Befundtreiber für diesen Knoten muß daher eine eigene Tabelle für die Verwaltung der lokalen Identifikationen sowie für deren Umrechnung in das globale System besitzen.
Der zugehörige medizinische Kontext lautet:
<MEDICALCONTEXT NAME=”Prenatal-Invasive” INTERNAL-ID =”x.x.x.x:3031/4712” EXTERNAL-ID=”invasive@prenatal.ufk.charite.hu-berlin.de” CODEBASE=”ufk-science.charite.hu-berlin.de/data/reference-server/prenatalcontext/md.exe>
<ATTR NAME=”Scope” TYPE=”Text” VALUE=”SNOMED V3.3” >
<ATTR NAME=”Language” TYPE=”Text” VALUE=”EN” >
<GROUP NAME=”Patient”>
<ATTR NAME=”Sex” TYPE=”Text” VALUE=”female”>
<ATTR NAME=”MaxAge” TYPE=”Integer” VALUE=”50”>
<ATTR NAME=”MinAge” TYPE=”Integer” VALUE=”10”> ....
</GROUP>
<GROUP NAME=”ListOfOrgane”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Placenta”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Fetus”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Uterus”> ...
</GROUP>
65
<GROUP NAME=”ListOfProcedures”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”CVS”>
<ATTR NAME=”Procedure” TYPE=”SNOMED V3.3” VALUE=”P2-00020”> ...
</GROUP>
<GROUP NAME=”ListOfDiagnosis”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”Q33.6”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=” secundäre Lungenhypoplasie”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”P27.0”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=” hypoplastische Nabelschnurarterie links”> ...
</GROUP>
</MEDICALCONTEXT>
Die im Kreißsaal verwendete Datenbank erfaßt die geburtshilflichen Informationen. Primär sind es Daten über die Geburten selbst mit Angaben über die Schwangerschaft, die Entbindung und das Kind bzw. die Kinder. Diese Datenbank wird wie ein Geburtenbuch organisiert. Ihr Merkmal ist es, daß die Daten jahresweise organisiert werden, wobei die Geburten innerhalb eines Jahres mit einer Geburtennummer als Schlüssel versehen werden. Ähnlich wie bei der Punktionsdatei muß hier der virtuelle Befundtreiber eine eigene Verwaltung und Umrechnung der Schlüssel für die Patientinnen und für die ”Behandlungen” (Entbindungen bzw. Operationen) besitzen.
Der zugehörige medizinische Kontext lautet:
<MEDICALCONTEXT NAME=”Obstetrics” INTERNAL-ID =”x.x.x.x:3031/4713” EXTERNAL-ID=”xx@obstetrics.ufk.charite.hu-berlin.de” CODEBASE=”ufk-science.charite.hu-berlin.de/data/reference-server/obstetricscontext/md.exe>
<ATTR NAME=”Scope” TYPE=”Text” VALUE=”SNOMED V3.3” >
<ATTR NAME=”Language” TYPE=”Text” VALUE=”EN” >
<GROUP NAME=”Patient”>
<ATTR NAME=”Sex” TYPE=”Text” VALUE=”female”>
<ATTR NAME=”MaxAge” TYPE=”Integer” VALUE=”50”>
<ATTR NAME=”MinAge” TYPE=”Integer” VALUE=”10”> ....
</GROUP>
<GROUP NAME=”ListOfOrgane”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Placenta”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Fetus”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Uterus”> ...
</GROUP>
<GROUP NAME=”ListOfProcedures”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”OBSTETRICS: EXCISIONS”>
<ATTR NAME=”Procedure” TYPE=”SNOMED V3.3” VALUE=”P1-86300”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Classical cesarean section”>
<ATTR NAME=”Procedure” TYPE=”SNOMED V3.3” VALUE=”P1-86311”> ...
</GROUP>
<GROUP NAME=”ListOfDiagnosis”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=” P 27.0”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=” hypoplastische Nabelschnurarterie”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=” P 02”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=” Minderwuchs”> ...
</GROUP>
</MEDICALCONTEXT>
Der Pränatale Knoten basiert auf einem Ultraschall-Befund- und -Archivierungssystem. Dieses ist ein System aus mehreren Servern, wobei der Anwendungs-Client sich immer an den Anwendungs-Server wendet, um die Anwendung nutzen zu können. Die Datenbank dieses Subsystems hat sowohl Schlüssel für die Untersuchun
66
gen als auch für die Patientinnen. Die Umsetzung dieser Identifikationen erfolgt gemäß Abschnitt 4.4.1 Objekt-Identifikation .
Die interne Struktur dieses Subsystems ist zwar recht komplex (siehe Abbildung 4-8 ). Diese Komplexität bleibt dem AMICI-Knoten jedoch verborgen. Er nimmt lediglich Kontakt mit seinem Ansprechpartner - dem virtuellen Befundtreiber - auf.
Abbildung 4-7: Struktur des Ultraschall-Befund- und -Archivierungssystems
Dem Befund- und Archivierungssystem erscheint der Pränatal-Ultraschall-Knoten wiederum als ein gewöhnlicher Client. Dieser führt lediglich besondere Funktionen aus, was dem Subsystem jedoch nicht bekannt sein muß. Die Kommunikation zwischen dem Befundsystem und dem Pränatal-Knoten erfolgt gemäß AMICI-Konzept über den virtuellen Befundtreiber. Der Pränatal-Ultraschall-Knoten-Server ist ein Windows NT-Server mit der Konfiguration gemäß Abbildung 4-2 . Der zugehörige medizinische Kontext lautet:
<MEDICALCONTEXT NAME=”Prenatal-US” INTERNAL-ID =”x.x.x.x:3031/4711” EXTERNAL-ID=”us@prenatal.ufk.charite.hu-berlin.de” CODEBASE=”ufk-science.charite.hu-berlin.de/data/reference-server/prenatalcontext/md.exe>
<ATTR NAME=”Scope” TYPE=”Text” VALUE=”SNOMED V3.3” >
<ATTR NAME=”Language” TYPE=”Text” VALUE=”EN” >
<GROUP NAME=”Patient”>
<ATTR NAME=”Sex” TYPE=”Text” VALUE=”female”>
<ATTR NAME=”MaxAge” TYPE=”Integer” VALUE=”50”>
<ATTR NAME=”MinAge” TYPE=”Integer” VALUE=”10”> ....
</GROUP>
<GROUP NAME=”ListOfOrgane”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Placenta”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Fetus”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Uterus”> ...
</GROUP>
<GROUP NAME=”ListOfProcedures”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Ultrasound”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Color-Doppler”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”3D-Color-Dopller”> ...
</GROUP>
67
<GROUP NAME=”ListOfDiagnosis”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”Q0”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=”xxxx”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”P0”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=”xxxx”> ...
</GROUP>
</MEDICALCONTEXT>
Der Fetalautopsie-Knoten ist eine Eigenentwicklung. Die Basisdatenbank ist in MS Access realisiert. Die Struktur dieser Datenbank ist schon nach dem allgemeinen Objektkonzept ausgerichtet. Ein Merkmal dieser Datenbank ist, daß alle Objekte ein eigenes Schlüsselsystem haben: Untersuchungen, Patienten (Fetus), Organe, Methoden, Bilder, etc. Der zugehörige medizinische Kontext lautet:
<MEDICALCONTEXT NAME=”Fetalautopsy” INTERNAL-ID =”x.x.x.x:3031/4714” EXTERNAL-ID=”autopsy@fetal.ifp.charite.hu-berlin.de” CODEBASE=”ifp-science.charite.hu-berlin.de/data/reference-server/pathologycontext/md.exe>
<ATTR NAME=”Scope” TYPE=”Text” VALUE=”SNOMED V3.3” >
<ATTR NAME=”Language” TYPE=”Text” VALUE=”EN” >
<GROUP NAME=”Context”>
<GROUP NAME=”Patient”>
<ATTR NAME=”Sex” TYPE=”Text” VALUE=”female”>
<ATTR NAME=”MaxAge” TYPE=”Integer” VALUE=”50”>
<ATTR NAME=”MinAge” TYPE=”Integer” VALUE=”10”> ....
</GROUP>
<GROUP NAME=”ListOfOrganes”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Placenta”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”Uterus”> ...
</GROUP>
<GROUP NAME=”ListOfProcedures”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Autopsy”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Macroscopy”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Microscopy”> ...
</GROUP>
<GROUP NAME=”ListOfDiagnosis”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”P0”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=”xxxx”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”P1”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=”xxxx”> ...
</GROUP>
</GROUP>
<GROUP NAME=”Context”>
<GROUP NAME=”Patient”>
<ATTR NAME=”Name” TYPE=”Text” VALUE=”Fetus”>
<ATTR NAME=”Sex” TYPE=”Text” VALUE=”don’t care”>
<ATTR NAME=”MaxAge” TYPE=”Integer” VALUE=”45” UNIT=”WoG”>
<ATTR NAME=”MinAge” TYPE=”Integer” VALUE=”0” UNIT=”WoG”> ....
</GROUP>
<GROUP NAME=”ListOfOrgane”>
<ATTR NAME=”Organe” TYPE=”Text” VALUE=”don’t care”>
</GROUP>
<GROUP NAME=”ListOfProcedures”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Autopsy”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Macroscopy”>
<ATTR NAME=”Procedure” TYPE=”Text” VALUE=”Microscopy”> ...
</GROUP>
68
<GROUP NAME=”ListOfDiagnosis”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”Q0”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=”xxxx”>
<ATTR NAME=”Diagnosis” TYPE=”ICD-10” VALUE=”Q1”>
<ATTR NAME=”Diagnosis” TYPE=”Text” VALUE=”xxxx”> ...
</GROUP>
</GROUP>
</MEDICALCONTEXT>
Erläuterung
Hier werden im Gegensatz zum Pränatal-Ultraschall-Kontext 2 Patiententypen eingetragen: die schwangere Frau und das Fet. Für jeden Patiententyp wird ein eigener Kontext angelegt.
Der HL7-Knoten basiert auf dem HL7-Server, der ursprünglich für die Erfassung der Patientenstammdaten für das Charité-Tumorzentrum konzipiert wurde.
Abbildung 4-8: Struktur des HL7-Servers
Der HL7-Server läuft aus Sicherheitsgründen auf einem System von verteilten und replizierten auf SyBase basierten Datenbankservern, das die Patienten-Stammdaten zwischenpuffert. Diese Server werden vom Kommunikationsserver des Charité-Rechenzentrums CAI über eine Transaktionsanwendung TAA (Modul ISH der Firma SAP bzw. System Clinicom der Fa. SMS) gespeist. Der HL7-Server bereitet die Daten auf und bietet den anfragenden Subsystemen durch Abfrage nur die Stammdaten an, die das Subsystem auch benötigt. Somit muß nicht jedes Subsystem die Stammdaten speichern bzw. zwischenspeichern. Im Gegensatz zu anderen HL7-Servern, die nach dem Broadcasting-Prinzip arbeiten, in dem die in der Patientenverwaltung stattfindenden Transaktionen wie Aufnahme, Verlegung und Entlassung als Nachrichten an alle Interessenten automatisch und ständig verschickt werden, bietet dieser HL7-Server die Daten per Abfrage an. Sie werden nur bei Bedarf vom
69
HL7-Server an den anfragenden Client geschickt. Der HL7-Server übernimmt ferner die Verwaltung von Zugangsberechtigungen, um den Datenschutz und die Datensicherheit zu gewährleisten. Dies betrifft auch den Schutz klinikinterner Daten.
Der AMICI-HL7-Knoten bedient sich dieses HL7-Servers und ist verantwortlich für die einheitliche Versorgung des AMICI-Netzes mit Patienteninformationen. Ein virtueller HL7-Treiber verpackt den HL7-Server mit der AMICI-Funktionalität, so daß der HL7-Anschluß gewährleistet ist.
Der zugehörige medizinische Kontext lautet:
<MEDICALCONTEXT NAME=”Admin” INTERNAL-ID =”x.x.x.x:3031/4715” EXTERNAL-ID=”patient@Admin.charite.hu-berlin.de” CODEBASE=”admin.charite.hu-berlin.de/data/reference-server/admincontext/md.exe>
<ATTR NAME=”Scope” TYPE=”Text” VALUE=”HL7 V2.2” >
<ATTR NAME=”Language” TYPE=”Text” VALUE=”DE” >
<GROUP NAME=”Patient” MATCH=”yes”>
<ATTR NAME=”Sex” TYPE=”Text” VALUE=”don’t care”>
<ATTR NAME=”MaxAge” TYPE=”Text” VALUE=” don’t care”>
<ATTR NAME=”MinAge” TYPE=”Integer” VALUE=” don’t care”> ....
</GROUP>
</MEDICALCONTEXT>
Der allgemeine Knoten hat kein eigentliches medizinisches Subsystem als Basis. Er fragt je nach Anfrage vom Client die Knoten im Netz ab. Sein medizinischer Kontext ist standardmäßig leer. Hier lassen sich jedoch beliebige medizinische Kontexte, beispielsweise für Studienzwecke dynamisch generieren.
Der Referenzknoten hat ebenfalls kein eigentliches medizinisches Subsystem als Basis. Hier werden die Systemdaten wie alle medizinischen Kontexte, der Namensraum, die Liste der gültigen Primitiva, die URL-Codebases für die Objekte und die Benutzer mit ihren Rechten und Autorisierungen, etc. verwaltet.
Obwohl dieser Knoten kein medizinisches Subsystem im Hintergrund besitzt, hat er jedoch einen virtuellen Befundtreiber, der die dort verwalteten Daten weitergibt.
Der zugehörige medizinische Kontext lautet:
<MEDICALCONTEXT NAME=”System” INTERNAL-ID =”x.x.x.x:3031/4710” EXTERNAL-ID=”system@amici.charite.hu-berlin.de” CODEBASE=”amici.charite.hu-berlin.de/data/reference-server/systemcontext/md.exe>
<ATTR NAME=”Scope” TYPE=”Text” VALUE=”SNOMED V3.3” MATCH=”no”>
<ATTR NAME=”Language” TYPE=”Text” VALUE=”EN” MATCH=”no”>
</MEDICALCONTEXT>
Die Untersuchung umfaßte ebenfalls eine Testimplemetation, die an folgenden Subsytemen vorgenommen wurde:
Die Testimplementation diente folgenden Zwecken:
70
Bis auf das Subsystem Pränatalultraschall, bei dem die Befunddaten verschüsselt in der Datenbank abgelegt werden, konnte die Semantik der restlichen Daten mit Hilfe von Abgleichen zwischen Datenbankinhalt und herkömmlichen Befunden festgestellt werden. Für den Zugriff auf die Pränatalultraschalldaten lieferte der Hersteller die Software für die Konvertierung der verschlüsselten Daten in eine SyBase-Datenbank im Klartext. Somit konnte auf alle Fremddaten ungehindert zugegriffen werden. Der Zugriff erfolgte über verschiedene ODBC-Treiber.
Mit eigener Software konnten ferner Zugriffseinschränkungen ohne weiteres aufgehoben werden. Beispielsweise konnte bei der Punktionsdatei mit der Originalsoftware nur jahresweise gearbeitet werden. Die eigene Software verarbeitet alle Jahrgänge von 1986 bis heute.
Ist der gleichzeitige Zugriffe auf mehrere Datenbestände möglich, so lassen sich viele Auswertungen vornehmen, die bisher nicht möglich waren. Beispielsweise kann der Anwender alle relevanten Informationen aus mehreren Datenbanken verwenden, die einen Patienten/eine Patientin betreffen. Somit lassen sich Krankengeschichten besser konstruieren. Eine andere Möglichkeit besteht der Abgleich verschiedener Datenbanken.
Tabelle 4-2 Verteilung eines Diagnosetextes in verschiedenen Schreibweisen
|
Diagnose |
Anzahl |
Diagnose |
Anzahl |
Diagnose |
Anzahl |
|
Zyogenetik |
9 |
Zytogenetikj |
1 |
Zytogenwetik |
1 |
|
Zytgenetik |
3 |
ZytogenetikKary |
1 |
Zytogernetik |
1 |
|
Zytoenetiik |
1 |
Zytogenetilk |
1 |
Zytoggenetik |
1 |
|
Zytoenetik |
8 |
Zytogenetk |
7 |
Zytognetik |
1 |
|
Zytogebnetik |
1 |
Zytogenezik |
1 |
Zytonetik |
1 |
|
Zytogeneik |
13 |
Zytogeneztik |
1 |
Zytoogenetik |
1 |
|
Zytogenetik |
1719 |
Zytogenik |
1 |
Zytotogenetik |
1 |
|
Zytogenetik 2 |
1 |
Zytogenmetik |
1 |
Zytpogenetik |
1 |
|
ZytogenetikAZ |
1 |
Zytogennetik |
1 |
Zytzogenetik |
1 |
|
ZytogenetikCVS |
1 |
Zytogentik |
3 |
Zyzogenetik |
1 |
In der Testimplementation wurden die GebDat-Datenbank mit 6919 Datensätzen und die Punktionsdatei mit 25605 Datensätzen miteinander abgeglichen, um zu überprüfen, ob die Adressen der Patientinnen in beiden Datenbanken noch übereinstimmen. Von den 6919 GebDat-Datensätzen sind 5248 Patientinnen auch in der Punktionsdatei enthalten, davon sind 58 Datensätze (1%), bei denen die Postleitzahlen übereinstimmen. Beim Abgleich der Straßennamen fanden sich 680 gleiche Einträge (13%) . Der Grund für die schlechte Übereinstimmung von 1% war, daß die eine Datenbank schon und die andere noch nicht auf die 5stellige PLZ umgestellt worden ist. Bei den Straßennamen lag der Grund in den verschiedenen Schreibweisen. Wie die Schreibweisen die Ergebnisse einer Auswertung verfälschen können, zeigt die Tabelle 4-2 , die die Verteilung der Diagnoseeingabe ”Zytogenetik” auf 30 verschiedenen Schreibweisen in einer Datenbank wiedergibt. Mit dieser Art der Abfrage ließe sich die Aktualisierung bzw. die Korrektur einer Datenbank mit Hilfe anderer, korrekterer Datenbestände ohne weiteres durchführen.
71
Der Abgleich der Daten aus mehreren Datenbeständen bereitete erwartungsgemäß Probleme bei der Identifikation der Patientinnen und der Untersuchungen, die naturgemäß in den Subsystemen unterschiedlich verwaltet werden.
In der Testimplementation wurden Antwortzeiten für verschiedene Zugriffsarten in der Abendzeit zwischen 17.00 und 20.00 Uhr gemessen. Zu dieser Zeit war kein nennenswerter Routinebetrieb mehr zu erwarten, der Einflüße auf die Messung haben konnte. Es wurde die Zugriffszeit für verschiedene Zugriffsarten an drei Systemen - jeweils mit der Originalversion und der eigenen Testimplementierung - gemessen. Jede Messung wurde 10 mal wiederholt. Die eigenen Versionen wurden mit Microsoft Visual C++ Version 5.0 bzw. Microsoft Access Version 5.0 und den entsprechenden ODBC-Treibern entwickelt.
Tabelle 4-3 Antwortzeitverhaten von Originalversion und Testimplementation
| Zugriffsart | Durchschnittliche Zugriffszeit [sek], [%] | Bemerkung Notiz |
||||||||
| System 1 | System 2 | System 3 | ||||||||
|
Ori |
E |
D% |
Ori |
E |
D% |
Ori |
E |
D% |
||
|
Suche eines Datensatzes |
< 1 |
< 1 |
0 |
< 1 |
< 1 |
0 |
< 1 |
< 1 |
0 |
|
|
Laden Befund mit Bildern |
50,6 |
29,5 |
-42 |
- |
- |
- |
- |
- |
- |
|
|
Starten der Anwendung |
12,1 |
9,5 |
-21 |
2,0 |
3,8 |
+90 |
8,0 |
2,4 |
-70 |
selten verwendet |
|
Liste aller Datensätze |
- |
50,6 |
- |
- |
9,7 |
- |
- |
4,9 |
- |
|
|
Statistik für einen Monat |
- |
- |
- |
10,6 |
19,3 |
+82 |
- |
- |
- |
|
|
Suche mit Suchmaske |
- |
< 1 |
- |
- |
< 1 |
- |
- |
< 1 |
- |
|
Tabelle 4-3 faßt die Ergebnisse der Messungen zusammen. Die am häufigsten benutzte Zugriffsart ist der Zugriff auf einen ausgewählten Datensatz. Hierbei konnnte wegen der bei beiden Versionen erzielten sehr geringen Zugriffszeiten kein Unterschied festgestellt werden. Die Zeit für den Start einer Anwendung variierte sehr stark: zwischen -70% und +90%. Diese Zugriffsart spielt jedoch keine wesentliche Rolle, da sie nur selten verwendet wird. Die anderen, häufig benötigten Zugriffsarten wie Liste aller Datensätze, Statistik für einen Monat und Suche mit Suchmaske werden leider von den meisten Originalversionen nicht angeboten.
© 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.
|
DiDi DTD Version 1.1 a subset from ETD-ML Version 1.1 |
Zertifizierter Dokumentenserver der Humboldt-Universität zu Berlin |
HTML - Version erstellt am: Tue Jun 9 12:35:01 1998 |