ihevs:Vokabular-Management

From eHealth Suisse
Revision as of 16:24, 13 August 2018 by Gnj (talk | contribs)
Jump to: navigation, search
Dieses Material ist Teil

des Leitfadens IHE Valuesets.

  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Terminologie-Management

Grundlagen

Die Übermittlung von konkreten Daten kann auf zweierlei Art und Weise erfolgen: Die einfachste Variante ist Freitext, bei der beliebige Daten - als Zeichenkette (ggf. noch eingeschränkt auf einen bestimmten Datentyp) - übertragen werden. Dieses Verfahren bietet sich an, wenn die individuelle Ausprägung sehr unterschiedlich sein kann wie bspw. dem Namen des Patienten oder ein Kommentar. Für immer wiederkehrende und im Prinzip gleiche Information - wie bspw. der Familienstand - werden die zu übertragenden Daten abgekürzt und durch einen "Platzhalter" ersetzt. Bei letzterem muss die Bedeutung aber klar sein. Hierfür werden Codesysteme definiert, die sowohl die Abkürzungen - Codes - als auch die Bedeutung auflisten. Die Zuordnung von einzelnen Feldern in einer Spezifikation für den Datenaustausch zu konkreten Wertelisten erfolgt mehrstufig: Die Festlegung der erlaubten Werte für ein codiertes Attribut erfolgt über die Angabe von sog. Konzept- oder Vokabeldomänen (Concept / Vocabulary Domains), Codesystemen (Code Systems) und Wertemengen (Value Sets).

Eine Konzeptdomäne dient dazu, den Wertebereich eines Attributs einzugrenzen ohne dabei direkt schon feste Codesysteme oder Value Sets vorzugeben. Eine Konzeptdomäne wird durch einen Namen, eine textuelle Beschreibung sowie eine Reihe von Beispielkonzepten definiert. Zum Beispiel soll die Konzeptdomäne (bzw. hier das Metadatum) DocumentEntry.typeCode von IHE den Typ eines Dokuments aus Benutzersicht codieren. IHE definiert aber noch keine konkreten Werte, ein Valueset muss durch die nutzende Gemeinschaft selber gemäss den Bedürfnissen definiert werden.

Ein Value Set ist eine eindeutige identifizierbare Sammlung von Konzeptrepräsentationen und es ist einer oder mehreren Konzeptdomänen zugeordnet. Ein Value Set kann Codes aus einem oder mehreren Codesystemen enthalten. Ein Codesystem wird dabei durch eine Liste von Codes mit zugehörigen Anzeigenamen und Beschreibungen definiert. Innerhalb eines Codesystems muss ein Code eine eindeutig definierte Bedeutung haben.

Value Sets können in unterschiedlicher Art und Weise definiert werden: extensional als Sammlungen von Codes (Konzepten) oder intensional über einen berechenbaren Ausdruck, aus dem sich eine Codeliste exakt ermitteln lässt. Die Value Sets für DocumentEntry.typeCode und DocumentEntry.classCode in diesem Leitfaden sind beispielsweise extensional als Listen definiert.

Wenn ein Value Set neben den genannten oder beschriebenen Codes zusätzliche Werte erlaubt, wird es als offen (open) bezeichnet, andernfalls als geschlossen (closed). Das Value Set für DocumentEntry.languageCode ist beispielsweise offen, da neue Sprachcodes gebildet und wenn notwendig auch verwendet werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.healthcareFacilityTypeCode sind hingegen geschlossen. Das heißt, dass eine Erweiterung nur über eine neue Version der Value Sets erfolgen sollte.

Die Identifikation eines Value Sets erfolgt bei CDA und IHE XDS über eine OID, bei FHIR über eine URL. Die Version eines Value Sets wird über einen Zeitstempel charakterisiert. Die Bindung eines codierten Elementes an ein Value Set (Binding) kann nun dynamisch (dynamic) oder statisch (static) erfolgen. Ein dynamisches Binding bezieht sich auf die jeweils aktuellste Version eines Value Sets, während bei einem statischen Binding eine feste Version angegeben wird. Bei einem statischen Binding müssen OID bzw. ein eindeutiger Bezeichner sowie ein Zeitstempel angegeben werden. Beim dynamischen Binding fehlt der Zeitstempel.

Unabhängig davon gibt es für das Binding von ValueSets noch weitere Unterscheidungsmöglichkeiten. Beim Design-Time Binding wird das zu verwendende Value Set explizit angegeben. Beim Runtime Binding werden nur die Konzeptdomäne und die sogenannte Realm (z.B. „Schweiz“) festgelegt. Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt.

Bindings können verpflichtend sein (required), empfohlen werden (suggested oder preferred) oder dienen nur als Beispiel (example). Einzelne Werte eines Value Sets können als verpflichtend (required), erlaubt (permitted) oder ausgeschlossen (excluded) gekennzeichnet werden. Die in diesem Leitfaden definierten Codes besitzen alle den Status permitted.


Umgang mit Änderungen

Entfernen von Codes

Das Ändern oder Entfernen von Codes hat lediglich Auswirkungen auf bereits bestehende, codierte Dokumente. Beim Entscheid für eine Löschung eines Eintrags, müssen die folgenden Aspekte bereits berücksichtigt werden und eine Lösungsvorschlag dazu erarbeitet werden. In beiden Fällen muss eine Lösung für eine alternative Codierung vorhanden sein. Anderenfalls darf ein Code nicht gelöscht werden.

