Semantische Interoperabilität erfordert die richtigen Modelle und Code-Systeme: Eine Prüfung verschiedener Ansätze für Score Systeme

1. Einführung

Die Nutzung von Kommunikationsstandards wie HL7 [1], [2] ist eine Grundvoraussetzung, um semantische Interoperabilität überhaupt erreichen zu können. Nationale oder anwendungs¬spezifische Anforderungen können in Form von "constraint Profiles" ausgedrückt werden, die den zugrundeliegenden Standard weiter einschränken. Wenn ein Hersteller mit diesen Anforderungen konformant sein will, sollte er eine präzise Aussage über das treffen, was seine Schnittstellen erfordern bzw. voraussetzen [3]. Dies wird dann über sog. "implementable Profiles" ausgedrückt, die Einschränkungen der vorab genannten constrainable Profiles sind. Erfahrung zeigt, dass ein Standard die Bereitstellung einer derartigen Dokumentation erzwingen sollte, damit ein Hersteller eine HL7-Konformität überhaupt erklären darf [13].

Andererseits sind die genutzten Kommunikationsstandards (HL7 v2.x und V3) sehr mächtig und nicht immer selbst erklärend. Sie bieten einen riesigen Satz von Optionen an, um in unterschiedlichen Domänen anwendbar zu sein. Die Schaffung von Implementierungsleitfäden, die Teile des Standards erklären, ist eine unabdingbare Voraussetzung [4], [5]. Sie stellen eine klare Anleitung dar und helfen, den Standard zu verstehen und auf eine einheitliche Weise umzusetzen, um Inkompatibilitäten zu reduzieren. Sie enthalten Use Cases, Storyboards, dynamische und statische Modelle sowie Beispiele. Semantische Interoperabilität hängt von einem gemeinsamen Verständnis und Verwendung der Informationen und deren Instanzen ab, die auf gemeinsamen Konzepten und deren Interpretation einschließlich einer Konzept-Grammatik und einer ontologie-basierten Terminologie basieren. Sogar in einer deterministischen Welt von quantitativen Messungen führt eine Interpretation vielleicht zu unterschiedlichen Ergebnissen. Dies wird noch deutlicher, wenn nicht-deterministische Messungen oder zusätzlich Algorithmen benutzt werden, die ebenfalls harmonisiert werden müssen. Um Instanzen der realen Welt vergleichbar zu machen, werden sie transformiert oder zu einem neuen Ausdruck gruppiert, der Score genannt wird. Hierbei gilt es einige Anforderungen zu erfüllen, um semantische Interoperabilität auf Instanzenebene garantieren zu können.

In einigen Fällen können unterschiedliche Implementierungsleitfäden zum gleichen Thema eine Interoperabilität sogar verhindern: Die einfache Frage eines Entwicklers, wie ein "APACHE"-Score mit HL7 v2.x kommuniziert werden soll, führt zu erstaunlichen Ergebnissen, die nun aufgeführt werden sollen.

2. Methoden

Die obengenannte Frage initiierte eine Untersuchung über Scoresysteme im allgemeinen. Eine erste Suche innerhalb des Internets enthüllte viele (>100) unterschiedliche Scoresysteme, die in der medizinischen Domäne für unterschiedliche Zwecke und Fachrichtungen im Gebrauch sind: Apache, Apgar, Braden, Barthel, BMI, GCS, Gleason, MODS, SAPS, TISS, um nur einige bekannte Scoresysteme zu nennen. Begleitende Informationen sind in unterschiedlichen Formen verfügbar: als herunterladbares Dokument oder Webseiten, die die Inhalte beschreiben, als wissenschaftliche Dokumente über Nutzbarkeit und Ergebnis-Interpretation, und nicht zuletzt als MS-Excel-Tabelle oder aktive Webseiten für eine online Berechnung. Manchmal variieren die Spezifikationen für das gleiche Scoresystem ein klein wenig und stellen deshalb unterschiedliche Varianten dar.

