Änderungen

Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten („Mandatory“ "Mandatory" (M), „Required“ "Required" (R) und „Fixed“ "Fixed" (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden „Technical Frameworks“ "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:

Ausgehend von obiger Basis definiert das vorliegende Dokument die genaue Spezifikation der Befüllung der XDS Metadaten speziell für die Anwendung im Rahmen der österreichischen Gesundheitsakte ELGA. Die Spezifikation wurde im Zusammenhang mit dem Allgemeinen Implementierungsleitfaden<ref name="ALF"></ref> und den „ELGA "ELGA CDA Implementierungsleitfäden“ Implementierungsleitfäden" erstellt.

'''<Verweis>'''<br/>Zulässige Werte gemäß Value Set '''„ELGA_FormatCode“"ELGA_FormatCode".'''

In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im „OID"OID-Portal für das Österreichische Gesundheitswesen“ Gesundheitswesen" publiziert (https://www.gesundheit.gv.at/OID_Frontend/).

Für die erste Umsetzungsphase von ELGA wurden die Dokumentenklassen Entlassungsbrief (Ärztlich, Pflegerisch), Laborbefund und Befunde der bildgebenden Diagnostik („Radiologiebefunde“"Radiologiebefunde") festgelegt. Zur Verwendung in ELGA werden diese Dokumente in standardisierte XML-Dateien im Format HL7 CDA R2 umgesetzt.

Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status „approved“ "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version („Updaten“"Updaten") [ITI-41]====

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird, die XDS-Metadaten des bestehenden Dokumentes bekommen den Status „deprecated“"deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp „replace“ "replace" (RPLC)).

Dokumente werden „Storniert“"Storniert", indem der Dokumentstatus auf „deprecated“ "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. „sicher“"sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe „Organisationshandbuch "Organisationshandbuch ELGA-Bereiche und Krankenanstalten“ Krankenanstalten" [8].

Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden „Metadaten“ "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE „IT"IT-Infrastructure“ Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI-TF3).<ref name="IHE ITI TF-3"></ref>

Die IHE hat im Rahmen des „Patient "Patient Care Coordination“ Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

Die genaue Beschreibung der einzelnen XDS Metadaten Bindings sind im IHE „Patient "Patient Care Coordination“ Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHE ITI"></ref>

===Metadaten aus „On"On-Demand Documents“ Documents" (ODD) ===Über XDS können auch Dokumente abgerufen werden, die zum Abfragezeitpunkt automatisch generiert werden. Für diese Dokumente werden Verweise in der Registry eingetragen, damit sie bei der Abfrage auch gefunden werden können. Die Metadaten von ODD unterscheiden sich notwendigerweise von den Metadaten der „stabilen Dokumente“ "stabilen Dokumente" (SD), da sie erst bei Generierung des Dokuments vorhanden sind.

<br />''Tabelle 1: Legende zur Spalte „Quelle“ "Quelle" der folgenden Tabelle''

''Tabelle 2: Legende zur Spalte „Optionalität“ "Optionalität" der folgenden Tabelle ''

|R||Verpflichtend („Required”"Required")

|R2||Verpflichtend wenn bekannt („Required "Required if Known“Known")

z.B.: 55113-5 „KOSObjekte“"KOSObjekte"

|Vertraulichkeitscode. Fester Wert „N“"N"

|Sprachcode. Fester Wert „de"de-AT“AT"

Fester Wert für KOS: „application"application/dicom“dicom"

Fester Wert „SD“"SD"

|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine „Community“"Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.

|Kennzeichnet ein Dokument als „ELGA"ELGA-Dokument“Dokument"

''Tabelle 1: Legende zur Spalte „Quelle“ "Quelle" der folgenden Tabelle''

|R||Verpflichtend („Required”"Required")

|R2||Verpflichtend wenn bekannt („Required "Required if Known“Known")

''Tabelle 2: Legende zur Spalte „Optionalität“ "Optionalität" der folgenden Tabelle ''

| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse)<br />z.B.: 18842-5 „Entlassungsbrief“"Entlassungsbrief"||C

| colspan="2" |'''typeCode'''¹¹||'''R'''||'''R'''||Dokumententyp (Unterklasse) <br />codierter Wert, z.B.: 11490-0, „Entlassungsbrief "Entlassungsbrief aus stationärer Behandlung (Arzt)“"||C

| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments<br />z.B.: „text"text/xml“ xml" für CDA||E1

| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine „Community“"Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A

| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als „ELGA"ELGA-Dokument“Dokument"||B

⁹ SD: „Stable Document“"Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.<br />¹⁰ OD: „On"On-demand Document“Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. <br />

¹² MUSS vorhanden sein, wenn eine „parentDocumentRelationship“ "parentDocumentRelationship" existiert. <br />¹³ MUSS gemeinsam mit einer „parentDocumentId“ "parentDocumentId" angegeben sein.<br />

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall “KO”"KO".

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 DocumentEntry Metadata Attribute Definition”Definition" angeführt.

Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name“Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

#*Identifikator: Code aus Attribut „Performing "Performing Physicians Identification Sequence“Sequence", (0008,1052), Datentyp SQ[[#%20ftn1|[1]]], wenn vorhanden#*Name: Attribut „Performing "Performing Physicians Name“Name", (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datenyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.

#*Modalität[[#%20ftn1|[2]]]: Attribut „Modality“"Modality", (0008,0060)#*Hersteller: Attribut „Manufacturer“"Manufacturer", (0008,0070)#*Modellname: Attribut „ " Manufacturer's Model Name“Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

*„Radiologie“"Radiologie"*„Modalität“"Modalität"

*„Facharzt "Facharzt für Radiologie“Radiologie"*„Facharzt "Facharzt für Nuklearmedizin“Nuklearmedizin"

Wenn eine Person als Autor vorhanden ist, MUSS der Wert einem DisplayName aus dem Value Set „ELGA_AuthorSpeciality“ "ELGA_AuthorSpeciality" entsprechen.

Es wird ein fester Wert gesetzt: 55113-5 „Key "Key images Document Radiology“ Radiology" (LOINC: 2.16.840.1.113883.6.1)

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 Objektklasse und den 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).

Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf KOS-Objekte ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf „normal“ "normal" (N) gesetzt.

