Konformitätskriterien

Aus Hl7wiki
(Teildokument von IHE Cookbook)
Wechseln zu: Navigation, Suche
Dieses Material ist Teil des Leitfadens IHE Cookbook.
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Konformitätskriterien

IHE hat einen Prozess etabliert, um Spezifikationen zu erstellen, die öffentlich, allgemein verfügbar und abgestimmt sind. Dies erfolgt in einem Zyklus, der sich jährlich wiederholt:

IHE cookbook zyklus.jpg

Abbildung 37: Der IHE-Zyklus

Es beginnt mit der Sammlung der Anforderungen seitens der Anwender, welches Szenarium zu realisieren ist und welcher dazugehörige Workflow etabliert werden soll. Das kann dann bspw. die Auftragskommunikation zur Radiologie unter Einbeziehung bildgebender Geräte und des Archives oder aber das Drucken von Barcode-Etiketten im Labor sein. Wenn der Workflow beschrieben ist, wird nach verfügbaren Standards gesucht, die zur Umsetzung eingesetzt werden können. Hierbei kommt dann häufig HL7, DICOM, ebXML oder auch NTP zum Einsatz. Diese Standards werden dann für die Nutzung innerhalb des Use Cases genauer spezifiziert. (Dieser Vorgang bezeichnet man als Profilierung und ist nachfolgend noch einmal näher erläutert.) Typischerweise entsteht dann eine Vorabspezifikation, die aus 2 Teilen besteht. Im ersten Teil ist der Workflow beschrieben, der dann als „Integration Profile" bezeichnet wird und die Interaktion zwischen verschiedenen Akteuren enthält. Beispiele dazu (wie XDS, ATNA oder CT) sind im Hauptteil dieses Cookbooks bereits aufgeführt. Im zweiten Teil sind dann die Transaktionsdetails auf Basis der verwendeten Standards genau dokumentiert, so dass ein Hersteller diese direkt implementieren kann.

Die dazu entstandene Software kann danach auf dem sog. Connect-a-thon getestet werden. Dieser Begriff ist ein Kunstwort, das sich aus „Connect" und „Marathon" zusammensetzt und im Prinzip eine einwöchige Veranstaltung bezeichnet, auf der sich viele Hersteller treffen, über eine LAN-Party direkt vernetzen und in einer geschützten Umgebung die neu entwickelte Software gegen- bzw. miteinander auf Einhaltung der Spezifikation und korrekten Umsetzung der Funktionalität testen können. Dies erfolgt unter Aufsicht sog. „Monitore" – das sind unabhängige Experten, die die umzusetzenden Spezifikationen im Detail kennen und entscheiden können, ob ein Hersteller die Spezifikation korrekt implementiert hat. Wenn das der Fall ist und der Hersteller in drei Tests mit unterschiedlichen Partnern dies demonstrieren kann, dann gilt die Vorgabe als erfüllt und der Hersteller bekommt dies als erfolgreiche Teilnahme bescheinigt.