Dieses Papier konzentriert sich weder auf die Nachprüfung von Scoresystemen noch auf die Kalkulation (Algorithmen) von den resultierenden Scoreergebnissen. Der wichtige Aspekt ist die Analyse und die Spezifikation der Details, die notwendig sind, um ein bestimmtes Scoresystem und seine Details innerhalb einer Nachricht oder eines Dokumentes zu identifizieren.

Für Interoperabilitätszwecke zwischen unterschiedlichen Anwendungen müssen geeignete Codes für beides zugewiesen werden: das Scoresystem und jedes seiner Details. Gegenwärtig stellt nur Snomed CT ([9]) für einige Scoresysteme Details mit einigen Codes in Form individueller Konzepte bereit. Diese Konzepte werden innerhalb der internen Achsen von Snomed CT in Form von Beziehungen zu anderen Konzepten organisiert, aber sie werden nicht als zu einem bestimmten Score gehörig identifiziert.

Das neuste Release des RELMA Werkzeuges für LOINC ([12]) stellt jetzt umfassende Informationen über einige Scoresysteme bereit. Man kann sogar urheberrechtliche Bemerkungen und Codes finden.

Beide Codesysteme stellen allerdings keine Anleitung bereit, wie dieses Codes -vorausgesetzt man kann sie auffinden mit Kommunikationsstandards kombiniert werden können, um eine interoperable Kommunikation zu unterstützen.

2.1. Der "holländische" Ansatz

Vor vier Jahren haben holländische HL7 Kollegen von NICTIZ begonnen, mehrere Scoresysteme zu analysieren (ca. 20) und Informationen über ihre Details zu sammeln. Basierend auf diesen Informationen entwickelten sie individuelle Domänen-Modelle für jedes Scoresystem unter Verwendung der HL7 V3 Methodologie.

Die folgende Grafik ist ein Beispiel für den "Barthel Index". Hier steht das Scoresystem in der Mitte und die zehn Komponenten arrangieren sich darum (Abb. 1).

Das zweite Problem ist nicht spezifisch für diesen Ansatz. Die Autoren der Modelle haben den Klassen proprietäre Codes zugewiesen. Das generische Modell, das im folgenden beschrieben wird, löst dieses Problem durch das Zuordnen von verschiedenen Codes für das gleiche Konzept und das Eintragen in der Datenbank. Auf diesem Weg können die proprietären Codes auf LOINC und Snomed CT gemappt werden.

Die Analyse der Definitionen jeweils eines Score-Systems hat gezeigt, dass sie sich unterscheiden können. Der holländische Barthel Index bspw. benutzt andere Werte, um die Ergebnisse darzustellen. Die Gesamtsumme reicht deshalb von 0 bis 30. Der deutsche Barthel Index hat hingegen einen Interpretationsbereich von 0 bis 100. Deshalb hat der Ergebniswert von 30 im holländischen System eine andere Interpretation als der gleiche Score für den deutschen Barthel Index. Als Konsequenz müssen sich die Konzepte unterscheiden, um das gesamte Scoresystem zu definieren. Dies kann deshalb nur mit anderen Codes realisiert werden.

3. Ergebnisse

Das allgemeine HL7 V3 Paradigma nutzt Codes als ein Mittel eindeutiger Identifikation. Diese Codes werden für Objektinstanzen wie Personen, ambulante und stationäre Aufenthalte, individuelle Diagnosen oder Maßnahmen benutzt. Sie haben gemeinsam, dass eine Interpretation während der Verarbeitung erforderlich ist. Offenbar scheint ein interpretativer Ansatz am besten geeignet zu sein, um Scoresysteme zu beschreiben. Dies führt zu einem generischen Ansatz.

3.1. Der generische Ansatz