Zulässige Werte gemäß Value Set „"[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]“".

Dieses Element enthält eine Liste der erbrachten Gesundheitsdienstleistungen, die das registrierte Dokument oder Objekt beschreibt. Im Fall von Bilddaten findet der APPC Anwendung. (Die korrekte Verwendung von APPC in DICOM Objekten wird im entsprechenden Leitfaden der DICOM Austria spezifiziert: „Leitfaden "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten“Daten".[[# ftn4|[4]]])

----[[# ftnref4|[4]]] DICOM Austria: „Leitfaden "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten“Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. („CT"CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule“Lendenwirbelsäule"

'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall “KO”"KO".

Es wird ein fester Wert gesetzt: '''55113-5''' „Key "Key images Document Radiology“Radiology"

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 Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste “hl7"hl7-austria-Dokumentenklassen” Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 “Linking "Linking Report to Set of DICOM Instances”Instances"

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki> In diesem Fall wird im CXI-Wert auch „Issuing Authority“ "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.

Dieses Attribut wird im Zuge des Einbringens von neuen Objekten („Submission“"Submission") durch die empfangende XDS Registry immer auf “"'''Approved'''” " gesetzt.

*158 „Fachärztin"Fachärztin/Facharzt“Facharzt"*300 „Allgemeine Krankenanstalt“"Allgemeine Krankenanstalt"

Zulässige Werte gemäß Value Set „"[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]“".

Das ''mimeType'' Element beschreibt den „Internet "Internet Media Type“ Type" des Objektes gemäß dem „Multipurpose "Multipurpose Internet Mail Extensions“ 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>

*F044 „Radiologie“"Radiologie"*F052 „Unfallchirurgie“"Unfallchirurgie"

Zulässige Werte gemäß Value Set „"[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]“".

Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ "stabiles Dokument" (stable document, SD) und „On"On-demand Dokument“ Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Das elgaFlag dient zur Kennzeichnung eines Objektes als „ELGA"ELGA-Objekt“Objekt"¹⁸. Ein XDS Source des ELGA-Bereiches sendet eine „XDS"XDS.b Provide and Register Transaktion [ITI-41]“", eine „XDS"XDS.b Register Document Transaktion [ITI-42]“ " oder eine „XDS "XDS Update Document [ITI-57]“ " an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut „elgaFlag“ "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. „elgaFlag“ "elgaFlag" kann folgende Werte annehmen:

Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine „XDS"XDS.b Provide and Register Transaktion [ITI-41]“", eine „XDS"XDS.b Register Document Transaktion [ITI-42]“ " oder eine „XDS "XDS Update Document [ITI-57]“ " an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot „ELGA"ELGA-Hash“ Hash" gespeichert.

Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten 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 IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 “DocumentEntry DocumentEntry Metadata Attribute Definition”Definition" angeführt.

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente „GDA Index“ "GDA Index" mit einer eindeutigen OID ausgestattet.

#Laut Festlegung wird der Autor im Header-Element „author“ "author" abgelegt:

*„Diensthabender Oberarzt“"Diensthabender Oberarzt"*„Verantwortlicher "Verantwortlicher diensthabender Arzt für die Dokumenterstellung“Dokumenterstellung"

#Laut Festlegung wird die „Rolle“ "Rolle" der Person, welche das Dokument inhaltlich erstellt hat im Element functionCode des Autors abgelegt:

*„Facharzt "Facharzt für Gynäkologie“Gynäkologie"*„Facharzt "Facharzt für interne Medizin“Medizin"

#Laut Festlegung wird die „Fachrichtung“ "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat im Element code des Autors abgelegt:

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 und den Dokumententyp angewendet werden. Eine entsprechende Liste “hl7"hl7-austria-Dokumentenklassen” Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

creationTime MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ "Kürzen" auf andere Formate ist nicht zulässig.

#Mehrere dieser Service-Events können durch beliebig viele „documentationOf“ "documentationOf" Elemente ausgedrückt werden.

Das PCC Profil definiert in Kapitel „Medical "Medical Document Bindings“ Bindings" Spezialbehandlungen für gewissen Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).

Das ''legalAuthenticator'' Element beschreibt die Identifikation und demographische Informationen der Person, welche das Dokument rechtlich verbindlich unterzeichnet hat. Entfällt bei automatisch erstellten und nicht durch natürliche Personen freigegebenen Dokumenten (z.B. On-Demand Documents wie der „Medikationsliste“"Medikationsliste").

#Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element „legalAuthenticator“ "legalAuthenticator" abgelegt:

Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung (“documentationOf"documentationOf/serviceEvent“serviceEvent") verpflichtend, wenn bekannt '''''[R2]'''''.

Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ "Kürzen" auf andere Formate ist nicht zulässig.

Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ "Kürzen" auf andere Formate ist nicht zulässig.

###Bsp: Code „11490"11490-0“0"

###Bsp: „Discharge "Discharge summarization note (physician)”"

###Bsp: „2"2.16.840.1.113883.6.1“1"

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 und den Dokumententyp angewendet werden. Eine entsprechende Liste “hl7"hl7-austria-Dokumentenklassen” Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

Aus dem „Allgemeinen Implementierungsleitfaden“ "Allgemeinen Implementierungsleitfaden" [1]: „"''Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten).''“"

Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise „"&“", OID-Wert, „"&ISO“ ISO" anzugeben sind.

Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten („Submission“"Submission") durch die empfangende XDS Registry immer auf “"'''Approved'''” " gesetzt.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels „":“ " (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

Das ''mimeType'' Element beschreibt den „Internet "Internet Media Type“ Type" des Dokuments gemäß dem „Multipurpose "Multipurpose Internet Mail Extensions“ Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045 bis 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>

##Folgende Relationen sind in ELGA erlaubt (siehe „"[[ILF:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]“ " [1]):

Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ "stabiles Dokument" (stable document, SD) und „On"On-demand Dokument“ Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Das elgaFlag dient zur Kennzeichnung eines Dokuments als „ELGA"ELGA-Dokument“Dokument"¹⁸. Ein XDS Source des ELGA-Bereiches sendet eine „XDS"XDS.b Provide and Register Transaktion [ITI-41]“", eine „XDS"XDS.b Register Document Transaktion [ITI-42]“ " oder eine „XDS "XDS Update Document [ITI-57]“ " an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut „elgaFlag“ "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. „elgaFlag“ "elgaFlag" kann folgende Werte annehmen:

Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine „XDS"XDS.b Provide and Register Transaktion [ITI-41]“", eine „XDS"XDS.b Register Document Transaktion [ITI-42]“ " oder eine „XDS "XDS Update Document [ITI-57]“ " an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot „ELGA"ELGA-Hash“ Hash" gespeichert.

|Erster „Release candidate“ "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.

|Fertigstellung des „Final "Final Working Group Draft“Draft". Veröffentlicht für öffentlichen Review.

|Fertigstellung der gültigen Version 2.01 „Final“"Final". <br />Abgrenzung des Geltungsbereiches (XDS­Do­cu­ment­Entry), Überarbeitung „Practice­Setting­Code“"Practice­Setting­Code", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der „parent­Document­Relationship“"parent­Document­Relationship", Typos ausgebessert

|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments“ Dokuments" eingefügt; 363: displayNameOf($code), „Of“ "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch „2“"2"-> „Enhanced“ "Enhanced" etc.) <br />Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt <br />Allgemein: Typos ausgebessert

|Änderungen in Tabelle 3: <br /> LegalAuthenticator – von [R] auf [R2] geändert<br /> IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen<br /> ReferenceIdList hinzugefügt<br /> Den Namen des Value Sets von „ELGA"ELGA-PracticeSettingCode“ PracticeSettingCode" auf „ELGA"ELGA-PracticeSettingCode-vs“ vs" geändert

|Anhang gelöscht: <br /> 3.1. IHE ITI-TF3, Kapitel 4.1.7 „Document "Document Definition Metadata“Metadata"<br /> 3.2. IHE PCC-TF2, Kapitel 4.1.1 „XDSDocumentEntry Metadata“"XDSDocumentEntry Metadata"<br /> 3.3. IHE XDS Data Types

|Korrekturen: <br /> ITI Version einheitlich geändert auf “"(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)“".<br /> 1.1.3 Hinweis auf Terminologieserver hinzugefügt<br /> Tabelle 3 angepasst:<br /> EntryUUID Beschreibung geändert<br /> patientId Beschreibung geändert

|Den Namen des Value Sets von „ELGA"ELGA-PracticeSetting Code-vs“ vs" auf „ELGA_Practicesetting_VS“ "ELGA_Practicesetting_VS" korrigiert

|EntryUUID als „ELGA"ELGA-Relevant“ Relevant" klassifiziert.<br /> Darstellung der Übersichtstabelle geändert

|Seite 2-3: Absätze „Verbindlichkeit“"Verbindlichkeit", „Hinweise "Hinweise zur Verwendung“ Verwendung" und „Erarbeitung "Erarbeitung des Implementierungsleitfadens“ Implementierungsleitfadens" hinzugefügt.

|1.4.3. Kapitel „Metadaten "Metadaten aus „On'On-Demand Documents“ Documents' (ODD)“ " eingefügt

|2.1 Tabelle 3: Spalte „Optionalität IHE“ "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 „ELGA relevant“ "ELGA relevant" deklariert (war E2)