Terminologie Nutzung

[[Kategorie:]]

ELGA CDA
Implementierungsleitfäden

Leitfaden zur Nutzung von ELGA-Terminologien

Informationen für Nutzer der ELGA Value Sets, der Codesysteme und des Terminologieservers

04.04.2016

1.4

Entwurf

1 Zusammenfassung

Dieser Leitfaden soll eine Hilfestellung für den Umgang mit den ELGA Terminologien sein und Fragen der Anwender zu folgenden Themen klären:

• Was kann sich bei einer Terminologie ändern?
• Wie erfahre ich von Änderungen der Terminologien?
• Wo kann man die Terminologien in welchem Format abrufen?
• Wie gehe ich mit Änderungen in meinem System um?
• Wie kann man Erweiterungen und Änderungen an Terminologien anfordern?

Was findet man wo?

• Wichtige Definitionen und Begriffsbestimmungen in Kapitel 1.2
• Eine Beschreibung des Terminologieservers in Kapitel 3
• Die Codelisten und Value Sets für ELGA in Kapitel 2
• Änderungsprozesse für Terminologien in Kapitel 2
• Best Practice für die Verwendung der Value Sets und des Terminologieservers in Kapitel 4
• Technische Details (Aufbau und Attribute der Exportformate) in Kapitel 5

2 Informationen über dieses Dokument

2.1 Hinweise zur Nutzung des Leitfadens

Der vorliegende Leitfaden wurde von der ELGA GmbH erstellt. Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die HL7 Austria und die ELGA GmbH genehmigen ausdrücklich die Anwendung des Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente und weisen darauf hin, dass dies mit dem Einverständnis aller Mitwirkenden erfolgt.

Fragen, Kommentare oder Anregungen für die Weiterentwicklung dieses Dokumentes können an cda@elga.gv.at gesendet werden. Weitere Informationen finden Sie unter www.elga.gv.at.

Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die ELGA GmbH erhoben und/oder abgeleitet werden.

2.2 Zielgruppen

Der Leitfaden richtet sich vorwiegend an IT-Betriebsverantwortliche, Software- oder Systembetreuer sowie Softwareentwickler und alle Personen, die Terminologien in Anwendungssysteme integrieren und gegebenenfalls aktualisieren.

2.3 Verbindlichkeit

Mit der ELGA-Verordnung 2015 (in der Fassung der ELGA-VO-Nov-2015) macht die Bundesministerin für Gesundheit die Festlegungen für Inhalt, Struktur, Format und Codierung verbindlich, die in den Implementierungsleitfäden Entlassungsbrief Ärztlich, Entlassungsbrief Pflege, Pflegesituationsbericht, Laborbefunde, Befund bildgebender Diagnostik, e-Medikation sowie XDS Metadaten (jeweils in der Version 2.06) getroffen wurden. Die anzuwendenden ELGA-Interoperabilitätsstufen ergeben sich aus § 21 Abs. 6 ELGA-VO. Die Leitfäden in ihrer jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind von der Gesundheitsministerin auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Dokumente für ELGA wird durch das das Gesundheitstelematikgesetz 2012 (GTelG 2012) und darauf basierenden Durchführungsverordnungen durch die Bundesministerin für Gesundheit vorgegeben.

Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.

2.4 Impressum

Medieneigentümer, Herausgeber, Hersteller, Verleger:
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050. Internet: http://www.elga.gv.at. Email: cda@elga.gv.at.
Geschäftsführer: DI Dr. Günter Rauchegger, DI (FH) Dr. Franz Leisch

Redaktion, Projektleitung, Koordination:
Mag. Dr. Stefan Sabutsch, stefan.sabutsch@elga.gv.at

Abbildungen: © ELGA GmbH

Nutzung: Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; www.hl7.at.
Die Nutzung ist zum Zweck der Erstellung medizinischer Dokumente ohne Lizenz- und Nutzungsgebühren ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter www.gesundheit.gv.at und www.elga.gv.at/cda

3 Einleitung

3.1 Motivation

Die Verwendung von gemeinsamen Codelisten und medizinischen Vokabularen ist eine Voraussetzung für das organisationsübergreifende Zusammenwirken von IT-Systemen im Gesundheitswesen. Nur in allen beteiligten Systemen gleich verwendete Codes ermöglichen die korrekte inhaltliche Interpretation und Verarbeitung der zwischen Medizin-IT-Systemen ausgetauschten Daten (semantische Interoperabilität). Dazu ist es notwendig, dass die Codes und ihre Bedeutung bei einer vertrauenswürdigen Quelle zuverlässig zur Verfügung stehen. Diese notwendige Funktion wird durch die Infrastrukturkomponente „Terminologieserver“ unterstützt.