Es sollte deshalb ein generisches Modell entwickelt werden, das ein Beschreiben aller Details fast aller Scoresysteme erlaubt. Die folgende Liste stellt einen Überblick über die Details bereit, die abgedeckt werden sollten:

• Scoresystem:
• Name (englisch und deutsch) inkl. Kurzbeschreibung.
• Autor.
  
• Referenzen/Hinweise (Hyperlinks zu Webinhalten).
  
• Zugeordnete Fachrichtungen.
• Status-Informationen.
  
• Grobe Berechnungsart.
• Hinweise auf Copyrights und Trademarks.
• Score Details:
• Mittels rekursiver Definition.
• Beschreibung (englisch + deutsch).
• Datentyp (Constraints) für:
  
• HL7 v2.x,
• HL7 V3.
• (erwartete) Werte für jedes Konzept.
• die Interpretation von Werten.
• zugeordnete Codes (proprietär, LOINC [10] und Snomed CT [9] gleichzeitig)
• inkl. LOINC-spezifischer Details, die das Anfordern von neuen Codes für neue Interpretationen erlaubt.

3.2. Das HL7 V3 Domänen Modell

Die wichtigste Herausforderung ist der Entwurf eines "rekursiven" Modells, das mit einem Scoresystem als Eintrittsstelle (Entry Point) beginnt und es erlaubt, dass die zugeordneten Komponenten entweder wieder ein Scoresystem oder ein Messwert/eine Beobachtung darstellen.

Innerhalb des HL7 V3 Domänen-Modells werden beide Klassen fast gleich modelliert (Abb. 2). Der offensichtlichste Unterschied ist der Name, der die zugewiesenen Codes an die vorgeschriebenen bindet. Diese Art der Trennung vereinfacht die Zuweisung und die Verwendung der korrekten Codes. Die beobachteten oder gemessene Werte werden innerhalb des Attributs "value" übermittelt. Der Datentyp ist im DMIM nicht spezifiziert und wird durch "ANY" dargestellt. Dadurch lassen sich für verschiedene Score-Systeme unterschiedliche Spezialisierungen vornehmen. Ein weiterer Unterschied zwischen dem Score und seinen Details ist die Anwesenheit von "value". Die Klasse Score kann aus Komponenten bestehen, welches über den Act Relationship Link zur Choice-Box dargestellt wird. Die Scores und/oder ihre Details können zu Referenzbereichen in Beziehung gesetzt werden. Die daraus resultierenden Probleme werden später in diesem Papier diskutiert. Nicht zuletzt hat jedes Scoresystem und/oder jedes Detail vielleicht seine eigenen involvierten Personen (Ausführenden, Autor, Prüfer), welche durch Particpations zu den entsprechenden Common Message Element Types (CMET) inkludiert werden.

3.3. Das HL7 v2.x Domänen Modell

Abbildung 3. HL7 v2.x Modell.

3.4. Interpretation von Werten

Ein weiteres Problem ist die Spezifikation von Referenzbereichen für Beobachtungen. Normalerweise hat eine einzelne Beobachtung einen Referenzbereich mit einer unteren und einer oberen Grenze. In den meisten Fällen – aber nicht in allen – werden alle Werte innerhalb dieses Bereiches als normal, alle anderen entweder als zu niedrig oder zu hoch behandelt. Dies führt zu einer unabhängigen Markierung (Flag), die die Interpretation angibt (Abb. 4).

Die Konsequenz für unser obiges Modell ist die Übermittlung eines Satzes von Referenzbereichen, wo jeder einzelne seine eigene Interpretation hat, die wiederum in Form eines Codes ausgedrückt werden kann.

3.5. Klassifikations-Systeme

