320
Bearbeitungen
Änderungen
→XDS-I Metadaten für DICOM KOS Objekte
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}
Die folgenden Kapitel spezifizieren die XDS-I Metadaten von DICOM KOS-Objekten für deren Verwendung
in ELGA. Nicht weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 “DocumentEntry Metadata Attribute Definition”" angeführt.
===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Dokument oder Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name“, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der Dokumentation KOS-Objektation innehatte.
Dieser Leitfaden beschreibt keine Einschränkungen für die Verwendung.
====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument KOS-Objekt verfasst hat.
Beispiel:
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse Objektklasse in feiner Granularität.<br /> Siehe Kapitel [[ILF:XDS Metadaten 2020#typeCode_.28und_typeCodeDisplayName.29|4.2.15]]
|}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse Objektklasse und den Dokumententyp Objekttyp angewendet werden. Eine entsprechende Liste “[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]” OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.
Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausKOS-schließlich Objekte ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf „normal“ (N) gesetzt.
Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:
</pre>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse Objektklasse und den Dokumententyp Objekttyp angewendet werden. Eine entsprechende Liste “hl7-austria-Dokumentenklassen” OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}
</Classification>
</RegistryPackage>
</pre>Jeder Container darf dementsprechend nur 1 Dokument Objekt enthalten.
===uniqueId===
Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des DokumentsObjektes. Dieser Identifier wird entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.
Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
====Versionierung bzw. Versionsklammer (ownDocument_setId)====
Um eine eindeutige Identifikation aller registrierten Versionen eines Dokuments Objektes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines Dokuments KOS-Objektes mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von ''StudyInstanceUID'' vorgeschlagen.
=====Spezifikation=====
===formatCode (und formatCodeDisplayName)===
Das ''formatCode'' Element beschreibt das Format des registrierten Objekts. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats Objektformats und somit die korrekte Darstellung und Verarbeitung.
====Spezifikation====
===mimeType===
Das ''mimeType'' Element beschreibt den „Internet Media Type“ des Dokuments Objektes gemäß dem „Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard wird beschrieben in [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".
===elgaFlag===
Das elgaFlag dient zur Kennzeichnung eines Dokuments Objektes als „ELGA-Dokument“Objekt“<sup>18</sup>. Ein XDS Source des ELGA-Bereiches sendet eine „XDS.b Provide and Register Transaktion [ITI-41]“, eine „XDS.b Register Document Transaktion [ITI-42]“ oder eine „XDS Update Document [ITI-57]“ an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut „elgaFlag“ entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. „elgaFlag“ kann folgende Werte annehmen:
*"true" oder
<sup>18</sup> Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente Objekte auftreten, die NICHT für ELGA vorgesehen sind.
===elgaHash===