Medizinische Terminologien unterliegen wie die Medizin selbst einer stetigen Veränderung, sie müssen daher immer wieder aktualisiert werden. Die Verwendung einheitlicher und qualitätsgesicherter Terminologien bildet die Grundlage der semantischen Interoperabilität. Alle Kommunikationsteilnehmer müssen dieselben Codes und ihre Bedeutung in der jeweiligen Terminologie kennen. Sollte dies nicht der Fall sein, können Codes nicht korrekt interpretiert werden, was zu Fehlern in der Kommunikation und in der Anwendung führen kann. Da sich in Kommunikationsnetzwerken mit hunderten oder tausenden teilnehmenden Systemen die Verteilung der semantischen Bezugssysteme nicht mehr manuell bewerkstelligen lässt, muss die lokale Semantik automatisch mit der zentralen Semantik synchronisiert werden können.

Die allgemeine Verfügbarmachung von Terminologien ist daher ein besonders wichtiges Ziel. Dabei stellen sich folgende Herausforderungen:

Alle Terminologien sollen von einem zentralen Zugangspunkt abgerufen werden können und in lesbarer als auch maschinenlesbarer Form zugänglich sein. Auch veraltete Versionen sollen für Recherchezwecke zugänglich bleiben, Änderungen bestehender Versionen müssen nachvollziehbar sein. Unterschiedliche Organisationen können für die Verwaltung und Weiterentwicklung von Terminologien zuständig sein, der Terminologieserver soll diese Tätigkeiten unterstützen und eine örtlich und zeitlich verteilte Arbeit an den Terminologien und einfache Übergabe an den zentralen Zugangspunkt ermöglichen.

Dieser Leitfaden soll die Stakeholder bei der korrekten Nutzung und Aktualisierung der Terminologien unterstützen.

3.2 Definitionen

Codesystem: Bezeichnung für eine Sammlung von computerverarbeitbaren Codes („Codeliste“) und ihren , zusammen mit dem zugehörigen Regelwerk (Regeln zur Codierung von Begriffen, Benennung etc.).

Value Set: Eine eindeutig identifizierbare und versionierte Auswahl von Werten aus einem oder mehreren Codesystemen für eine bestimmte Anwendung bzw für ein Element einer Anwendung (etwa für CDA-Laborbefunde, für XDS-Metadaten etc.). Ein Value Set enthält die Codes selbst sowie die Information über die Herkunft des Codes (die Quell-Terminologie).

Terminologie: Allgemeiner Begriff für zur elektronischen Verarbeitung nutzbar gemachte Sammlungen von Konzepten und ihren Identifikatoren („Codes“). Darunter fallen Codesysteme, Value Sets, Vokabulare, Ontologien etc.