Scoresysteme bestehen aus Klassen (oder Werten), die an einen eindeutigen Identifikator oder Code gebunden werden. Zum Ausdrücken von Beziehungen und Abhängigkeiten sind multi-axiale Klassifikationen eingeführt worden. Ein Beispiel für so ein multi-axiales Klassifikationssystem ist Snomed III, ein Vorgänger des aktuell genutzten Snomed CT. Eine Ontologie führt dann Beziehungen zwischen den klassifizierten Konzepten ein. Ein wichtiger Teil der präsentierten Arbeit ist die Zuweisung von Codes, die die Identifikation des übermittelten Konzepts ermöglichen. Dabei können unterschiedliche Codesysteme benutzt werden:

• LOINC,
  
• SNOMED CT,
  
• ICD 10, 
• proprietäre Codes.

Das am einfachsten zu nutzende Code-system (neben proprietären Codes) ist LOINC, das vom Regenstrief Institute eingeführt wurde [12] Es hat einen einfachen Mechanismus zur Definitionen von neuen Konzepten. Wenn kein Konzept gefunden werden kann, müssen die Details für die Anforderung eines neuen Codes parallel dazu festgehalten werden. Die Datenbank (s.u.) kann deshalb mehrere Codes von unterschiedlichen Codesysteme parallel verwalten.

Abbildung 6. Gegenüberstellung des 2 bzw. 3 Ebenenansatz.

Snomed CT ([9]) ist ein sehr ausdifferenziertes Codesystem, das die Spezifikation von Konzepten mitunter für jeden individuellen Wert erlaubt. Das konzeptionelle Domänen-Modell für Scoresysteme erlaubt prinzipiell die Übersendung der Ergebnisse entweder in einem zwei oder drei Ebenen Ansatz (Abb. 6). Der zwei Ebenen Ansatz sendet einen Wert für den beobachteten Messwert, wohingegen innerhalb des drei Ebenen Ansatzes noch ein Code als Komponente übermittelt wird. Letzteres sorgt für eine zusätzliche 1:1 Beziehung.

3.6. Die Score-Datenbank

Die erste Zusammenfassung der Score Details wurde in einer MS-Excel-Tabelle dargestellt. Die ersten Schritte in der Entwicklung eines Implementierungsleitfadens haben gezeigt, dass die Details mehrdimensional sind, so dass eine "echte" Datenbank als geeigneter erschien. Das führte zur Entwicklung eines ER-Modells, um die Informationen in einer relationalen Datenbank zu speichern. Eine GUI hilft in der effektiven Verwaltung der o.g. Informationen. Auswertungen/Berichte (Reports) helfen, um die Daten an Interessenten zu verteilen sowie Tabellen zu generieren, um neue LOINC Codes vom Regenstrief Institut anzufordern.

Ein HTML-Generator erlaubt die Bereitstellung der Informationen im WWW. Ein weiterer Generator, der gerade entwickelt wird, wird die Daten in einem R-MIM im Definition-Mood erzeugen, so dass diese Informationen direkt in einem Dokument oder einer Nachricht verwendet werden können. Dieses R-MIM enthält so die Beschreibung/Detailspezifikation des eigentlichen Score-Systems.

3.7. IHE PCC

Das IHE Patient Care Coordination (PCC) TC hat eine Spezifikation geschaffen [14], um Informationen für einige wenige Scoresysteme innerhalb eines CDA Dokumentes zu übersenden: Functional Status, Pain Scale, Braden Score und Geriatric Depression-Scale (GDS).

Leider konzentriert sich die Spezifikation nur auf ein Template, das bei der Identifikation hilft, ob ein entsprechender Teil in solch einem Dokument enthalten ist oder nicht. Schematron Regeln verifizieren, ob alle erforderlichen Teile mit so einer Template ID und den zugeordneten LOINC Codes in einem Dokument vorkommen. Die Spezifikation selbst kümmert sich nicht um weitergehende Details, weder in textueller Form – noch als Level 3 strukturierter Entries.

Erweiterungen zu der bereits erwähnten Datenbank erlauben auch das Erzeugen von Score-spezifischen Patterns mit mehr Details. Dies umfasst basierend auf zusätzlichen Informationen nicht nur die textuelle Spezifikation als ein Dokument selbst, sondern auch das dazugehörende HL7 V3 Template XML Schema und Schematron Regeln [15].