Dies ist dann wiederum die Grundlage für die sog. Integration Statements als Konformitätserklärung (s.u.), die angibt, welche Akteure aus welchen Integrationsprofilen seine Software realisieren kann. Auf dieser Basis werden dann Showcases auf größeren Messen wie der HIMSS in den USA, der woHIT in Europa oder dem DRK in Deutschland durchgeführt. Gleichzeitig wird damit demonstriert, dass die neue Spezifikation geeignet ist, um den beschriebenen Use Case zu realisieren. Diese wird dann als Technical Framework auf [www.ihe.net-http://www.ihe.net/] veröffentlicht.

Konformitätserklärung von Herstellern

Das IHE Integration Statement ist eine Konformitätserklärung eines Herstellers für seine Software:

IHE Integration Statement
Vendor Product Name Version Date
Super Vision Inc. SuperVision 7.5.3 2011
This product implements all transactions required in the IHE Technical Framework to support the IHE Integration Profiles, Actors and Options listed below:
Integration Profiles Implemented Actors Implemented Options Implemented
Consistent Time (CT) http://ihe.univ-rennes1.fr/TF/actor.php?actor=TIME_CLIENT (TIME_CLIENT) Time Client  
Patient Administration Management (PAM) (PDS) Patient Demographics Consumer Merge Option
(PES) Patient Encounter Consumer  
Patient Information Reconciliation (PIR) (OP) Order Placer  
Scheduled Workflow (SWF) (OP) Order Placer  
Internet address for vendor’s IHE information: www.supervision.com/ihe
Links to Standards Conformance Statements for the Implementation
HL7 www.supervision.com/hl7
DICOM www.supervision.com/dicom
Links to general information on IHE
North America: www.ihe.net Europe: www.ihe-europe.net Japan: www.jira-net.or.jp/ihe-j

Abbildung 38 IHE Integration Statement

Diese enthält neben Detailangaben zum Produkt auch eine Liste der umgesetzten Integrationsprofile nebst den dazugehörigen Akteuren. Einige Integrationsprofile (wie bspw. PAM) erfordern noch eine weitere Präzisierung hinsichtlich geforderter Optionen innerhalb des Profils. So muss bei Patient Administration Management angegeben werden, ob die Software die „Merge" oder „Link"-Option realisiert hat, denn eines von beiden muss vorhanden sein. Auf dieser Basis kann dann leichter entschieden werden, ob zwei Softwarekomponenten unterschiedlicher Hersteller zueinander kompatibel sind oder nicht.

Anwender können bei ihrer Suche nach geeigneten Softwarekomponenten auf diese Konformitätserklärungen zurückgreifen, in dem in Ausschreibungen direkt danach gefragt wird.

Profilierungsmechanismen

Jeder Kommunikationsstandard besitzt eine mehr oder weniger große Anzahl an Nachrichten mit Feldern und ggf. Komponenten, die entweder verpflichtend („muss"), optional („kann") oder verboten sind. Damit sind dann eine Reihe von Wahlmöglichkeiten bei dem Einsatz dieser Standards geschaffen, die Konfliktpotential bergen.

Für den Einsatz in einem konkreten Szenarium muss der Grundlagenstandard eingeschränkt werden, d.h. einige der ursprünglich vorhandenen Wahlmöglichkeiten werden weiter präzisiert. So muss bei einem internationalen Standard bspw. angegeben werden, wie mit deutschen Besonderheiten (Namen oder Adressen) umzugehen ist:

IHE Cookbook-conf kriterien.gif

Abbildung 39 Konformanzkriterien

Dieser Prozess des Einschränkens kann iterativ geschehen, indem immer mehr Optionen weggenommen werden, bis letztendlich keinerlei Wahlmöglichkeit mehr besteht. Man spricht hier von „constrainable profiles" (mit noch vorhandenen Optionen) und „implementable profiles" (keine Optionen mehr vorhanden).

Dabei kann es bei internationalen Standards mitunter auch passieren, dass Ergänzungen vorgenommen werden müssen, die dann quasi Erweiterungen außerhalb des Standards darstellen. Derartige Notwendigkeiten sollten dann aber Anlass sein, eine offizielle Erweiterung des Standards zu beantragen, um diesen Zustand zu beheben.

Natürlich sind bei der Festlegung von Einschränkungen Regeln einzuhalten, wie derartige Einschränkungen vorzunehmen sind, damit keine Widersprüche entstehen:

IHE Cookbook conf uebergang.gif

Abbildung 40 Konformanzübergänge

So müssen einmal verpflichtend gemachte Elemente („muss") immer verpflichtend bleiben. Das gleiche gilt für verbotene Elemente. Für optionale Elemente hingegen, kann entschieden werden, sie entweder verpflichtend zu machen oder sogar zu verbieten. So ist bspw. bei den deutschen Nachrichtenprofilen entschieden worden, aufgrund der deutschen Gesetzgebung die Information zu Rasse zu verbieten.

Spezifikationen ohne jegliche Optionen werden letztendlich nur von Herstellern herausgegeben. (Nationale) Vorgaben umfassen immer nur Teileinschränkungen auf den gesamten Standard und beinhalten somit immer noch Wahlmöglichkeiten, bei denen sich der Hersteller entscheiden muss, ob er dies umsetzt oder nicht.

Neben diesen grundsätzlichen Einschränkungsmechanismen gibt es noch eine Reihe weiterer Details, die es zu berücksichtigen gilt. Dazu gehören dann Kardinalitäten, Längenangaben, Vokabularienbindung mit Value Sets etc., was aber hier nicht weiter ausgeführt werden soll.

Conformance Statements

Umgekehrt sollte ein Hersteller nun für seine Schnittstelle präzise angeben können, welche Informationen berücksichtigt werden und welche nicht. Eine Aussage wie „optional" – was hier einem „weiß ich nicht" entspricht – sollte nicht vorkommen.

Eine derartige Detailspezifikation wird Conformance Statement genannt und in verschiedenen Detaillierungsgraden ausgeführt. Bei DICOM ist dies relativ oberflächlich, HL7 v2.8 geht hier bis ins kleinste Detail.

Je präziser eine derartige Dokumentation ist, desto leichter lässt sich die Kompatibilität der Software feststellen.

Konformanzprüfung

Die wahrscheinlich interessanteste Frage beim Einsatz von Schnittstellen zur Verbindung zweier Systeme ist wohl nach der Kompatibilität dieser beiden Systeme, d.h. können 2 Systeme problemlos untereinander Daten austauschen, wenn beide sich nach derselben Vorgabe richten oder nicht?

IHE Cookbook profil hierarchie.gif

Abbildung 41 Profilhierarchien

Wie unter Berücksichtigung der o.g. Regeln wohl relativ leicht einzusehen ist, muss diese Frage leider mit „NEIN" beantwortet werden, weshalb die Dokumentation einer Schnittstelle einen sehr hohen Stellenwert in Bezug auf die Frage nach semantischer Interoperabilität einnimmt.
Auf die damit verbundenen Möglichkeiten des Offline-Tests hinsichtllich Schnittstellenkompatibilität von Softwarekomponenten soll an dieser Stelle allerdings nicht weiter eingegangen werden.