Es gibt es zwei Möglichkeiten wie damit umgegangen werden kann:

Aktualisieren der bestehenden Dokumente
Aktualisierung aller bestehenden Dokumente mit dem geänderten Code (Änderung) oder alternativen Code (Löschung). Hierfür kann das IHE Profil "XDS Metadata Update" genutzt werden.

Beziehungstabelle - Transitive Closure
Führen einer Tabelle, welche die gelöschten Codes sowie geänderten Codes und mapping auf die aktuell gültigen Codes enthält, so dass eine Beziehung zwischen diesen Codes besteht, die bei einer Suche berücksichtigt wird (Transitive Closure).

[Abbildung 1] Transitive Closure Beziehungen

Anschauliches Beispiel:
Gegeben sei eine Relation „Direkter-Vorgesetzter“ mit folgenden Beziehungen:

  • A ist direkter Vorgesetzter von B
  • B ist direkter Vorgesetzter von C und D

Die transitive Hülle dieser Relation enthält nun zusätzlich auch die indirekten Vorgesetzten:

  • A ist Vorgesetzter von B, C, D
  • B ist Vorgesetzter von C, D

Beispiel Metadaten:
Im Valueset wurde der Eintrag urn:che:epd:EPD_Structured_Document Structured EPD document gelöscht und durch spezifischere Einträge (z.B. urn:ihe:pcc:ic:2009 Immunization Content (IC), urn:ihe:lab:xd-lab:2008 CDA Laboratory Report) ersetzt.

Später soll der Eintrag urn:ihe:pcc:ic:2009 Immunization Content (IC) durch zwei neue Versionen ersetzt werden (urn:ihe:pcc:ic:2009a und urn:ihe:pcc:ic:2009b).

Lösungsvorschlag (Variante 2) Die neuen Einträge (urn:ihe:pcc:ic:2009, etc.) sind, logisch sowie historisch gesehen, Kinder des alten Elements urn:che:epd:EPD_Structured_Document. Für Sie soll ein Eintrag in der Tabelle erstellt werden.

Resultierende Tabelle:
[Tabelle 1] Tabelle Transitive Closure

Neuer Code Vorangehende Codes
urn:ihe:pcc:ic:2009 urn:che:epd:EPD_Structured_Document, *allenfalls weitere, ältere Codes*
urn:ihe:pcc:ic:2009a urn:ihe:pcc:ic:2009, urn:che:epd:EPD_Structured_Document, *allenfalls weitere, ältere Codes*
urn:ihe:pcc:ic:2009b urn:ihe:pcc:ic:2009, urn:che:epd:EPD_Structured_Document, *allenfalls weitere, ältere Codes*


Wir nun nach Dokumenten mit dem formatCode urn:ihe:pcc:ic:2009 gesucht werden, muss die Regel lauten, dass auch alle Dokument mit formatCodes gemässs Spalte "Vorangehende Codes" zurückgegeben werden. Falls sich die Heriarchie in mehrere Kinder spaltet (siehe Beziehung B zu C und D), kann eine Suchabfrage nach C oder D somit auch gleiche Dokumente zurückgeben (nämlich alle die mit B oder A codiert wurden).

Hinzufügen von Codes / Bezeichnungen

Wenn neue Codes hinzugefügt werden, muss in den Systemen, wo die Metadaten genutzt werden (Dokumente mit Metadaten erstellen, suchen, verarbeiten) die Liste aktualisiert werden. Allenfalls müssen vordefinierte Filter, Regeln entsprechend angepasst werden.

Kombination von Attributen

Bei dem Zuordnen von Metadaten zu Dokumenten wird man feststellen, dass die Zuordung zu einem Dokumenttyp einer bestimmten Berufsgruppe (z.B. Ärztlicher Austrittsbericht) so nicht vorhanden ist. Der Grund dafür ist, die Listen so kurz wie nötig zu halten, und durch die Kombination von Attributen die Zuordnung zu machen.

Für die Einordnung bzw. Kombination sind die folgenden Attribute wichtig:

Die Dokument-Klasse wird dabei gemäss dem definierten Mapping gesetzt.

Beispiele

Dokumenttyp authorRole practiceSettingCode typeCode healthcareFacilityTypeCode
Austrittsbericht (ärztlich) Arzt diverse Austrittsbericht Stationäre Einrichtung/Spital
Austrittsbericht Frauenklinik (ärztlich) Arzt Austrittsbericht Stationäre Einrichtung/Spital
Pflegeüberweisungsbericht Pflegefachperson diverse Pflegebericht Stationäre Einrichtung/Spital
Logopädie Befund (nach ambulanter oder stationärer Behandlung) Logopäde Logopädie
Mund-, Kiefer- und Gesichtschirurgie
TODO: Validieren
Untersuchungsbefund (allgemein) Stationäre Einrichtung/Spital
Notfallbericht Orthopädie Arzt Orthopädie und Traumatologie TODO: braucht es einen speziellen Notfallbericht?
Stationäre Einrichtung/Spital


Cite error: <ref> tags exist for a group named "Abbildung", but no corresponding <references group="Abbildung"/> tag was found, or a closing </ref> is missing
Cite error: <ref> tags exist for a group named "Tabelle", but no corresponding <references group="Tabelle"/> tag was found, or a closing </ref> is missing