Die einzige offene Frage ist die Herausforderung, um die Inhalte dieser Datenbank in das gegenwärtige bestehende IHE PCC Technical Framework zu integrieren, um Verwaltungs-Konflikte zu vermeiden. Gemäß der Entscheidung des IHE PCC Technical Committee von 2008 wird es ein zweiteiliges Whitepaper geben, das später als eigenständiges Integrationsprofil bereitgestellt werden kann. Der erste Teil erläutert den Aufbau und das Mapping auf die Kommunikationsstandards v2.x, V3 und CDA, der zweite wird mit den Detailinformationen aus der Datenbank generiert.

3.8. UML-Modell

Das ER-Schema für die Datenbank basiert auf einem vereinfachten Modell für die erforderlichen Fakten. Des weiteren stellt die Datenbank nur die Details bereit, die notwendig sind, um die Inhalte zu spezifizieren. Deshalb stellt sie kein Feld bereit, um den resultierenden Wert zu speichern. Für das Kommunikations-Szenario wird der Wert wichtig, womit es im UML Modell enthalten ist.

Der wichtigste Umstand ist die Tatsache, dass ein Score selbst eine Beobachtung ist. Deshalb wird er als eine Spezialisierung davon dargestellt (sehen Sie a) in Abb. 7). In der Datenbank werden diese zwei Klassen zusammengeführt, um die Daten einfach verwalten zu können. Dies macht es leichter, die Rekursion zu verwalten, d.h. eine Beobachtung kann andere Beobachtungen als Komponenten enthalten. Daher stellt jeder Eintrag in dieser Tabelle ein eigenes Konzept dar, welches in anderen Definitionen wiederverwendet werden kann.

Abbildung 7. UML Modell.

Die nächste wichtige Tatsache ist die Verwendung von Codes, um das semantische Konzept darzustellen. In Abbildung 7 stellt die Klasse CatalogEntry ein Konzept mit einem Code und einer Beschreibung mit Bezug zu einem Katalog/Codesystem dar. Ein solches Konzept könnte vielleicht aus einem Katalog wie LOINC [10] oder Snomed CT [9] stammen. Die zwei verschiedenen Spezialisierungen als ObsCatEntry und Interpretation helfen, die Referenzierungen korrekt vorzunehmen. Die erste Klasse soll Konzepte für Codes von Beobachtungen identifizieren, wohingegen die zweite Klasse Konzepte für Interpretationen darstellt.

3.9. UML-OWL-Modell

Um mit dem in dem oben erwähnten UML Modell enthaltenen Wissen zu argumentieren, sollte es in eine OWL-Darstellung konvertiert werden. Im Prinzip sind beide ganz ähnlich. Der wichtigste Unterschied ist die Abstammung von einer gemeinsamen Klasse, genannt owl:Thing. Des weiteren werden einige der Eigenschaften als Beziehungen zu anderen Klassen dargestellt. Eine Person (Beobachter oder Autor) als eine Spezialisierung von LivingSubject ist ein gutes Beispiel dafür.

Abbildung 8. UML OWL Modell.

Anmerkung: die Anmerkungen für Abb.7 gelten auch für Abb. 8.

Abbildung 9. Protegé OWL-Modell.

Abbildung 9 stellt die Klassen-Hierarchie in Protegé dar [16].

3.10. Integritätsregeln für das OWL-Modell

Diese Klassenhierarchie allein ist nicht ausreichend. OWL erlaubt auch, den Klassen Beschränkungen zuzuweisen, die helfen, die Beziehungen unter ihnen zu verifizieren. Das Beispiel in Abbildung 10 drückt aus, dass jeder Score eine Beobachtung haben muss. Weiterhin erbt es die Beschränkung von Observation, um einen Code aus CatalogEntry zu haben.

