5.399
Bearbeitungen
Änderungen
keine Bearbeitungszusammenfassung
{{#seo:
|title=Terminologie Nutzung
|titlemode=append
|keywords=Terminologie Nutzung, Terminologie, Terminologieserver, Codesysteme, Value Sets, Value Set,
|description= Ein Terminologieserver stellt Terminologien in standardisierter Form für Benutzer zur Verfügung. Dadurch wird die semantische Interoperabilität in verteilten Systemen unterstützt.
}}
{{#customtitle:Terminologie Nutzung}}
{{Underconstruction}}
Was findet man wo?
* Wichtige Definitionen und Begriffsbestimmungen in [[ILF:Terminologie_Nutzung#Definitionen|Kapitel 1.2]]* Eine Beschreibung des Terminologieservers in [[ILF:Terminologie_Nutzung#Beschreibung_des_Terminologieservers| Kapitel 3]]* Die Codelisten und Value Sets für ELGA in [[ILF:Terminologie_Nutzung#ELGA_Value_Sets |Kapitel 2]]* Änderungsprozesse für Terminologien in [[ILF:Terminologie_Nutzung#.C3.84nderbarkeit_von_Value_Sets|Kapitel 2]]* Best Practice für die [[ILF:Terminologie_Nutzung#Verwendung_von_Value_Sets| Verwendung der Value Sets ]] und des [[ILF:Terminologie_Nutzung#Verwendung_des_Terminologieservers| Terminologieservers in Kapitel 4]]* Technische Details (Aufbau und Attribute der Exportformate) in [[ILF:Terminologie_Nutzung#Technische_Informationen| Kapitel 5]]
=Informationen über dieses Dokument=
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 [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [https://www.elga.gv.at/index.html 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.
==Support, Helpdesk, Kontakt==
* Grundsätzlich ist die ELGA-Serviceline bei allen Anfragen zu Terminologien und zum Terminologieserver zu kontaktieren: [mailto: info@elga-serviceline.at info@elga-serviceline.at] (Tel: +43.50.124 4411)
=Die ELGA-Terminologien =
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¬geange-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<sup>3</sup>. Solange keine neuere Version vorhanden ist, bleibt ein Value Set gültig (siehe auch [[ILF:Terminologie_Nutzung#Value_Set_Binding| Kapitel 2.2.1“Value 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.
===Value Set Binding===
<sup>1</sup> „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/ )<br/>
<sup>2</sup> Mit wenigen Ausnahmen <br/>
<sup>3</sup> 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.
===Kommunikation der Veränderung von Terminologien===
Alle Änderungen von Terminologien sind am Terminologieserver zentral abrufbar. Die Mechanismen werden in [[ILF:Terminologie_Nutzung#Pr.C3.BCfung_auf_Aktualisierung|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 [[ILF:Terminologie_Nutzung#Pr.C3.BCfung_auf_Aktualisierung| Kapitel 6 „Best Practice Terminologien“ ]] des KAV Wien beschrieben.
===Anforderung von Erweiterungen oder Korrekturen von Terminologien ===
Alle Fragen zu ELGA-relevanten Terminologien können an [mailto:info@elga-serviceline.at 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 <sup>4</sup> 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.
=Der Terminologieserver=
Ü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.
[[Datei:Terminologieserver für die Entwicklung und Nutzung von Terminologien.png|600px]]<br/>''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.
* 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 [[ILF:Terminologie_Nutzung#Terminologieserver:_Export_mittels_Webservice|4.2.1.2]].
=Best Practice=
# Bei der Verwendung von Level-3-codierten Informationen MÜSSEN Code und Codesystem gleichzeitig betrachtet werden.
# 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.
## Nur wenn der Code nicht im Codesystem gefunden werden kann, können alternativ der OriginalText oder DisplayName aus dem jeweiligen Dokument ver¬wendet verwendet werden.
# 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.
# Für die Verwendung „historischer“ Level-3-Werte wird daher folgendes Vorgehen beim Import neuer Value Sets EMPFOHLEN:
## Vorbedingung: Alle Einträge erhalten im lokalen System einen Gültigkeitszeitraum (oder ein äquivalentes Gültigkeitskennzeichen).
## 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¬sehenversehen, dadurch werden die bisherigen Einträge als „veraltet“ gekenn-zeichnet. Zusätzlich kann noch ein entsprechender Status gesetzt werden.
## 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.
Am Terminologieserver können aktuelle Änderungen an Terminologien angezeigt werden („Aktuelle Vorgänge“). Diese können nach mehreren Kriterien gefiltert werden.
====Terminologieserver: Export mittels Webservice====
Der Export von Terminologien ist ein zweistufiges Verfahren. In beiden Schritten kann eine entsprechende Prüfung auf Aktualisierung stattfinden:
# 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. ## 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ültigegültige. Diese Variante der Aktualisierungsprüfung auf Versionsebene ist empfohlen.
# 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 ([[ILF:Terminologie_Nutzung#Elemente_der_Downloadformate|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.
# 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: [mailto: engelbert.prenner@bmg.gv.atengelbert.prenner@bmg.gv.at], Telefon: +43-1/71100-4795)
=Technische Informationen=
<sup>5</sup> Mapping der Basisattribute der Laborparameter auf Elemente im Terminologieserver siehe Leitfaden zur Anwendung von LOINC in ELGA
===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.
=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.''
[[Datei:KAV Best Practice Terminologien.png|600px]]
'''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
[[Datei:Grafikübersicht Mapping KAV.png|600px]]
'''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<br/>
:: Der Umgang mit 0 oder N Resultaten ist in der Applikation abzudecken<br/>
:: Die Verarbeitung des Gültigkeitszeitraumes ist in der Applikation abzudecken<br/>
* 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:<br/>
: Mapping Typ<br/>
: Zu mappender Code<br/>
:Resultat ist eine Ergebnisliste
'''KAV Mapping – Erweiterungen in Konzeption'''
* Bessere Integration der „Gültig ab/bis“ Logik<br/>
: Unterstützung beim Mapping<br/>
: Unterstützung in Abfragen
* Generische Ausnahmenbehandlung<br/>
: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<br/>
: Tel: 01/40409 - 66036<br/>
: KAV-IT<br/>
: 1220 Wien, Stadlauer Straße 54<br/>
: E-Mail: [mailto:konrad.hoelzl@wienkav.at konrad.hoelzl@wienkav.at] <br/>
: http://www.wienkav.at/ikt
