Konformitätskriterien
Dieses Material ist Teil des Leitfadens IHE Cookbook.
|
Inhaltsverzeichnis
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:
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:
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:
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?
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.