Alle Beziehungen können als Beschränkungen ausgedrückt werden, die von sog. Reasonern verwendet werden können, um die Konsistenz der Ontologie überprüfen.

3.11. Handhabung von Übersetzungen

Gegenwärtig stellt die Datenbank textuelle Informationen über die Scoresysteme und ihre Details in deutscher und englischer Sprache bereit. Die meisten Felder in der Datenbank sind zu diesem Zweck dupliziert worden. Der erste Autor hat darüber nachgedacht, hier ebenfalls einen generischen Ansatz für Übersetzungen zu implementieren. Dies würde bei dem UML-Modell anfangen. Allerdings führte das Wissen um das mühsame Sammeln der notwendigen Codes zu dem Entschluss dass gegenwärtig nicht mehr als zwei Sprachen berücksichtigt werden sollten: Die Verfügbarkeit der Codes wird den Übersetzungsprozess signifikant vereinfachen, da in den übersetzten Originalkatalogen nachgeschlagen werden kann.

3.12. Einsatz der Datenbank

Die Datenbank wurde auf Basis von MS-Access entwickelt, da hiermit alle Daten (Daten über die Scores, Formulare und Berichte) in Form einer einzelnen Datei bereitgestellt werden. Während der ersten Entwicklungsschritte des Projektes haben die Beteiligte sich diese Datenbank per eMail zugeschickt. Mit dem Anwachsen des Projektes ist dieses Vorgehen nicht mehr weiter aufrecht zu erhalten. Der Inhalt sollte daher auf der DCM Webseite [18] als generierte HTML-Dateien veröffentlicht werden. Alle Korrekturen und Ergänzungen sollten deshalb an den Autor geschickt werden. Dieses neue Vorgehen erlaubt die Protokollierung und Verifikation von Änderungen.

3.13. Projektstatus

Gegenwärtig (Jan. 2009) haben intensive Diskussionen mit den Beteiligten stattgefunden. Die HL7 Patient Care Work Group hat dieses Material (R-MIM) zur Abstimmung als Draft Standard for Trial Use (DSTU, HL7 MB21 Jan. 2009) gestellt und als Ergebnis eine prinzipielle Zustimmung erhalten.

Darüber hinaus hat das IHE PCC Technical Committee der Erstellung eines Whitepaper zugestimmt.

4. Schlussfolgerung

Die Details, die oben aufgezählt werden, werden jetzt in der beschriebenen Datenbank verwaltet. Gegenwärtig enthält sie mehr als 80 Scoresysteme. Für eine Reihe von ihnen werden auch schon die erforderlichen Details bereitgestellt. Die meisten von ihnen erfordern eine Verifikation durch die verantwortlichen Organisationen und Fachverbände. Weiterhin wird der vorgestellte Ansatz mit den verantwortlichen Personen und Technical Committees innerhalb der SDOs diskutiert. Trotz der schon existierenden ausführlichen Spezifikationen für ein paar Scoresysteme setzen sich alle Beteiligte für die weitere Ausarbeitung des generischen Ansatzes ein, der beim Verwalten der Details helfen wird. Die Bereitstellung eines abgestimmten Satzes von Codes – auch wenn es mehrere Codes aus verschiedenen Codesystemen für dasselbe Konzept sind – ist die wichtigste Aufgabe, um eine semantische Interoperabilität zu erreichen.

Anerkennungen

Die Autoren würden gern Frau Dr. Sylvia Thun (DIMDI), Hr. Dr. Rainer Röhrig und Frau Ricarda Rüth (beide Universitätskrankenhaus Gießen) für ihre Unterstützung bei der Ausarbeitung der Modelle und dem Füllen der Datenbank danken. Des weiteren Herr Dr. William Goossen (Acquest, NL) für die Unterstützung des generischen Ansatzes innerhalb der HL7 Patient Care Work Group.

Literatur