ehsuh:IHE Metadaten
![]() |
Dieses Dokument gibt wieder:
Umsetzungshilfe Value Sets für XDS - Version 0.1 (30.06.2018). Die Teilmaterialien gehören der Kategorie ihevs an. |
![]() |
![]() |
Value Sets für IHE Metadaten im elektronischen Patientendossier
Pre-Publication Review
(Aktualisierte Version vom 30.06.2018)
Schwarzenburgstrasse 157
Versionierung | ||||
---|---|---|---|---|
Version | Datum | Status | Änderungen gegenüber Vorversion | Download |
0.1 | 14.09.2017 | Entwurf | Entwurf für Sitzung Expertengruppe Metadaten | kein download verfügbar |
0.2 | 28.05.2018 | Entwurf | Entwurf für Sitzung Expertengruppe Metadaten vom 6. Juni 2018 | kein download verfügbar |
0.3 | 15.06.2018 | Entwurf | Überarbeitung gemäss der Besprechung in der EGM. Ergänzung Anforderungen, Einschluss Valueset DocumentEntry.eventCodeList | kein download verfügbar |
0.3 | 15.06.2018 | Entwurf |
|
kein download verfügbar |
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
Contents
- 1 Einleitung
- 2 Grundlagen
- 3 Anwendungsfälle
- 4 Terminologie-Management
- 5 Value-Set-Tabellen
- 6 Value Sets
- 6.1 DocumentEntry.authorRole
- 6.2 DocumentEntry.authorSpeciality
- 6.3 DocumentEntry.sourcePatentInfo/administrativeGender
- 6.4 DocumentEntry.confidentialityCode
- 6.5 DocumentEntry.classCode
- 6.6 DocumentEntry.typeCode
- 6.7 DocumentEntry.healthcareFacilityTypeCode
- 6.8 DocumentEntry.practiceSettingCode
- 6.9 DocumentEntry.formatCode
- 6.10 DocumentEntry.mimeType
- 6.11 DocumentEntry.languageCode
- 6.12 DocumentEntry.eventCodeList
- 6.13 SubmissionSet.contentTypeCode
- 7 Konkrete Beispiele für Metadaten von häufigen Dokumenten
- 8 Anhang
Einleitung
Ziel & Zweck
Das Dokument soll eine Hilfestellung für die Nutzung der EPD Metadaten sein, sowie einen Rahmen für deren Weiterentwicklung geben.
Hintergrund
Die IHE-Profile zum einrichtungsübergreifenden Austausch medizinischer Dokumente (XDS – Cross-Enterprise Document Sharing, XDR, XDM) werden, kommen im EPD zur Anwendung. Sie stellen eine moderne, internationale Grundlage für den elektronischen Austausch medizinischer Dokumente im Gesundheitswesen dar.
Zum besseren Wiederfinden, zur leichteren Anzeige, Auswertung und Archivierung sollten die ausgetauschten Dokumente mit einer Reihe von beschreibenden Codes indexiert werden. Daher schreiben die Profile einen umfangreichen Satz an Metadaten (wie z.B. Fachrichtung, Einrichtungsart und Dokumententyp) zur Beschreibung der medizinischen Dokumente vor. Die internationalen IHE-Profile geben hier jedoch keine konkreten Terminologien vor, um die landestypischen Konzepte (z.B. eine Spitex als Einrichtungsart) abzubilden.
Vorgehensweise
Im Jahr 2012 wurde eine erste Empfehlung für die Nutzung von Metadaten im EPD mit einem Starterset verabschiedet. Seit dann wurde das Set kontinuierlich weiterentwickelt.
Während der Umsetzung des EPD wird das Starterset mit den Anforderungen aus der Klinik und BAG Reporting abgeglichen und wo nötig ergänzt. Viele Spitäler werden ihre Universalarchive ans EPD anbinden. Mit den Fachverantwortlichen der Archive werden die dort vorhandenen Dokumente und Medien analysiert. Die Analyse soll die Dokumente aufzeigen, die potentiell im EPD registriert werden. Aus den Suchstrategien bzw. Filterkriterien in den Archiven können dann auch Annahmen über das Suchverhalten im EPD abgeleitet werden. Daraus werden Use Cases abgeleitet, die wiederum sicherstellen sollen, dass alle nötigen Anforderungen mit den Metadaten adressiert werden können.
Angesprochene Leserschaft
Das Dokument richtet sich an Personen die mit dem Ordnen und Archivieren von Dokumenten in Gesundheitsinstitutionen betraut sind (z.B. Betreuung von Universalarchiven) und Hersteller solcher Systeme. Mit dem Dokument soll Ihnen ein Leitfaden für das Zuordnen der EPD-Dokumenttypen zu den lokal genutzten Einteilungen gegeben werden. Das Dokument dient auch der Expertengruppe Metadaten als Leitfaden für die Pflege und Weiterentwicklung der Metadaten im EPD. Für die Hersteller von EPD-Infrastrukturen (GFP/Patientenportale) dient der Leitfaden als Übersicht, wie die Metadaten genutzt werden sollten und welche Anforderungen sich an die Verwendung und Verwaltung stellen.
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
Grundlagen
Grundlagendokumente
Das folgende Dokument baut auf verschiedenen Vorarbeiten auf:
- Deutschland - Valuesets für XDS
- XDS Metadaten in der ELGA
- Definition XDS-Metadatenset 2010
- Anwendungsfälle und Metadaten für Berechtigungssteuerung 2013
- Empfehlungen I Semantik und Metadaten 2013
- EPD - Metadaten Definitionsprozess und erstes Startset
- IHE Metadata Handbook
Aufgaben der Metadaten
Die Metadaten erfüllen im Wesentlichen folgende Aufgaben:
- Identifizierung des Patienten, auf den sich das Dokument bezieht
- Beschreibung der Herkunft des Dokuments
- Erfüllung der Anforderungen zu Sicherheit und Vertraulichkeit der Dokumente
- inhaltliche Beschreibung, um die Dokumente möglichst schnell und zuverlässig wiederzufinden und um eine einfach navigierbare Aktensicht aufzubauen
- Beschreibung des Lebenszyklus des Dokumentes, z.B. ob es noch aktuell ist oder durch ein anderes Dokument ersetzt wurde
- Erleichterung der maschinellen Verarbeitung der Dokumente, z.B. zur Entscheidung welcher Viewer für die Anzeige des Dokuments geeignet ist
IHE XDS
Überblickstabelle der XDS Metadaten
Die folgende Tabelle gibt einen Überblick über alle XDS-Metadaten-Elemente gemäss dem IHE IT Infrastructure Technical Framework, Volume 3 (ITI TF-3). Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. EPD für das Einbringen von Dokumenten, sowie die Quelle aus der die Informationen stammen.
In der Tabelle 3 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (OD) angegeben.
Code | Bedeutung |
---|---|
C | Aus CDA-Inhalt abgeleitet oder automatisch setzbar (direkt oder indirekt, gilt nicht für On-Demand-Documents) |
E1 | Explizit gesetzt (EPD relevant) |
E2 | Explizit gesetzt (nicht EPD relevant) |
A | Von Registry oder Repository automatisch gesetzt |
Tabelle 1: Legende zur Spalte „Quelle“ der folgenden Tabelle
Code | Bedeutung |
---|---|
R | Verpflichtend („Required”) |
R2 | Verpflichtend wenn bekannt („Required if Known“) |
O | Optional |
X | Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen |
Tabelle 2: Legende zur Spalte „Optionalität“ der folgenden Tabelle
Metadaten Element | Optionalität | Beschreibung | Quelle | ||
XDS DS1 | XDS OD2 | ||||
Aus dem CDA-Inhalt ableitbare Metadaten | |||||
author (besteht aus den folgenden Komponenten) | R2 | R2 | Die Person, welche das Dokument verfasst hat | - | |
authorInstitution | R | R | ID der Organisation der die Person angehört. (GLN aus dem HPD-Index) | C | |
authorPerson | R | R | Daten der Person. (Name, ID, etc.) |
C | |
authorRole | R2 | X | Rolle der Person | C | |
classCode | R | R | Dokumentenklasse (Oberklasse) | C | |
confidentialityCode | R | X | Vertraulichkeitsstufe des Dokuments | C | |
creationTime | R | X | Zeitpunkt der Dokumentenerstellung | C | |
eventCodeList | O (XDS-I.b: R) | O | Liste von Gesundheitsdienstleistungen | C | |
intendedRecipient | O | O | Derzeit nicht in Verwendung. | C | |
languageCode | R | R | Sprachcode des Dokuments z.B.: "de-CH" |
C | |
legalAuthenticator | O | O | Rechtlicher Unterzeichner des Dokuments | C | |
serviceStartTime | R2 | O | Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme | C | |
serviceStopTime | R2 | O | Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung | C | |
sourcePatientId | R | R | Patienten ID im Informationssystem der GFP. (z.B.: im KIS eines Spitals) | C | |
sourcePatientInfo | O | O | Demographische Daten des Patienten im Informationssystem der GFP (z.B.: im KIS eines Spitals) | C | |
Title | O | O | Titel des Dokuments | C | |
typeCode3 | R | R | Dokumententyp (Unterklasse) | C | |
uniqueId | R | R | Global eindeutige ID des Dokuments | C | |
referenceIdList | O | O | Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert | C | |
Explizit zu setzende Metadaten | |||||
availabilityStatus | O | O | Gültigkeit des Dokuments | E1 | |
formatCode | R | R | Format des Dokumenteninhalts | E1 | |
healthcareFacilityTypeCode | R | R | Typ der Institution | E1 | |
mimeType | R | R | Mime Type des Dokuments z.B.: "text/xml" für CDA |
E1 | |
practiceSettingCode | R | R | Fachliche Zuordnung des Dokuments | E1 | |
entryUUID | R | R | UUID des Metadaten-Records des Dokuments (XDS DocumentEntry) | E1 | |
objectType | R | R | Typ des DocumentEntries (SD oder ODD) | E1 | |
comments | O | O | Kommentar zum Dokument | E2 | |
patientId | R | R | Patienten-ID in der XDS Affinity Domain | E1 | |
Von Registry oder Repository automatisch gesetzte Metadaten | |||||
hash | O | X | Hash Wert des Dokuments. Wird vom Repository befüllt. | A | |
homeCommunityId | O | O | Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten. | A | |
repositoryUniqueId | O | R | Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt. | A | |
size | O | X | Größe des Dokuments in Bytes. Wird vom Repository befüllt. | A | |
URI | -6 | - | Wird in XDS nicht verwendet | A |
Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch) gemäs IHE ITI TF Vol3 (Rev. 14) 21.07.2017 - Optionalität beim abspeichern.
1 Gemäss Tabelle 4.3.1-1 Sending Actor/Transation Pairs; IHE ITI TF Vol3 (Rev. 14) 21.07.2017
2 „On-Demand Document“: Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. Gemäss Tabelle 4.3.1-1 Sending Actor/Transation Pairs; IHE ITI TF Vol3 (Rev. 14) 21.07.2017
3 Der Inhalt des typeCodes soll mit dem contentTypeCode des SubmissionSets übereinstimmen.
4 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert.
5 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein.
6 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.
Wichtige Definitionen zum Autor
Author
Definition IHE XDS: Represents the humans and/or machines that authored the document or SubmissionSet within the authorInstitution. The author may be the patient itself. This is a sub-attribute of the author attribute.
Mapping CDA: authorPerson: /ClinicalDocument/author/assignedAuthor/assignedPerson
Hinweis zum Thema "Gerät oder Software als Autor": Alternativ zu einer Person kann in CDA auch ein Gerät oder eine Software als Autor angegeben werden (/ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice). Die Zugriffrechte im EPD werden aber stets an Personen vergeben und deshalb kann das EPD Metadaten Attribut 'authorPerson' aus CDA-CH nicht ermittelt werden, wenn es sich um ein Dokument handelt, das von einem Gerät oder einer Software erstellt worden ist.
legalAuthenticator
Definition IHE XDS: Represents a participant within an authorInstitution who has legally authenticated or attested the document. Legal authentication implies that a document has been signed manually or electronically by the legalAuthenticator.
Ermittlung in CDA-CH Dokumenten: /ClinicalDocument/legalAuthenticator
DataEnterer
CDA unterscheidet eine weitere Rolle, welche in den Metadaten nicht abgebildet ist: den «DataEnterer». Der «Author» ist die Person, die den Inhalt vorgibt. Der «DataEnterer» ist die Person, die den Inhalt des «Authors» erfasst (z.B. Arztsekretärin auf Basis von Diktat).
Ziel des Projekts
Ziel des Projektes ist die Erarbeitung gemeinsamer Metadaten, damit die unterschiedlichen Gemeinschaften im EPD Dokumente austauschen können und um neuen Projekten einen schnelleren Einstieg zu ermöglichen.
Folgende Value Sets werden initial bereitgestellt:
- DocumentEntry.authorRole
- DocumentEntry.authorSpecialty
- DocumentEntry.confidentialityCode
- DocumentEntry.classCode
- DocumentEntry.typeCode
- DocumentEntry.healthcareFacilityTypeCode
- DocumentEntry.practiceSettingCode
- DocumentEntry.eventCodeList
- DocumentEntry.formatCode
- DocumentEntry.mimeType
- DocumentEntry.languageCode
- SubmissionSet.contentTypeCode
Verbindlichkeit der Value Sets
Die in diesem Leitfaden eingeführten Value Sets sind für die Schweiz im Rahmen des elektronischen Patientendossiers, wo nicht anders angegeben, verbindlich.
Änderung und Pflege
Änderung und Pflege der hier vorgestellten Value Sets erfolgt durch die Expertengruppe Metadaten von eHealth Suisse.
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
Anwendungsfälle
Information Retrieval – Suchen und Finden
Der wichtigste Anwendungsfall für die Metadaten und deren Wertebereiche ist das "Information Retrieval", das heisst das Suchen, Finden, Sortieren und Anzeigen von EPD-Dokumenten. Unter der Annahme, dass in Zukunft in einem Patientendossier eine Vielzahl von Dokumenten verfügbar gemacht werden, muss der Anwender möglichst schnell und einfach jene Dokumente finden, die ihn im Moment interessieren.
Durch passende Filterkriterien wird die Ergebnisliste einer Suche eingegrenzt werden müssen, damit die Bedienbarkeit gegeben ist. Für die Suche nach Informationen ist es unabdingbar, dass alle Akteure und Benutzer des EPD-Systems wissen, nach welchen Begriffen gesucht, gefiltert und sortiert werden kann. Das bedeutet im Umkehrschluss auch, dass diejenigen, die die Dokumente in das EPD einstellen oder dort verfügbar machen, genau diese Begriffe verwenden müssen. Letztendlich ist grundlegende Voraussetzung, dass alle Begriffe von allen auch gleich interpretiert und verstanden werden, sonst wird die suchende Person nicht auf Anhieb fündig. Für das EPD wird aufgrund der Architektur und der Zugriffsberechtigungen auf Dokumente, eine Volltextsuche nur sehr schwierig bzw. zu teuer zu realisieren sein. Die Suche muss darum in erster Linie über die Metadaten und Dokumenttitel realisiert werden.
Referenzen:
[1] Information retrieval pathways for health information exchange in multiple care settings, Am J Manag Care. 2014 Nov;20(11 Spec No. 17):SP494-501.
[2]Frieder, O., Grossman, D., Chowdhury, A., & Frieder, G. (2006). Efficiency Considerations for Scalable Information Retrieval Servers. Journal of Digital Information, 1(5). Retrieved from https://journals.tdl.org/jodi/index.php/jodi/article/view/21/21
[3]Croft, W. B., Metzler, D., & Strohman, T. (2010). Search engines: Information retrieval in practice. Boston: Addison-Wesley.
Storyboard "Hüftgelenkersatz"
Dieses Fallbeispiel dient lediglich der Illustrierung und wurde der CDA-CH Spezifikation entnommen.
Ein 70-jähriger Patient wendet sich wegen belastungsabhängigen Schmerzen im rechten Hüftgelenk, welche schon seit längerer Zeit bestehen, in den vergangenen Monaten aber deutlich zugenommen haben, an seinen Hausarzt.
Aufgrund der Anamnese und des klinischen Status des Patienten stellt der Hausarzt die Verdachtsdiagnose einer Arthrose des rechten Hüftgelenkes als Ursache für die Beschwerden. Der Hausarzt entschliesst sich, den Verdacht durch eine Röntgenuntersuchung des Hüftgelenkes zu bestätigen. Da er selbst keine Röntgenuntersuchungen durchführt, meldet er den Patienten in einem externen Röntgeninstitut mittels eines Auftragsformulars an und vereinbart auch gleich einen Untersuchungstermin. Die Bilder der Untersuchung sowie ein Röntgenbefund mit Beurteilung durch den radiologischen Facharzt werden dem Hausarzt kurz
nach Durchführung der Untersuchung zugestellt.
Bei der nächsten Konsultation bespricht der Hausarzt die Situation mit dem Patienten. Es wird gemeinsam entschieden, den Patienten an einen Facharzt für Orthopädie zur Besprechung der Therapieoptionen zu überweisen. Der Hausarzt verfasst einen Überweisungsbericht, welcher den bisherigen Krankheitsverlauf und die Untersuchungsergebnisse umreisst und übermittelt diesen, zusammen mit den Röntgenbildern an die Praxis des Orthopäden.
Nachdem er sich über den radiologischen Befund anhand der übermittelten Röntgenbilder bereits vorgängig orientiert hat, empfiehlt der Orthopäde dem Patienten die operative Sanierung des rechten Hüftgelenkes mittels Implantation einer Hüftgelenks-Endoprothese. Der Patient erklärt sich mit dem Vorschlag einverstanden.
Der Orthopäde informiert den Hausarzt über den Entscheid und bittet ihn, die Spitaleinweisung zu organisieren und die präoperativen Laboruntersuchungen in der Hausarztpraxis durchzuführen.
Kurz vor dem Spitaleintritt hat der Patient einen Termin bei seinem Hausarzt, um die vor der Operation notwendigen Laborwerte bestimmen zu lassen. Die Laborwerte werden vom Hausarzt der Klinik übermittelt, wo sie ins elektronische Patientendossier aufgenommen werden.
Während der Operation stehen dem Orthopäden die Röntgenbilder der Hüfte zur Verfügung. Die Lage der Endoprothese wird intraoperativ mittels C-Bogen kontrolliert. Postoperativ werden in der Klinik erneut Kontroll-Röntgenbilder der Hüfte erstellt. Der Orthopäde dokumentiert den Operationsverlauf und gibt Instruktionen für die weitere Nachbehandlung in einem Operationsbericht. Dem Hausarzt wird eine Kopie dieses Operationsberichtes
zugestellt.
Der Patient kann nach einer Woche Spitalaufenthalt in eine stationäre Rehabilitation entlassen werden.
Nach abgeschlossener Rehabilitation des Patienten erstellt die Rehabilitationsklinik ihrerseits einen orientierenden Bericht zuhanden des Hausarztes mit Kopie an den Orthopäden. Die Behandlung wird mit einer Abschusskonsultation beim Hausarzt schliesslich beendet.
Storyboard Mehrere Erkrankungen
[Abbildung 1] Storyboard Mehrere Erkrankungen
Hannes Hofer hat zunehmend gesundheitliche Probleme: Er leidet an Übergewicht, Hypertonie und einem Diabetes Typ 2. Kurz nach seiner Pensionierung hatte er einen ersten Herzinfarkt. Sein Hausarzt und die Herzspezialistin sind froh, dass Hannes Hofer ein EPD hat.
![]() |
Suche nach Dokumenten: Der Herzspezialist sucht im EPD von Hannes Hofer (PatientId) alle Dokumente vom Hausarzt und vom Spital (Name oder Typ der Gesundheitseinrichtung) abgefragt. |
So sind sie immer auf dem gleichen Wissensstand. Aufgrund des Diabetes hat Hannes Hofer zusätzlich eine schlecht heilende Wunde am Fuss, die intensiv von der Spitex gepflegt werden muss. Die Mitarbeiterin der Spitex fotografiert die Wunde regelmässig und stellt die Bilder ins EPD.
![]() |
Einstellen von Dokumenten:
|
Der Dermatologe kann so die Wundheilung überwachen, ohne dass jedes Mal eine Konsultation nötig ist.
![]() |
Suche nach Dokumenten: Der Dermatologie sucht im EPD von Hannes Hofer (PatientId) alle Dokumente vom Typ 'Wund-Befund'. |
Mögliche vordefinierte Filter für die Suche
Anfrage | nötige Angaben | Bemerkungen |
---|---|---|
Die 20 neusten Dokumente | PatientId, Einstelldatum | |
Letzter Bericht vom Hausarzt | PatientId, Einstelldatum, Gesundheitseinrichtung oder Name des Hausarztes, ev. Rolle des Autors | |
Aktuelle Medikation | PatientId, Dokumenttyp | |
Dokumente vom letzten Jahr | PatientId, Erstelldatum | |
Dokumente von Therapeuten | PatientId, Gesundheitseinrichtung oder Rolles des Autors, Fachrichtung der Einrichtung | |
Operationsbericht vom Hüftgelenksersatz von 2000 | PatientId, Dokumenttyp, Art des Eingriffs, Erstelldatum | - |
Aktueller Notfallpass des Patienten | PatientId, Dokumenttyp, Erstelldatum | - |
[Tabelle 1] Mögliche vordefinierte Filter für die Suche
Abgeleitete Anforderungen
Von | Anforderung | Beispiel | Stand |
---|---|---|---|
Allgemein | Indices für die Metadaten | Achtung: Anforderung an die Implementierung | |
Filter | Damit z.B. eine Gruppe von Dokumenten gefunden werden kann (z.B. alle für einen Notfall relevanten Dokumente) sollten für einen Filter/eine Suche mehrere Kriterien für ein Attribut gemacht werden können (siehe Beispiel, Angabe von mehreren Dokumenttypen die gelistet werden sollen) | Beispiel Notfall
Dokumenttyp:
|
Achtung: Anforderung an die Benutzeroberfläche |
[Tabelle 2] Abgeleitete Anforderungen aus den Anwendungsfällen
Prozess-Unterstützung durch Metadaten
Ein weiterer Anwendungsfall für Dokument-Metadaten ist die Prozess-Unterstützung. So könnte aufgrund eines bestimmten Dokumententyps (z.B. ‚Laborauftrag’) und Dokumentenformates (z.B. strukturierte XML-Datei) im empfangenden System direkt ein Arbeitsschritt automatisch angestossen werden. Ebenso könnte eine Konsilanfrage direkt in der Arbeitsliste der entsprechenden Experten erscheinen.
![]() |
Für spätere Versionen dieses Dokuments sind konkrete Beispiele dazu vorgesehen. |
Zugriffssteuerung durch Metadaten
Im EPD-Berechtigungskonzept werden nur sehr wenige Dokumenten-Metadaten für die Zugriffssteuerung benutzt. Das wichtigste Metadatum ist der „Confidentiality Code“, der die Vertraulichkeitsstufe eines Dokumentes beschreibt (1). Zudem sind die Angaben zum Patienten relevant. Nicht direkt relevant ist hingegen die Information, wer das Dokument eingestellt hat oder an wen es eventuell adressiert ist. Diese Informationen können zwar zum Teil hilfreiche Hinweise für die Zugriffssteuerung enthalten, werden aber nicht für den endgültigen Entscheid der Freigabe benutzt. So könnte zum Beispiel die Information, an wen eine Konsilanfrage gerichtet wird („intended recipient“) benutzt werden, damit der Patient aufgefordert wird, dieser Person einen Zugriff zu erlauben (2). Eine automatische Berechtigung ohne explizite Einwilligung des Patienten ist jedoch nicht erlaubt.
Abgeleitete Anforderungen
Von | Anforderung | Bemerkungen | mittels Attribut | Beispiel | Stand |
---|---|---|---|---|---|
(1) | ConfidentialityCode muss die Vertraulichkeitsstufen gemäss EPDG abdecken | - | DocumentEntry.confidentialityCode | Patient möchte ein Dokument "geheim" halten:
confidentialityCode = 1141000195107 Secret (qualifier value) |
Umgesetzt |
(2) | intendedRecipient muss (0 ... *) GLN einer Gesundheitsfachperson enthalten | - | SubmissionSet.intendedRecipient | - | Optionalität für die Implementation, Forderung durch BAG in EPDV offen |
[Tabelle 3] Abgeleitete Anforderungen Vertraulichkeitsstufen
Monitoring BAG
Abgeleitete Anforderungen
Von | Anforderung | Bemerkungen | mittels Attribut | Beispiel | Stand |
---|---|---|---|---|---|
1, 4 | Dokumentenklasse | - | DocumentEntry.classCode | Interventionseinträge/-notizen | ![]() |
1,4,5 | Typ des Dokuments | - | DocumentEntry.typeCode | Anästhesie-Befund | ![]() |
1 | Typ der erfassenden Gesundheitseinrichtung |
|
|
||
1 | Autor des Dokuments | Angaben zur Person sowie Rolle | DocumentEntry.authorRole | Apotheker | ![]() |
4 | Vertraulichkeitsstufe | - | DocumentEntry.confidentialityCode | geheim | ![]() |
5 | Strukturierung des Dokuments | - | DocumentEntry.formatCode | Immunization Content (IC) (CDA Impfdossier) | ![]() |
[Tabelle 4] Abgeleitete Anforderungen Monitoring BAG
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
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.
![]() |
Das Valueset FormatCode wird aus Codes von den folgenden Codesystemen zusammengesetzt:
Eine Konzeptrepräsentation darin wäre urn:ihe:pharm:pre:2010 (Code) Community Prescription (Anzeigename) 1.3.6.1.4.1.19376.1.2.3 (Codesystem) Dieses Konzept enthält keine weitere Beschreibung. |
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.
![]() |
Wie soll verfahren werden, wenn das hier beschriebene Vorgehen nicht ganz klar ist? Das einfachste ist eine eMail an info@e-health-suisse.ch, in der die Frage übermittelt wird. |
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).

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 5] 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äss 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 |
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
Value-Set-Tabellen
Wie sind die Tabellen mit den Value Sets zu interpretieren?
Spalte | Beschreibung |
---|---|
Beschreibung | Sinn & Zweck des Valuesets |
Einschlusskriterien | Bedingungen für einen neuen Eintrag |
Offen/Geschlossen | siehe dazu Grundlagen |
Definitionsart | siehe dazu Grundlagen |
Statisch/Dynamisch | siehe dazu Grundlagen |
Verpflichtung | siehe dazu Grundlagen |
Eignung für Suche | Wie kann das Attribut für die Suche genutzt werden. Weitere Beispiele liefern die Anwendungsfälle |
Granularität | Wie grob/fein ist das Valueset ausgestaltet |
Umgang mit "unknown" | Wie soll verfahren werden, wenn ein Wert nicht vorhanden ist oder nicht bekannt ist |
Umgang mit Spezialfällen | Was sind typische Schwierigkeiten und wie geht man damit um |
Mapping zu CDA | Wie ist ein CDA allenfalls aus den Metadaten oder umgekehrt zu befüllen. |
Level/Typ | Angabe der Hierarchie, in der sich der Code befindet. Diese Information wird aus zwei Teilen gebildet:
Der linke Teil (Level) gibt als numerischen Wert die Hierarchie an, in der sich das Element befindet. Ein höherer Werte bedeutet eine tiefere Ebene. Damit ist der Code spezifischer als der auf der nächst höheren Ebene. Der rechte Teil (Typ) gibt an, wie der Code zu verwenden ist. A - abstrakt, d.h. der Code darf nicht selbst genutzt werden, sondern nur eine Spezialisierung davon. L - Leaf, d.h. Blatt ohne weitere Spezialisierungen S - Specializable, d.h. es gibt noch einen Wert auf einer tieferen Ebene D - Deprecated, d.h. der Kode darf nicht mehr verwendet werden und wird nur aus Kompatibilitäts- und Verwaltungsgründen noch aufgeführt. Typischerweise gibt es dafür einen oder sogar mehrere andere Codes. |
Code | der definierte und zu benutzende Code |
Anzeigename | textuelle Beschreibung, die zur Anzeige verwendet werden soll |
Codesystem | der zu benutzende Kode, typischerweise als OID |
Beschreibung | zusätzliche Hinweise |
Value Sets
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.authorRole
Beschreibung | Dieser Code definiert die Rolle des Autors innerhalb der Institution, z.B Arzt, Pflegefachperson, Therapeut, etc. Das IHE Metadata Handbook definiert es so: "Allows to search for a document of interest produced by a certain type of healthcare professional (doctor, surgeon, nurse, etc.) with respect to the patient at the time the document was published" |
---|---|
Einschlusskriterien | Neue Rollen können dazu kommen, wenn diese in der EPDV EDI erwähnt wird oder diese wichtig für die Suche ist. |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | statisch |
Verpflichtung | required |
Eignung für Suche | Kann für die Angabe, ob es sich um eine einen ärztliche, pflegerische oder therapeutische Ausprägung des Dokuments handelt, genutzt werden. (Bsp. ärztlicher Austrittsbericht) |
Granularität | coarse |
Umgang mit unknown | Nutzung des generellen Codes 223366009 Healthcare professional (occupation) |
Umgang mit Spezialfällen | Diskussion |
Mapping zu CDA | /ClinicalDocument/author/functionCode Definiert im Template Author |
Id | 2.16.756.5.30.1.127.3.10.1.1.3 ref ch-epr- | Effective Date | 2021‑04‑01 08:55:32 | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 202104.0-stable | |||||||||||||||||||||||||||||||||||
Name | DocumentEntry.author.authorRole | Display Name | DocumentEntry.author.authorRole | |||||||||||||||||||||||||||||||||||
Description | Role of the author.
This code defines the role of the author of the document. This is a sub-attribute of epd_xds_author. | |||||||||||||||||||||||||||||||||||||
Source Code System | 2.16.756.5.30.1.127.3.10.6 - ch-ehealth-codesystem-role - urn:oid:2.16.756.5.30.1.127.3.10.6 | |||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. NullFlavor OTH (other) suggests text in originalText. |
Mögliches Mapping zu ISCO08
Code | CodeSystem | DisplayName | Code | DisplayName | Codesystem |
---|---|---|---|---|---|
46255001 | 2.16.840.1.113883.6.96 | Pharmacist (occupation) | 2262 | Pharmacists | ISCO |
309343006 | 2.16.840.1.113883.6.96 | Physician (occupation) | 221 | Medical doctors | ISCO |
3842006 | 2.16.840.1.113883.6.96 | Chiropractor (occupation) | 2269 | Health Professionals Not Elsewhere Classified | ISCO |
159033005 | 2.16.840.1.113883.6.96 | Dietitian (occupation) | 2265 | Dieticians and nutritionists | ISCO |
309453006 | 2.16.840.1.113883.6.96 | Registered midwife (occupation) | 2222 | Midwifery professionals | ISCO |
224609002 | 2.16.840.1.113883.6.96 | Complementary health worker (occupation) | 323 | Traditional and complementary medicine associate professionals | ISCO |
116154003 | 2.16.840.1.113883.6.96 | Patient (person) | |||
106292003 | 2.16.840.1.113883.6.96 | Professional nurse (occupation) | 2221 | Nursing professionals | ISCO |
59944000 | 2.16.840.1.113883.6.96 | Psychologist (occupation) | 2634 | Psychologists | ISCO |
158933003 | 2.16.840.1.113883.6.96 | Social caseworker (general) (occupation) | 2635 | Social Work and Counselling Professionals | ISCO |
159026005 | 2.16.840.1.113883.6.96 | Speech/language therapist (occupation) | 2266 | Audiologists and speech therapists | ISCO |
36682004 | 2.16.840.1.113883.6.96 | Physiotherapist (occupation) | 2264 | Physiotherapists | ISCO |
80546007 | 2.16.840.1.113883.6.96 | Occupational therapist (occupation) | 2263 | Environmental and occupational health and hygiene professionals | ISCO |
225726006 | 2.16.840.1.113883.6.96 | Lactation consultant (occupation) | 3222 | Midwifery associate professionals | ISCO |
106289002 | 2.16.840.1.113883.6.96 | Dentist (occupation) | 2261 | Dentists | ISCO |
223366009 | 2.16.840.1.113883.6.96 | Healthcare professional (occupation) | 22 | Health professionals | ISCO |
DocumentEntry.authorSpeciality
Das Valueset wird zu einem späteren Zeitpunkt definiert.
Beschreibung | Dieser Code definiert die Spezialisierung des Autors. |
---|---|
Einschlusskriterien | |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | statisch |
Verpflichtung | optional |
Eignung für Suche | tbd |
Granularität | coarse |
Umgang mit unknown | tbd |
Umgang mit Spezialfällen | tbd |
Mapping zu CDA | tbd |
DocumentEntry.sourcePatentInfo/administrativeGender
Beschreibung | Dieser Code definiert das Geschlecht des Patienten |
---|---|
Einschlusskriterien | Geschlecht gemäss HL7 und/oder eCH |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | statisch |
Verpflichtung | required |
Eignung für Suche | Bedingt geeignet |
Granularität | coarse |
Umgang mit unknown | Nutzung "UN Undifferentiated" |
Umgang mit Spezialfällen | Diskussion |
Mapping zu CDA | /ClinicalDocument/recordTarget/patientRole/patient/administrativeGenderCode Definiert im Template Patient - recordTarget |
No versions with status draft, active, review or pending
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.confidentialityCode
Beschreibung | Definiert die Vertraulichkeitsstufe eines Dokuments. |
---|---|
Einschlusskriterien | Stufen gemäss Vorgaben der TOZ (Technische & Organisatorische Zertifizierungsvoraussetzungen EPDV EDI). |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | Important |
Granularität | coarse |
Umgang mit unknown | Default ist "1131000195104 Restricted (qualifier value)". |
Umgang mit Spezialfällen | Nicht anwendbar |
Mapping zu CDA | /ClinicalDocument/confidentialityCode Definiert im Template Confidentiality Code Der Wert im CA behält immer den ursprünglichen Wert, der zum Zeitpunkt der Erstellung des Dokuments gültig ist. Der Code wird lediglich in den Metadaten geändert, wenn der Patient die Vertraulichkeitsstufe anpasst. |
Id | 2.16.756.5.30.1.127.3.10.1.5 ref ch-epr- | Effective Date | 2021‑04‑01 17:05:35 | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 202104.0-stable | |||||||||||||||||||||||||
Name | DocumentEntry.confidentialityCode | Display Name | DocumentEntry.confidentialityCode | |||||||||||||||||||||||||
Description | Document confidentiality as per Annex; EPRO-FDHA. | |||||||||||||||||||||||||||
Copyright | This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. | |||||||||||||||||||||||||||
2 Source Code Systems | 2.16.840.1.113883.6.96 - SNOMED Clinical Terms - http://snomed.info/sct 2.16.756.5.30.1.127.3.4 - SNOMED Clinical Terms Swiss Extension - urn:oid:2.16.756.5.30.1.127.3.4 | |||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. NullFlavor OTH (other) suggests text in originalText. |
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.classCode
Beschreibung | Das Attribut ,classCode' ist gemäß IHE-XDS zwingend gefordert und erlaubt eine erste Klassifizierung der Dokumente in der XDS-Registry in Dokumentenklassen, wie z.B. Briefe, Befunde oder Bilddaten. Die Wertemenge für diese Obermengen sollte nicht zu detailliert sein, da im Attribut ‚typeCode‘ eine weitere, verfeinerte Beschreibung der Dokumente erfolgt, die allerdings keine Spezialisierung des ,classCode' darstellen muss.
IHE International empfiehlt, dass eine XDS Affinity Domain die Wertemenge für das Attribut ‚classCode‘ definiert. Zur Definition der Wertemenge kann auf internationale Codes aus SNOMED CT, LOINC oder auf eigene Codes zurückgegriffen werden. |
---|---|
Einschlusskriterien | Neue Einträge sollten nur sehr bedacht geändert oder hinzugefügt werden. |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | Wichtig, dient kann für eine grobe Filterung der Dokumente genutzt werden. |
Granularität | coarse |
Umgang mit unknown | Nutzung des Codes "419891008 Other Composition" |
Umgang mit Spezialfällen | Spezialfälle sollten grundsätzlich mit den Dokumenttypen abgedeckt werden und nicht mit Dokumentklassen. |
Mapping zu CDA | Keines, da es sich hier um ein reines IHE XDS.b Metadaten Attribut handelt. |
Id | 2.16.756.5.30.1.127.3.10.1.3 ref ch-epr- | Effective Date | 2021‑04‑01 16:32:17 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 202104.0-stable | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | DocumentEntry.classCode | Display Name | DocumentEntry.classCode | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | Document class as per EPRO-FDHA Annex 3 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright | This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2 Source Code Systems | 2.16.840.1.113883.6.96 - SNOMED Clinical Terms - http://snomed.info/sct 2.16.756.5.30.1.127.3.4 - SNOMED Clinical Terms Swiss Extension - urn:oid:2.16.756.5.30.1.127.3.4 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. NullFlavor OTH (other) suggests text in originalText. |
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.typeCode
Beschreibung | Das Attribut typeCode ist gemäß IHE-XDS zwingend gefordert und kann zusätzlich zum classCode zur genaueren Klassifizierung des Dokuments genutzt werden, z.B. kann ein Dokument mit classCode "Befunde" durch den typeCode als "Pathologiebefund" oder als "Ergebnisse bildgebender Diagnostik" gekennzeichnet werden. Das Attribut typeCode stellt keine Spezialisierung von classCode dar. Somit kann ein bestimmter typeCode mit verschiedenen classCodes zur Beschreibung unterschiedlicher Dokumente kombiniert werden. Zum Beispiel haben ein Röntgenbild und der dazugehörige Radiologie-Befund den gleichen typeCode "Ergebnisse bildgebender Diagnostik" aber zwei unterschiedliche classCodes, "Bilddaten" bzw."Befunde". Daraus folgt, dass ein Dokument sowohl einem classCode als auch einem typeCode explizit zugeordnet werden muss; die Zuordnung zu einem typeCode allein reicht nicht aus, weil hierüber kein implizites Mapping auf einen einzigen „übergeordneten“ classCode möglich ist.
Eine noch detailliertere Beschreibung der Dokumentenart kann jederzeit nach Bedarf über das Freitext-Attribut "DocumentEntry.title" erfolgen (z.B. "Röntgen-Thorax-Befund" oder "Anamnesebogen"). Dieses wird in der Regel nicht maschinell ausgewertet (d.h. nicht zur Suche, Filterung, Gliederung herangezogen), sondern dient primär dem Anwender als zusätzliche Information im Benutzerinterface. Auch wird in der Dokumentenquelle bei medizinischen Dokumenten häufig kein anderer Dokumententitel geführt, daher bietet sich eine solche detaillierte Beschreibung der Dokumentenart ("Röntgen-Thorax-Befund") als Titel an. IHE International empfiehlt, dass eine XDS Affinity Domain die Wertemenge für das Attribut typeCode definiert. Zur Definition der Wertemenge kann auf internationale Codes aus SNOMED CT, LOINC oder auf eigene Codes zurückgegriffen werden. |
---|---|
Einschlusskriterien | Präzisierung einer Klasse. Fachspezifische Keine fachspezifischen Dokumente die auch über eine Kombination von Attributen gelöst werden kann (z.B. Arzt-Bericht, Pflegebericht etc). Dokumente in Kombination mit dem Gebiet aus welchem das Dokument kommt (practiceSettingCode). |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | Wichtig |
Granularität | fine |
Umgang mit unknown | Nutzung des Codes "424975005 Record entry (record artifact)" |
Umgang mit Spezialfällen | Diskussion |
Mapping zu CDA | /ClinicalDocument/code/translation Definiert im Template Document Code |
Id | 2.16.756.5.30.1.127.3.10.1.27 ref ch-epr- | Effective Date | 2021‑04‑01 16:49:20 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 202104.0-stable | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | DocumentEntry.typeCode | Display Name | DocumentEntry.typeCode | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | Type of document as per Annex 3 EPRO-FDHA. The code defines a document’s type (e.g. discharge report, laboratory report). Each document type should be assigned to precisely one document class. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright | This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2 Source Code Systems | 2.16.840.1.113883.6.96 - SNOMED Clinical Terms - http://snomed.info/sct 2.16.756.5.30.1.127.3.4 - SNOMED Clinical Terms Swiss Extension - urn:oid:2.16.756.5.30.1.127.3.4 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. NullFlavor OTH (other) suggests text in originalText. |
Mapping zu DocumentEntry.classCode
Damit ein konsistentes Mapping zwischen der Dokumentklasse und Dokumenttyp entsteht, wird nachfolgend ein weiteres Valueset bereitgestellt, welches diese Abhängigkeit zeigt.
No versions with status draft, active, review or pending
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.healthcareFacilityTypeCode
Beschreibung | DocumentEntry.healthcareFacilityTypeCode repräsentiert die Art der Einrichtung, in der die Tätigkeit stattfand, die zur Erzeugung des Dokuments führte. Zum Beispiel sollten Dokumente, die während eines ambulanten Falls in einem Krankenhaus entstehen, mit dem healthcareFacilityTypeCode für „Krankenhaus“ gekennzeichnet werden. Dabei ist zu beachten, dass es sich nicht notwendigerweise um die Art der Einrichtung handelt, in der das Dokument erstellt wurde. Beispielsweise ist es bei teleradiologischer Befundung eines Röntgenbildes für den healthcareFacilityTypeCode unerheblich, ob der befundende Radiologe in einem Krankenhaus oder in einer radiologischen Praxis ansässig ist; für den healthcareFacilityTypeCode wird die Einrichtungsart der Untersuchungsstelle (in der das Gerät betrieben wird) herangezogen.
Ein Großteil der Dokumente, welche im Kontext von Datenaustauschszenarien in eine XDS-Domäne eingestellt werden sollen, entsteht in Einrichtungen der Patientenversorgung, wie beispielsweise Arztpraxen, Krankenhäusern oder auch Apotheken. In Deutschland werden aber nicht nur in Einrichtungen der Patientenversorgung Dokumente erzeugt, die über XDS-basierte Patientenakten ausgetauscht werden sollen. Innerhalb von anderen Institutionen wie beispielsweise Krankenkassen oder Forschungseinrichtungen werden ebenfalls entsprechende Dokumente erzeugt. Weiterhin kann der Patient selbst natürlich auch entsprechende Informationen in eine XDS-Domäne einstellen, z.B. mittels einer Healthcare-Smartphone-App oder Wearables. Der Anteil der Dokumente, die nicht in Einrichtungen der Patientenversorgung entstehen, wird voraussichtlich in Zukunft steigen. |
---|---|
Einschlusskriterien | Einschluss von Institutionen, die für die Suche benötigt werden bzw. aufgrund der Zertifizierungsvoraussetzungen unterschieden werden müssen. |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | Wichtig |
Granularität | coarse |
Umgang mit unknown | Nutzung des Konzepts "43741000 Site of care (social concept)" |
Umgang mit Spezialfällen | Spitex: Obschon das die Behandlung beim Patienten zu Hause durchgeführt wird, soll bei diesen Dokumenten der 'Code 66280005 Private home-based care (environment)' genutzt werden. |
Mapping zu CDA | Keines, da es sich hier um ein reines IHE XDS.b Metadaten Attribut handelt. |
Id | 2.16.756.5.30.1.127.3.10.1.11 ref ch-epr- | Effective Date | 2021‑04‑01 16:16:46 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 202104.0-stable | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | DocumentEntry.healthcareFacilityTypeCode | Display Name | DocumentEntry.healthcareFacilityTypeCode | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | Type of healthcare facility as per Annex 3; EPRO-FDHA.
This code describes the type of healthcare facility in which the document was compiled during the treatment process. In conjunction with the authorisation control, the patient can use this information to assign all documents from a specific type of healthcare facility to a specific confidentiality level in their rights and attributes, for example. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright | This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Source Code System | 2.16.840.1.113883.6.96 - SNOMED Clinical Terms - http://snomed.info/sct | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. NullFlavor OTH (other) suggests text in originalText. |
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.practiceSettingCode
Beschreibung | DocumentEntry.practiceSettingCode spezifiziert die Fachrichtung der erstellenden Einrichtung. Typische Beispiele hierfür sind ärztliche Fachgebiete wie Allgemeinmedizin oder Radiologie. IHE International empfiehlt, dass die Codeliste zwischen 10 und 100 Codes umfassen sollte, so dass die Fachrichtung hinreichend genau abgebildet werden kann.
Jedem Dokument muss genau ein practiceSettingCode zugeordnet werden, auch wenn es in vielen Situationen mehrere beteiligte Fachrichtungen gibt. Ein Beispiel hierfür ist ein Röntgen-Befund, der aus der Chirurgie angefordert wird. Um hier eindeutig zu sein, schreibt IHE-XDS vor, dass als Fachrichtung jene gewählt werden muss, die die Fachrichtung der medizinischen Versorgungseinrichtung beschreibt, deren Tätigkeit zur Erstellung des Dokuments geführt hat. Im obigen Beispiel hat die Radiologie die Röntgen-Aufnahme durchgeführt und dem daraus resultierenden Dokument (der Röntgen-Befund) sollte somit der practiceSettingCode für „Radiologie“ zugeordnet werden. Dabei ist zu beachten, dass die Charakterisierung der durchführenden Organisation entscheidend ist, nicht der Facharzttitel des Akteurs oder die Typisierung des Dokuments. Wenn histologische Befunde aus der Dermatologie kommen, sollte der practiceSettingCode „Dermatologie“ verwendet werden. Wenn ein als Allgemeinarzt tätiger Internist einen Arztbrief schreibt, muss diesem Brief daher der practiceSettingCode für „Allgemeinmedizin“ zugeordnet werden. In den verschiedenen Ländern existieren unterschiedliche Anforderungen an diesen Code. IHE UK definierte ein Value Set (http://wiki.ihe-uk.org/AppendixB), desgleichen Holland (http://decor.nictiz.nl/services/RetrieveValueSet?id=2.16.840.1.113883.2.4.3.11.60.106.11.10&effectiveDate=2013-12-12T10:41:06&prefix=xds-&format=html&language=de-DE), aber auch für Connect-a-thons werden eigene Codes definiert (http://www.hl7.org/FHIR/valueset-xds-practice-codes.html). |
---|---|
Einschlusskriterien | Die Fachrichtung in einem Spital existiert und nicht mit einem vorhandenen Fachgebiet abgedeckt werden kann. |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | Bedingt geeignet |
Granularität | fine |
Umgang mit unknown | Nutzung des Codes "394658006 Clinical specialty (qualifier value)" |
Umgang mit Spezialfällen | Diskussion |
Mapping zu CDA | Keines, da es sich hier um ein reines IHE XDS.b Metadaten Attribut handelt. |
Id | 2.16.756.5.30.1.127.3.10.1.18 ref ch-epr- | Effective Date | 2021‑04‑01 16:19:35 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 202104.0-stable | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | DocumentEntry.practiceSettingCode | Display Name | DocumentEntry.practiceSettingCode | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | Medical specialisation of the data captured in the document as per Annex 3; EPRO-FDHA.
This attribute assigns the contents of a document to a medical specialisation. It is conceivable that this information will assist the patient with setting or changing the confidentiality level of documents, which is relevant for controlling access. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright | This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Source Code System | 2.16.840.1.113883.6.96 - SNOMED Clinical Terms - http://snomed.info/sct | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. NullFlavor OTH (other) suggests text in originalText. |
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.formatCode
Beschreibung | Der Code spezifiziert das Format des Dokumentes. Zusammen mit dem typeCode (und ggf. mit dem mimeType) soll der formatCode für hinreichende Information sorgen, um einem potenziellen XDS-Dokument-Konsumenten die Entscheidung zu ermöglichen, ob und wie er das Dokumentenformat verarbeiten kann.
Der formatCode muss dabei hinreichend eindeutig formuliert sein, um die Verarbeitung/Anzeige des von der Registry angeforderten Dokumentes durch den Dokumentenkonsumer zu gewährleisten. |
---|---|
Einschlusskriterien | formatCodes können durch verschiedene Organisationen, insbesondere durch IHE International, IHE Schweiz, HL7 Schweiz oder die Betreiber einer XDS-Domäne (EPD Gemeinschaft/Stammgemeinschaft) definiert werden. Die vergebende Organisation legt den Aufbau des Codes fest. Die einzige Vorgabe für alle vergebenden Organisationen besteht darin, dass eine eindeutige URN verwendet werden soll. |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | für eine automatische Weiterverarbeitung wichtig |
Granularität | fine |
Umgang mit unknown | urn:che:epd:EPD_Unstructured_Document oder urn:ihe:iti:xds:2017:mimeTypeSufficient |
Umgang mit Spezialfällen | separat behandeln, siehe Beispiel PDF |
Mapping zu CDA | Keines, da es sich hier um ein reines IHE XDS.b Metadaten Attribut handelt. |
Aufbau der formatCodes
Aufbau der durch IHE International vergebenen formatCodes
formatCodes, welche von IHE ITI definiert werden, haben immer das Präfix
urn:ihe:iti:
Beispiel: urn:ihe:iti:xds-sd:pdf:2008. Beipiele hierzu finden sich im Wiki von IHE International (http://wiki.ihe.net/index.php?title=IHE_Format_Codes). Wenn andere IHE Domänen formatCodes definieren, so sollen sie das Präfix
urn:ihe:’domain initials’:
benutzen, wobei „domain initials“ die Domäne selbst repräsentiert.
Aufbau der für das EPD vorgegebenen formatCodes
formatCodes, welche für das EPD definiert werden, haben immer das Präfix
urn:che:epr:'Bezeichner':'Jahr':
'Bezeichner' und 'Jahr' sollen Platzhalter für den Inhalt des Dokuments und für das Jahr der Veröffentlichung sein. Sollten innerhalb eines Jahres mehrere Versionen erscheinen, wird der Angabe des Jahres zusätzlich eine zweistellige Monatszahl, getrennt von einem Bindestrich, '-'. hinzugefügt (Beispiel: 2010-07).
Aufbau für nicht CDA-Dokumente
Falls der MIME Type allein das Format des Dokuments ausreichend beschreibt, wird dies im formatCode durch die fest vorgegebene URN „urn:che:epr:EPR_Unstructured_Document“ ausgedrückt. Der MIME Type selbst wird in den IHE Document Sharing Metadaten bei DocumentEntry.mimeType angegeben.
Beispiel Um ein gewöhnliches PDF-Dokument in einer Document Registry zu registrieren, über dessen Aufbau (Strukturierung) keine weiteren Informationen vorhanden sind, werden der Format-Code (DocumentEntry.formatCode) „urn:che:epr:EPR_Unstructured_Document“ und der MIME Type (DocumentEntry.mimeType) „application/pdf“ verwendet.
Sonderfall PDF Die unterschiedlichen Ausprägungen des PDF Formats (z.B. PDF-A für elektronische Archivierung) benötigen eine gesonderte Behandlung, da der MIME Type „application/pdf“ diese unterschiedlichen Ausprägungen nicht differenziert.
Die unterschiedlichen Ausprägungen des PDF Formats (z.B. PDF-A für elektronische Archivierung) benötigen eine gesonderte Behandlung. Da der MIME Type „application/pdf“ diese unterschiedlichen Ausprägungen nicht differenziert, könnten in bestimmten Fällen statt des Codes „urn:ihe:iti:xds:2017:mimeTypeSufficient“ selbst definierte formatCodes genutzt werden. Beispiel: „urn:che:epr:PDF_A1:2005”. Wenn es keinen formatCode für die verwendete PDF Ausprägung definiert hat (wie z.B. für PDF/X), wird der Code „urn:ihe:iti:xds:2017:mimeTypeSufficient“ als formatCode und „application/pdf“ als MIME Type verwendet.
Empfehlungen für den Aufbau von formatCodes für andere Organisationen
Wir empfehlen die Verwendung eines IANA-registrierten domain names als Namespace Identifier (NID: der Teil der URN, der auf „urn: “ folgt und bis zum nächsten Doppelpunkt reicht).
Value Set formatCode
Id | 2.16.756.5.30.1.127.3.10.1.9 ref ch-epr- | Effective Date | 2021‑04‑01 17:06:52 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 202104.0-stable | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | DocumentEntry.formatCode | Display Name | DocumentEntry.formatCode | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | Document format as per Annex; EPRO-FDHA.
This unambiguous code defines the format of the XDS document. Together with the mimetype, this should provide the potential consumer with sufficient information as to whether they are in a position to process the document. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright | This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
3 Source Code Systems | 2.16.756.5.30.1.127.3.10.10 - ch-ehealth-codesystem-format - urn:oid:2.16.756.5.30.1.127.3.10.10 1.2.840.10008.2.6.1 - DICOM UID - urn:dicom:uid 1.3.6.1.4.1.19376.1.2.3 - IHE.FormatCode.cs - http://ihe.net/fhir/ValueSet/IHE.FormatCode.codesystem | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. NullFlavor OTH (other) suggests text in originalText. |
Links
- RFC 3406 (2002) URN Namespace Definition Mechanisms. Online, verfügbar unter http://tools.ietf.org/html/rfc3406* Internet Assigned Numbers Authority (IANA). Media Types. Online, verfügbar unter http://www.iana.org/assignments/media-types/media-types.xhtml
- RFC 2288 (1998) Using Existing Bibliographic Identifiers as Uniform Resource Names. Online, verfügbar unter http://tools.ietf.org/html/rfc2288
- RFC 2141 (1997).URN Syntax. Online, verfügbar unter https://www.ietf.org/rfc/rfc2141.txt
- RFC 3151 (2001) A URN Namespace for Public Identifiers. Online, verfügbar unter https://tools.ietf.org/html/rfc3151
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.mimeType
Beschreibung | Dieser Code definiert der Medientyp des Dokuments. |
---|---|
Einschlusskriterien | Nutzung in Archivsystemen bzw. klinischen Alltag notwendig ist. Das Format muss auch breit genutzt, und soweit möglich im Browser darstellbar sein. |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | Nicht wichtig |
Granularität | fine |
Umgang mit unknown | Valueset muss allenfalls ergänzt werden, falls MimeType fehlt. |
Umgang mit Spezialfällen | Valueset muss allenfalls ergänzt werden, falls MimeType fehlt. |
Mapping zu CDA | Keines, da es sich hier um ein reines IHE XDS.b Metadaten Attribut handelt. Für CDA Level 1 Dokumente (PDF im Body), soll der Code 'multipart/x-hl7-cda-level1' genutzt werden. Für CDA Body-Level 2 und 3 'text/xml' mit dem entsprechenden formatCode. |
Id | 2.16.756.5.30.1.127.3.10.1.16 ref ch-epr- | Effective Date | 2021‑04‑01 17:07:34 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 202104.0-stable | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | DocumentEntry.mimeType | Display Name | DocumentEntry.mimeType | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description | MIME type of the document as per Annex; EPRO-FDHA. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Source Code System | 2.16.840.1.113883.5.79 - Media Type - urn:oid:2.16.840.1.113883.5.79 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. NullFlavor OTH (other) suggests text in originalText. |
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.languageCode
Beschreibung | Der languageCode dient der Spezifikation der Sprache, in welcher der wesentliche, menschenlesbare Teil des Dokuments abgefasst ist. |
---|---|
Einschlusskriterien | DocumentEntry.languageCode besitzt somit ein Format, welches aus zwei Kleinbuchstaben für den Sprachencode ("language") und zwei Großbuchstaben für den Ländercode ("territory") besteht. Die beiden Buchstabengruppen werden dabei durch ein '-' verbunden. Die allgemeine Syntax sieht damit aus wie folgt: „aa-BB“ (laut RFC 1766: <Primary Tag>-<Subtag>).
Dabei wird zusätzlich die Einschränkung zu RFC 1766 hinzugefügt, dass für das Primary Tag (vor dem Bindestrich) ausschließlich die zweibuchstabigen ISO 639-1 Codes für Sprachen als Kleinbuchstaben verwendet werden dürfen. Das Subtag wird für den languageCode verpflichtend und muss mit DIN EN ISO 3166-1 kodiert werden. Diese zweibuchstabigen Länder-Codes müssen als Großbuchstaben ausgedrückt werden. |
Offen/Geschlossen | open |
Definitionsart | intensional |
Statisch/Dynamisch | dynamic |
Verpflichtung | suggested |
Eignung für Suche | Nicht wichtig |
Granularität | fine |
Umgang mit unknown | - |
Umgang mit Spezialfällen | Diskussion |
Mapping zu CDA | /ClinicalDocument/languageCode Definiert im Template Document Language |
Beispiele für den DocumentEntry.languageCode:
Sprache (Land) | languageCode |
---|---|
Deutsch (Deutschland) | de-DE |
Deutsch (Österreich) | de-AT |
Deutsch (Schweiz) | de-CH |
Deutsch (Liechtenstein) | de-LI |
Deutsch (Luxemburg) | de-LU |
Dänisch (Dänemark) | da-DK |
Englisch (Großbritannien) | en-GB |
Englisch (USA) | en-US |
Englisch (Kanada) | en-CA |
Englisch (Australien) | en-AU |
Französisch (Frankreich) | fr-FR |
Französisch (Belgien) | fr-BE |
Französisch (Schweiz) | fr-CH |
Französisch (Kanada) | fr-CA |
Französisch (Luxemburg) | fr-LU |
Italienisch (Schweiz) | it-CH |
[Tabelle 6] Beispiele für Sprachcodes
Wie man aus obiger Tabelle ersieht, können für ein Land mehrere languageCodes existieren. Der Code dient der Spezifikation der Sprache, in der das Dokument abgefasst ist. D.h., wenn eine Sprache in mehreren Ländern gesprochen wird, so wird durch den Code ausgedrückt, in welcher dieser landes-spezifischen Sprachvarianten das Dokument abgefasst ist. Aus Konsistenzgründen wird aber auch bei Sprachen, die nur in einem Land als amtliche Landessprache genutzt werden, der Landes-Code hinzugefügt.
Das Value Set für Sprachangaben ist als „open“ definiert. Somit können die Anwender weitere Codes gemäß den festgelegten Regeln hinzuzufügen.
Nützliche Hinweise für gebräuchliche language/territory Kombinationen und die verwendeten Codes (primary tag/subtag) bietet das entsprechende Chart aus dem Common Locale Data Repository (CLDR).
Links
- HL7 Deutschland: deutsche Nachrichtenprofile: XDS-MDM-CDA-Mapping. Online, verfügbar unter http://wiki.hl7.de/index.php?title=XDS-MDM-CDA-Mapping
- RFC 1766 „Tags for the Identification of Languages“. Online, verfügbar unter https://www.ietf.org/rfc/rfc1766.txt
- DIN EN ISO 3166-1 „Codes für die Namen von Ländern und deren Untereinheiten - Teil 1: Codes für Ländernamen“ . Online, verfügbar unter http://www.beuth.de/de/norm/din-en-iso-3166-1/215472359?SearchID=959804312
- IETF „Tags for Identifying Languages“ . Online, verfügbar unter http://tools.ietf.org/html/bcp47
- CLDR „Language-Territory Information“ . Online, verfügbar unter http://www.unicode.org/cldr/charts/latest/supplemental/language_territory_information.html
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
DocumentEntry.eventCodeList
Beschreibung | Die eventCode Liste wurde konzipiert um den medizinischen Kontext von Dokumenten abzubilden. Jedem Dokument können beliebig viele eventCodes zugeordnet werden. Zum Beispiel kann ein OP-Bericht über den eventCode mit je einem codierten Wert für die durchgeführte Prozedur (z.B. Blinddarmentfernung) und die vorliegende Erkrankung (z.B. Appendizitis) versehen werden. Dies ermöglicht die Suche nach Dokumenten, die mit einer bestimmten Prozedur oder Diagnose zusammenhängen. Über den medizinischen Kontext hinaus kann das Attribut auch allgemein zur Kontextualisierung und zur Inhaltszusammenfassung verwendet werden. Zum Beispiel sieht das IHE BPPC Profil die Nutzung des eventCodes vor, um die Policy ID eines Patienteneinwilligungsdokuments abzubilden. IHE XDW wiederum nutzt es, um offene von abgeschlossenen Workflow-Aufgaben zu unterscheiden.
Das von der Expertengruppe definierte ValueSet umfasst aktuell nur von IHE International vorgegebenen Event Codes aus XDS-I.b. |
---|---|
Einschlusskriterien | Definition von konkreten Anwendungsfällen notwendig. |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | bedingt |
Granularität | coarse |
Umgang mit unknown | Anwendungsfall nötig |
Umgang mit Spezialfällen | Anwendungsfall nötig |
Mapping zu CDA | ClinicalDocument/documentationOf/serviceEvent Definiert im Template Health Service - documentationOf |
Id | 2.16.756.5.30.1.127.3.1.10.1.8 | Effective Date | 2017‑11‑15 11:33:59 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Status | ![]() | Version Label | 201704.3-beta | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Name | xds-evCoLi | Display Name | EprDocumentEventCodeList | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright | This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2 Source Code Systems | 1.2.840.10008.2.16.4 - DICOM Controlled Terminology 2.16.840.1.113883.6.96 - SNOMED Clinical Terms | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Legenda: Type L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavors to appear in @nullFlavor attribute instead of @code. |
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
SubmissionSet.contentTypeCode
Beschreibung | Für das SubmissionSet wird vorderhand nur ein einzelner Code definiert. Wenn ein konkreter Anwendungsfall vorliegt, der die möglichen Werte im Valueset definieren könnte, wird dieses Valueset überarbeitet.
Das Attribute 'contentTypeCode' ist gemäß IHE verpflichtend für ein SubmissionSet und erlaubt die Angabe des Grundes für die Übermittlung von neuen Daten, wie z.B. Weiterbehandlung, Verlegung, Einweisung. IHE International spezifiziert, dass der contentTypeCode die klinische Aktivität beinhalten soll (IHE ITI TF-3 Vol 3, Abschnitt 4.2.3.3.4), welche zum Zusammenstellen und Versenden der Daten geführt hat. Jedoch beschränkt sich der contentTypeCode auf einen einzigen Wert. Da die klinische Aktivität aber häufig durch einen einzigen Wert nicht ausreichend beschrieben werden kann, könnte eine Stossrichtung sein, lediglich den Grund der Übermittlung im 'contentTypeCode' zu codieren. Wir empfehlen, die klinische Aktivität stattdessen über die flexiblere 'eventCodeList' auf Ebene des Dokuments zu codieren. Detaillierte Anwendungsfälle sollen noch beschrieben werden, vorderhand wird auf eine Ausarbeitung des Valuesets verzichtet. |
---|---|
Einschlusskriterien | Vorliegen eines Anwendungsfalles der mögliche Werte definiert. |
Offen/Geschlossen | closed |
Definitionsart | extensional |
Statisch/Dynamisch | static |
Verpflichtung | required |
Eignung für Suche | Nicht wichtig |
Granularität | coarse |
Umgang mit unknown | zur Zeit nicht anwendbar, da nur ein Platzhalter |
Umgang mit Spezialfällen | zur Zeit nicht anwendbar, da nur ein Platzhalter |
Mapping zu CDA | Keines, da es sich hier um ein reines IHE XDS.b Metadaten Attribut handelt. |
No versions with status draft, active, review or pending
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
Konkrete Beispiele für Metadaten von häufigen Dokumenten
Folgend werden beispielhaft ein paar Dokumente kategorisiert mit konkreten Werten zu den Attributen.
Spitalaustrittsbericht aus der Nephrologie
Attribut | Anzeige | Coe |
---|---|---|
DocumentEntry.authorRole | Arzt | 309343006 Physician (occupation) |
DocumentEntry.confidentialityCode | Normal | 1051000195109 Normal (qualifier value) |
DocumentEntry.classCode | Zusammenfassender Bericht | 1271000195108 Episode Summary Report (record artifact) |
DocumentEntry.typeCode | Austrittsbericht | 373942005 Discharge summary (record artifact) |
DocumentEntry.healthcareFacilityTypeCode | Spital oder stationäre Einrichtung | 22232009 Hospital (environment) |
DocumentEntry.practiceSettingCode | Nephrologie | 394589003 Nephrology (qualifier value) |
DocumentEntry.formatCode | Scanned Documents (PDF) | urn:ihe:iti:xds-sd:pdf:2008 |
DocumentEntry.languageCode | Deutsch | de-CH |
SubmissionSet.contentTypeCode | Anderweitige Dokumente | 419891008 Other Composition |
Labor-Befund
Am Beispiel vom CDA "Allgemeiner Laborbefund".
Attribut | Anzeige | Coe |
---|---|---|
DocumentEntry.authorRole | Arzt | 309343006 Physician (occupation) |
DocumentEntry.confidentialityCode | Normal | 1051000195109 Normal (qualifier value) |
DocumentEntry.classCode | Diagnostischer Untersuchungsbefund | 1291000195107 Diagnostic Test Result (record artifact) |
DocumentEntry.typeCode | Laborbefund | 4241000179101 Laboratory report (record artifact) |
DocumentEntry.healthcareFacilityTypeCode | Arztpraxis | 35971002 Ambulatory care site (environment) |
DocumentEntry.practiceSettingCode | Labor | |
DocumentEntry.formatCode | CDA Laboratory Report | urn:ihe:lab:xd-lab:2008 |
DocumentEntry.languageCode | Französisch | fr-CH |
SubmissionSet.contentTypeCode | Anderweitige Dokumente | 419891008 Other Composition |
Aktuelle Medikationsliste
Attribut | Anzeige | Coe |
---|---|---|
DocumentEntry.authorRole | Arzt | 309343006 Physician (occupation) |
DocumentEntry.confidentialityCode | Normal | 1051000195109 Normal (qualifier value) |
DocumentEntry.classCode | Zusammenfassung aktueller Zustand | 1311000195108 Present State Summary (record artifact) |
DocumentEntry.typeCode | Aktuelle Medikationsliste | 721912009 Medication summary document (record artifact) |
DocumentEntry.healthcareFacilityTypeCode | Arztpraxis oder Spital | 35971002 Ambulatory care site (environment) oder 22232009 Hospital (environment) |
DocumentEntry.practiceSettingCode | Entsprechende Fachrichtung, z.B. "Endokrinologie" | 394583002 Endocrinology (qualifier value) |
DocumentEntry.formatCode | Community Medication List | urn:ihe:pharm:pml:2013 |
DocumentEntry.languageCode | Deutsch | de-CH |
SubmissionSet.contentTypeCode | Anderweitige Dokumente | 419891008 Other Composition |
e-Rezept
Attribut | Anzeige | Coe |
---|---|---|
DocumentEntry.authorRole | Arzt | 309343006 Physician (occupation) |
DocumentEntry.confidentialityCode | Normal | 1051000195109 Normal (qualifier value) |
DocumentEntry.classCode | Behandlungsschema | 1321000195103 Care Plan (record artifact) |
DocumentEntry.typeCode | eRezept | 440545006 Prescription record (record artifact) |
DocumentEntry.healthcareFacilityTypeCode | Arztpraxis oder Spital | 35971002 Ambulatory care site (environment) oder 22232009 Hospital (environment) |
DocumentEntry.practiceSettingCode | Entsprechende Fachrichtung, z.B. "Chirurgie" | 394609007 General surgery (qualifier value) |
DocumentEntry.formatCode | Prescription | urn:ihe:pharm:pre:2010 |
DocumentEntry.languageCode | Italienisch | it-CH |
SubmissionSet.contentTypeCode | Anderweitige Dokumente | 419891008 Other Composition |
Sozio-medizinischer Bericht oder Pflege-Verlegungsbericht
Attribut | Anzeige | Coe |
---|---|---|
DocumentEntry.authorRole | Pflegefachperson | 106292003 Professional nurse (occupation) |
DocumentEntry.confidentialityCode | Normal | 1051000195109 Normal (qualifier value) |
DocumentEntry.classCode | Zusammenfassung aktueller Zustand | 1311000195108 Present State Summary (record artifact) |
DocumentEntry.typeCode | Austrittsbericht | 373942005 Discharge summary (record artifact) |
DocumentEntry.healthcareFacilityTypeCode | Spital oder Pflegeheim | 22232009 Hospital (environment) oder 42665001 Nursing home (environment) |
DocumentEntry.practiceSettingCode | Pflege | 722165004
Nursing (qualifier value) |
DocumentEntry.formatCode | Scanned Documents (PDF) | urn:ihe:iti:xds-sd:pdf:2008 |
DocumentEntry.languageCode | Französisch | fr-CH |
SubmissionSet.contentTypeCode | Anderweitige Dokumente | 419891008 Other Composition |
Patientendaten (nicht-validiert/validiert)
Attribut | Anzeige | Coe |
---|---|---|
DocumentEntry.authorRole | Patient | 116154003 Patient (person) |
DocumentEntry.confidentialityCode | Normal | 1051000195109 Normal (qualifier value) |
DocumentEntry.classCode | Zusammenfassung aktueller Zustand | 1311000195108 Present State Summary (record artifact) |
DocumentEntry.typeCode | Austrittsbericht | 373942005 Discharge summary (record artifact) |
DocumentEntry.healthcareFacilityTypeCode | Spital oder Pflegeheim | 22232009 Hospital (environment) oder 42665001 Nursing home (environment) |
DocumentEntry.practiceSettingCode | Pflege | 722165004 Nursing (qualifier value) |
DocumentEntry.formatCode | Scanned Documents (PDF) | urn:ihe:iti:xds-sd:pdf:2008 |
DocumentEntry.languageCode | Französisch | fr-CH |
SubmissionSet.contentTypeCode | Anderweitige Dokumente | 419891008 Other Composition |
DocumentEntry.legalAuthenticator | Dr. Hans Muster | 1234567890128 (falls nicht validiert bleibt dieses Feld leer) |
Mögliche weitere Beispiele
- Eigene Daten des Patienten: Wunddokumentation mit iPhone Bilder/Video (Format HVEC)
- Organspendeausweis
- Verordnung (vorhanden => 1371000195104 Non-drug prescription record (record artifact), bei Medikation entsprechend drug prescription)
- Notfallbericht (=> Organisation fachgebiet: 394576009 Accident & emergency (qualifier value), Typ Bericht: 373942005 Discharge summary (record artifact))
- Schwangerschafts- und Geburtsbericht (=> Organisation fachgebiet:394586005 Gynecology (qualifier value) /Typ Bericht: 373942005 Discharge summary (record artifact))
- Auftrag (vorhanden => 721963009 Order (record artifact))
- Therapeutischer Bericht (über Rolle => Therapeut)
- Anderer Dokumenten-Typ (vorhanden => 424975005 Record entry (record artifact))
- Spezialbericht (Ärztlich) (zu "Spezial", bitte genauen Use Case angeben. "ärztlich" wird über die Rolle abgebildet)
- Ärztliche Zeugnisse (=> NEUE KLASSE Zeugnis wird ür nächste Version vorgesehen, zu verabschieden durch Expertengruppe)
- Patientenunterlagen (über authorRole sowie Dokument-Klasse =>Rolle = Patient / Klasse = Data from Patient oder anderenfalls angeben was für ein Typ Dokument)
Anhang
Lizenzen
SNOMED Clinical Terms® (SNOMED CT®)
This material includes SNOMED Clinical Terms® (SNOMED CT®) which is used by permission of SNOMED International (former known as International Health Terminology Standards Development Organisation IHTSDO). All rights reserved. SNOMED CT®, was originally created by The College of American Pathologists. “SNOMED” and “SNOMED CT” are registered trademarks of SNOMED International.
Abbildungen
Tabellen
Referenzen
- ↑ Information retrieval pathways for health information exchange in multiple care settings, Am J Manag Care. 2014 Nov;20(11 Spec No. 17):SP494-501
- ↑ Frieder, O., Grossman, D., Chowdhury, A., & Frieder, G. (2006). Efficiency Considerations for Scalable Information Retrieval Servers. Journal of Digital Information, 1(5). Retrieved from https://journals.tdl.org/jodi/index.php/jodi/article/view/21/21
- ↑ Croft, W. B., Metzler, D., & Strohman, T. (2010). Search engines: Information retrieval in practice. Boston: Addison-Wesley.
Dieses Material ist Teil
des Leitfadens Umsetzungshilfen von eHealth Suisse.
|
Offene Punkte
- Wie sucht ein Patient nach Dokumenten => Usecases?
- Wie sucht eine Gesundheitsfachperson von Dokumenten => Usecases
- Ersetzen von Dokumenten
- formatCode: wie geht man damit um, dass CDA Dokumente auch ausserhalb EPD benutzt werden können - wird dann je nach Ausprägung eine andere URN definiert?
- formatCode/mimeType: Braucht eine spezielle Angabe für die Unterschiedlichen PDF Formate?
- Mapping typeCode und classCode einschliessen