Terminologieserver: Ein Server, der Terminologien in standardisierter Form aktuell verfügbar macht. Der Terminologieserver ist eine Komponente der österreichischen e-Health Infrastruktur (https://termpub.gesundheit.gv.at/). Ein Terminologieserver ist eine Datenbankanwendung mit der Terminologien, also „Codelisten“, im weitesten Sinn verwaltet und zugänglich gemacht werden können. Die Daten enthalten neben fachlichen Erläuterungen auch verschiedene Meta-Informationen (z.B. Quelle).

3.3 Support, Helpdesk, Kontakt

• Grundsätzlich ist die ELGA-Serviceline bei allen Anfragen zu Terminologien und zum Terminologieserver zu kontaktieren: info@elga-serviceline.at (Tel: +43.50.124 4411)

4 Die ELGA-Terminologien

4.1 Codesysteme

In ELGA wird eine Vielzahl unterschiedlicher Codesysteme mit unterschiedlicher Struktur von verschiedenen internationalen, nationalen und lokalen Quellen verwendet. Über den Terminologieserver werden diese in eine möglichst einheitliche Form gebracht.

Die Aktualisierung von Codesystemen und deren Zeitpunkt oder Häufigkeit liegt in der Verantwortung der Ersteller und damit meist außerhalb des Einflussbereiches von ELGA.

Ein Codesystem wird durch eine OID eindeutig identifiziert. Die Bedeutung eines Codes kann nur gemeinsam mit der OID des Codesystems entschlüsselt werden.

Ein Grundsatz der Terminologie-Entwicklung ist, dass Codes nicht gelöscht und auch die Bedeutung eines Codes nicht verändert werden dürfen¹. Solche Änderungen erzeugen eine Inkonsistenz bei der Verwendung von älteren codierten Daten mit der aktuellen Version des Codesystems. Üblicherweise bekommen solche „inkompatiblen“ Versionsstände des Codesystems unterschiedliche OIDs um sie auseinanderzuhalten (z.B. die jährlichen Versionen des ICD-10). Nicht alle Codesysteme halten sich in der Praxis an diese Vorgabe. Bei der Übernahme von Aktualisierungen von Codesystemen ist daher immer mit Bedacht vorzugehen.

4.2 ELGA Value Sets

Wo immer durch ELGA CDA Implementierungsleitfäden eine Werteauswahl getroffen werden kann, wird ein passendes Value Set definiert und mit seinem eindeutigen Namen angegeben. ELGA Value Sets beziehen sich immer² auf eine bestimmte „Version“ eines Codesystems oder auch mehrerer Codesysteme, was über die OID der Codesysteme erkenntlich ist. Dadurch werden die Value Sets unabhängig von der Veränderung der Codesysteme.

Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert: https://termpub.gesundheit.gv.at/.

Value Sets sind nicht nur durch einen eindeutigen Namen, sondern auch durch eine OID und eine Versionsnummer gekennzeichnet, dazu wird ein Gültigkeitsdatum (gültig ab…) ange-geben. Darüber hinaus können Value Sets eine Reihenfolge und eine Baumstruktur (Hierarchie) enthalten.

Value Sets sind so lange gültig, bis das Gültigkeitsdatum einer neueren Version dieses Value Sets erreicht wird – dann gilt die neuere Version³. Solange keine neuere Version vorhanden ist, bleibt ein Value Set gültig (siehe auch Kapitel 2.2.1 “Value Set Binding“).

Value Sets benötigen keine Status-Information für die einzelnen Codes, weil per Definition nur „gültige und verwendbare“ Codes in einem Value Set enthalten sind.

Wenn Codes, ab einem bestimmten Gültigkeitsdatum nicht mehr verwendet werden dürfen, wird eine neue Version des Value Sets erzeugt, aus dem die Codes entfernt sind. Die neue Version des Value Sets erhält dann das neue „gültig ab“-Datum.

4.2.1 Value Set Binding

Für jedes Value Set ist ein Zeitpunkt angegeben, an dem es Gültigkeit erlangt („Gültig ab“). Dies ist besonders wichtig für Value Sets, die schon vor ihrem Inkrafttreten veröffentlicht werden.

Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets. Das bedeutet, dass immer die aktuell am Terminologieserver publizierte Version eines Value Sets anzuwenden ist. (Das Setzen des entsprechenden Schlüsselworts DYNAMIC ist daher in den Leitfäden nicht erforderlich).

Value Sets können auch STATISCH an ein Code-Element gebunden werden. Dies wird durch die Angabe des Value Sets mit Name, OID, Version und "Gültig ab"-Datum (effectiveDate) sowie dem Schlüsselwort STATIC gekennzeichnet.

4.2.2 Änderbarkeit von Value Sets

Inhalte von Value Sets können sich ändern, der Name und die OID eines Value Sets bleiben aber gleich. Bei neuen Versionen werden Versionsnummer, Änderungsdatum und „Gültig ab“-Datum (effectiveDate) angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden.

In Ausnahmen kann bei der Definition eines Value Sets (im Leitfaden) angegeben werden, dass es nicht geändert oder versioniert werden darf (Property „Immutability“).

Wie häufig Value Sets geändert werden, hängt von der jeweiligen Anwendung ab. Value Sets, die für „strukturelle“ Elemente benötigt werden (z.B. im CDA-Header, XDS-Metadaten) werden sich selten ändern. „Inhaltliche“ Value Sets (z.B. für Arzneimittellisten, Laboranalysen, Diagnosen-Codierungen) werden sich entsprechend häufig ändern müssen, hier ist mit jährlichen bis wöchentlichen Änderungen gerechnet werden.

¹ „Concept Permanence“, beschrieben in „Cimino’s Desiderata“ (Desiderata for Controlled Medical Vocabularies in the Twenty-First Century; 1998; http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3415631/ )
² Mit wenigen Ausnahmen
³ Ausnahmen sind statiche Value Set Bindings in CDA-Leitfäden („STATIC“), die sich explizit auf eine bestimmte Version eines Value Sets beziehen. Wenn nicht anders angegeben sind aber alle Bindings dynamisch, beziehen sich also immer auf die aktuelle Version.

4.2.3 Kommunikation der Veränderung von Terminologien

Alle Änderungen von Terminologien sind am Terminologieserver zentral abrufbar. Die Mechanismen werden in Kapitel 4.2.1 beschrieben.

Prüfungen auf geänderte Terminologien sollten mindestens wöchentlich erfolgen.

Nicht alle Terminologie-Änderungen können automatisch übernommen werden, in manchen Fällen werden manuelle Änderungen in Systemen notwendig sein (abhängig von der Anwendung). Der Umgang mit Terminologie-Änderungen und ihre organisatorische Einbettung wird exemplarisch im Anhang Kapitel 6 „Best Practice Terminologien“ des KAV Wien beschrieben.

4.2.4 Anforderung von Erweiterungen oder Korrekturen von Terminologien

Alle Fragen zu ELGA-relevanten Terminologien können an info@elga-serviceline.at gemeldet werden, von dieser Adresse aus wird die Bearbeitung zentral koordiniert.

Codesysteme können nur dann korrigiert werden, wenn (1) ein technisches Problem vorliegt oder (2) es sich um eine in Auftrag der ELGA GmbH entwickeltes Codesystem handelt.

Von und für ELGA definierte Value Sets können nach fachlicher Prüfung durch die Inhaltsverwalter korrigiert werden. Bei ELGA Value Sets, die einem regulären Wartungs- und Updatezyklus unterliegen, können Erweiterungen und Änderungen durch den zuständigen Inhaltsverwalter durchgeführt werden (z.B. ELGA Laborparameter, ASP-Liste). Bei anderen inhaltlichen Korrekturen von ELGA Value Sets muss gegebenenfalls die fachliche Entscheidung der Arbeitsgruppe⁴ eingeholt werden, die den entsprechenden Leitfaden entwickelt hat, in dessen Rahmen das Value Set definiert wurde.

Zu anderen (nicht-ELGA-relevanten) Terminologien kann das Kontaktformular des Terminologieservers genutzt werden: https://termcollab.gesundheit.gv.at/TermBrowser/gui/info/enquiry.zul.

⁴ Ein „CDA Beirat“, der Entscheidungen in Umlaufverfahren(qui tacet consentit) trifft. Die getroffenen Entscheidungen können per Mailverteiler publik gemacht werden.

5 Der Terminologieserver

5.1 Beschreibung des Terminologieservers

Ein Terminologieserver stellt Terminologien in standardisierter Form für Benutzer zur Verfügung. Dadurch wird die semantische Interoperabilität in verteilten Systemen unterstützt. Mit den Services ist es möglich, lokale Semantik mit global vereinbarter Semantik zu synchronisieren und aktuell zu halten.

Terminologieserver stellen einerseits Dienste zum manuellen oder automatischen Abruf von Vokabularen, andererseits zur automatisierten Synchronisation dezentral verwalteter Vokabulare bereit.

Über eine Web-Anbindung können Vokabulare veröffentlicht werden: Primärsysteme können ihre lokalen Terminologien via Webservices synchronisieren und pflegen, Endbenutzer können auf Terminologien über eine Weboberfläche zugreifen. Wesentlich ist, dass die Daten eine hohe Strukturierung aufweisen und sich automatisch verarbeiten lassen.

Abbildung 1: Terminologieserver für die Entwicklung und Nutzung von Terminologien

Auf dem österreichischen Terminologieserver werden alle Terminologien, die für den Einsatz in ELGA notwendig sind, verwaltet. Die Benutzeroberfläche trennt Codelisten und Value Set. Zu jeder Terminologie können Versionen angezeigt werden. Im rechten Bereich öffnet sich die gewünschte Version, um alle Konzepte (ggf. mit Hierarchie) anzuzeigen. Es kann sowohl innerhalb einer Terminologie als auch über alle Codelisten oder Value Sets gesucht werden. Jede Version kann exportiert werden. Details dazu entnehmen Sie bitte dem Benutzerhandbuch Publikationsumgebung, das sie am Terminologieserver unter „Hilfe“ finden.

Über die Detailansicht (Rechtsklick) können weitere Informationen zur Terminologie bzw. ihrer Version angezeigt werden, etwa das „gültig ab“ Datum.

Genauso können Details zu jedem Konzept angezeigt werden, etwa:

• Begriff: displayName
• Bedeutung: deutsche Sprachvariante
• Beschreibung: nähere Beschreibung (Anwendungsbeschreibung) des Konzepts
• Hinweise: Hinweise zur Anwendung des Konzepts

Terminologien können auch über eine Webservice-Schnittstelle exportiert bzw. auf Aktualisierungen geprüft werden. Siehe dazu Kapitel 4.2.1.2.

6 Best Practice

6.1 Verwendung von Value Sets

1. Für das „Schreiben“ (Erzeugen von Dokumenten) MUSS immer das aktuell gültige Value Set verwendet werden.
2. Der medizinisch relevante Inhalt MUSS in CDA Dokumenten IMMER im narrativen Text vollständig lesbar sein (Level 3-Information sind für das Lesen NICHT erforderlich).
3. Bei der Verwendung von Level-3-codierten Informationen MÜSSEN Code und Codesystem gleichzeitig betrachtet werden.
4. Die Bedeutung (bzw. die Benennung) eines Codes in einem Codesystem MUSS aus dem Codesystem ermittelt werden und DARF NICHT aus dem Attribut displayName entnommen werden.
   1. Nur wenn der Code nicht im Codesystem gefunden werden kann, können alternativ der OriginalText oder DisplayName aus dem jeweiligen Dokument verwendet werden.
5. Theoretisch müsste immer das komplette Codesystem beim Empfänger verfügbar sein, um die Codes zu interpretieren. Das ist v.a. bei umfangreichen Terminologien unpraktikabel, diese können auch nicht durchgängig ins Deutsche übersetzt werden (z.B. LOINC).

In der Praxis reicht es, das jeweilige Value Set (das immer durchgängig ins Deutsche übersetzt ist) zu importieren.

1. Für die Verwendung „historischer“ Level-3-Werte wird daher folgendes Vorgehen beim Import neuer Value Sets EMPFOHLEN:
   1. Vorbedingung: Alle Einträge erhalten im lokalen System einen Gültigkeitszeitraum (oder ein äquivalentes Gültigkeitskennzeichen).
   2. Beim Import eines neuen Value Sets wird im ersten Schritt das „gültig bis“-Datum für alle bisherigen Einträge mit dem „gültig ab“-Datum des neuen Value Sets versehen, dadurch werden die bisherigen Einträge als „veraltet“ gekenn-zeichnet. Zusätzlich kann noch ein entsprechender Status gesetzt werden.
   3. Im zweiten Schritt wird das aktuelle Value Set importiert, wobei der Inhalt bereits bestehender übereinstimmender Codes durch die neuen Informationen ersetzt. und das „gültig bis“-Datum dieser im Value Set enthaltenen Codes entfernt wird. Das „gültig ab“-Datum für neue (bisher nicht enthaltener) Einträge entspricht dem „gültig ab“-Datum des Value Sets.

6.2 Verwendung des Terminologieservers

Der Terminologieserver dient nicht als Online-Ressource (Prüfung einzelner Werte), sondern als Quelle für neue Terminologien, die lokal abgespeichert werden sollen.

6.2.1 Prüfung auf Aktualisierung

Sowohl über die Benutzeroberfläche des Terminologieservers als auch über die Webservice-Schnittstelle können Aktualisierungen erkannt bzw. automatisiert geprüft werden. Näheres siehe nachfolgende Kapitel. Prüfungen sollten wöchentlich durchgeführt werden.

6.2.1.1 Terminologieserver: Benutzeroberfläche

Am Terminologieserver können aktuelle Änderungen an Terminologien angezeigt werden („Aktuelle Vorgänge“). Diese können nach mehreren Kriterien gefiltert werden.

6.2.1.2 Terminologieserver: Export mittels Webservice

Der Export von Terminologien ist ein zweistufiges Verfahren. In beiden Schritten kann eine entsprechende Prüfung auf Aktualisierung stattfinden:

1. Auflisten aller Code Systeme bzw. Value Sets und deren Versionen. Dies ist bei jedem Exportvorgang notwendig, da es von jeder Terminologie mehrere Versionen geben kann (die natürlich unterschiedliche Version-IDs haben, aber auch unterschiedliche OIDs besitzen können). Mit den erhaltenen IDs (CodeSystemID/ ValueSetID und jeweilige Versions-ID) kann die gewünschte Terminologie-Version im nächsten Schritt exportiert werden.
   1. In diesem Schritt wird durch den Abgleich der lokal vorhandenen Value Set -IDs bzw. Version-IDs mit den aktuell abgefragten (und ggf. höheren) ID eine Aktualisierungsprüfung durchgeführt. Man erhält sowohl die aktuell gültigen als auch zukünftig gültigen Versionen (siehe nächster Schritt). Ist keine höhere ID vorhanden, ist die lokal vorhandene Version die gültige. Diese Variante der Aktualisierungsprüfung auf Versionsebene ist empfohlen.
2. Export der Terminologie

Unter Angabe der ID, Versions-ID und des gewünschten Exportformats kann die Ter-minologie exportiert werden. Die Export-Datei enthält das Gültigkeitsdatum (siehe 5.1 Elemente der Downloadformate). Mit dem Gültigkeitsdatum kann entschieden werden, ob die Terminologie direkt oder später (erst ab Gültigkeitsdatum) importiert werden soll.

1. Zur Überprüfung der Aktualität der Einträge kann optional die Update-Prüfungs-Funktion genutzt werden: Dazu muss clientseitig der Zeitstempel des letzten Abrufs (Export) gespeichert und beim erneuten Export mitgegeben werden. Als Response erhält man daraufhin nur jene Konzepte, bei denen es seit dem letzten Abruf zu Änderungen gekommen ist (Achtung: Es werden nur aktuell gültige Konzepte ausgegeben, keine gelöschten!).

Detaillierte Beschreibungen der Webservices finden Sie im „Benutzerhandbuch Web-services“, das im Bundesministerium für Gesundheit angefordert werden kann: Mag. Engelbert Prenner (E-Mail: engelbert.prenner@bmg.gv.at, Telefon: +43-1/71100-4795)

7 Technische Informationen

7.1 Elemente der Downloadformate

Im Folgenden werden die unterschiedlichen Exportformate mit ihren Elementen und Besonderheiten beschrieben. Die Auflistung gilt mit Ausnahme des Value Sets ELGA_Laborparameter⁵ und der Codeliste ASP-Liste.

7.1.1 SVS

Das angebotene SVS ist ein erweitertes IHE Sharing Value Set Format. In diesem XML-Format können Codelisten und Value Sets exportiert werden.

Diese enthält Attribute zur Terminologie bzw. der Version (Element „valueSet“):

• Name: Bezeichnung der Terminologie
• Beschreibung und description der Terminologie
• effectiveDate: „gültig-ab“ Datum der Version
• Id: OID der Version
• statusCode (derzeit nicht unterstützt)
• website: Link zu Quelle etc.
• version: Nummer/Bezeichnung der Version
• version-beschreibung (bei Codelisten): Beschreibung der Version
• gueltigkeitsbereich
• statusCode: 0=>Vorschlag: 1=>Public; 2=>Obsolet
• last_change_date: Datum der letzten Änderung

Alle Konzepte sind als „concept“-Elemente in der „conceptList“ vorhanden und enthalten folgende Attribute:

• code
• codeSystem: OID des Quell-Code Systems des Konzepts
• displayName: Begriff
• concept_beschreibung: nähere Beschreibung (Anwendungsbeschreibung) des Konzepts
• deutsch: deutsche Sprachvariante, Bedeutung
• einheit_codiert, einheit_print: nur relevant bei Laborparametern
• hinweise: Hinweise zur Anwendung des Konzepts
• level/type: Abbildung der Hierarchie
• relationships: etwaige Verbindungen zu anderen Konzepten
• orderNumber (nur bei Value Sets): Index zur Fixierung der Reihenfolge
• conceptStatus: 0=>Vorschlag; 1=>Public; 2=>Obsolet
• unvollständig (bei Codelisten): Flag zur Kennzeichnung von Codelisten, die nur auszugsweise am Terminologieserver veröffentlicht sind
• verantw_Org (bei Codelisten): verantwortliche Organisation

7.1.2 CSV

CSV (comma separated values) steht als Exportformat für Codelisten und Value Sets zur Verfügung. Es enthält als flache Liste lediglich Informationen zu den Konzepten, nicht aber zur Terminologie selbst bzw. zu ihrer Version:

• code
• codeSystem: OID des Quell-Code Systems des Konzepts
• displayName: Begriff
• concept_beschreibung: nähere Beschreibung (Anwendungsbeschreibung) des Konzepts
• meaning: deutsche Sprachvariante, Bedeutung
• hints: Hinweise zur Anwendung des Konzepts
• orderNumber (nur bei Value Sets): Index zur Fixierung der Reihenfolge
• level/type: Abbildung der Hierarchie
• relationships: etwaige Verbindungen zu anderen Konzepten
• einheit_codiert, einheit_print: nur relevant bei Laborparametern

⁵ Mapping der Basisattribute der Laborparameter auf Elemente im Terminologieserver siehe Leitfaden zur Anwendung von LOINC in ELGA

7.1.3 ClaML

ClaML (Classification Markup Language) ist ein spezielles XML-Datenformat für Klassifikationen. Der ClaML Export steht nur für Codelisten zur Verfügung.

Informationen zur Terminologie bzw. Versionen sind in den ersten Elementen enthalten. Die OID findet sich im „uid“-Attribut des Elements Identifier. Weitere Informationen zur Terminologie finden sich in den ersten „Meta“-Elementen als name-value Paar:

• Description: deutsche Beschreibung der Terminologie
• Description_eng: englische Beschreibung der Terminologie
• Website: Link zu Quelle etc.
• version_description: Beschreibung der Version
• insert_ts: Datum des Imports/Anlegen am Terminologieserver
• status_date: „Status geändert am“-Datum
• expiration_date: „gültig-bis“ Datum
• last_change_date: „geändert am“ Datum
• gueltigkeitsbereich
• statusCode: 0=>Vorschlag; 1=>Public; 2=>Obsolet
• unvollständig (bei Codelisten): Flag zur Kennzeichnung von Codelisten, die nur auszugsweise am Terminologieserver veröffentlicht sind
• verantw_Org (bei Codelisten): verantwortliche Organisation

Alle anderen Informationen zur Version befinden im title-Element:

• tite@date: „gültig-ab“ Datum
• tite@name: Name der Terminologie
• tite@version: Bezeichnung bzw. Nummer der Version

Die einzelnen Konzepte werden als class-Element abgebildet, jeweils mit name-value Paaren:

• class/@code: Code
• <Rubric kind='preferred'>/Label: Begriff
• <Rubric kind='note'>/Label: nähere Beschreibung (Anwendungsbeschreibung) des Konzepts
• TS_ATTRIBUTE_HINTS: Hinweise zur Anwendung des Konzepts
• TS_ATTRIBUTE_MEANING: deutsche Sprachvariante, Bedeutung
• TS_ATTRIBUTE_STATUS/ TS_ATTRIBUTE_STATUSUPDATE: Informationen zum Status des einzelnen Konzepts
• Level/Type: Abbildung der Hierarchie
• Relationships: etwaige Verbindungen zu anderen Konzepten

Zu beachten ist hier, dass die Elemente in der Exportdatei nicht vorhanden sind, wenn sie am Terminologieserver nicht befüllt sind.

8 Anhang: Best Practice Beispiel KAV Wien

Das Konzept des KAV Wien zum Umgang mit ELGA Terminologien im Zusammenspiel mit GDA/Verbund spezifischen Katalogen wurde von Mag. Konrad Hölzl (KAV Wien) freundlicherweise zur Verfügung gestellt und hier als Beispiel übernommen.

KAV Ausgangssituation

• Der Wiener Krankenanstaltenverbund betreibt sehr mehr als 20 Jahren eine spitalsübergreifende elektronische Krankengeschichte
• Um das Zusammenspiel bei der Datenerzeugung in den jeweiligen KAV Spitälern sicherstellen zu können wurde ein eigenes Katalogssystem entwickelt
• Dieses Katalogssystem stellt sicher, dass Änderungen im Inhalt der einzelner Kataloge verwaltet und verteilt werden können
• In diesem Katalogssystem sind sowohl KAV-weite Kataloge als auch anstaltsspezifische Kataloge eingebunden
• Es wurde dafür Sorge getragen, dass bei Anstaltskatalogen soweit sinnvoll auch entsprechende Umschlüsselungen zu KAV-Katalogen existiert
• Aufgrund der Heterogenität der IT-Systemlandschaft im KAV sind für manche in zugekauften Systemen verwendeten Katalogen bilateral vereinbarte Übermittlungswege realisiert

Die Problemstellung

• Um im ELGA Kontext automatisiert auswertbare Daten erstellen zu können ist die Verwendung einheitlicher Value Sets notwendig
• Eine sofortige Umstellung der im Spitals/Verbund Kontext verwendeten Kataloge ist nicht möglich
• Es ist ein System zu etablieren welches die Zuordnung von Katalogen sowie Katalogseinträgen zu ELGA Value Sets sowie ELGA Codes/Concepts und umgekehrt ermöglicht
• Das System muss mit Erweiterungen und Änderungen umgehen können – sowohl auf Ebene von Einträgen/Codes als auch auf Ebene von Katalogen/Value Sets

ELGA Begriffe - Terminologieserver

• Der Terminologieserver soll den Stakeholdern des österreichischen Gesundheitswesens die Möglichkeit bieten, Terminologien über das Internet öffentlich zur Verfügung zu stellen, sowie Terminologie-Recherche und Terminologie-Download ermöglichen.
• Über eine Web-Anbindung können Terminologien veröffentlicht werden. Primärsysteme können ihre lokalen Terminologien via Webservices synchronisieren und pflegen (Webservice-Nutzer), Webfrontend-Nutzer können auf Terminologien über eine Weboberfläche zugreifen.

ELGA Begriffe – Codesystem/-liste

• Codesystem (engl. code system): Bezeichnung für eine Terminologie mit dem zugehörigen Regelwerk (z.B. Regeln zur Codierung von Begriffen, Benennung etc.).
• Wird häufig synonym mit Codeliste verwendet.
• Jedes Codesystem ist durch eine eindeutige OID gekennzeichnet, dadurch wird durch Angabe von Code und OID ein bestimmtes Konzept eindeutig bezeichnet.

ELGA Begriffe – Value Set

• Ein „Value Set“ oder „Wertemenge“ ist eine eindeutig identifizierbare und versionierte Sicht auf eine oder mehrere Terminologien
• Ein Value Set kann als Kollektion von 1-n Codes der 1-n Terminologien gesehen werden.
• Die Festlegung der zulässigen Menge von Codes erfolgt über eine "Value Set Assertion". Dadurch werden Codes aus einem oder mehreren Codesystemen ausgewählt, eine solche Auswahl stellt ein "Value Set" dar. Dabei wird u.a. angegeben, welche Codes bei der Implementierung unterstützt werden müssen, welche Codes unterstützt werden dürfen und welche Codes nicht verwendet werden dürfen. Jedem Value Set wird wiederum eine OID zur eindeutigen Referenzierung zugeordnet.
• ACHTUNG: Die OID des Value Sets dient nur der Referenzierung des Value Sets, sie ersetzt nicht die OID des Codesystems. Die Bedeutung eines kodierten Konzepts ergibt sich immer aus der Kombination Code/Codesystem. (So kann ein ValueSet theoretisch mehrere gleichlautende Codes enthalten, die aber zu verschiedenen Codesystemen gehören!)

KAV Begriffe - Katalog

• Jeder Katalog hat einen Katalogstyp welcher gleichartige Codes zusammenfasst
• Zu jedem Code können bestimmte vordefinierte Attribute erfasst werden
• Innerhalb eines Katalogs kann mit einer Präfixierungslogik eine weitere Untergliederung vorgenommen werden

Der Teminologieserver in ELGA

• Der Terminologieserver stellt die verbindliche Publikationsinstanz für in ELGA zu verwendenden Value Sets dar
• Über eine Webservice-Schnittstelle kann jeder ELGA Teilnehmer den aktuellen Stand der in ELGA verwendeten Value Sets in seine Domäne herunterladen.

Dies soll in periodischen Abständen (z.b. täglich) erfolgen

• Der Terminologieserver ist NICHT dafür ausgelegt häufige Codevalidierungen durchzuführen

Die im KAV umgesetzte Lösung

• Einbindung der ELGA Value Sets in die KAV weite Katalogsverteilung
• Entwicklung eines Mapping Tools welches die Übersetzung der vom Terminologieserver geladenen Value Sets auf die KAV Kataloge (und vice versa) ermöglicht
• Es ist für jede Mapping Tabelle ein Verantwortlicher zu definieren welcher im Falle einer Änderung von den für das Mapping relevanten Katalogen oder Value Sets das Mapping entsprechend (teilweise Fachwissen erforderlich) umsetzt.
• Es ist ein „Uebermapper“ definiert welcher bei neuen Katalogen oder Savesets erforderlichen falls neue Mapping Verantwortliche findet
• Einsatz eines Webservices um allen im KAV eingesetzten Applikationen die Möglichkeit der Umschlüsselung zwischen KAV Katalogen sowie ELGA Value Sets zu ermöglichen

Datenübernahme ELGA - KAV

• Ein periodisch laufender Batchjob übernimmt die Informationen (Value Sets und Codelisten) aus dem Terminologieserver und legt diese KAV intern ab
• Ein Importer übernimmt die abgelegten Terminologieserver Daten und fügt diese dem KAV Terminologie Store hinzu
  • Fehlerresistent gegenüber gelöschten und doppelten Einträgen

Datenmapping - Datenserver

• KAV Katalogs Content Server

Stellt die intern verwendeten Kataloge zur Verfügung

• KAV Terminologie Store

Stellt die ELGA Value Sets und Codesysteme zur Verfügung

• KAV Mapping DB

Verbindet den KAV Katalogs Content Server und den KAV Terminologie Store

Datenmapping - Abbildung

• Ein Mapping stellt einen bestimmten Mapping-Typ dar
  • Dieser ist eine unidirektionale N:N Verbindung zwischen zwei Tabellen
  • Jeder einzelne Mapping Eintrag kann auch eine „Gültig ab/bis“ Information haben
  • Die Abfrage eines Mapping Typs mit einem Codewert kann eine Liste von 0 bis N Elementen liefern

Zu jedem Listelement wird die gesamte Information geliefert

Der Umgang mit 0 oder N Resultaten ist in der Applikation abzudecken

Die Verarbeitung des Gültigkeitszeitraumes ist in der Applikation abzudecken

• Wenn eine bidirektionale Umschlüsselung notwendig ist dann ist ein 2ter Mappingtyp zu erstellen

Datenmapping Zugriff

• Es wird ein Webservice angeboten welches die Informationen der KAV Mapping DB abfragen kann
• Parameter:
  

Mapping Typ

Zu mappender Code

Resultat ist eine Ergebnisliste

KAV Mapping – Erweiterungen in Konzeption

• Bessere Integration der „Gültig ab/bis“ Logik
  

Unterstützung beim Mapping

Unterstützung in Abfragen

• Generische Ausnahmenbehandlung
  

Abhängig vom Resultat des Mappings soll schon beim Mapping Typ das Verhalten in bestimmten Situationen (0 oder N Ergebnisliste) konfiguriert werden können

Einbindung des ELGA Bereichs

• Im ELGA Bereich werden keine KAV Katalogseinträge verwendet – nur ELGA Value Sets
• Der ELGA Bereich benötigt daher keine Mapping Tabellen
• Der ELGA Bereich benötigt jedoch Teile der jeweils aktuellen ELGA Value Sets
• Die Versorgung des ELGA Bereichs mit den benötigten Value Sets ist sicherzustellen entweder durch
  • direkten Abgleich mit dem Terminologieserver (SVS)
  • oder durch Benutzung der abgezogenen Daten aus dem Katalogssystem (proprietäre Schnittstelle)

Einbindung zusätzlicher GDAs

• Wenn zusätzliche GDAs in das Mappingsystem eingebunden werden sollen so ist ein GDA Katalogs Content Server der intern verwendeten Kataloge anzulegen
• Der Prozess des Abgleichs mit der Mapping DB ist analog zu sehen

Kontakt für „KAV Best Practice Terminologien“

• Mag. Konrad Hölzl
  

Tel: 01/40409 - 66036

KAV-IT

1220 Wien, Stadlauer Straße 54

E-Mail: konrad.hoelzl@wienkav.at

http://www.wienkav.at/ikt