ihevs:Grundlagen

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

des Leitfadens IHE Valuesets.

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

Grundlagen

Grundlagendokumente

Das folgende Dokument baut auf verschiedenen Vorarbeiten auf:

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:

Folgende Value Sets werden zu einem späteren Zeitpunkt bereitgestellt:

  • DocumentEntry.authorSpecialty

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.