Conformance Statements in der Version 2.4

Im November letzten Jahres wurde die neue Version 2.4 freigegeben. In der letzten Ausgabe der HL7-Mitteilungen ist auf die wesentlichen Änderungen schon eingegangen worden. Dabei konnten die sogenannten Conformance Statements aber nur in aller Kürze erläutert werden.

Fast alle der im Standard angegebenen Ereignisse und Nachrichten funktionieren nach dem oben schematisch aufgezeichneten Prinzip: Im Standard sind eine Reihe von Ereignissen und den dazugehörigen Nachrichten spezifiziert. Sollte nun bei einem System eines dieser Ereignisse auftreten, so verschickt dieses System die dazugehörige Nachricht. Ein vorhandener "Verteilmechanismus" sorgt nun dafür, daß alle angeschlossenen Systeme eine Kopie dieser Nachricht erhalten. An dieser Stelle spielt es keine Rolle, ob dieser Verteilmechanismus im sendenden System eingebaut ist oder ein Kommunikationsserver für die Verteilung der Nachrichten sorgt.

Ein zweiter Grund Nachrichten zu versenden ist, bei Nichtvorhandensein von Informationen eine Anfrage an das entsprechende System zu schicken und konkret danach zu fragen:

Wofür benötigt man Conformance Statements, wenn im Standard alle notwendigen Ereignisse und die dazugehörigen Nachrichten definiert sind? Die Conformance Statements stellen nun einen Formalismus dar, um die beiden o.g. Mechanismen in eigenen Spezifikationen nutzen zu können: Typischerweise sind die meisten Applikationen auf bestimmte Anwendungsgebiete spezialisiert und würden gerne eine Auswahl an Funktionen exportieren. Damit ein anderes System diese Funktionen nutzen kann, muß es sich entsprechend - konform - verhalten. Welche Implementierungsdetails dazu berücksichtigt werden müssen, werden in diesen Conformance Statements vom Hersteller des Systems genau festgelegt und seinen Kommunikationspartnern zur Verfügung gestellt.

Die verschiedenen Aspekte, die mit Hilfe von Conformance Statements ausgedrückt werden können, spannen einen dreidimensionalen Raum auf, der nun näher betrachtet werden soll:

Je nach Szenario kann man grundsätzlich drei Frage/Antwort-Modelle unterscheiden:

Die erste Art und Weise ist zugleich die einfachste: Sie folgt dem einfachen Schema "Nenne mir ..." und gehorcht damit dem bisher genutzten Vorgehen.

Die imperative Nutzung erlaubt den "Export" von systeminternen - applikationsspezifischen - Aktionen, also das Anstoßen interner Funktionen von außen über HL7-Nachrichten. Die Frage ist also die Aufforderung, etwas zu tun. Die dazu passende Antwort ist dann die Bestätigung, ob die Anfrage ausgeführt worden ist. Zum Beispiel könnten Formulare gedruckt werden.

Die deklarative Vorgehensweise ist eigentlich auch nicht neu, ist sie doch nichts anderes als das Veröffentlichen von neuen systemspezifischen Ereignissen, für die sich andere Systeme interessieren könnten und dann in die Verteilerliste einschreiben: "Publish and Subscribe". Beispielsweise könnte ein OP-System automatisch eine Nachricht (an das Com-Center) senden, wenn alle OP-Säle belegt sind, um dann schwere Notfälle in ein anderes Krankenhaus umzuleiten.

Conformance Statements bestehen nun aus mehreren Teilen, die entsprechend den Erfordernissen kombiniert werden können. Jeder Teil kann dabei in Form einer einfachen Tabelle angegeben werden:

Die Einleitung dient lediglich der Festlegung der Event-Codes einschließlich der Nachrichtentypen und ein paar weiterer Angaben wie bspw. der Art und des Zweckes des Conformance Statements:

Viel wichtiger ist jedoch die Festlegung, wie die Nachrichten aussehen sollen. Hierzu können die bereits vielfach genutzten Nachrichtentabellen verwendet werden, die vorhandene Segmente hintereinander anordnen und gruppieren. Die Ergänzung um drei weitere Spalten erlaubt zusätzliche Angaben, um Wiederholungsgruppen von Segmenten gezielt zu kennzeichnen oder Kommentare und Kennzeichen zwecks Unterstützung einzelner Segmente hinzuzufügen. Hierüber läßt sich gezielt angegeben, bis zu welcher Tiefe die Nachrichtenstruktur bei einer Antwort gefüllt/genutzt werden soll. Beispielsweise kann im nachfolgenden Ausschnitt einer ORU-Nachricht angegeben werden, ob in der Antwort nur die OBR-Gruppe (OBRG) oder auch die OBX-Gruppe (OBXG) gefüllt werden soll.

Wenn keine Besonderheiten vorliegen und segmentorientierte Nachrichten genutzt werden, so reichen diese beiden Konstrukte bereits aus, um ein Conformance Statement auszufüllen.

Interessant dürfte die Spezifikation einer Anfrage sein, die nach Daten fragt, die am besten in Form einer Tabelle arrangiert werden können. Dies ist dann sinnvoll, wenn kein passendes Segment vorhanden ist und das Ausfüllen mehrerer Segmente zu viel Overhead produziert. Beispielsweise könnte man nach allen Zimmern einschließlich des Start- und Endzeitpunkts fragen, in denen ein bestimmter Patient während eines bestimmten Aufenthaltes gelegen hat. Für diesen Zweck gibt es die virtuellen Tabellen.

Hierbei bedient man sich der RDT und RDF Segmente, mit denen Inhalt und Form der Tabelle beschrieben werden können. Dazu gehören die Datentypen der einzelnen Spalten, Optionalitäten und sonstige Bedingungen.

Neben Tabellen kann eine Anfrage auch mit fertig formatiertem Text beantwortet werden. In diesem Fall wird in einem Conformance Statement ein Beispiel für die zu erwartende Ausgabe angegeben.

Weiterhin kann in einem Conformance Statement noch der Umfang der Antwort kontrolliert werden. Im RCP-Segment wird angegeben, ob die Antwort mengenmäßig in der Anzahl Zeilen/Seiten/Zeichen oder der Tiefe der Nachricht (Group Control) eingeschränkt werden soll. In diesem Segment wird ebenfalls das Sortierkriterium festgelegt.

Bleibt neben dem Wie nur noch das Was zu klären: die genaue Spezifikation der Parameter, die in der Anfrage mitgeschickt werden müssen. Hierbei ist nicht nur die Bedeutung wichtig, sondern auch ob ein Parameter ggf. (als Default) weggelassen werden kann.

Hier existieren ebenfalls mehrere Möglichkeiten, die Kriterien für eine Anfrage festzulegen. Die einfachste ist die "Query by simple Parameters", bei der die Parameter als Felder der Reihe nach an das QPD-Segment angehängt werden. Hierdurch entfallen aufwendige Parsingmechanismen oder das Übermitteln mehrerer Segmente, um an die Werte zu gelangen. Der Inhalt des QPD-Segmentes ist im Conformance Statement unter Angabe der Felder mit Datentypen, Längenangaben sowie einer Beschreibung genau festzulegen, da dieses Segment bei jeder Anfrage anders aussieht.

Die zweite Möglichkeit ist "Query by Example", bei der die entsprechenden Felder in bekannten Segmenten ausgefüllt werden. Das ist in etwa dem bekannten Abfragemechanismus für Datenbanken vergleichbar, sagt man doch, welche Werte im Ergebnis vorkommen sollen.

Schließlich gibt es noch die QSC Variante: "Query by Search Criteria". Diese erlaubt komplexe Bedingungen unter Nutzung von Operatoren zu formulieren. Diese Art der Spezifikation ist am ehesten der WHERE-Klausel in SQL-Statements vergleichbar.

Die mit Conformance Statements bereitgestellten Formalismen reichen aus, um funktionelle Erweiterungen der eigenen Applikation über den Standard hinaus genau zu beschreiben und den Kommunikationspartnern zur Verfügung zu stellen. Natürlich kann mit dieser kurzen Einführung nicht weiter auf Details eingegangen werden, deshalb sei der interessierte Leser auf Kapitel 5 des Standards verwiesen.

Last Update : April 27, 2001