ILF:Terminologie Nutzung: Unterschied zwischen den Versionen

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
[unmarkierte Version][unmarkierte Version]
(CSV)
(Anhang: Best Practice Beispiel KAV Wien)
Zeile 310: Zeile 310:
  
 
''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.''
 
''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.''
 +
 +
[[Datei:KAV Best Practice Terminologien.png|600px]]

Version vom 28. September 2017, 10:24 Uhr

[[Kategorie:]]


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ürfen1. 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 immer2 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…) an¬ge-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 Version3. 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.

Konzepte in den Value Sets werden nach ihrem Typ unterschieden:

  • L= Code besitzt keine weitere Spezialisierung, kann verwendet werden
  • S= Code kann spezialisiert, aber auch in dieser Ebene verwendet werden.
  • A= Code wird spezialisiert, dieser Code dient nur zur Gruppierung der Spezialisierung und darf nicht verwendet werden

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.


1 „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/ )
2 Mit wenigen Ausnahmen 3 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.

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.

Terminologieserver für die Entwicklung und Nutzung von Terminologien.png

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 ver¬wendet 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 ver¬sehen, 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.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.

  1. 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_Laborparameter5 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


5 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 Best Practice Terminologien.png