2.168
Bearbeitungen
Änderungen
K
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiel
Die im Weiteren angeführten Templatespezifikationen wurden im Art-Decor Projektrepository [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates ELGA Ambulanzbefund] erstellt und können dort eingesehen werden.
<br />
''<u>Hinweis auf anderen Implementierungsleitfaden:</u>''{{BeginILFBox}}'''Verweis'''<br />Verweis auf den Allgemeinen Leitfaden:…{{EndILFBox}}''<u>Themenbezogenes CDA Beispiel-Fragment im Codefragment (XPath, XML Formatoder RIM-Classification):</u>''
<!-- Seitenumbruch --><p style="page-break-before: always"></p><!-- Tatsächlicher Inhalt -->
! style="text-align:left" width="10%" | Kürzel CodeWerk Software Services and Development GmbH||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person<sup>1</sup>Jürgen Brandstätter|- style="background:#FFEBAD"| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator|- style="background:#FFFFFF"| SSA || ELGA GmbH || Stefan SabutschDICOM Austria|- style="background:#FFEBAD"Emmanuel Helm| style="text-align:left" colspan="3" | Autoren |- style="background:#FFFFFF"DICOM Austria| JB|| CodeWerk Software Services and Development GmbH|| Jürgen BrandstätterSilvia Winkler|- style="background:#FFFFFF"| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch|- style="background:#FFFFFF"| OKU|| ELGA GmbH|| Oliver Kuttin|- style="background:#FFFFFF"| KHOELGA GmbH|Stefan Repas|- | Wiener Krankenanstaltenverbund|| Konrad Hölzl|} <sup>1</sup> Namen ohne Titel
<p style="page-break-before: always"></p>
Für Eine IHE XDS Registry verwaltet Dokumente und macht diese zugänglich. Sie erlaubt die Registrierung von Bilddaten Suche und das Filtern nach den Dokumenten über XDS-I wird eine eigene Spezifikation veröffentlichtdie Metadaten der Dokumente (Metadaten sind Daten, die andere Daten definieren und beschreiben). Werden, wie für ELGA, mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden und Metadatenstandards bereitgestellt werden: Wertebereiche, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung und Policies.
Eine Mit Ausnahme der Kapitel "5.1.12.2 submissionSet.contentTypeCode" und "6.1.12.2 submissionSet.contentTypeCode" wird keine weitere Profilierung des XDS SubmissionSets Submission Sets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.
===Farbliche Hervorhebungen===
''<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>''
{{BeginYellowBox}}
'''<Hinweis>'''<br/>authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''<u>Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):</u>''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''<u>Verweis auf ELGA Value Set:</u>''
{{BeginILFBox}}
'''<Verweis>'''<br/>Zulässige Werte gemäß Value Set '''„ELGA_FormatCode“.'''
{{EndILFBox}}
TODO:Bilddaten können über KOS-Objekte (Key Object Selection Document) referenziert und abgerufen werden. Die notwendigen Metadaten können in gewissem Maße aus diesen KOS-Objekten selbst automatisiert entnommen werden. Eine genaue Beschreibung für den Aufbau von KOS-Objekten findet sich im Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch.
<!==Überblickstabelle der XDS--XDS I Metadaten für CDA Dokumente-->DICOM KOS Objekte==
<p style="page-break-before: always"></p><p style="page-break-before: always"></p>=Überblickstabelle der XDS Metadaten=Die folgende Tabelle gibt einen Überblick über alle XDS-I Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von DokumentenDICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.
TODO<br />''Tabelle 1: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?Legende zur Spalte "Quelle" der folgenden Tabelle''
''Tabelle 2: Legende zur Spalte „Optionalität“ der folgenden Tabelle ''
|z.B.: 55113- style=5 "background:whiteKey images Document Radiology"|-| colspan="6" style="text-align:center2" |'''confidentialityCode''Explizit zu setzende Metadaten'|'''M [1..1]'''|A|- style=Vertraulichkeitscode. Fester Wert "background:whiteN"|-| colspan="2" |'''availabilityStatuscreationTime'''||'''RM [1..1]'''|K|'''R'''||Gültigkeit Zeitpunkt der Erstellung des registrierten Dokuments||E1oder Objektes|- style="background:white"| colspan="2" |'''mimeTypeeventCodeList'''||'''RM [1..*]'''|A/K|Liste von Codes von Gesundheitsdienstleistungen|-||'''ReventCodeDisplayName'''||Mime Type des Dokuments<br />z'''M [1.B.: „text1]'''|A/xml“ für CDAK||E1Bezeichnung von Gesundheitsdienstleistungen nach APPC|- style="background:white"| colspan="2" |'''parentDocumentIdintendedRecipient'''||'''O<sup>12</sup>NP [0..0]'''|-|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung|-| colspan="2" |'''OlanguageCode'''|'''M [1..1]'''|Verweis auf ein referenziertes DokumentA||E1Sprachcode. Fester Wert "de-AT"|- style="background:white"| colspan="2" |'''parentDocumentRelationshiplegalAuthenticator'''|'''NP [0..0]'''|-|Rechtlicher Unterzeichner|-| colspan="2" |'''O<sup>13</sup>serviceStartTime'''||'''OM [1..1]'''|K|Typ Beginn-Datum der Relation zu dem referenzierten Dokument.<br />Gesundheitsdienstleistung, z.B.: RPLC, XFRM||E1Datum der Untersuchung|- style="background:white"| colspan="2" |'''entryUUIDserviceStopTime'''||'''RNP [0..0]'''|-|'''R'''||UUID des MetadatenEnde-Records des Dokuments (XDS DocumentEntry)||E1Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung|- style="background:white"| colspan="2" |'''objectTypesourcePatientId'''||'''RM [1..1]'''|K|'''R'''||Typ Patienten ID im Informationssystem des DocumentEntries (SD oder ODD)||E1GDA, z.B.: im RIS|- style="background:white"| colspan="2" |'''commentssourcePatientInfo'''||'''ONP [0..0]'''|-|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS|-| colspan="2" |'''Otitle'''|'''M [1..1]'''|Kommentar zum DokumentA/K||E2Titel des Dokuments|- style="background:white"| colspan="2" |'''patientIdtypeCode'''||'''RM [1..1]'''|A|'''R'''||Patienten-ID in der XDS Affinity Domain||E1Objekttyp (Unterklasse)
|- style="background:white"| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''|- style="background:white"| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash codierter Wert des Dokuments. Wird vom Repository befüllt.||A|- style="background:white"| colspan="2" |'''homeCommunityIduniqueId'''||'''R'''||'''R'''||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|- style="background:white"| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A|- style="background:white"| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in BytesM [1. Wird vom Repository befüllt.||A|- style="background:white"| colspan="2" |1]'''URI'''||'''-<sup>14</sup>'''||'''-'''||<span style="color:red;">'''Wird in XDS nicht verwendet'''</span>||A|- style="background:white"K| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''|- style="background:white"| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als „ELGA-Dokument“||B|- style="background:white"| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität Global eindeutige ID des XDS-Metadatensatzes||B|}''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''Objektes
<sup>9</sup> SDFester Wert für KOS: „Stable Document“: Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.<br "application/>dicom"<sup>10</sup> OD: „On|-demand Document“: Dokument, das nur als | colspan="2" |'''parentDocumentId'''|'''O [0..1]'''|E1|Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wirdauf ein referenziertes Objekt|-| colspan="2" |'''parentDocumentRelationship'''|'''O [0.. <br />1]'''|E1<sup>11</sup> Der Inhalt des typeCodes soll mit |Typ der Relation zu dem contentTypeCode des SubmissionSets übereinstimmenreferenzierten Objekt. z.B.<br /><sup>12</sup> MUSS vorhanden sein: APPND, RPLC, wenn eine „parentDocumentRelationship“ existiertXFRM|-| colspan="2" |'''practiceSettingCode'''|'''M [1.. <br />1]'''|E1<sup>13</sup> MUSS gemeinsam mit einer „parentDocumentId“ angegeben sein.<br />|Fachliche Zuordnung des Dokuments<sup>14</sup> Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.|-<p style| colspan="page-break-before: always2"></p>|'''entryUUID'''|'''M [1..1]'''|E1=|UUID des Metadaten-Records des Dokuments(XDS Metadaten für CDA Dokumente= DocumentEntry)TODO: Struktur überdenken |- keine Trennung hier nach QuelleTODO: Dopplung entfernen| colspan="2" |'''objectType'''==XDS Metadaten |'''M [1..1: aus dem CDA-Inhalt abgeleitet==]'''|E1|Typ des DocumentEntries
CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, In der der Autor des Dokuments angehört grundsätzlich in folgendem Element abgelegt:## ClinicalDocument/author/assignedAuthor/representedOrganization# Ein Organisationselement in CDA beinhaltet unter anderem Tabelle 6 werden die folgenden Unterelemente:## '''id'''[1] … ID XDS-Metadaten-Elemente mit der Organisation mit den folgenden Attributen:### @root … Root OID minimalen Anzahl des ID Pools, oder direkte die OID Vorkommens der Organisation Elemente (ohne @extension-AttributOptionalität)### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool , jeweils für Stable Documents (falls die @root nicht direkt die Organisation identifiziertSD)## '''name''' … Name der Organisation als String<br /> Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, soll das name Element SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen und On-Demand-Documents (im GDA-I im Tag description enthaltenODD). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.<br /> Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz"
=====Spezifikation=====''Tabelle 5: Legende zur Spalte "Optionalität" der folgenden Tabelle ''
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:=XDS-I Metadaten für DICOM KOS Objekte=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 IT Infrastructure Technical Framework, Vol 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt<ref name="ITITF3"/>.
<span > $person</span> = ClinicalDocument/author/assignedAuthorDie folgende Tabelle gibt einen Überblick jener XDS-I Metadaten-Elemente, die direkt aus dem DICOM KOS bzw. der zugrundeliegenden DICOM Study abgeleitet werden können. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.
concat(<br/>''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''<span > $person</span>/id/@extension,"^",<br/><span > $person</span>/assignedPerson/name/family,"^",<br/><span > $person</span>/assignedPerson/name/given[1],"^",<br/><span > $person</span>/assignedPerson/name/given[2],"^",<br/><span > $person</span>/assignedPerson/name/suffix,"^",<br/><span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br/><span > $person</span>/id/@root,"&amp;ISO"<br/>)<br/><pre {| class="ilfbox_codewikitable"><Classification classificationSchemewidth="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d100%" classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556|-5cffbe50f027" idstyle="urnbackground:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037#CBD7F1" nodeRepresentation=""> <Slot name| colspan="authorPerson2"> <ValueList>|'''XDS-I Metadaten Element''' <Value>2323^Hummel^Frank^^^^^^&amp;1|'''Opt.2.40.0.34.99.4613.3.3&amp;ISO </Value> </ValueList>''' </Slot> |'''Attribut in'''</Classification></pre>{{BeginYellowBox}}'''der Studie'''Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.{{EndYellowBox}}Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].|'''Attribut'''
'''authorPerson''' wird ELGA schreibt vor, hier sowohl die Kurzbezeichnung als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:auch die OID der Institution aus dem GDA-Index anzugeben.
<span > $person</span> = ClinicalDocument/author/assignedAuthorZur Ermittlung des Namens kann das DICOM Tag (0008,0080) herangezogen werden.
concat'''Achtung:''' Dieses Attribut ist Type 3 (<br/>"^",<br/><span > $person</span>/assignedAuthoringDevice/manufacturerModelName,"^",<br/><span > $person</span>/assignedAuthoringDevice/softwareName<br/>optional)<br/><pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation=""> <Slot name="authorPerson"> <ValueList> <Value>^Good Health System^Best Health Software Application</Value> </ValueList> </Slot></Classification></pre>(General Equipment Module).
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß '''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.|- style="background:white"| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:|- style="background:white"|author.authorPerson|R [IHE ITI-TF30..1].|(0008,1052)||Performing Physicians Identification Sequence
====authorRole====Das ''authorRole'' Element beschreibt die Rolle, die Code und weitere Daten aus dem ersten Item in der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.Sequence
Beispiel:* „Diensthabender Oberarzt“* „Verantwortlicher diensthabender Arzt für die Dokumenterstellung“Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Laut Festlegung wird die „Rolle“ der Person, welche das Dokument inhaltlich erstellt hat im Element functionCode des Autors abgelegt:## ''ClinicalDocument/author/functionCode'Achtung'''# : Die Angabe einer Rolle Identifikationsdaten der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist in ELGA ein verpflichtendes ElementSorge zu tragen, dass die Person angegeben wird, wenn vorhanden die die maßgeblichen Teile der Studie verantwortet.|- style="background:white"|||'''''[R2]Alternativ:'''''.# Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.
=====Spezifikation=====(0008,1050)||Performing Physicians Name
'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:Enthält dieses Attribut mehrere Namen, so ist der erste Name zu wählen.
ClinicalDocument/author/functionCode/@displayName<br/>'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.<pre class|- style="ilfbox_code"><Classification classificationScheme="urnbackground:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838dwhite" classifiedObject| colspan="urn5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:uuid:f0573b34|-ea9a-4c6d-8556-5cffbe50f027" idstyle="urnbackground:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037white" nodeRepresentation=""> <Slot name="authorRole"> <ValueList> <Value>Diensthabender Oberarzt</Value> </ValueList> </Slot> |author.authorPerson</Classification>|R [0..1]</pre>|(0008,0060) + (0008,0070) + (0008,1090){{BeginYellowBox}}Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer|{{EndYellowBox}}|Modality Code + Manufacturer + Manufacturer's Model Name
====authorSpeciality====Das ''authorSpeciality Element'Achtung:''' beschreibt die Fachrichtung Zur Studie können mehrere Geräte beitragen. Bei der PersonErmittlung des Autors ist Sorge zu tragen, welche dass das Dokument verfasst hatmaßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.|- style="background:white"| colspan="2" |creationTime|M [1..1]|(0008,0020) + (0008,0030)|(0008,0020) + (0008,0030)|Study Date + Study Time
Beispiel:* „Facharzt für Gynäkologie“* „Facharzt für interne Medizin“Im Für den Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit , dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den CDA Header Elementen:Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.# Laut Festlegung wird die „Fachrichtung“ der Person, welche das Dokument inhaltlich erstellt hat im Element code des Autors abgelegt|- style="background:white"## ''ClinicalDocument/author/assignedAuthor/code''| colspan="2" |eventCodeList# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''|M [R21..*]'''''.# Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.|||Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC
ClinicalDocument/author/assignedAuthor/code/@displayName<br/><pre class=siehe "ilfbox_codeLeitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten"><Classification classificationSchemeref name="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838dLFAPPCDicom"/> classifiedObject="urn:uuid:f0573b34-ea9a|-4c6d-8556-5cffbe50f027" idstyle="urnbackground:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="white"> <Slot name| colspan="authorSpeciality2">|serviceStartTime <ValueList>|M [1..1] <Value>Anästhesiologie und Intensivmedizin</Value>|(0008,0020) + (0008,0030) </ValueList> </Slot> </Classification></pre>{{BeginYellowBox}}Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer{{EndYellowBox}} ===classCode |(und classCodeDisplayName0008,0020)===Das ''classCode'' Element beschreibt die Dokumentenklasse + (grobe Granularität0008,0030) der das Dokument angehört und ist relevant für das Berechtigungssystem. Unterscheidung classCode/typeCode:{| class="wikitable"Study Date und Study Time
<br />(0010,0030)
====Spezifikation====(0010,0040)|(0010,0020)
'''classCode (und classCodeDisplayName0010,0010)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
TODO: <span>translation/@displayName</span> ist im CDA optional(0010, in XDS jedoch 1..1 M0030)
$code = ClinicalDocument/code/translation/@code<br />(0010,0040)$displayName = ClinicalDocument/code/translation/@displayName<br />|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.$codeSystem |- style= ClinicalDocument/code/translation/@codeSystem<br /><pre class="ilfbox_code"><Classification classificationScheme="urn:uuidbackground:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject=white"theDocument" nodeRepresentation="$code"> <Name> <LocalizedString value| colspan="$displayName2"/> </Name> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</Value>|title </ValueList>|M [1..1] </Slot>|(0008,0060) + (0008,1030)</Classification>|</pre>|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.
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-austria-Dokumentenklassen” OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http'''Anmerkung://www.hl7.at).'''
Die Konzeption des ELGA Berechtigungssystems sieht vorDiese kann von jedem Bereich frei gewählt werden, den Zugriff auf Dokumente ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt. Die Angabe dieses verpflichtenden XDS Metadaten Elements sie ist dennoch erforderlich und wird fix auf "N" (normal) gesetztmit dem Datentyp '''<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>''' anzugeben.
Es wird Eine mögliche Wahl der Vertraulichkeitscode aus setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />|- style="background:white"|value mit CXi.5 = <br />"<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"|R [0..1]|(0008,0050) oder ein vergleichbares Attribut wie z.B. (0040,1001) Requested Procedure ID<br />|(0008,0050)<br />|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist. Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben. '''Achtung:''' Welche ID dazu geeignet ist, die Verlinkung mit dem zugehörigen Befund herzustellen, ist vom jeweils implementierten Workflow abhängig. Gemäß dem CDA Header Element gemäß folgender Spezifikation übernommenIntegrationsprofil IHE RAD Scheduled Workflow dient dazu die Accession Number, die im DICOM Attribut (0008,0050) enthalten ist. Weicht der lokale radiologische Workflow vom IHE Profil ab, kann es erforderlich sein, ein anderes DICOM Attribut für die Verlinkung heranzuziehen. Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.|- style="background:white"| colspan="2" |comments|O [0..1]|(0008,1030)|(0008,1030)|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.|}
confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:<br/>
<pre class="ilfbox_code">==author===<Classification classificationScheme="urnDie Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication). classifiedObject="theDocument" nodeRepresentation="N"> <Name> <LocalizedString value="normal"/> </Name> <Slot name="codingScheme">authorInstitution==== <ValueList> <Value>urnDas ''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:oid:2Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.16.840.1.113883.5.25</Value> </ValueList> </Slot></Classification></pre>
===creationTime===Das creationTime Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element beschreibt einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Zeitpunkt Leser einfacher wird.<br /> Beispiel: Statt "Allgemeines Krankenhaus der Dokumentenerstellung. Das XDS Profil schreibt vorStadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz"<br />Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dass sämtliche Zeiten in UTC vorliegen MÜSSENdafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen*''oid'':# Im CDA wird OID der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:## ClinicalDocument/effectiveTime# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert Organisation aus dem GDA-Index (muss ermittelt werden.)# Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute*''name'':# @value … enthält das Datum in folgenden möglichen Formen## YYYYMMDD## YYYYMMDDhhmmss[+/-]HHMM (Zeitzone0008,0080)### Bsp: 20081224082015+0100### Für: 24.12.2008, 08:20:14Institution Name, Name der Organisation als String, Zeitzone GMT+1
CreationTime entfällt Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei OnRegistrierung geprüft wird.<br>Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. <br> '''Achtung:''' Das DICOM-Demand DocumentsTag (0008,0080), Institution Name, ist vom Type 3 (optional) (General Equipment Module). '''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:concat(<br/>ClinicalDocument<span>$</span>name,"^^^^^^^^^",<br /effectiveTime><span>$</@value = span>oid,"20200511193000+0200&amp;ISO"<br />)<br />
creationTime MUSS – entsprechend '''Achtung:''' Die Identifikationsdaten und Namen der tatsächlichen Angabe durchführenden Ärzte können in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werdenverschiedenen Serien der Studie unterschiedlich sein. Ein „Kürzen“ auf andere Formate Bei der Ermittlung des Autors ist nicht zulässigSorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS Achtung:'''diese zuvor gemäß Zur Studie können mehrere Geräte beitragen. Bei der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000)Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:# Im CDA '''authorPerson''' wird die Liste der Service-Events wie folgt abgelegtals ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:## ClinicalDocument/documentationOf/serviceEvent# Mehrere dieser Service-Events können durch beliebig viele „documentationOf“ Elemente ausgedrückt werden.# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2]1.# Ein serviceEvent Element in CDA beinhaltet unter anderem die folgenden ElementeFall:## code … ein Code-Element, welches die Art des ServiceEvents angibtDie Vorschriften zur Befüllung Bei der CDA R2 ServiceEvents leiten lokalen ID handelt es sich vom Allgemeinen und vom jeweiligen speziellen CDA Implementierungsleitfäden ab. In den speziellen Implementierungsleitfäden wird definiert, ob im Service Event eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat. um KEINE OID:
'''eventCodeList $person = (und eventCodeListDisplayName0008,1050)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>Performing Physicians Name
Für jedes documentationOf Element 1..n:<br/>$root = OID-Knoten für den Personenidentifikator
====Spezielle Vorschriften laut IHE PCC====
Das PCC Profil definiert in Kapitel „Medical Document Bindings“ Spezialbehandlungen für gewissen Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).
Diese speziellen Vorschriften werden in ELGA '''nicht''' angewandt2.Fall: Bei der lokalen ID handelt es sich um eine OID:
===languageCode===concat(<br />Das ''languageCode'' Element beschreibt den Sprachcode in dem das Dokument verfasst ist. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:<span> $id</span>,"^",<br />====Spezifikation==== '''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: ClinicalDocument<span> $person</languageCodespan><br /@code = "de-AT">)<br /><pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f93606bcf-054d9494-47f243ec-a0329b4e-9b2a5b5186c1a7748d1a838d" statusclassifiedObject="urn:oasisuuid:names:tc:ebxmlf0573b34-ea9a-4c6d-8556-regrep:StatusType:Approved5cffbe50f027" id="urn:uuid:1e2ede8233adae7e-8570f1ed-4be24345-bd46acab-de986a4333be73f59bc1d037" nodeRepresentation=""> <Slot name="languageCodeauthorPerson">
===legalAuthenticator===Das ''legalAuthenticator'authorPerson' 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“). '' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
Für CDA R2 Dokumente gilt folgende Verknüpfung mit den CDA Header Elementen:# Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element „legalAuthenticator“ abgelegt:## ClinicalDocument/legalAuthenticator/assignedEntity{{BeginYellowBox}}'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element $Modality = Modality (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.{{EndYellowBox}}# Die vidierende Person## Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente:### id … ID der Person mit den folgenden Attributen:#### @root … Root OID des ID Pools0008, oder direkte die OID der Person (ohne @extension-Attribut0060)#### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)### assignedEntity#### Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält##### Name
<span > $person </span>= ClinicalDocument/legalAuthenticator/assignedEntity
concat(<br/><span > $person</span>/id/@extension,"^",<br/><span > $person</span>/assignedPerson/name/familyModality,"^",<br/><span > $person</span>/assignedPerson/name/given[1],"^",<br/><span > $person</span>/assignedPerson/name/given[2]Manufacturer,"^",<br/><span > $person</span>/assignedPerson/name/suffix,"^",<br/><span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br/>ManufacturersModelName <span > $person</span>/id/@root,"&amp;ISO"<br/>)<br/><pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f93606bcf-054d9494-47f243ec-a0329b4e-9b2a5b5186c1a7748d1a838d" statusclassifiedObject="urn:oasisuuid:names:tc:ebxmlf0573b34-ea9a-4c6d-8556-regrep:StatusType:Approved5cffbe50f027" id="urn:uuid:1e2ede8233adae7e-8570f1ed-4be24345-bd46acab-de986a4333be73f59bc1d037" nodeRepresentation=""> <Slot name="legalAuthenticatorauthorPerson">
===serviceStartTime / serviceStopTime===Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben Dieser Leitfaden beschreibt keine Einschränkungen für die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/BehandlungVerwendung.
Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung (“documentationOf/serviceEvent“) verpflichtend, wenn bekannt '''''[R2]'''''. Beispiel:
Wenn vorhanden, beinhaltet dieses Element die semantisch korrekten Informationen zu Start- und Enddatum gemäß der jeweiligen Fachdomäne (z.B.: das Aufnahme/Entlassungsdatum im Falle von Entlassungsbriefen aus stationärer Behandlung). Die relevanten Informationen dazu finden sich in den speziellen ELGA CDA Implementierungsleitfäden.*"Radiologie"*"Modalität"
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:====authorSpeciality====# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem Service-Event verpflichtend:## ClinicalDocument/documentationOf/serviceEvent# Das ''authorSpeciality Element serviceEvent beinhaltet unter anderem '' beschreibt die folgenden Unterelemente:## effectiveTime gibt das Zeitintervall anFachrichtung der Person, in dem die Gesundheitsdienstleistung durchgeführt wurde## Laut Vorgabe der ELGA Gesundheitsdaten SOLL ein Zeitintervall (HL7 IVL_TS) in wie folgt angeordnet werden:### low … enthält welche das Startdatum### high … enthält das Endedatum### Andere im CDA möglichen Angaben (low/width, width/high, ..KOS-Objekt verfasst hat.) sind nicht gestattet
TODOBeispiel: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.
====Spezifikation====*"Facharzt für Radiologie"*"Facharzt für Nuklearmedizin"
Dieses Element Wenn eine Person als Autor vorhanden ist, '''MUSS – entsprechend ''' der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen. Im Fall von Geräten oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässigSoftware als Autor '''MUSS''' das Element leer bleiben.
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000).
{{BeginYellowBox}}
Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200516133000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, ===confidentialityCode===Das ''confidentialityCode'MUSS''' diese zuvor gemäß Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes. Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf KOS-Objekte ausschließlich in der Zeitzone in UTC Zeit konvertiert werden! ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf "normal" (z.B. in 20200516113000N)gesetzt.{{EndYellowBox}}
===sourcePatientId===Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDADie Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich.Es wird der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header ElementenZulässige Werte gemäß Value Set "ELGA_Confidentiality" <ref name="ConfVS">Value Set "ELGA_Confidentiality" https:# Im CDA wird die ID des Patienten in folgendem Element abgelegt//termpub.gesundheit.gv.at:## ClinicalDocument443/recordTargetTermBrowser/patientRolegui/id# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzwmain/main. verpflichtend, wenn bekannt:## id[1] … Lokale ID des Patienten vom einbringenden System## d[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)<br/><span stylezul?loadType=ValueSet&loadName="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!ELGA_Confidentiality</spanref>.
'''sourcePatientId''' confidentialityCode wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
concat($code = "N"<br />$displayName = "normal"<br />$codeSystem = "2.16.840.1.113883.5.25"
ClinicalDocument<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="theDocument" nodeRepresentation="N"> <Name> <LocalizedString value="normal"/recordTarget> </patientRoleName> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:2.16.840.1.113883.5.25</Value> </ValueList> </Slot></id[Classification></pre> ===creationTime===Das creationTime Element beschreibt den Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes. Es soll die Zeit angegeben werden, die diese Erstellungszeit am besten beschreibt: #Erstellungsdatum der Studie (aus dem KOS Objekt oder der DICOM Studie):#*Study Date (0008,0020)#*Study Time (0008,0030)#Sollte das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das Erstellungsdatum des KOS Objektes verwendet werden:#*Content Date (0008,0023)#*Content Time (0008,0033) Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1].1.8</@extensionref> berücksichtigt werden, falls angegeben: *Timezone Offset From UTC (0008,0201)*Es DÜRFEN NUR folgende Datumsformen verwendet werden:*#YYYYMMDD*#YYYYMMDDhhmmss
"^^^&amp;"====Spezifikation==== '''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br /> $date = (0008,0020) Study Date oder (0008,0023) Content Date $time = (0008,0030) Study Time oder (0008,0033) Content Time und (0008,0201) Timezone Offset from UTC concat(
ClinicalDocument/recordTarget/patientRole/id[1]/@root$date,
"&amp;ISO"$time
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI{{BeginYellowBox}}Das Datum '''MUSS''' immer entweder 8-TF3]stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).
===sourcePatientInfo===Das In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS'sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienteneine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}
{{BeginYellowBox}}===eventCodeList (und eventCodeListDisplayName)===In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigtDieses Element enthält eine Liste der erbrachten Gesundheitsdienstleistungen, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf das registrierte Dokument oder Objekt beschreibt. Im Fall von Bilddaten findet der Registry unnötigAPPC Anwendung. Eine Speicherung (Die korrekte Verwendung von APPC in der Registry ist DICOM Objekten wird im Sinne entsprechenden Leitfaden der Datenminimierung DICOM Austria spezifiziert: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten"<ref name="KOS-Leitfaden"></ref>). Es können mehrere APPC bzw. Events (DSGVOund displayNames) NICHT ERLAUBTangegeben werden. Sind mehrere Events vorhanden, muss die Reihenfolge der Events und zugehörigen displayNames gleich sein.{{EndYellowBox}}
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:## ClinicalDocument<br /title====Spezifikation====>
'''title''' wird als ebRIM "NameFür jedes documentationOf Element [1..n]:<br /@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:>
ClinicalDocument<span>$code </title span>= APPC code (alle Achsen) z.B. "2.4.0.5-3-3"<br /><span>$displayName</span> = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule"<br /><span>$codeSystem</span> = OID des Codesystems APPC: 1.2.40.0.34.5.38<br />
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}
===typeCode (und typeCodeDisplayName)===
Das ''typeCode'' Element beschreibt den Dokumententyp, dem das Dokument angehört. Der Dokumententyp ist die Spezialisierung einer Dokumentenklasse, jeder Dokumententyp gehört zu genau einer Dokumentenklasse.
Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
| '''typeCode'''
| '''Dokumentenklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
| classCode
| Dokumentenklasse in grober Granularität.<br/> Siehe Kapitel [[ILF:XDS Metadaten 2020#classCode_.28und_classCodeDisplayName.29|classCode]]
|}
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:
## ClinicalDocument/code
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.
# Ein Code-Element in CDA beinhaltet unter anderem die folgenden Attribute:
## @code … Codierter Wert der Dokumentenklasse
### Bsp: Code „11490-0“
## @displayName … Lesbarer Wert der Dokumentenklasse
### Bsp: „Discharge summarization note (physician)”
## @codeSystem … Codierter Wert des zugrundliegenden Codesystems
### Bsp: „2.16.840.1.113883.6.1“
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.
<span > $code</span> = ClinicalDocument/code/@code<br/><span > $displayName</span> = ClinicalDocument/code/@displayName<br/><span > $codeSystem</span> = ClinicalDocument/code/@codeSystem<br/>Fester Wert "de-AT"
{{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 und den Dokumententyp 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}}
$code = ClinicalDocument/code/@codeconcat(
$displayName = ClinicalDocument/code/@displayNameStudy Date,
$codeSystem = ClinicalDocument/code/@codeSystemStudy Time + Timezone Offset from UTC
<Classification classificationSchemeid="urn:uuid:aa5437401e2ede82-bdda8570-424e4be2-8c96bd46-df4873be8500" classifiedObject="theDocument" nodeRepresentation="$codede986a4333be"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="codingSchemeserviceStartTime"> <ValueList> <Value>urn:oid:$codeSystem20100511134500</Value> </ValueList> </Slot> </Classification></RegistryPackageExtrinsicObject>
===uniqueId===Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des Dokuments. Dieser Identifier wird entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.uniqueId wird als ebRIM Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen(0010,0020) Patient ID (VR:# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtendLO, VM:## ClinicalDocument/id1)
uniqueId '''sourcePatientId''' wird als ebRIM ExternalIdentifier zum DocumentEntry Slot gemäß folgender Vorschrift zusammengesetzt:<br/> $patientID = (0010,0020) Patient ID
Fall 1<br/>Attribut ClinicalDocument/id/@extension ist nicht vorhanden$oid = OID des lokalen Patientenidentifikators
$value = concat(ClinicalDocument/id/@root)
Fall 2<br/>Attribut ClinicalDocument/id/@extension ist vorhandenconcat(
<pre class="ilfbox_code^^^&amp;">,<ExternalIdentifierregistryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"value="$value">oid, <Name> <LocalizedString value="XDSDocumentEntry.uniqueId&amp;ISO"/> </Name></ExternalIdentifier></pre>)
Im Rahmen von In ELGA ist werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die ClinicalDocument/SetId als ein Eintrag in Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der referenceIdList in den XDS Metadaten einzubringenRegistry unnötig. Weitere andere Einträge Eine Speicherung in der referenceIdList sind möglich, aber derzeit nicht Bestandteil Registry ist im Sinne der ELGA VorgabenDatenminimierung (DSGVO) NICHT ERLAUBT.
Aus dem „Allgemeinen Implementierungsleitfaden“ [1]: „===title===Das ''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).title''“Element beschreibt den lesbaren Titel des registrierten Objektes.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name='''title''' wird als ebRIM "Name/@value"IHE ITI TF-3Attribut im Container "ExtrinsicObject"></ref>gemäß folgender Vorschrift zusammengesetzt:
{| class="wikitable" width="100%"!Data Type||Source Standard||Encoding Specification|-|CX||HL7 V2.5 Identifier||This is an identifier. HL7 Identifier type CX consists of several components, but this specification restricts them to the use of two components, the Id Number, and the Assigning Authority concat(AA). The Assigning Authority identifies the "domain" over which the Id Number represents a unique entity. Furthermore, the AA is characterized by a Universal Id and Universal Id Type. In Document Sharing profiles, ISO Object Identifiers (see OID below) must be used as Universal Id.<br />Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />Note that the '&' character must be properly encoded in the XML content.|-|'''CXi'''||HL7 V2 Identifier||'''This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.'''*'''CXi.1 shall be present and hold the identifier value.'''*'''CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.'''*'''CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.'''*'''When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.'''*'''No other components shall be present.'''|}
'''ACHTUNG: '''Aufgrund der Tatsache" ", dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt)<pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"> <Name> <LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" /> </Name></ExtrinsicObject></pre>{{BeginYellowBox}}Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.{{EndYellowBox}}
concat===typeCode (und typeCodeDisplayName)===Das ''typeCode'' Element beschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer Objektklasse.
ClinicalDocument/setId/@extension, "^^^", ====Spezifikation====
ClinicalDocument/setId/@root, "^", '''typeCode (und typeCodeDisplayName)''' wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
"urn:elga:iti:xdsEs wird ein fester Wert gesetzt:2014:ownDocument_setId", '''55113-5''' "^Key images Document Radiology",
homeCommunityId<span> $code</span> = "55113-5"<br /><span> $displayName</span> = "Key images Document Radiology"<br /><span> $codeSystem</span> = "2.16.840.1.113883.6.1"<br /><pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="KeyImageObject" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot></Classification></pre>
)====submissionSet.contentTypeCode====Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise „&“, OID$code = "55113-Wert, „&ISO“ anzugeben sind.5"
Beispiel $codeSystem = "2.16.840.1.113883.6.1"<pre class="ilfbox_code"><RegistryPackage status="urn:oasis:names:tc: setIdebxml-regrep:StatusType:Approved" <Classification classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject="KeyImageObject" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </@root und setIdName> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</@extension sind im CDA strukturiert. In Value> </ValueList> </Slot> </Classification></RegistryPackage></@extension wird KEINE UUID angegebenpre>Jeder Container darf dementsprechend nur 1 Objekt enthalten.
<pre class="ilfbox_code"><ClinicalDocument xmlns="urn:hl7-org:v3">…<setId root="1.2.40.0.34.99.111.1.1" extensionuniqueId=="ZZZZZZZZZZZZZZZZZZZ"/><versionNumber value="2"/> …Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des Objektes. Dieser Identifier wird vom Document Source Actor erzeugt.</ClinicalDocument></pre>Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
Wie oben angeführt wird folgender CXi Wert erstellt(0008,0018) SOP Instance UID (VR:UI, VM:1)<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" idSpezifikation==="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value>ZZZZZZZZZZZZZZZZZZZ^^^&amp;amp;1.2.40.0.34.99.111.1.1 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki> ^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value> </ValueList> </Slot> </ExtrinsicObject></pre> Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
Beispiel 2: in setId/@extension im CDA wird eine UUID geführt$value = (0008,0018) SOP Instance UID
Wie oben angeführt wird folgender CXi Wert erstellt===referenceIdList===Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:
"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId^&amp;, M [1.2.40.1])#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, R [0.34.99.999&amp;ISO"1])<pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2#Verlinkung zwischen DICOM KOS-a032-9b2a5b5186c1</nowiki>" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value><nowiki><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki> &amp;amp;1.2.40.Objekten und einer Aufenthaltszahl (encounterId, O [0.34.99.999&amp;amp;ISO</Value> </ValueList> </Slot> </ExtrinsicObject></pre>1])
===intendedRecipient===Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist '''Weitere Einträge in der intendedRecipient notwendig. Derzeit wird dieses Element in ELGA referenceIdList sind möglich, aber derzeit nicht verwendet. Sobald IHE XDW für Bestandteil der ELGA zugelassen wird, folgt die Spezifikation dieses ElementesVorgaben. '''
Mögliche Werte laut IHE sind:====Versionierung bzw. Versionsklammer (ownDocument_setId)====* Approved* DeprecatedUm eine eindeutige Identifikation aller registrierten Versionen eines 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 KOS-Objektes mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von ''StudyInstanceUID'' vorgeschlagen.
Dieses Attribut =====Spezifikation=====ownDocument-SetId wird im Zuge des Einbringens von neuen Dokumenten („Submission“) durch die empfangende XDS Registry immer auf “'''Approved'''” gesetzt.als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildetFür KOS Objekte kann die ''StudyInstanceUID'' (0020, das das DocumentEntry repräsentiert000D) als SetId verwendet werden.
<pre class$id ="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id(0020,000D) VR="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/></pre>UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1
====Bildungsregel für den formatCodeDisplayName ====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.
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). concat
'''Beispiele:'''* '''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''* '''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''* '''ELGA Laborbefund, EIS Full Support v2.06+'''(
====Spezifikation===='''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br/><span >$code</span> = ClinicalDocument/hl7at:formatCode/@code <br/><span >$displayName</span> = gemäß Liste der in ELGA gültigen FormatCodes<br/><span >$codeSystem</span> = OID der Liste der in ELGA gültigen FormatCodesid, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]<pre class="ilfbox_code^^^^"><Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot></Classification></pre>,
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA.Es wird der Code aus dem CDA Header Element "healthCareFacility<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>" genutzt., "^",
====Spezifikation===="&amp;",
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:$homeCommunityId, "&amp;ISO"
<span >$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code)
<span >$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName
Im Fall =====Spezifikation=====Bei der Registrierung von CDA R2 Dokumenten KOS Objekten SOLL eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. Diese dient als Basis für die Verlinkung mit einem Befund der bildgebenden Diagnostik (diagnostic image report). Wird in der ReferenceIdList der XDS-I Metadaten keine Accession Number angeführt, ist der Mime Type laut IHE immer fix "text/xml"eine Verlinkung nicht möglich. Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
====Spezifikation====Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
Folgende Mime-Types sind für Dokumente zugelassen:<br/>CDA R2: '''text/xml'''<br/>DICOM/KOS: '''application/dicom'''<br/>$id = Accession Number z.B. 20201111
<pre class$root ="ilfbox_code"><ExtrinsicObject id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" mimeType="text/xml" objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/></pre>OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1
===parentDocumentId, parentDocumentRelationship===Das ''parentDocumentId'' Element verweist auf das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation steht.concat
Das ''parentDocumentRelationship'' Element beschreibt den Typ der Relation (Versionierung, Transformation).
Da nicht alle lokalen und temporären Versionen eines Dokuments veröffentlicht werden müssen$id, können die tatsächlichen und technischen Dokumentenverweise in XDS nicht über die parentDocumentId erfasst werden"^^^", sondern über Association-Objekte."&amp;"
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:$root, "&amp;ISO", "^",
# Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt"<nowiki>urn:## ClinicalDocument/relatedDocument# Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werdenihe:## ClinicalDocument/relatedDocument/@typeCode## Folgende Relationen sind in ELGA erlaubt (siehe „[[ILFiti:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]“ [1])xds:### Versionierung (RPLC)# Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben2013:## ClinicalDocument/relatedDocumentaccession</parentDocumentnowiki>"
'''parentDocumentId''' MUSS mit folgenden Elementen ====Referenz zwischen Aufenthaltszahl und Studie (encounterId)====Durch encounterId wird die Verlinkung sämtlicher Bilddaten (DICOM KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in CDA übereinstimmen:den XDS-I Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.
concat(=====Spezifikation=====ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",ClinicalDocument/relatedDocument/parentDocument/id/@extension)Bei der Registrierung von KOS Objekten KANN eine encounterId in den XDS-I Metadaten in der ReferenceIdList angegeben werden.
'''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen:$root = OID der Liste der Aufenthaltszahlen der Organisation, z.B. 1.2.40.0.34.99.4613.3.4
ClinicalDocument/relatedDocument/@typeCodeconcat
===practiceSettingCode (und practiceSettingCodeDisplayName)===Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Dokumentes. Es SOLL den Fachbereich wiedergeben$root, dem der Inhalt des Dokuments am besten entspricht "&amp;ISO", "^", unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung.
Im CDA-Schema wurde für die HL7-Austria Domäne wurde ein genau entsprechendes Element geschaffen, "hl7at<nowiki>urn:practiceSettingCodeihe:iti:xds:2015:encounterId</nowiki>".
====Spezifikation==== '''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt: <span >$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br/><span >$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br/><span >$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br/><pre class="ilfbox_code"> <ClassificationExtrinsicObject mimeType="text/xml" classificationScheme objectType="<nowiki>urn:uuid:cccf55987edca82f-8b07054d-4b7747f2-a05ea032-ae952c785ead9b2a5b5186c1</nowiki>" classifiedObject status="<nowiki>urn:uuidoasis:names:tc:f0573b34ebxml-ea9a-4c6d-8556-5cffbe50f027regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:63134a8d1e2ede82-9d4c8570-4fe04be2-ad9bbd46-9198b6deeddfde986a4333be</nowiki>"> nodeRepresentation <Slot name="$code<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <NameValueList> <Value>Az123456^^^<LocalizedString value="$displayName"/nowiki> &</Namenowiki> amp;amp;1.2.40.0.34.99.4613.3.4<Slot name="codingScheme"nowiki> &<ValueList/nowiki> amp;amp;ISO^<Valuenowiki>urn:oidihe:$codeSystemiti:xds:2015:encounterId</nowiki> </Value> </ValueList> </Slot> </ClassificationExtrinsicObject>
Für "Stable Document" DocumentEntry*'''Study Instance UID''' mit dem Datentyp:<pre class="ilfbox_code"nowiki><ExtrinsicObject mimeType="text/xml" objectType="urn:uuidihe:7edca82fiti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-054d-47f2-a032-9b2a5b5186c1Wert auch "Issuing Authority"weggelassen, weil die ID weltweit eindeutig ist. status="*'''UniqueID''' mit dem Datentyp: <nowiki>urn:oasisihe:namesiti:tcxds:ebxml-regrep2013:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>uniqueId</prenowiki>
Für "On-Demand Document" DocumentEntryFolgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:34268e477edca82f-fdf5054d-41a647f2-ba33a032-82133c4652489b2a5b5186c1</nowiki>" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value> <Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value> <Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value> <Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value> </ValueList> </Slot> </ExtrinsicObject>
===elgaFlag===Das elgaFlag dient zur Kennzeichnung Im Fall eines Dokuments als „ELGAKOS-Dokument“<sup>18</sup>. Ein XDS Source des ELGA-Bereiches sendet eine „XDS.b Provide and Register Transaktion [ITI-41]“Objektes gilt folgende Verknüpfung mit den Metadaten:(0008, eine „XDS.b Register Document Transaktion [ITI-42]“ oder eine „XDS Update Document [ITI-57]“ an die ELGA-Zugriffssteuerungsfassade (ZGF1030). Hierbei wird das Attribut „elgaFlag“ entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade Study Description (ZGFVR:LO, VM:1) explizit gesetzt. „elgaFlag“ kann folgende Werte annehmen:* "true" oder* "false"
<pre class="ilfbox_code"><Slot name="urnXDS Metadaten 2:elga-bes:elgaFlag">explizit zu setzen (ELGA relevant)== <ValueList>===availabilityStatus=== <Value>true</Value> </ValueList></Slot><Das availabilityStatus-Element beschreibt die Aktualität/pre>Sichtbarkeit des eingebrachten Objektes.
<sup>18</sup> Das ist für Registries notwendig, Dieses Attribut wird im Zuge des Einbringens von neuen Objekten ("Submission") durch die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sindempfangende XDS Registry immer auf "'''Approved'''" gesetzt.
===elgaHash===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.b Provide and Register Transaktion [ITI-41]“, eine „XDS.b Register Document Transaktion [ITI-42]“ oder eine „XDS Update Document [ITI-57]“ an die ZGF. Dabei availabilityStatus wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot „ELGA-Hash“ gespeichert. Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller Attribut @status des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziertebRIM ExtrinsicObject abgebildet, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt istdas DocumentEntry repräsentiert.
====Spezifikation====
<rim:Slot nameExtrinsicObject mimeType="text/xml" objectType="urn:elgauuid:7edca82f-054d-47f2-a032-bes:elgaHash9b2a5b5186c1"> <rimstatus="urn:oasis:names:tc:ValueList> <rimebxml-regrep:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rimStatusType:Value>Approved" </rimid="urn:uuid:ValueList> <1e2ede82-8570-4be2-bd46-de986a4333be"/rim:Slot>
<!--Anhänge--> =XDS Metadaten für CDA Dokumente===XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet== ===author===Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty healthcareFacilityTypeCode (und authorTelecommunicationhealthcareFacilityTypeCodeDisplayName). CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen. ====authorInstitution====Das ''authorInstitutionhealthcareFacilityTypeCode'' Element beschreibt die Organisation (Klassifizierung des GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurdez.B.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört grundsätzlich in folgendem Element abgelegt:## ClinicalDocument*158 "Fachärztin/author/assignedAuthor/representedOrganization# Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:## '''id'''[1] … ID der Organisation mit den folgenden Attributen:### @root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)Facharzt"## '''name''' … Name der Organisation als String<br /> Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, soll das name Element SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.<br /> Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw *300 "Wien AKH - AugenambulanzAllgemeine Krankenanstalt"
# GDAs, Im KOS Objekt steht kein Element für ein automatisches Mapping in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente „GDA Index“ mit einer eindeutigen OID ausgestattetdieses Feld zur Verfügung. # Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste IDEine vorgeschlagene Methodik siehe Kapitel zu authorInstitution) zu verwenden.
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wirdZulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
=====Spezifikation===== '''authorInstitutionhealthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Slot Classification gemäß folgender Vorschrift zusammengesetzt:
* Fall 1:<br/>Element $inst/id[1] ist vorhanden<br/>Attribut $inst/id[1]/@root ist vorhanden<br/>Attribut $inst/id[1]/@extension ist nicht vorhanden<br/> concat(<br/><span>$instcodeSystem </span>/name,"^^^^^^^^^",<br/>= OID der ausgebenden Stelle<span>$inst</span>/id[1]/@root<br/>)<br/>
*Fall 2Folgende Mime-Types sind für DICOM KOS Objekte zugelassen:<br/>Element $inst/id[1] ist vorhanden<br/>Attribut $inst/id[1]/@root ist vorhanden<br/>Attribut $inst/id[1]/@extension ist vorhanden<br/>
concat(<br*application/><span >$inst</span>/name,"^^^^^&",<br/><span >$inst</span>/id[1]/@root,"&ISO^^^^"<br/><span >$inst</span>/id[1]/@extension<br/>)dicom<br/>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß [IHE ITI-TF3].
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:*F044 "Radiologie"# Laut Festlegung wird der Autor im Header-Element „author“ abgelegt:## ClinicalDocument/author/assignedAuthor# Der Autor (Person)## Ein Personenelement enthält unter anderem die folgenden Unterelemente:### id … ID der Person mit den folgenden Attributen:#### @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)#### @extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)### assignedPerson#### Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält##### name# Gerät oder Software als Autor ## Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:### assignedAuthoringDevice#### Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software ##### manufacturerModelName#### Enthält ein Element mit dem Namen des Geräts oder der Software ##### softwareName*F052 "Unfallchirurgie"
=====Spezifikation Im KOS-Objekt steht kein Element für Personen===ein automatisches Mapping in dieses Feld zur Verfügung.{{BeginYellowBox}}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]".{{EndYellowBox}}
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:====Spezifikation====
<span > $person</span> = ClinicalDocument/author/assignedAuthor'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
concat(<br/><span > $personcode</span>/id/@extension,"^",= Code aus Value Set ELGA_PracticeSetting<br/><span > $persondisplayName</span>/assignedPerson/name/family,"^",= Klartext des angegebenen Codes (displayName)<br/><span > $personcodeSystem</span>/assignedPerson/name/given[= OID des Codesystems (1],"^",<br/><span > $person</span>/assignedPerson/name/given[.2],"^",<br/><span > $person</span>/assignedPerson/name/suffix,"^",<br/><span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br/><span > $person</span>/id/@root,"&amp;ISO"<br/>.40.0.34.5.12)<br/>
'''authorPerson''' ===objectType===Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [==ELGA-spezifische Erweiterungen der XDS-Metadaten==Die folgenden Daten entsprechen nicht dem IHE ITI-TF3]Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.
Beispiel:* „Diensthabender Oberarzt“"true" oder* „Verantwortlicher diensthabender Arzt für die Dokumenterstellung“Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Laut Festlegung wird die „Rolle“ der Person, welche das Dokument inhaltlich erstellt hat im Element functionCode des Autors abgelegt:## ''ClinicalDocument/author/functionCode''# Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R2]'''''.# Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet."false"
=====Spezifikation=====<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 Objekte auftreten, die NICHT für ELGA vorgesehen sind.
'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:====Spezifikation====
ClinicalDocument/author/functionCode/@displayName<br/><pre class="ilfbox_code"><Classification classificationSchemeSlot name="urn:uuid:93606bcfelga-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urnbes:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="elgaFlag"> <Slot name="authorRole"ValueList> <ValueList> <Value>Diensthabender Oberarzttrue</Value> </ValueList> </Slot> </Classification>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer
{{EndYellowBox}}
Beispiel:====Spezifikation====* „Facharzt für Gynäkologie“<pre class="ilfbox_code">* „Facharzt für interne Medizin“ <rim:Slot name="urn:elga-bes:elgaHash">Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen <rim:ValueList># Laut Festlegung wird die „Fachrichtung“ der Person, welche das Dokument inhaltlich erstellt hat im Element code des Autors abgelegt <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>## ''ClinicalDocument </authorrim:ValueList> </assignedAuthorrim:Slot></code''# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R2]'''''.# Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.pre>
'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt==XDS Metadaten 1:aus dem CDA-Inhalt abgeleitet==
Im Fall Das AuthorInstitution-Element ist von Geräten oder Software als Autor sowie in ODD bleibt besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird.<br>Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Element leerName-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
Unterscheidung classCode/typeCode:{| class="wikitable"|- style="background:white"|'''''classCode'''''|'''''Dokumentenklasse in grober Granularität'''''|- style="background:white"|'authorInstitution'typeCode''|Dokumentenklasse in feiner Granularität.<br /> Siehe Kapitel [[ILFwird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:XDS Metadaten 2020#typeCode_.28und_typeCodeDisplayName.29|4.2.15]]|}
====Spezifikation====
'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt*Fall 1:<br />
TODO: Element $inst/id[1] ist vorhanden<spanbr />translationAttribut $inst/id[1]/@displayNameroot ist vorhanden<br /span> Attribut $inst/id[1]/@extension ist im CDA optional, in XDS jedoch 1..1 Mnicht vorhanden<br />
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-austria-Dokumentenklassen” OID {1.*Fall 2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http:<br //www.hl7.at). ===confidentialityCode===Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des Dokuments.>
Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt. $inst/id[1] ist vorhanden<br /> Attribut $inst/id[1]/@root ist vorhanden<br />Die Angabe dieses verpflichtenden XDS Metadaten Elements Attribut $inst/id[1]/@extension ist dennoch erforderlich und wird fix auf "N" (normal) gesetzt. Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen: ====Spezifikation==== confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:vorhanden<br/>
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:## ClinicalDocument/effectiveTime# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.#Im CDA '''authorPerson''' wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.# Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:# @value … enthält das Datum in folgenden möglichen Formen## YYYYMMDD## YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)### Bsp: 20081224082015+0100### Für: 24.12.2008, 08:20als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:14, Zeitzone GMT+1{{BeginYellowBox}}CreationTime entfällt bei On-Demand Documents.{{EndYellowBox}}
'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:concat(<br/>ClinicalDocument<span> $person</effectiveTimespan>/id/@value extension,"^",<br /><span> $person</span>/assignedPerson/name/family,"^",<br /><span> $person</span>/assignedPerson/name/given[1],"^",<br /><span> $person</span>/assignedPerson/name/given[2],"^",<br /><span> $person</span>/assignedPerson/name/suffix,"^",<br /><span> $person</span>/assignedPerson/name/prefix[@qualifier= "20200511193000+0200AC"],"^^^&amp;",<br /><span> $person</span>/id/@root,"&amp;ISO"<br />)<br />
creationTime MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder Ist clinicalDocument/author/assignedAuthor/id mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig. Wenn Datumselemente in CDA mit Zeit einem NullFlavor angegeben , sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS '''diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000)die entsprechenden Felder für @extension und @root leer zu lassen.
Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:# Im CDA '''authorPerson''' wird die Liste der Service-Events wie folgt abgelegtals ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:## ClinicalDocument/documentationOf/serviceEvent# Mehrere dieser Service-Events können durch beliebig viele „documentationOf“ Elemente ausgedrückt werden.# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2].# Ein serviceEvent Element in CDA beinhaltet unter anderem die folgenden Elemente:## code … ein Code-Element, welches die Art des ServiceEvents angibtDie Vorschriften zur Befüllung der CDA R2 ServiceEvents leiten sich vom Allgemeinen und vom jeweiligen speziellen CDA Implementierungsleitfäden ab. In den speziellen Implementierungsleitfäden wird definiert, ob im Service Event eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat.
'''eventCodeList concat(und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/> Für jedes documentationOf Element 1..n:"^",<br/> <span >$code person</span>= ClinicalDocument/documentationOf[n]/serviceEvent/codeassignedAuthoringDevice/@codemanufacturerModelName,"^",<br/><span >$displayNameperson</span> = ClinicalDocument/documentationOf[n]/serviceEventassignedAuthoringDevice/code/@displayNamesoftwareName<br/><span >$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem)<br/>
<Name/Classification></pre> Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<LocalizedString valueref name="$displayNameITITF3"/>. ====authorRole==== </Name>Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.</Classification></pre>Beispiel:
====Spezielle Vorschriften laut IHE PCC====*"Diensthabender Oberarzt"Das PCC Profil definiert in Kapitel „Medical Document Bindings“ Spezialbehandlungen *"Verantwortlicher diensthabender Arzt für gewissen Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).die Dokumenterstellung"
Diese speziellen Vorschriften werden in ELGA '''nicht''' angewandt.Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
===languageCode===#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:Das ##''languageCodeClinicalDocument/author/functionCode'' #Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element beschreibt den Sprachcode in dem , wenn vorhanden '''''[R]'''''.#Wenn das Dokument verfasst Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:====Spezifikation====
'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:=====Spezifikation=====
===legalAuthenticator===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“). Beispiel:
Für CDA R2 Dokumente gilt folgende Verknüpfung mit den CDA Header Elementen:*"Facharzt für Gynäkologie"# Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element „legalAuthenticator“ abgelegt:## ClinicalDocument/legalAuthenticator/assignedEntity{{BeginYellowBox}}'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.{{EndYellowBox}}# Die vidierende Person## Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente:### id … ID der Person mit den folgenden Attributen:#### @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)#### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)### assignedEntity#### Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält##### Name*"Facharzt für interne Medizin"
====Spezifikation====Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
<span > $person </span>= ClinicalDocument/legalAuthenticator/assignedEntity====Spezifikation=====
concat(<brClinicalDocument/><span > $person<author/span>assignedAuthor/idcode/@extension,"^",<br/><span > $person</span>/assignedPerson/name/family,"^",<br/><span > $person</span>/assignedPerson/name/given[1],"^",<br/><span > $person</span>/assignedPerson/name/given[2],"^",<br/><span > $person</span>/assignedPerson/name/suffix,"^",<br/><span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br/><span > $person</span>/id/@root,"&amp;ISO"<br/>)displayName<br/>
Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3]{{BeginYellowBox}}Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.{{EndYellowBox}}
Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung (“documentationOfUnterscheidung classCode/serviceEvent“) verpflichtend, wenn bekannt typeCode:{| class="wikitable"|- style="background:white"|'''''classCode'''''|'''''Dokumentenklasse in grober Granularität''''[R2]'|- style="background:white"|''typeCode''|Dokumentenklasse in feiner Granularität. <br /> Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]|}
Wenn vorhanden, beinhaltet dieses Element die semantisch korrekten Informationen zu Start- und Enddatum gemäß der jeweiligen Fachdomäne (z.B.: das Aufnahme/Entlassungsdatum im Falle von Entlassungsbriefen aus stationärer Behandlung). Die relevanten Informationen dazu finden sich in den speziellen ELGA CDA Implementierungsleitfäden.====Spezifikation====
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem Service-Event verpflichtend:## ClinicalDocument/documentationOf/serviceEvent# Das Element serviceEvent beinhaltet unter anderem die folgenden Unterelemente:## effectiveTime gibt das Zeitintervall an, in dem die Gesundheitsdienstleistung durchgeführt wurde## Laut Vorgabe der ELGA Gesundheitsdaten SOLL ein Zeitintervall '''classCode (HL7 IVL_TSund classCodeDisplayName) in wie folgt angeordnet werden''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:### low … enthält das Startdatum### high … enthält das Endedatum### Andere im CDA möglichen Angaben (low/width, width<br /high, ...) sind nicht gestattet>
TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.$code = ClinicalDocument/code/translation/@code<br /> ====Spezifikation===$displayName = '''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:ClinicalDocument/documentationOfcode/serviceEventtranslation/effectiveTime@displayName<br /low>$codeSystem = ClinicalDocument/code/translation/@value = "20200511193000+0200"codeSystem<br />
{{BeginYellowBox}}
Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000).
{{EndYellowBox}}
'''serviceStopTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value = "20200516133000+0200"
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200516133000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200516113000).{{EndYellowBox}} ===sourcePatientIdcreationTime===Das ''sourcePatientId'' Element beschreibt Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden. Dieses Datum kann für die Patienten ID des Patienten im lokalen Informationssystem des GDAchronologische Sortierung der Befunde bei der Anzeige der Dokumentenliste verwendet werden.
# Im CDA wird die ID des Patienten in folgendem Element abgelegt:
## ClinicalDocument/recordTarget/patientRole/id
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wenn bekannt:
## id[1] … Lokale ID des Patienten vom einbringenden System
## d[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)<br/><span style="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>
====Spezifikation====#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:<br />ClinicalDocument/effectiveTime#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe verpflichtend.#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert.#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:<br />@value … enthält das Datum in folgenden möglichen Formen##YYYYMMDD##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)<br />Bsp: 20081224082015+0100<br />Für: 24.12.2008, 08:20:14, Zeitzone GMT+1# Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.
'''sourcePatientId''' wird gemäß folgender Vorschrift zusammengesetzt:{{BeginYellowBox}}CreationTime entfällt bei On-Demand Documenten.{{EndYellowBox}}
concatDas Aktualisierungsdatum von Dokumenten (Update-Datum) kann über submissionTime (in XDS.submissionSet) erkannt werden.
ClinicalDocument/recordTarget/patientRole/id[1]/@extension,====Spezifikation====
"^^^&amp;",'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />ClinicalDocument/recordTarget/patientRole/id[1]effectiveTime/@root, value = "&amp;ISO20200511193000+0200" )
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].
{{BeginYellowBox}}Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In ELGA den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden die Elemente name. Falls eine Zeit angegeben ist, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf '''MUSS '''diese zuvor gemäß der Registry unnötigZeitzone in UTC Zeit konvertiert werden! (z.B. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO20200511173000) NICHT ERLAUBT.
'''title''' #Im CDA wird als ebRIM "Namedie Liste der ServiceEvents wie folgt abgelegt:##ClinicalDocument/documentationOf/@value"-Attribut im Container serviceEvent#Mehrere dieser ServiceEvents können durch beliebig viele "ExtrinsicObjectdocumentationOf" gemäß folgender Vorschrift zusammengesetztElemente ausgedrückt werden.#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines ServiceEvents verpflichtend, wenn bekannt [R].#Ein ServiceEvent Element in CDA beinhaltet unter anderem die folgenden Elemente:##code … ein Code-Element, welches die Art des ServiceEvents angibt
ClinicalDocument/title <pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"> <Name> <LocalizedString charset="UTF-8" value="Entlassungsbrief Die Vorschriften zur Befüllung der chirurgischen Abteilung" xml:lang="de-AT" /> </Name></ExtrinsicObject></pre>{{BeginYellowBox}}Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBTCDA R2 ServiceEvents leiten sich vom Allgemeinen und vom jeweiligen speziellen CDA Implementierungsleitfäden ab. In den speziellen Implementierungsleitfäden wird definiert, ob im ServiceEvent eine Gesundheitsdienstleistung angegeben werden muss und welche Bedeutung dieses Element hat.{{EndYellowBox}}
Unterscheidung typeCode/classCode:{| class="wikitable"|- style="background:white"| '''typeCode'''| '''Dokumentenklasse in feiner Granularität eventCodeList (Spezialisierungund eventCodeListDisplayName).'''|- style="backgroundwird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:white"| classCode| Dokumentenklasse in grober Granularität.<br/> Siehe Kapitel [[ILF:XDS Metadaten 2020#classCode_.28und_classCodeDisplayName.29|classCode]]|}
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:## ClinicalDocument/code# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.# Ein Code-Für jedes documentationOf Element in CDA beinhaltet unter anderem die folgenden Attribute:## @code … Codierter Wert der Dokumentenklasse### Bsp: Code „11490-0“## @displayName … Lesbarer Wert der Dokumentenklasse### Bsp: „Discharge summarization note (physician)”## @codeSystem … Codierter Wert des zugrundliegenden Codesystems### Bsp: „2.16.840.1.113883.6.1“# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend. ====Spezifikation====n:<br />
'''typeCode (und typeCodeDisplayName)''' wird wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt: <span > $code</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code<br/><span > $displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName<br/><span > $codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem<br/>
<Name>
<LocalizedString value="$displayName"/>
</Name>
{{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 und den Dokumententyp 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}}
$code = ClinicalDocument/code/@codeDiese speziellen Vorschriften werden in ELGA '''nicht''' angewandt.
$displayName = ClinicalDocument/code/@displayName==languageCode===Das ''languageCode'' Element beschreibt den Sprachcode in dem das Dokument verfasst ist. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:====Spezifikation====
$codeSystem = ClinicalDocument/code/@codeSystem'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<Classification classificationSchemeid="urn:uuid:aa5437401e2ede82-bdda8570-424e4be2-8c96bd46-df4873be8500" classifiedObject="theDocument" nodeRepresentation="$codede986a4333be"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="codingSchemelanguageCode"> <ValueList> <Value>urn:oid:$codeSystemde-AT</Value> </ValueList> </Slot> </Classification></RegistryPackageExtrinsicObject>
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:
## ClinicalDocument/id
====Spezifikation====Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt#id … ID der Person mit den folgenden Attributen:<br/>##@root … Root OID des ID Pools, oder direkt die OID der Person (ohne @extension-Attribut)##@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)#assignedEntity##Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält###Name
Fall 1<br/>Attribut ClinicalDocument/id/@extension ist nicht vorhanden====Spezifikation====
$value = concat(ClinicalDocument'''legalAuthenticator''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br /id/@root)>
Fall 2<brspan> $person </span>Attribut = ClinicalDocument/idlegalAuthenticator/@extension ist vorhandenassignedEntity
$value = concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)
===referenceIdList===Um eine eindeutige Identifikation aller Dokumente Im Fall eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA VorgabenEs soll jeweils das erste '''serviceEvent''' für das Mapping verwendet werden.
Aus dem „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).''“
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend:
## ClinicalDocument/setId
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
Dieser Datentyp ist in IHE ITI Data Types in '''serviceStartTime''' wird als ebRIM Slot gemäß folgender Weise spezifiziertVorschrift zusammengesetzt:ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value = "20200511193000+0200"<ref pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"> <Slot name="IHE ITI TF-3serviceStartTime"> <ValueList> <Value>20200511173000</refValue> </ValueList> </Slot></ExtrinsicObject></pre>{{BeginYellowBox}}Dieses Element '''MUSS''' – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein "Kürzen" auf andere Formate ist nicht zulässig.
{| class="wikitable" width="100%"!Data Type||Source Standard||Encoding Specification|-|CX||HL7 V2.5 Identifier||This is an identifier. HL7 Identifier type CX consists of several componentsWenn Datumselemente in CDA mit Zeit angegeben sind, but this specification restricts them to the use of two components, the Id Number, and the Assigning Authority so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (AA)z. The Assigning Authority identifies the "domain" over which the Id Number represents a unique entityB. Furthermore, the AA is characterized by a Universal Id and Universal Id Type20200511193000+0200). In Document Sharing profiles, ISO Object Identifiers (see OID below) must be used as Universal Idden XDS Metadaten können jedoch keine Zeitzonen abgebildet werden.<br />Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. SpecificallyFalls eine Zeit angegeben ist, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />Note that the '&' character must be properly encoded in the XML content.|-|'MUSS''CXi'''||HL7 V2 Identifier||'''This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.'''*'''CXi.1 shall be present and hold the identifier value.'''*'''CXi4 diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entityz. It is formatted just like CXB.4 in the CX datatype above.'''*'''CXi.5 (Identifier Type Code20200511173000) shall be present and chosen from either a URN defined by IHE, or a locally defined value.'''*'''When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.'''*'''No other components shall be present.'''|{{EndYellowBox}} '''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
referenceIdList Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200516133000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200516113000).{{EndYellowBox}}
concat===sourcePatientId===Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.
(Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
ClinicalDocument/setId/@root, "^", ====Spezifikation====
"urn'''sourcePatientId''' wird gemäß folgender Vorschrift zusammengesetzt:elga:iti:xds:2014:ownDocument_setId", "^",
homeCommunityIdconcat(
)ClinicalDocument/recordTarget/patientRole/id[1]/@extension,
Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise „"^^^&“amp;amp;", OID-Wert, „&ISO“ anzugeben sind.
Beispiel 1: setId/@root und setId/@extension sind im CDA strukturiert. In /@extension wird KEINE UUID angegeben."&amp;ISO"
Wie oben angeführt wird folgender CXi Wert erstellt:<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" statussourcePatientInfo="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value>ZZZZZZZZZZZZZZZZZZZ^^^&amp;amp;1.2.40.0.34.99.111Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.1.1 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>{{BeginYellowBox}} ^&amp;amp;1In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig.2.40.0.34Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.99.999&amp;amp;ISO</Value> </ValueList>{{EndYellowBox}} </Slot> </ExtrinsicObject></pre> ===title===Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert istDas ''title'' Element beschreibt den lesbaren Titel des Dokuments.
Beispiel 2#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend: in setId##ClinicalDocument/@extension im CDA wird eine UUID geführttitle
<pre class="ilfbox_code"><ClinicalDocument xmlns="urn:hl7-org:v3">…<setId root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2"/><versionNumber valueSpezifikation===="2"/> …</ClinicalDocument></pre>
Wie oben angeführt '''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender CXi Wert erstelltVorschrift zusammengesetzt:
"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^<ClinicalDocument/nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"title
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"> </nowiki>"Name> <Slot nameLocalizedString charset="UTF-8" value="<nowiki>urnEntlassungsbrief der chirurgischen Abteilung" xml:ihe:iti:xds:2013:referenceIdList</nowiki>lang="> <ValueList> <Value><nowiki><nowiki>urn:uuid:19FEE6C3de-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki> &amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value> <AT" /ValueList> </SlotName> </ExtrinsicObject>
Der intendedRecipient entfällt bei OnUnterscheidung typeCode/classCode:{| class="wikitable"|-Demand Documentsstyle="background:white"|'''typeCode'''|'''Dokumentenklasse in feiner Granularität (Spezialisierung).'''|- style="background:white"|classCode|Dokumentenklasse in grober Granularität.<br /> Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29_2|classCode]]|}
==XDS Metadaten 2Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen: explizit zu setzen (ELGA relevant)=====availabilityStatus===Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments.
Mögliche Werte laut IHE sind#Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:* Approved##ClinicalDocument/code* Deprecated#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.#Ein Code-Element in CDA beinhaltet unter anderem die folgenden Attribute:##@code … Codierter Wert der Dokumentenklasse###Bsp: Code "11490-0"##@displayName … Lesbarer Wert der Dokumentenklasse###Bsp: "Discharge summarization note (physician)"##@codeSystem … Codierter Wert des zugrundliegenden Codesystems###Bsp: "2.16.840.1.113883.6.1"#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.
Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten („Submission“) durch die empfangende XDS Registry immer auf “'''Approved'''” gesetzt.====Spezifikation====
availabilityStatus '''typeCode (und typeCodeDisplayName)''' wird im Attribut @status des als ebRIM ExtrinsicObject abgebildet, das das Classification zum DocumentEntry repräsentiert.umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
<ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/></pre> ===formatCode (und formatCodeDisplayName)===Das ''formatCode'' Element beschreibt das Format des Dokuments bezüglich seiner semantischen Interoperabilität. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments.Im CDA-Schema wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "hl7at:formatCode". ====Bildungsregel für den formatCodeDisplayName ====TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS. 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). '''Beispiele:'''* '''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''* '''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''* '''ELGA Laborbefund, EIS Full Support v2.06+''' ====Spezifikation===='''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br/><span >$code</span> = ClinicalDocument/hl7at:formatCode/@code <br/><span >$displayName</span> = gemäß Liste der in ELGA gültigen FormatCodes<br/><span >$codeSystem</span> = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:a09d5840f0306f51-386c975f-46f2434e-b5ada61c-9c3699a4309dc59651d33983" classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddftheDocument" nodeRepresentation="$code">
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:$displayName = ClinicalDocument/code/@displayName
<span >$code </span>codeSystem = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code <span >$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayNamecodeSystem
<span >$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem
'''parentDocumentId''' MUSS mit folgenden Elementen in CDA übereinstimmenuniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br />
concat(ClinicalDocument/relatedDocument/parentDocument/idFall 1<br /@root,"^",>Attribut ClinicalDocument/relatedDocument/parentDocument/id/@extension)ist nicht vorhanden
'''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen<pre class="ilfbox_code"><ExternalIdentifierregistryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"value="$value"> <Name> <LocalizedString value="XDSDocumentEntry.uniqueId"/> </Name></ExternalIdentifier></pre>
ClinicalDocument===referenceIdList===Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE ITI TF-3<ref name="ITITF3"/relatedDocument/@typeCode> (27 September 2013) Dokument neu hinzugekommen. Für CDA-Befunde sind drei unterschiedliche Einträge in referenceIdList vorgesehen:
===practiceSettingCode (und practiceSettingCodeDisplayName)==={{BeginYellowBox}}Das ''practiceSettingCode'' Element beschreibt Im Rahmen von ELGA MUSS die fachliche Zuordnung des Dokumentes. Es SOLL ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den Fachbereich wiedergeben, dem der Inhalt des Dokuments am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden AbteilungXDS Metadaten strukturiert sein. {{EndYellowBox}}
Im CDA-Schema wurde für die HL7-Austria Domäne wurde ein genau entsprechendes Element geschaffen, "hl7at:practiceSettingCode".
====Spezifikation====Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß Dieser Datentyp ist in IHE ITI TF-3<ref name="ITITF3"/> Data Types in folgender Vorschrift zusammengesetztWeise spezifiziert:
<span >$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br/><span >$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br/><span >$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br/><pre {| class="ilfbox_codewikitable"><Classification classificationSchemewidth="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead100%" classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"!Data Type||Source Standard||Encoding Specification id="urn:uuid:63134a8d-9d4c-4fe0-ad9b|-9198b6deeddf" nodeRepresentation=|CX||HL7 V2.5 Identifier||This is an identifier. HL7 Identifier type CX consists of several components, but this specification restricts them to the use of two components, the Id Number, and the Assigning Authority (AA). The Assigning Authority identifies the "$codedomain"> over which the Id Number represents a unique entity. Furthermore, the AA is characterized by a Universal Id and Universal Id Type. In Document Sharing profiles, ISO Object Identifiers (see OID below) must be used as Universal Id.<Namebr /> Therefore, Universal Id Type is always ISO. The required format is: <LocalizedString value="$displayName"br /> IdNumber^^^&OIDofAA&ISO<br /Name> No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<Slot name="codingScheme"> <ValueListbr /> <Value>urnAn explicit example is:oid:$codeSystem<br /Value> 543797436^^^&1.2.840.113619.6.197&ISO<br /ValueList>Note that the '&' character must be properly encoded in the XML content. </Slot>|-</Classification></pre>|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.
===objectType ===*CXi.1 shall be present and hold the identifier value.Das objectType Element gibt den Typ des XDS DocumentEntry wieder*CXi4 (Assigning Authority) shall be present when the identifier in CXi. Entsprechend den 1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ (stable document, SD) und „On-demand Dokument“ (on-demand documentor a locally defined value.*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, ODD) unterschiedensee CX. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert4 in the CX datatype above.*No other components shall be present.|}
Für "Stable Document" DocumentEntry{{BeginYellowBox}}'''ACHTUNG:'''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt, wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.{{EndYellowBox}} <pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"Versionierung bzw. Versionsklammer (ownDocument_setId)==== id="urn:uuid:1e2ede82Um eine eindeutige Identifikation aller registrierten Versionen eines CDA R2 Dokumentes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-8570Metadaten 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 CDA R2 Dokuments mit derselben ID eindeutig zu kennzeichnen. Für ELGA wird dazu ownDocument_setId definiert, die auf dem CDA Header-4be2-bd46-de986a4333beElement "setId"/></pre>basiert.
Für Aus dem "On-Demand DocumentAllgemeinen Implementierungsleitfaden" DocumentEntry[1]:<pre class="ilfbox_code''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).''"><ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/></pre>
==ELGA-spezifische Erweiterungen der XDS-Metadaten==Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
===elgaFlag===Das elgaFlag dient zur Kennzeichnung eines Dokuments als „ELGA-Dokument“<sup>18</sup>. Ein XDS Source des #Laut Vorgabe der 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 Dokumenten Leitfäden ist die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird Angabe einer setId für 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 annehmenDokument verpflichtend:#* "true" oder* "false"ClinicalDocument/setId [M]
<pre class="ilfbox_code"><Slot name="urn:elga-bes:elgaFlag"> <ValueList> <Value>true</Value> </ValueList></Slot></pre>concat
<sup>18<ClinicalDocument/sup> Das ist für Registries notwendigsetId/@root, "&amp;ISO", die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten"^", die NICHT für ELGA vorgesehen sind.
===elgaHash===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.b Provide and Register Transaktion [ITI-41]“"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^", "&amp;", eine „XDS.b Register Document Transaktion [ITI-42]“ oder eine „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-Hash“ gespeichert.
Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publizierthomeCommunityId, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist."&amp;ISO"
====Spezifikation====<pre class="ilfbox_code"> <rim:Slot name="urn:elga-bes:elgaHash"> <rim:ValueList> <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value> </rim:ValueList> </rim:Slot></pre>)
|-
|[2]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at
|-|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.Beispiel 2.40.0.34.7.3.6], http:in setId//www.elga.gv.at |-| || ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA @extension im CDA Dokumente. |-| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.1.6], http://www.elga.gv.atwird eine UUID geführt
|<pre class="ilfbox_code"><ClinicalDocument xmlns="urn:hl7-|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2org: Laborbefund. v3">|-…| || ELGA CDA Implementierungsleitfäden (<setId root="2.06) [OID 1.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2"/><versionNumber value="2.40.0.34.7.4.6], http:"/> …</ClinicalDocument></www.elga.gv.atpre>
|-|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2Wie oben angeführt wird folgender CXi Wert erstellt: Befund bildgebende Diagnostik. |-| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at|-|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation. |-| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at
|"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: |B1CC-| || Pflegesituationsbericht (B2B5B4001AB2^^^&amp;2.06) [OID 25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.799.12.6], http999&amp;ISO</nowiki>"<pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</wwwnowiki><nowiki>&</nowiki>amp;amp;2.25 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki> &amp;1.2.40.0.34.gv99.at999&amp;ISO</Value> </ValueList> </Slot> </ExtrinsicObject></pre>
|-|[8]|| ELGA GmbH ====Referenz zwischen Dokument und Studie (2015Accession Number) Organisationshandbuch. |-====| || ELGA-Bereiche Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und Krankenanstalten den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (2.2.1''report'') [OID 1verfügbar ist.2.40.0.34.3.1.2.1Dies trifft auf die Accession Number zu (bzw.32]ein vergleichbares Element, http://www.elgadas im implementierten Workflow zur Verknüpfung von Studie und Befund verwendet wird).gv.at|}
keine Bearbeitungszusammenfassung
{{#seo:
|title=XDS Metadaten 20203.0.1
|titlemode=append
|keywords= XDS Metadaten, Metadaten, XDS, CDA, CDA Dokumente
|description=Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS).
}}
{{#customtitle:XDS -Metadaten 2020}}{{Underconstruction(Version 3.0.1+20211001)}}
<!--
{{Underconstruction}} --><!-- Implementierungsleitfaden "XDS -Metadaten 2020(Version 3)"
-->
{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden|Title = ELGA Implementierungsleitfaden XDS -Metadaten (XDSDocumentEntry)|Subtitle Title = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA (Version 3)|Subtitle = Zur Anwendung im österreichischen Gesundheitswesen [1.2.40.0.34.7.6.79.3]|Short = XDS -Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.01+20211001
|Submitted = ELGA GmbH
|Date = Februar 01.10.2021
|Copyright = 2011-
|Status = KommentierungNormativ
|Period = n.a.
|OID = 1.2.40.0.34.7.6.79.3
|Realm = Austria
}}
{{TOC limit|4}}
<!--
<!--
{{Infobox Contributors Begin}}
{{Contributor | Logo = Logo.jpg | Name = Abc | Location = Hürth Wien}}
{{Infobox Contributors End}}
-->
}
}}
=Zusammenfassung=
{{BeginYellowBox}}
Dieses Dokument beschreibt die IHE XDS Metadaten (XDSDocumentEntry), die für die Registrierung von Befunden (HL7 CDA Dokumenten ) und Bilddaten (DICOM KOS) in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten zugrundeliegenden Informationsobjekten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden [https://wiki.hl7.at/index.php?title=ILF:XDS_Metadaten_Guide XDS-Metadaten-Guide ] im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische die Registrierung elektronischer Dokumente in der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012)<ref name="GTelG">Gesundheitstelematikgesetz 2012 [https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120 https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120]</ref>. Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITIhttps://www.ihe.net/resources/technical_frameworks/#iti]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>. Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte sowie DICOM Key Object Selection Documents (in Folge KOS)<ref name="ELGADICOM" gemäß Gesundheitstelematikgesetz 2012 >NEMA PS3 / ISO 12052, Digital Imaging and Communications in Medicine (GTelG 2012DICOM®)Standard, National Electrical Manufacturers Association, Rosslyn, VA, USA. Unter ständiger Weiterentwicklung, aber auch für medizinische Dokumente im österreichischen Gesundheitswesendie aktuelle Version ist frei verfügbar auf http://dicom.nema.org/).<br /ref>TODO: XDSi-Metadaten einfügen.
=Informationen über dieses Dokument=
Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt. <br />
Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> . <!-- Seitenumbruch --><p style="page-break-before: always"><br /p>
===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
Die Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.
Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf [http://www.gesundheit.gv.at 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.
Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich österreichischem und europäischem Recht, insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012, DSGVO) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.
Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.
==Verwendete Grundlagen und Bezug zu anderen Standards==
Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (IHE) International, Incorporated [http://www.ihe.net http://www.ihe.net]</ref>.
Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)<ref name="CDA"></ref> , für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref name="ISO CDA">ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html https://www.iso.org/standard/44429.html]</ref>. CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen. Die Dokumentmetadaten für CDA Dokumente im Österreichischen Gesundheitswesen werden grundsätzlich vom "Allgemeinen CDA Implementierungsleitfaden" <ref name="ALF">Allgemeiner Implementierungsleitfaden für CDA Dokumente [https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_2020Allgemeiner_Implementierungsleitfaden_(Version_3) https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3)]</ref> definiert.Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020Version 3]'''und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadens erstellt werden.
{{EndILFBox}}
==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website : [[ILF:Ambulanzbefund_GuideXDS_Metadaten_Guide|Ambulanzbefund XDS Metadaten Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
{{EndYellowBox}}
Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:
*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}
==Bedienungshinweise==
===Farbliche Hervorhebungen und Hinweise===
''<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>''
{{BeginYellowBox}}
'''<Hinweis:>'''<br />Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''<u>Verweis auf ELGA Value Set:</u>''
{{BeginILFBox}}
'''<Verweis>'''<br/>Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
</div></div>
=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens'''<br/>
Dieser Implementierungsleitfaden entstand in Zusammenarbeit der nachfolgend genannten Personen:
{| class="wikitable"
|-
! colspan="2" style="text-align:left" |Autoren|- ! style="text-align:left" width="10%" |Organisation|| style="text-align:left" width="60%" |Person<sup>1</sup>|- style="background:#FFEBAD"| colspan="2" style="text-align:left" |Herausgeber, Projektleiter, CDA-Koordinator|- |ELGA GmbH||Stefan Sabutsch|- style="background:#FFEBAD"| colspan="32" style="text-align:left"| Autoren
|-
<sup>1</sup> Namen ohne Titel
<!--Einleitung-->
=Einleitung=
==Intention und Abgrenzung ==
Dieses Dokument beschreibt den dokumentspezifischen Teil der Metadaten für die '''Registrierung von CDA-Dokumentenin ELGA''' über IHE XDS in ELGA , unter dem Aspekt der Ableitung von XDS Metadaten aus CDA Dokumenten und der Etablierung von einheitlichen Vokabularen. Eine IHE XDS Registry verwaltet Dokumente und macht diese zufänglich. Sie erlaubt die Suche und das Filtern nach den Dokumenten über die Metadaten der Dokumente (Metadaten sind Daten, die andere Daten definieren und beschreiben). Werden wie für ELGA mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden und Metadatenstandards bereitgestellt werden: Wertebereiche, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung und Policies.
Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.
==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumentenin Form von Befunden<ref name="ALF"></ref> oder Bilddaten 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:* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten Dokumente (Metadaten der XDSDocumentEntry Objekte)** : ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 1712.0 (1622.94.20202016) Final Text''<ref name="IHE ITI TF-3ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 1712.0 (20202016)[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf], zuletzt besucht am 25.01.2021</ref> 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> , den "ELGA CDA Implementierungsleitfäden" und dem Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch<ref name="KOS-Leitfaden">DICOM Austria: Leitfaden zur Erstellung und Verwendung von KOS Objekten für den „ELGA CDA Implementierungsleitfäden“ ELGA Bilddatenaustausch [https://collab.dicom-austria.at/pages/viewpage.action?pageId=27033635 DICOM Austria KOS Leitfaden], zuletzt besucht am 19.02.2021</ref> erstellt.
===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in den entsprechenden Schnittstellenspezifikationen (u.a. Schnittstellen Berechtigungssystem, Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und im Rahmen konkreter System-Anbindungen zu berücksichtigen.
==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden im am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.
Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.
===OID ===
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/).
==Allgemeines zu Dokumenten in ELGA==
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.
Die Vorgaben für die Erstellung der CDA-Dokumente sind die in den "ELGA CDA-Implementierungsleitfäden"ersichtlich. Nur über eine Verordnung definierte Dokumentenklassen dürfen in ELGA verwendet werden, alle Dokumente MÜSSEN entsprechend der Spezifikationen der ELGA CDA-Implementierungsleitfäden erstellt werden.
===Dokumentlebenszyklus und XDS-Transaktionen===
ELGA unterstützt die im Folgenden folgenden aufgezählten Aktionen (in Klammer die entsprechende ITI-Transaktion). Alle Transaktionen werden in den Protokollierungssystemen aufgezeichnet:
====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
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]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.
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, . Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion 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)).
Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.
====Stornieren [ITI-57, XDS Metadata Update]====
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. ====Löschen aus der Registry [ITI-62]====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“, 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 ELGA-Bereiche und Krankenanstalten“ [8].
===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1], Kapitel 6.10]].
==Allgemeines zu XDS-Metadaten==
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 Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
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 ITITF-TF33).<ref name="IHE ITI TF-3ITITF3"></ref>.
Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{EndYellowBox}}
'''Hinweis:''' Sehen Sie Siehe auch die Vorschrift Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3ITITF3"></ref> .
===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument oder binären Objekt entnommen werden und müssen daher von der erstellenden Anwendung mitgegeben werden. Es entsteht dadurch ein zusätzlicher Aufwand insbesondere hinsichtlich der Qualität der Daten. Die Metadaten müssen das beiliegende Dokument oder binäre Objekt korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.
===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.
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="IHEPCC">IHE ITI">Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</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. Die genaue Beschreibung für On-Demand Documents findet sich IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3ITITF3"></ref>.
===Metadaten aus Bilddaten (KOS)===
===XDS Metadaten im Vergleich IHE vs. ELGA===
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können(XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).
In der Tabelle 3 werden die XDS-I Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.
{| class="wikitable" width="100%"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|CK||Aus CDAKOS-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}
''Tabelle 12: Legende zur Spalte „Quelle“ "Optionalität" der folgenden Tabelle''
{| class="wikitable" width="100%"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|RM||Verpflichtend Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden."Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''(„Required”"required")''.
|- style="background:white"
|R2R||Verpflichtend wenn Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt . Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''(„Required "required if Known“known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|XNP||Wird nicht unterstützt – wird bei Das '''Element i'''st NICHT ERLAUBT. Entspricht der Registrierung nicht eingetragenin älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''{| class="wikitable" width="100%"|- style="background:#CBD7F1"| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''|| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''|| rowspan="2" style="text-align:left" width="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''|- style="background:#CBD7F1"|'''SD<sup>9</sup>'''||'''OD<sup>10</sup>Beschreibung'''|- style="background:#CBD7F1"| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''|- style="background:white"| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''R'''||'''RM [1..1]'''|<nowiki>-</nowiki>|Die Personoder das Gerät, welche (s) das Dokument verfasst hat||-|- stylerowspan="background:white4"|| ||authorInstitution||'''R'''||'''RM [1..1]'''|E1/K|ID der Organisation , der die Person angehört. (OID aus dem GDA-Index)||C|- style="background:white"| ||authorPerson||'''R'''||'''R'''||Daten der Person. (Name, ID, etc.)||C|- style="background:white"| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C|- style="background:white"| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C|- style="background:white"| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse)<br />z.B.: 18842-5 „Entlassungsbrief“||C|- style="background:white"| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C|- style="background:white"| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C|- style="background:white"| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''authorPerson|'''R[0..1]'''|'''R'''|Format des DokumenteninhaltsK|CDaten der Person|- style="background:white"| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C|- style="background:white"| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments<br />z.B(Name, ID, etc.: "de-AT"||C|- style="background:white"| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C)
|-
| colspan="2" |'''practiceSettingCode'''authorRole|'''R[0..1]'''|'''R'''K|Fachliche Zuordnung des DokumentsRolle der Person|C-|- style="background:white"authorSpeciality| colspan="2" |'''serviceStartTime'''||'''R2R [0..1]'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C|- style="background:white"E1/K| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum Fachrichtung der Entlassung||CPerson|- style="background:white"| colspan="2" |'''sourcePatientId'''||'''R'''||'''RclassCode'''||Patienten ID im Informationssystem des GDA. z.B.: im KIS des KH||C|- style="background:white"| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (zM [1.B.: im KIS einer Krankenanstalt)||C|- style="background:white"| colspan="2" |'''Title'''||'''R'''||'''R1]'''||Titel des Dokuments||C|- style="background:white"A| colspan="2" |'''typeCode'''<sup>11<Dokumenten/sup>||'''R'''||'''R'''||Dokumententyp (Unterklasse) <br />codierter Wert, z.B.: 11490-0, „Entlassungsbrief aus stationärer Behandlung Objektklasse (ArztOberklasse)“||C|- style="background:white"| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C|- style="background:white"| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C|- style="background:white"| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA|C
z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K/E1
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments
Fester Wert "SD"|-| colspan="2" |'''comments'''|'''O [0..1]'''|K|Kommentar zum Dokument/Objekt|-| colspan="2" |'''patientId'''|'''M [1..1]'''|E1|Patienten-ID in der XDS Affinity Domain|-| colspan=author"5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''|-| colspan="2" |'''hash'''|'''M [1..1]'''|A|Hash Wert des Dokuments. Wird vom Repository befüllt|-| colspan="2" |'''homeCommunityId'''|'''M [1..1]'''|A|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.|-| colspan="2" |'''repositoryUniqueId'''|'''M [1..1]'''|A|Die Personen und/oder Maschineneindeutige Identifikation (OID) des Document Repositories, die in welchem das Dokument erstellt habenabgelegt ist. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty Wird vom Repository befüllt.|-| colspan="2" |'''size'''|'''M [1..1]'''|A|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.<br />|-| colspan="2" |'''URI'''|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]|A|Wird in XDS-I nicht verwendet|-|-| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (und authorTelecommunicationnon-IHE)'''''|-| colspan="2" |'''elgaFlag'''|'''M [1..1]'''|B|Kennzeichnet ein Dokument als "ELGA-Dokument"|-| colspan="2" |'''elgaHash'''|'''M [1..1]'''|B|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes|}<br />[[#%20ftn1|<nowiki/>]]
<br />
<p style="page-break-before: always"></p>
====authorInstitution==Überblickstabelle der XDS Metadaten für HL7 CDA Objekte==Das ''authorInstitution'' Element beschreibt die Organisation (GDA)Die folgende Tabelle gibt einen Überblick über alle XDS-Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in dessen Gültigkeitsbereich IHE bzw. ELGA für das Dokument erstellt wurdeEinbringen von Dokumenten, sowie die Quelle aus der die Informationen stammen.
''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''{| class="wikitable" width="100%"|- style="background:#CBD7F1"! style="text-align:left" |Code|| style="text-align:left" |Bedeutung|- style="background:# GDAsCBD7F1"|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente „GDA Index“ mit einer eindeutigen OID ausgestattet. gilt nicht für On-Demand-Documents)|- style="background:# Falls mehrere IDwhite"|E1||Explizit gesetzt (ELGA relevant)|-Elemente angegeben sind, ist id[1] style="background:#white"|E2||Explizit gesetzt (die erste IDnicht ELGA relevant) zu verwenden. {{BeginYellowBox}}|- style="background:#white"|A||Von Registry oder Repository automatisch gesetztDas AuthorInstitution|-Element ist von besonderer Wichtigkeit, da sie vom style="background:#white"|B||Vom ELGA Berechtigungssystem bei Registrierung geprüft wird.-Berechtigungssteuerungssystem automatisch gesetzt{{EndYellowBox}|}
{| class="wikitable" width="100%"|- ! style="text-align:left" |Code|| style="text-align:left" |Bedeutung|- style="background:CBD7F1"|M||Das '''Element'''MUSS mit einem korrekten "echten" Wert angegeben werden."Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] 'authorInstitution'("required")'' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt.|- style="background:white"|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.|- style="background:white"|O||Optional|- style="background:white"|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')|}
''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''{| class="wikitable" width="100%"|- style="background:#CBD7F1"| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''| rowspan="2" style="text-align:left" |'''Beschreibung '''|- style="background:#CBD7F1"|'''SD'''<span sup>$inst9</spansup>||'''ODD'''<sup> … ClinicalDocument10</author/assignedAuthor/representedOrganizationsup>|- style="background:#CBD7F1"| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''* Fall 1|- style="background:<br/>white"Element $inst/id| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1] ist vorhanden<br/>'''|C||Die Person, welche das Dokument verfasst hat|- style="background:white"Attribut $inst/id| ||authorInstitution||'''M [1..1]/@root ist vorhanden<br/>Attribut $inst/id'''||'''M [1..1]/@extension ist nicht vorhanden<br/>''' concat|C||ID und Name der Organisation (<br/>Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.<span>$inst</span>/name,|- style="^^^^^^^^^background:white",<br/><span>$inst</span>/id| ||authorPerson||'''M [1..1]'''||'''M [1..1]/@root<br/>'''|C||Daten der Person (Name, ID, etc.)<br/><pre class|- style="ilfbox_codebackground:white"><Classification classificationScheme| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''|C||Rolle der Person|- style="urnbackground:uuidwhite"| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''|C||Fachrichtung der Person|- style="background:93606bcf-9494-43ec-9b4e-a7748d1a838dwhite" classifiedObject| colspan="urn2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''|C||Dokumentenklasse (Oberklasse)<br />z.B.:uuid:f0573b3418842-ea9a-4c6d-8556-5cffbe50f0275 "Entlassungsbrief" id|- style="urnbackground:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037white" nodeRepresentation| colspan="2">|'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''|C||Vertraulichkeitscode des Dokuments <Slot name|- style="authorInstitutionbackground:white"> <ValueList> <Value>Unfallkrankenhaus Neusiedl^^^^^^^^^| colspan="2" |'''creationTime'''||'''M [1.2.31]'''||'''NP [0.4.50]'''|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden|- style="background:white"| colspan="2" |'''eventCodeList'''||'''R [0.6.7*]'''||'''R [0.8.9*]'''|C||Liste von Gesundheitsdienstleistungen|-| colspan="2" |'''formatCode'''|'''M [1.1789.45&amp;ISO</Value>1]''' </ValueList>|'''M [1..1]''' </Slot> |C</Classification>|Format des Dokumenteninhalts</pre>|- style="background:white"| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.*Fall 2|- style="background:<br/>white"Element $inst/id| colspan="2" |'''languageCode'''||'''M [1..1] ist vorhanden<br/>Attribut $inst/id'''||'''M [1..1]/@root ist vorhanden'''|C||Sprachcode des Dokuments<br/>z.B.: "de-AT"|- style="background:white"Attribut $inst/id| colspan="2" |'''legalAuthenticator'''||'''R [0..1]/@extension ist vorhanden<br/>'''||'''NP [0..0]'''|C||Rechtlicher Unterzeichner des Dokumentsconcat(<br/>|-<span >$inst</span>/name,| colspan="^^^^^&2",<br/>|'''practiceSettingCode'''|'''M [1..1]'''<span >$inst</span>/id|'''M [1..1]/@root,'''|C|Fachliche Zuordnung des Dokuments|- style="&ISO^^^^background:white"<br/><span >$inst</span>/id| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]/@extension<br/>''')<br/>|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme<pre class|- style="ilfbox_codebackground:white"><Classification classificationScheme| colspan="urn2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''|C||Ende-Datum der Gesundheitsdienstleistung, z.B.:uuidDatum der Entlassung|- style="background:93606bcf-9494-43ec-9b4e-a7748d1a838dwhite" classifiedObject| colspan="urn2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''|C||Patienten ID im Informationssystem des GDA, z.B.:uuidim KIS des KH|- style="background:f0573b34-ea9a-4c6d-8556-5cffbe50f027white" id| colspan="urn2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.:uuidim KIS einer Krankenanstalt)|- style="background:33adae7e-f1ed-4345-acab-73f59bc1d037white" nodeRepresentation| colspan="2">|'''Title'''||'''M [1..1]'''||'''M [1..1]'''|C||Titel des Dokuments <Slot name|- style="authorInstitutionbackground:white"> | colspan="2" |'''typeCode'''<ValueListsup> 11<Value/sup>Unfallkrankenhaus Neusiedl^^^^^&||'''M [1.2.31]'''||'''M [1..41]'''|C||Dokumententyp (Unterklasse) <br />codierter Wert, z.5B.6: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"|- style="background:white"| colspan="2" |'''uniqueId'''||'''M [1.7.81]'''||'''M [1.9.1789&amp;ISO^^^^45</Value>1]'''|C||Global eindeutige ID des Dokuments </ValueList>|- style="background:white" </Slot> | colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''</Classification>|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert</pre>|- style="background:white"Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß | colspan="2" |'''healthcareFacilityTypeCode'''||'''M [IHE ITI-TF31..1]'''||'''M [1..1]'''|C||Klassifizierung des GDA
|- style="background:white"| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''|- style=authorPerson"background:white"| colspan="2" |'''availabilityStatus'''||'''M [1..1]'''||'''M [1..1]'''|E1||Gültigkeit des Dokuments|- style="background:white"| colspan="2" |'''mimeType'''||'''M [1..1]'''||'''M [1..1]'''|E1||Mime Type des Dokuments<br />z.B.: "text/xml" für CDA|- style="background:white"Das Element | colspan="2" |'''authorPersonparentDocumentId'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät'<sup>12</die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft)sup>||'''O [0..1]'''||'''O [0.. Mindestens eine Person1]'''|E1||Verweis auf ein referenziertes DokumentIm Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen|- style="background:white"| colspan="2" |'''parentDocumentRelationship'''<sup>13</sup>||'''O [0..1]'''||'''O [0..1]'''# Laut Festlegung wird |E1||Typ der Autor im HeaderRelation zu dem referenzierten Dokument.<br />z.B.: RPLC, XFRM|-Element „author“ abgelegtstyle="background:white"## ClinicalDocument/author/assignedAuthor| colspan="2" |'''entryUUID'''||'''M [1..1]'''||'''M [1..1]'''# Der Autor |E1||UUID des Metadaten-Records des Dokuments (PersonXDS DocumentEntry)## Ein Personenelement enthält unter anderem die folgenden Unterelemente|- style="background:white"### id … ID der Person mit den folgenden Attributen:| colspan="2" |'''objectType'''||'''M [1..1]'''||'''M [1..1]'''#### @root … Root OID |E1||Typ des ID Pools, DocumentEntries (SD oder direkte die OID der Person (ohne @extensionODD)|-Attribut)style="background:white"#### @extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)| colspan="2" |'''comments'''||'''O [0..1]'''||'''O [0..1]'''### assignedPerson|E2||Kommentar zum Dokument#### Enthält ein HL7 Personen|-Element, welches das Namenstyle="background:white"| colspan="2" |'''patientId'''||'''M [1..1]'''||'''M [1..1]'''|E1||Patienten-Element zur Person enthältID in der XDS Affinity Domain ##### name|- style="background:white"# Gerät | colspan="6" style="text-align:center" |'''''Von Registry oder Software als Autor Repository automatisch gesetzte Metadaten'''''## Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar|- style="background:white"### assignedAuthoringDevice| colspan="2" |'''hash'''||'''M [1..1]'''||'''NP [0..0]'''#### Enthält ein Element mit dem Namen |A||Hash Wert des Herstellers Dokuments. Wird vom Repository befüllt.|- style="background:white"| colspan="2" |'''homeCommunityId'''||'''M [1..1]'''||'''M [1..1]'''|A||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des Geräts oder /der Software XCA Responding Gateway(s)) zu erhalten.##### manufacturerModelName|- style="background:white"#### Enthält ein Element mit dem Namen | colspan="2" |'''repositoryUniqueId '''||'''M [1..1]'''||'''M [1..1]'''|A||Die eindeutige Identifikation (OID) des Geräts oder der Software Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.|- style="background:white"##### softwareName| colspan="2" |'''size'''||'''M [1..1]'''||'''NP [0..0]'''|A||Größe des Dokuments in Bytes. Wird vom Repository befüllt.|- style="background:white"| colspan="2" |'''URI'''||'''NP [0..0]'''||'''NP [0..0]'''|A||'''Wird in XDS nicht verwendet'''|- style="background:white"| colspan="6" style=Spezifikation für Personen="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''|- style="background:white"| colspan="2" |'''elgaFlag'''||'''M [1..1]'''||'''M [1..1]'''|B||Kennzeichnet ein Dokument als "ELGA-Dokument"|- style="background:white"| colspan="2" |'''elgaHash'''||'''M [1..1]'''||'''M [1..1]'''|B||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes|} <sup>9</sup> SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.<br /><sup>10</sup> ODD: "On-demand Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. <br /><sup>11</sup> Der Inhalt des typeCodes soll mit dem contentTypeCode des Submission Sets übereinstimmen.<br /><sup>12</sup> MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. <br /><sup>13</sup> MUSS gemeinsam mit einer "parentDocumentId" angegeben sein.<br />
'''im KOS'''|'''Beschreibung'''|- style="background:white"| colspan="2" |author|M [1..1]| colspan="3" ||- style="background:white"| rowspan=Spezifikation für Software und Geräte====="6" ||author.authorInstitution|M [1..1]|(0008,0080)|(0008,0080)|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.
siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>|- style=====Spezifikation======"background:white"||eventCodeList<br />DisplayNameList|M [1..1]||'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:|Enthält den Display Name des APPC
|- style="background:white"
|'''''classCode'''''colspan="2" |sourcePatientId|M [1..1]|(0010,0020)|(0010,0020)|'''''Dokumentenklasse in grober Granularität'''''Die Patient ID im eigenen Informationssystem
|- style="background:white"
|''typeCode''colspan="2" |sourcePatientInfo|Dokumentenklasse in feiner Granularität.<br /> Siehe Kapitel [M [ILF:XDS Metadaten 2020#typeCode_1.28und_typeCodeDisplayName.29|4.2.15]1]|}(0010,0020) (0010,0010)
Alternativ darf anstatt der Study Description der DisplayName des APPC verwendet werden.
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".<br />|- style="background:white"| colspan="2" |uniqueId|M [1..1]||(0008,0018)|Die SOP Instance UID des KOS|- style=confidentialityCode"background:white"| colspan="2" |referenceIdList|M [1..1]|||Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente|- style="background:white"| rowspan="2" ||value mit CXi.5 =<br />"<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des Dokuments|M [1..1]|(0020,000D) oder ein vergleichbares Attribut|(0020,000D) oder ein vergleichbares Attribut|Die setId zur Klammerung aller Versionen eines KOS
====Spezifikation==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==
{{BeginYellowBox}}
{{EndYellowBox}}
=====Spezifikation===== '''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: <span>$name</span> … Name der Organisation, die die Studie erstellt hat <span>$oid ... OID der Organisation aus dem GDA-Index</span>
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f93606bcf-054d9494-47f243ec-a0329b4e-9b2a5b5186c1a7748d1a838d" statusclassifiedObject="urn:oasisuuid:names:tc:ebxmlf0573b34-ea9a-4c6d-8556-regrep:StatusType:Approved5cffbe50f027" id="urn:uuid:1e2ede8233adae7e-8570f1ed-4be24345-bd46acab-de986a4333be73f59bc1d037" nodeRepresentation=""> <Slot name="creationTimeauthorInstitution">
<ValueList>
<Value>20200511173000Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO </Value>
</ValueList>
</Slot> </ExtrinsicObjectClassification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 DTM XON Datentyp gemäß [IHE ITITF-TF3]3<ref name="ITITF3" />. ====authorPerson====Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche die Bilddaten inhaltlich erstellt hat. Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (optionalen) DICOM Attributen: #Die Person kann aus den DICOM Attributen der Studie abgeleitet werden#*Identifikator: Code aus Attribut "Performing Physicians Identification Sequence", (0008,1052), Datentyp SQ, wenn vorhanden. Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence.#*Name: Attribut "Performing Physicians Name", (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datentyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.#*Root: OID-Unterknoten für Personen (entsprechend der Organisations-OID aus dem GDA-Index)#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den folgenden DICOM Attributen abgleitet werden#*Modalität: Attribut "Modality", (0008,0060), erlaubte Werte siehe DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality <ref name="DICOMModality">DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</ref>#*Hersteller: Attribut "Manufacturer", (0008,0070)#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090)
{{BeginYellowBox}}
{{EndYellowBox}}
===eventCodeList (und eventCodeListDisplayName)==Spezifikation für Personen=====Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt.
$id ====Spezifikation====Code #1 aus (0008,1052) Performing Physicians Identification Sequence
concat(<br /><span >$code id</span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code,"^",<br/><span >$displayNameperson</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName,"^",<br/><span >$codeSystem</span> = ClinicalDocumentroot,"&amp;ISO"<br /documentationOf[n]/serviceEvent/code/@codeSystem>)<br/>
<pre class="ilfbox_code">
<Classification classificationScheme= "urn:uuid:2c6b8cb793606bcf-8b2a9494-405143ec-b2919b4e-b1ae6a575ef4a7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="$code"> <Slot name="codingSchemeauthorPerson"> <ValueList> <Value>urn:oid:$codeSystem11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO </Value>
</ValueList>
</Slot> <Name> <LocalizedString value="$displayName"/> </Name> </Classification></pre>
<ValueList>
<Value>de-AT2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot> </ExtrinsicObjectClassification></pre>Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https:/pre/ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben. =====Spezifikation für Software und Geräte=====
$Manufacturer ====Spezifikation====Manufacturer (0008,0070)
$ManufacturersModelName = Manufacturer'''legalAuthenticator''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>s Model Name (0008,1090)
concat(
<ValueList>
<Value>1234^MusterdoktorCT^HerbertGeräthersteller^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISOGerätename</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification></pre> Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITITF-3<ref name="ITITF3" />. ====authorRole====Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-TF3]Objekt Erzeugung innehatte.
=====Spezifikation===== '''serviceStartTimeauthorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:ClinicalDocumentBsp: Fachärztin/documentationOfFacharzt für Radiologie<br /serviceEvent/effectiveTime/low/@value = "20200511193000+0200"><pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f93606bcf-054d9494-47f243ec-a0329b4e-9b2a5b5186c1a7748d1a838d" statusclassifiedObject="urn:oasisuuid:names:tc:ebxmlf0573b34-ea9a-4c6d-8556-regrep:StatusType:Approved5cffbe50f027" id="urn:uuid:1e2ede8233adae7e-8570f1ed-4be24345-bd46acab-de986a4333be73f59bc1d037" nodeRepresentation=""> <Slot name="serviceStartTimeauthorSpeciality">
<ValueList>
<Value>20200511173000Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot> </ExtrinsicObjectClassification>
</pre>
{{BeginYellowBox}}
{{EndYellowBox}}
===classCode (und classCodeDisplayName)===
Das ''classCode'' Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechtigungssystem.
Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität.<br /> Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}
====Spezifikation====
'''serviceStopTimeclassCode (und classCodeDisplayName)''' wird als ebRIM Slot Classification gemäß folgender Vorschrift zusammengesetzt:<br /> Es wird ein fester Wert gesetzt: 55113-5 "Key images Document Radiology" (LOINC: 2.16.840.1.113883.6.1)ClinicalDocument$code = "55113-5"<br /documentationOf>$displayName = "Key images Document Radiology"<br /serviceEvent/effectiveTime/high/@value >$codeSystem = "20200516133000+02002.16.840.1.113883.6.1"<br />
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f41a5887f-054d8865-47f24c09-a032adf7-9b2a5b5186c1e362475b143a" statusclassifiedObject="theDocument" nodeRepresentation="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved$code"> id<Name> <LocalizedString value="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be$displayName"/> </Name> <Slot name="serviceStopTimecodingScheme">
<ValueList>
<Value>20200516113000urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification>
</pre>
====Spezifikation====
)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientIdcreationTime">
<ValueList>
<Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
===title=Spezifikation====Das ''title'' Element beschreibt den lesbaren Titel des Dokuments.
<pre class="ilfbox_code">
<ExtrinsicObject mimeTypeClassification classificationScheme="text/xml" objectType="urn:uuid:7edca82f2c6b8cb7-054d8b2a-47f24051-a032b291-9b2a5b5186c1b1ae6a575ef4" statusclassifiedObject="urn:oasis:names:tc:ebxml-regrep:StatusType:ApprovedtheDocument" nodeRepresentation="$code"> id<Slot name="codingScheme"> <ValueList> <Value>urn:uuidoid:1e2ede82-8570-4be2-bd46-de986a4333be"$codeSystem</Value> </ValueList> </Slot>
<Name>
<LocalizedString charset="UTF-8" value="Entlassungsbrief der chirurgischen Abteilung" xml:lang="de-AT$displayName" />
</Name>
</ExtrinsicObjectClassification>
</pre>
===languageCode===
Das ''languageCode'' Element beschreibt den Sprachcode in dem ein Dokument oder Objekt verfasst bzw. beschlagwortet ist. Derzeit wird ein fester Wert vorgeschrieben: '''de-AT'''
====Spezifikation====
'''typeCode (und typeCodeDisplayName)languageCode''' wird wird als ebRIM Classification zum DocumentEntry umgesetzt und Slot gemäß folgender Vorschrift zusammengesetzt:
<pre class="ilfbox_code">
<ClassificationExtrinsicObject mimeType="text/xml" classificationSchemeobjectType="urn:uuid:f0306f517edca82f-975f054d-434e47f2-a61ca032-c59651d339839b2a5b5186c1" classifiedObjectstatus="theDocumenturn:oasis:names:tc:ebxml-regrep:StatusType:Approved" nodeRepresentationid="$code"> <Name> <LocalizedString value=urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"$displayName"/> </Name> <Slot name="codingSchemelanguageCode">
<ValueList>
<Value>urn:oid:$codeSystemde-AT</Value>
</ValueList>
</Slot>
</ClassificationExtrinsicObject>
</pre>
===legalAuthenticator=submissionSet==Dieses Element darf für XDS-I nicht verwendet werden [NP].contentTypeCode ===serviceStartTime / serviceStopTime===Der contentTypeCode Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des SubmissionSets Patientenkontakts bzw. der Untersuchung. Für KOS-Objekte kann die ''serviceStartTime'' aus dem Objekt gemappt werden: #Das Erstellungsdatum der Studie (aus dem KOS Objekt oder bevorzugt der DICOM Studie):#*Study Date (0008,0020)#*Study Time (0008,0030)#Alle Zeiten müssen in XDS in UTC konvertiert werden, daher sollte Timezone Offset From UTC berücksichtigt werden, falls angegeben:#*Timezone Offset From UTC (0008,0201) Für die serviceStopTime steht kein Mapping zur Verfügung und wird daher nicht angegeben [NP]. ====Spezifikation===='''serviceStartTime''' wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.Slot gemäß folgender Vorschrift zusammengesetzt:
)
<pre class="ilfbox_code">
<RegistryPackageExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).
In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!
{{EndYellowBox}}
===sourcePatientId===
Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.
Eine OID zur Definition des Namensraumes des verwendeten Patientenidentifikators muss entsprechend vorhanden sein.
====Spezifikation====
$value = concat(ClinicalDocument/id/@rootpatientID, "^",ClinicalDocument/id/@extension)
<pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType=referenceIdList"urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"> <Slot name="sourcePatientId"> <ValueList> <Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</Value> </ValueList>Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS </Slot></ExtrinsicObject></pre>Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß IHE ITI TF-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig3<ref name="ITITF3" />.
===sourcePatientInfo===Das referenceIdList ''sourcePatientInfo'' Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommenbeschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
{{EndYellowBox}}
Im Fall eines CDA R2 Dokuments KOS-Objektes gilt folgende Verknüpfung mit den CDA Header ElementenMetadaten: # Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend: ## ClinicalDocument/setId
#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''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".
{{EndYellowBox}}
====Spezifikation====
Modality,
Study Description
Unterscheidung typeCode/classCode:{| class="wikitable"|- style="background:white"|'''typeCode'''|'''Objektklasse in feiner Granularität (Spezialisierung).'''|- style="background:white"|classCode|Objektklasse in grober Granularität.<br /> Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]|}
$displayName = "Key images Document Radiology"
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:
<pre class="ilfbox_code">
<ClinicalDocument xmlnsExternalIdentifierregistryObject="urn:hl7uuid:1e2ede82-8570-4be2-bd46-org:v3de986a4333be">…<setId root="2.25" extensionidentificationScheme="urn:uuid:19FEE6C32e82c1f6-6B35a085-4C5B4c72-B1CC9da3-2B5B4001AB28640a32e42ab"/value="$value"> <Name> <versionNumber LocalizedString value="2XDSDocumentEntry.uniqueId"/> … </Name></ClinicalDocumentExternalIdentifier></pre>
Der intendedRecipient entfällt bei On-Demand DocumentsWert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name="ITITF3"/><!-- Seitenumbruch --><p style=XDS Metadaten "page-break-before: always"></p>{| class="wikitable" width="100%"!Data Type||Source Standard||Encoding Specification|-|CX||HL7 V2.5 Identifier||This is an identifier. HL7 Identifier type CX consists of several components, but this specification restricts them to the use of two components, the Id Number, and the Assigning Authority (AA). The Assigning Authority identifies the "domain" over which the Id Number represents a unique entity. Furthermore, the AA is characterized by a Universal Id and Universal Id Type. In Document Sharing profiles, ISO Object Identifiers (see OID below) must be used as Universal Id.<br />Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2and 3 shall be empty as listed above.<br />An explicit example is: explizit zu setzen <br />543797436^^^&1.2.840.113619.6.197&ISO<br />Note that the '&' character must be properly encoded in the XML content.|-|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components. *CXi.1 shall be present and hold the identifier value.*CXi4 (ELGA relevantAssigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.*CXi.5 (Identifier Type Code)==shall be present and chosen from either a URN defined by IHE, or a locally defined value.*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.*No other components shall be present.|}{{BeginYellowBox}}===availabilityStatus===Das availabilityStatus'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments255 Zeichen vorgeschrieben.{{EndYellowBox}}
$homeCommunityId ===formatCode (und formatCodeDisplayName)===Das ''formatCode'' Element beschreibt das Format OID des Dokuments bezüglich seiner semantischen Interoperabilitätlokalen ELGA-Bereiches. Diese MUSS [1. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments.Im CDA-Schema wurde 1], unabhängig vom für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen$id gewählten Identifier, angeführt sein, "hl7at:formatCode"z.B. 1.2.40.0.34.99.999
Wie oben angeführt wird folgender CXi Wert für <span Value>$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem erstellt:
<pre class="ilfbox_code">
<ClassificationExtrinsicObject mimeType="text/xml" classificationScheme objectType="<nowiki>urn:uuid:f33fb8ac7edca82f-18af054d-42cc47f2-ae0ea032-ed0b0bdb91e19b2a5b5186c1</nowiki>" classifiedObject status="<nowiki>urn:uuidoasis:names:tc:f0573b34ebxml-ea9a-4c6d-8556-5cffbe50f027regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:63134a8d1e2ede82-9d4c8570-4fe04be2-ad9bbd46-9198b6deeddf" nodeRepresentation="$codede986a4333be</nowiki>"> <Name> <LocalizedString valueSlot name="$displayName"/<nowiki> urn:ihe:iti:xds:2013:referenceIdList</Namenowiki> <Slot name="codingScheme"> <ValueList> <Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:oidelga:$codeSystemiti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value> </ValueList> </Slot> </ClassificationExtrinsicObject></pre>Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
===mimeType=Referenz zwischen Dokument und Studie (Accession Number)====Das Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''mimeTypeacquisition, store'' Element beschreibt den „Internet Media Type“ des Dokuments gemäß dem „Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard wird beschrieben in RFC 2045 bis RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions als auch bei der Befundschreibung (MIME''report'') Part One: Format of Internet Message Bodies [http://toolsverfügbar ist.ietf.org/html/rfc2045 IETF RFC 2045]</ref><ref name="RFC2046">Multipurpose Internet Mail Extensions Dies trifft auf die Accession Number zu (MIMEdasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird) Part Part Two: Media Types [http://tools.ietf.org/html/rfc2046 IETF RFC 2046]</ref><ref name="RFC2047">Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text [http://tools.ietf.org/html/rfc2047 IETF RFC 2047]</ref><ref name="RFC2048">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [http://tools.ietf.org/html/rfc2048 IETF RFC 2048]</ref><ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>
)<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" status=Spezifikation=="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value> </ValueList> </Slot> </ExtrinsicObject></pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"
encounterId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
$id = Aufenthaltszahl z.B. Az123456
(
$id, "^^^", "&amp;"
</pre>
===objectType =Weitere Einträge der referenceIDList====Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ (stable document, SD) und „On-demand Dokument“ (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:
</pre>
===intendedRecipient===Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA-spezifische Erweiterungen nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes. Der intendedRecipient entfällt bei der Registrierung von KOS Objekten via XDS-MetadatenI. ===comments===Das ''comments'' Element enthält Kommentare zum Objekt. Die folgenden Daten entsprechen Verwendung ist in ELGA optional (wird in einigen Implementierungen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetztangezeigt, z. Die Angabe in diesem Leitfaden dient nur zur InformationB. ELGA Bürgerportal)
====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre><br />
Mögliche Werte laut IHE sind:
*Approved
*Deprecated
<pre class="ilfbox_code">
</pre>
===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 Objektformats und somit die korrekte Darstellung und Verarbeitung.
====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
<br />
<span>$code</span> = "1.2.840.10008.5.1.4.1.1.88.59"<br />
<span>$displayName</span> = "Key Object Selection Document"<br />
<span>$codeSystem</span> = "1.2.840.10008.2.6.1"
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
{{EndYellowBox}}
====Spezifikation====
<span>$code </span>= Klassifizierung des GDA (Code)
<span >$instdisplayName </span> … ClinicalDocument/author/assignedAuthor/representedOrganization= Klartext des angegebenen Codes
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcff33fb8ac-949418af-43ec42cc-9b4eae0e-a7748d1a838ded0b0bdb91e1"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e63134a8d-f1ed9d4c-43454fe0-acabad9b-73f59bc1d0379198b6deeddf" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="authorInstitutioncodingScheme">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISOurn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>
===mimeType===
Das ''mimeType'' Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045<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> und RFC 2049<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>.
Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".
====Spezifikation====
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"ExtrinsicObject classifiedObject id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id mimeType="application/dicom" objectType="urn:uuid:33adae7e34268e47-f1edfdf5-434541a6-acabba33-73f59bc1d037" nodeRepresentation="82133c465248"> <Slot name status="authorInstitutionurn:oasis:names:tc:ebxml-regrep:StatusType:Approved"> <ValueList> <Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value> </ValueList> </Slot> </Classification>
</pre>
====authorPerson=practiceSettingCode (und practiceSettingCodeDisplayName)===Das Element ''authorPersonpracticeSettingCode'' Element beschreibt die Identifikation und demographische Informationen fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Person Fachrichtung des Autors oder das Gerät/die Softwareder erstellenden Abteilung, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft)z.B. Mindestens eine Person:
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcfcccf5598-94948b07-43ec4b77-9b4ea05e-a7748d1a838dae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e63134a8d-f1ed9d4c-43454fe0-acabad9b-73f59bc1d0379198b6deeddf" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="authorPersoncodingScheme">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO urn:oid:$codeSystem</Value>
</ValueList>
</Slot> </Classification></pre>{{BeginYellowBox}}Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.{{EndYellowBox}}Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3]. =====Spezifikation für Software und Geräte=====
Für KOS Objekte wird der fixe Wert "<span nowiki> $personurn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</spannowiki> = ClinicalDocument/author/assignedAuthor concat(<br/>"^für ",<br/><span > $person</span>/assignedAuthoringDevice/manufacturerModelName,Stable Document"^",<br/><span > $person</span>/assignedAuthoringDevice/softwareName<br/>)<br/>vorgegeben:
<pre class="ilfbox_code">
<Classification classificationSchemeExtrinsicObject mimeType="application/dicom" objectType="urn:uuid:93606bcf7edca82f-9494054d-43ec47f2-9b4ea032-a7748d1a838d9b2a5b5186c1" classifiedObjectstatus="urn:uuidoasis:names:tc:f0573b34ebxml-ea9a-4c6d-8556-5cffbe50f027regrep:StatusType:Approved" id="urn:uuid:33adae7e1e2ede82-f1ed8570-43454be2-acabbd46-73f59bc1d037de986a4333be" nodeRepresentation=""> <Slot name="authorPerson"> <ValueList> <Value>^Good Health System^Best Health Software Application</Value> </ValueList> </Slot></Classification></pre>
====authorRole=elgaFlag===Das ''authorRole'' Element beschreibt die RolleelgaFlag dient zur Kennzeichnung eines Objektes als "ELGA-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 inhaltliche Autor Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Dokuments zum Zeitpunkt Patienten von der Dokumentation innehatteELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt."elgaFlag" kann folgende Werte annehmen:
</pre>
====authorSpeciality=elgaHash===Das ''authorSpeciality Element'' beschreibt 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.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die Fachrichtung ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert. Die Reihenfolge sowie der PersonHash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, welche da ausschließlich das Dokument verfasst hatELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.
=XDS Metadaten für CDA Dokumente=Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht angegebene Metadaten sind nicht weiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol. 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name====Spezifikation======"ITITF3"/>
===author===Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication). CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen. ====authorInstitution====Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen: #Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:##ClinicalDocument/author/assignedAuthor/code/representedOrganization#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:##'''id'''[1] … ID der Organisation mit den folgenden Attributen:###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @displayNameroot nicht direkt die Organisation identifiziert)##'''name''' … Name der Organisation als String<br/><pre class=Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"ilfbox_codedescriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.<br /><Classification classificationScheme=Beispiel: Statt "urn:uuid:93606bcf-9494-43ec-9b4eAllgemeines Krankenhaus der Stadt Wien-a7748d1a838dMedizinischer Universitätscampus" classifiedObject=→ "urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027Wien AKH" id=bzw "urn:uuid:33adae7eWien AKH -f1edAugenambulanz"<br />Die offizielle Kurzbezeichnung eines GDA kann im GDA-4345I über die WSDL-acabSchnittstelle ausgelesen werden, dafür steht ab 2021-73f59bc1d037" nodeRepresentation=ER2 ein eigenes optionales Attribut "Shortname">im Response zur Verfügung. <Slot name=#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "authorSpecialityGDA Index">mit einer eindeutigen OID ausgestattet. <ValueList> <Value>Anästhesiologie und Intensivmedizin</Value> </ValueList> </Slot> </Classification></pre>#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
{{EndYellowBox}}
===classCode (und classCodeDisplayName)==Spezifikation=====Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.
<br span>$inst</span>… ClinicalDocument/author/assignedAuthor/representedOrganization
concat(<br /><span>$code = ClinicalDocumentinst</codespan>/translation/@codename,"^^^^^^^^^",<br /><span>$displayName = ClinicalDocumentinst</codespan>/translationid[1]/@displayNameroot,"&amp;ISO"<br />$codeSystem = ClinicalDocument/code/translation/@codeSystem)<br /><pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:41a5887f93606bcf-88659494-4c0943ec-adf79b4e-e362475b143aa7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" nodeRepresentation id="$codeurn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037"> <Name> <LocalizedString valuenodeRepresentation="$displayName"/> </Name> <Slot name="codingSchemeauthorInstitution">
<ValueList>
<Value>urn:oid:$codeSystemUnfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>
concat(<br />
<span>$inst</span>/name,"^^^^^&",<br />
<span>$inst</span>/id[1]/@root,"&ISO^^^^"<br />
<span>$inst</span>/id[1]/@extension<br />
)<br />
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac93606bcf-e6cb9494-488343ec-b5249b4e-f2705394840fa7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" nodeRepresentation id="Nurn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037"> <Name> <LocalizedString valuenodeRepresentation="normal"/> </Name> <Slot name="codingSchemeauthorInstitution">
<ValueList>
<Value>urn:oid:Unfallkrankenhaus Neusiedl^^^^^&1.2.163.4.8405.16.7.1138838.59.251789&amp;ISO^^^^45</Value>
</ValueList>
</Slot> </Classification></pre>Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>. ====authorPerson====Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft). Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen: #Laut Festlegung wird der Autor im Header-Element "author" abgelegt:##ClinicalDocument/author/assignedAuthor#Der Autor (Person)##Ein Personenelement enthält unter anderem die folgenden Unterelemente:###id … ID der Person mit den folgenden Attributen:####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)###assignedPerson####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält#####name#Gerät oder Software als Autor ##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:###assignedAuthoringDevice####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software #####manufacturerModelName####Enthält ein Element mit dem Namen des Geräts oder der Software #####softwareName
===creationTime==Spezifikation für Personen=====Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.
<span> $person</span> ====Spezifikation====ClinicalDocument/author/assignedAuthor
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f93606bcf-054d9494-47f243ec-a0329b4e-9b2a5b5186c1a7748d1a838d" statusclassifiedObject="urn:oasisuuid:names:tc:ebxmlf0573b34-ea9a-4c6d-8556-regrep:StatusType:Approved5cffbe50f027" id="urn:uuid:1e2ede8233adae7e-8570f1ed-4be24345-bd46acab-de986a4333be73f59bc1d037" nodeRepresentation=""> <Slot name="creationTimeauthorPerson">
<ValueList>
<Value>202005111730002323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO </Value>
</ValueList>
</Slot> </ExtrinsicObjectClassification></pre> Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3].
{{BeginYellowBox}}
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
===eventCodeList (==Spezifikation für Software und eventCodeListDisplayName)Geräte=====Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt.
<span> $person</span> ====Spezifikation====ClinicalDocument/author/assignedAuthor
<pre class="ilfbox_code">
<Classification classificationScheme= "urn:uuid:2c6b8cb793606bcf-8b2a9494-405143ec-b2919b4e-b1ae6a575ef4a7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="$code"> <Slot name="codingSchemeauthorPerson">
<ValueList>
<Value>urn:oid:$codeSystem^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: ClinicalDocument/languageCodeauthor/functionCode/@code = "de-AT"displayName<br /><pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f93606bcf-054d9494-47f243ec-a0329b4e-9b2a5b5186c1a7748d1a838d" statusclassifiedObject="urn:oasisuuid:names:tc:ebxmlf0573b34-ea9a-4c6d-8556-regrep:StatusType:Approved5cffbe50f027" id="urn:uuid:1e2ede8233adae7e-8570f1ed-4be24345-bd46acab-de986a4333be73f59bc1d037" nodeRepresentation=""> <Slot name="languageCodeauthorRole">
<ValueList>
<Value>de-ATDiensthabender Oberarzt</Value>
</ValueList>
</Slot> </ExtrinsicObjectClassification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}
====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.
#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:##''ClinicalDocument/author/assignedAuthor/code''#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden 'legalAuthenticator''' '[R]'''''.#Wenn das Element angegeben ist, wird die Fachrichtung als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>Text im Attribut @displayName erwartet.
'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f93606bcf-054d9494-47f243ec-a0329b4e-9b2a5b5186c1a7748d1a838d" statusclassifiedObject="urn:oasisuuid:names:tc:ebxmlf0573b34-ea9a-4c6d-8556-regrep:StatusType:Approved5cffbe50f027" id="urn:uuid:1e2ede8233adae7e-8570f1ed-4be24345-bd46acab-de986a4333be73f59bc1d037" nodeRepresentation=""> <Slot name="legalAuthenticatorauthorSpeciality">
<ValueList>
<Value>1234^Musterdoktor^Herbert^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISOAnästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot> </ExtrinsicObjectClassification>
</pre>
===serviceStartTime / serviceStopTimeclassCode (und classCodeDisplayName)===Die Das ''serviceStartTime/serviceStopTimeclassCode'' Elemente beschreiben Element beschreibt die Zeitpunkte des Beginns Dokumentenklasse (grobe Granularität) der das Dokument angehört und Beendigung des Patientenkontakts/Behandlungist relevant für das Berechtigungssystem.
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f41a5887f-054d8865-47f24c09-a032adf7-9b2a5b5186c1e362475b143a" statusclassifiedObject="theDocument" nodeRepresentation="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved$code"> id<Name> <LocalizedString value="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be$displayName"/> </Name> <Slot name="serviceStartTimecodingScheme">
<ValueList>
<Value>20200511173000urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification>
</pre>
===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des Dokuments.
Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt.
Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich und wird fix auf "N" (normal) gesetzt.
Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen:
====Spezifikation====
confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:<br />
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82ff4f85eac-054de6cb-47f24883-a032b524-9b2a5b5186c1f2705394840f" statusclassifiedObject="theDocument" nodeRepresentation="urn:oasis:names:tc:ebxml-regrep:StatusType:ApprovedN"> id<Name> <LocalizedString value="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333benormal"/> </Name> <Slot name="serviceStopTimecodingScheme">
<ValueList>
<Value>20200516113000urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification></pre>{{BeginYellowBox}}Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientIdcreationTime">
<ValueList>
<Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO20200511173000</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name===sourcePatientInfo==="ITITF3"/>.{{BeginYellowBox}}Das creationTime '''MUSS'sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten– entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein "Kürzen" auf andere Formate ist nicht zulässig.
{{EndYellowBox}}
===titleeventCodeList (und eventCodeListDisplayName)===Das ''title'' Im Fall eines Entlassungsbriefs beschreibt dieses Element beschreibt die Liste der vollbrachten Gesundheitsdienstleistungen für den lesbaren Titel des Dokumentsim Dokument dokumentierten Patientenkontakt.
Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:## ClinicalDocument/title====Spezifikation====
===typeCode (und typeCodeDisplayName)=Spezifikation====Das ''typeCode'' Element beschreibt den Dokumententyp, dem das Dokument angehört. Der Dokumententyp ist die Spezialisierung einer Dokumentenklasse, jeder Dokumententyp gehört zu genau einer Dokumentenklasse.
<pre class="ilfbox_code">
<Classification
classificationScheme= "urn:uuid:f0306f512c6b8cb7-975f8b2a-434e4051-a61cb291-c59651d33983b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>
====submissionSet.contentTypeCodeSpezielle Vorschriften laut IHE PCC====Der contentTypeCode des SubmissionSets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragenDas IHE Patient Care Coordination (PCC) Technical Framework vol. 2<ref name="IHEPCC"/> definiert in Kapitel "Medical Document Binding" Spezialbehandlungen für gewisse Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).
ClinicalDocument/languageCode/@code = "de-AT"
<pre class="ilfbox_code">
<RegistryPackageExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
</pre>
===uniqueIdlegalAuthenticator===Das ''uniqueIdlegalAuthenticator'' 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"). Für CDA R2 Dokumente gilt folgende Verknüpfung mit den global eindeutigen Identifier des Dokuments. Dieser Identifier CDA Header Elementen: #Laut Festlegung wird entweder vom Document Source Actor erzeugt oder die Person, welche das Dokument vidiert hat, im Fall eines evtlElement "legalAuthenticator" abgelegt:##ClinicalDocument/legalAuthenticator/assignedEntity{{BeginYellowBox}}'''ACHTUNG:''' Nach DocumentEntry. verwendeten Adapters vom Informationssystem des GDA legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommenwerden.uniqueId wird als ebRIM {{EndYellowBox}}
concat(<br />
<span> $person</span>/id/@extension,"^",<br />
<span> $person</span>/assignedPerson/name/family,"^",<br />
<span> $person</span>/assignedPerson/name/given[1],"^",<br />
<span> $person</span>/assignedPerson/name/given[2],"^",<br />
<span> $person</span>/assignedPerson/name/suffix,"^",<br />
<span> $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br />
<span> $person</span>/id/@root,"&amp;ISO"<br />
)<br />
<pre class="ilfbox_code">
<ExternalIdentifierExtrinsicObject mimeType="text/xml"registryObject objectType="urn:uuid:1e2ede827edca82f-054d-857047f2-4be2a032-bd469b2a5b5186c1" status="urn:oasis:names:tc:ebxml-de986a4333beregrep:StatusType:Approved"identificationScheme id="urn:uuid:2e82c1f61e2ede82-a0858570-4c724be2-9da3bd46-8640a32e42abde986a4333be">value <Slot name="$valuelegalAuthenticator"> <ValueList> <Value>1234^Musterdoktor^Herbert^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO<Name/Value> <LocalizedString value="XDSDocumentEntry.uniqueId"/ValueList> </NameSlot></ExternalIdentifierExtrinsicObject></pre>Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>. ===serviceStartTime / serviceStopTime===Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlung. Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung ("documentationOf/serviceEvent") verpflichtend, wenn bekannt '''''[R]'''''. Wenn vorhanden, beinhaltet dieses Element die semantisch korrekten Informationen zu Start- und Enddatum gemäß der jeweiligen Fachdomäne (z.B.: das Aufnahme/Entlassungsdatum im Falle von Entlassungsbriefen aus stationärer Behandlung). Die relevanten Informationen dazu finden sich in den speziellen ELGA CDA Implementierungsleitfäden.
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem ServiceEvent verpflichtend:##ClinicalDocument/documentationOf/serviceEvent#Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist ServiceEvent beinhaltet unter anderem die folgenden Unterelemente:##effectiveTime gibt das Zeitintervall an, in dem die Gesundheitsdienstleistung durchgeführt wurde##Laut Vorgabe der ELGA Gesundheitsdaten SOLL ein Zeitintervall (HL7 IVL_TS) in wie folgt angeordnet werden:###low … enthält das Startdatum###high … enthält das Endedatum###Andere im IHE_ITI_TF_Vol3 CDA möglichen Angaben (27 September 2013low/width, width/high, ...) Dokument neu hinzugekommen. sind nicht gestattet
{{BeginYellowBox}}
{{EndYellowBox}}
====Spezifikation====
'''serviceStopTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value = "20200516133000+0200"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStopTime">
<ValueList>
<Value>20200516113000</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Dieses Element '''MUSS''' – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein "Kürzen" auf andere Formate ist nicht zulässig.
#Im CDA wird die ID des Patienten in folgendem Element abgelegt:##ClinicalDocument/setIdrecordTarget/@extensionpatientRole/id#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wenn bekannt:##id[1] … ID des Patienten vom einbringenden (lokalen) System##id[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)<br /><span style="^^^color:red;", >Achtung: Diese ID gelangt nicht in die Metadaten!</span>
ClinicalDocument/recordTarget/patientRole/id[1]/@root,
)
<pre class="ilfbox_code">
<ClinicalDocument xmlnsExtrinsicObject mimeType="text/xml" objectType="urn:hl7uuid:7edca82f-054d-47f2-a032-org9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:v31e2ede82-8570-4be2-bd46-de986a4333be">… <setId rootSlot name="sourcePatientId"> <ValueList><Value>4711^^^&amp;1.2.403.04.345.996.1117.18.1" extension="ZZZZZZZZZZZZZZZZZZZ"9&amp;ISO</Value> <versionNumber value="2"/ValueList> … </Slot></ClinicalDocumentExtrinsicObject>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
{{BeginYellowBox}}
Ein spezieller Leitfaden kann eine abweichende Mapping-Vorschrift definieren!
{{EndYellowBox}}
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}
===intendedRecipienttypeCode (und typeCodeDisplayName)===Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der intendedRecipient notwendig. Derzeit wird dieses Das ''typeCode'' Element in ELGA nicht verwendetbeschreibt den Dokumententyp, dem das Dokument angehört. Sobald IHE XDW für ELGA zugelassen wirdDer Dokumententyp ist die Spezialisierung einer Dokumentenklasse, folgt die Spezifikation dieses Elementesjeder Dokumententyp gehört zu genau einer Dokumentenklasse.
<span> $code</span> = ClinicalDocument/code/@code<br />
<span> $displayName</span> = ClinicalDocument/code/@displayName<br />
<span> $codeSystem</span> = ClinicalDocument/code/@codeSystem<br />
<pre class="ilfbox_code">
<Name>
<LocalizedString value="$displayName"/>
</pre>
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)=submissionSet.contentTypeCode====Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung Der contentTypeCode des GDA.Es Submission Sets wird der Code aus dem CDA Header Element "healthCareFacility" genutztals ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
$code ====Spezifikation====ClinicalDocument/code/@code
<pre class="ilfbox_code">
<ClassificationRegistryPackage classificationSchemestatus="urn:uuidoasis:names:tc:f33fb8acebxml-18af-42cc-ae0e-ed0b0bdb91e1regrep:StatusType:Approved" classifiedObject<Classification classificationScheme="urn:uuid:f0573b34aa543740-ea9abdda-4c6d424e-85568c96-5cffbe50f027df4873be8500" id classifiedObject="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddftheDocument" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot> </Classification></RegistryPackage>
</pre>
===mimeTypeuniqueId===Das ''mimeTypeuniqueId'' Element beschreibt den „Internet Media Type“ global eindeutigen Identifier des Dokuments gemäß dem „Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard Dieser Identifier 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><ref name="RFC2046">Multipurpose Internet Mail Extensions (MIME) Part Part Two: Media Types [http://tools.ietf.org/html/rfc2046 IETF RFC 2046]</ref><ref name="RFC2047">Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text [http://tools.ietf.org/html/rfc2047 IETF RFC 2047]</ref><ref name="RFC2048">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [http://tools.ietf.org/html/rfc2048 IETF RFC 2048]</ref><ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref> Im entweder vom Document Source Actor erzeugt oder im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml"eines evtl. ====Spezifikation==== '''mimeType''' wird im Attribut @mimeType verwendeten Adapters vom Informationssystem des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert. Folgende Mime-Types sind für Dokumente zugelassen:<br/>CDA R2: '''text/xml'''<br/>DICOM/KOS: '''application/dicom'''<br/> <pre class="ilfbox_code"><ExtrinsicObject id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" mimeType="text/xml" objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/></pre> ===parentDocumentId, parentDocumentRelationship===Das ''parentDocumentId'' Element verweist auf das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation steht. Das ''parentDocumentRelationship'' Element beschreibt den Typ der Relation (Versionierung, Transformation). Da nicht alle lokalen und temporären Versionen eines Dokuments veröffentlicht werden müssen, können die tatsächlichen und technischen Dokumentenverweise in XDS nicht über die parentDocumentId erfasst werden, sondern über Association-ObjekteGDA übernommen.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA werden Laut Vorgabe der ELGA Gesundheitsdaten ist die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in Angabe einer bestimmten Relation stehen, in folgendem Element abgelegt:## ClinicalDocument/relatedDocument# Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:## ClinicalDocument/relatedDocument/@typeCode## Folgende Relationen sind in ELGA erlaubt (siehe „[[ILF:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden ID für ELGA CDA Dokumente]]“ [1]):### Versionierung (RPLC)# Das zugrundeliegende das Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegebenverpflichtend:## ClinicalDocument/relatedDocument/parentDocumentid
====Spezifikation====
$value = concat(ClinicalDocument/id/@root)
Fall 2<br />
Attribut ClinicalDocument/id/@extension ist vorhanden
$value = concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)
#eindeutige Identifikation aller Dokumente eines Dokumentenstammes, d.h. vorhergehende und auch zukünftige Versionen (ownDocument_setId, M [1..1])
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, O [0..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).
=====Spezifikation=====ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
(
ClinicalDocument/setId/@extension, "^^^", "&amp;",
Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise "&", OID-Wert, "&ISO" anzugeben sind.
Beispiel 1: setId/@root und setId/@extension sind im CDA strukturiert. In /@extension wird KEINE UUID angegeben.
<!--Anhänge-pre class="ilfbox_code"><ClinicalDocument xmlns="urn:hl7-org:v3">…<setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZZZZZ"/><versionNumber value="2"/> …</ClinicalDocument></pre>
Wie oben angeführt wird folgender CXi Wert erstellt:<pre class=Anhänge"ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" status=Referenzen"<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id=={||"<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">|[1]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2 <Slot name="<nowiki>urn:ihe:iti:xds:2013: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente. |-referenceIdList</nowiki>">| ||ELGA CDA Implementierungsleitfäden (2.06) [OID <ValueList> <Value>ZZZZZZZZZZZZZZZZZZZ^^^&amp;1.2.40.0.34.799.111.1.6], http1 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId<//wwwnowiki> ^&amp;1.2.40.0.34.elga99.gv999&amp;ISO</Value> </ValueList> </Slot> </ExtrinsicObject></pre> Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.at
==Revisionsliste=={| class="wikitable"Spezifikation=====!Vers.!Datum!Änderungsgrund|Für Befunde der bildgebenden Diagnostik (diagnostic image report) KANN als Accession Number jene aus der ReferenceIdList der XDS-|0I Metadaten des KOS Objektes, mit dem eine Verlinkung hergestellt werden soll, genutzt werden. Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).05|16Accession Number wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: $id = Accession Number z.05B.201120201111|Ergebnisse aus dem technischen Online-Meeting|-|2$root = OID des lokalen Namensraums der ID, z.00 Beta|12B.08.2011|Erster „Release candidate“ des Dokuments für internen Review innerhalb der Arbeitsgruppe1.|-|2.00 rc1|3040.080.2011|Redaktionelle Überarbeitung34.99.111.|-|2.00 FWGD1|10.10.2011|Fertigstellung des „Final Working Group Draft“. Veröffentlicht für öffentlichen Review.concat|-|2.01(|11.06.2012|Fertigstellung der gültigen Version 2.01 „Final“. <br />Abgrenzung des Geltungsbereiches (XDSDocumentEntry)$id, Überarbeitung „PracticeSettingCode“"^^^", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der „parentDocumentRelationship“, Typos ausgebessert"&amp;"|-|2.01$root, "&amp;ISO", "^",|21.12.2012|Layout-Anpassung|-|2.01a|07.03-"<nowiki>urn:ihe:iti:xds:2013|Zeile: 5: accession</nowiki>"und )<pre class=" eingefügt; 14: ilfbox_code"diesem> <ExtrinsicObject mimeType=" eingefügt; 16: text/xml"dieses Dokuments“ eingefügt; 363 objectType="<nowiki>urn: displayNameOf($code), „Of“ gelöscht; 364uuid: "aus" eingefügt; 814 und 818: ELGA7edca82f-054d-Interoperabilitätslevel 47f2-> Interoperabilitätsstufe (auch „2“a032-> „Enhanced“ etc.) 9b2a5b5186c1<br /nowiki>Tabelle ab 357: classcode" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</typeCode nowiki>"Spalte id=" eingefügt und erste Zeile eingefügt <br /nowiki>Allgemeinurn:uuid: Typos ausgebessert|1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">|2.02|12.08. <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">|2.3 <ValueList> <Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.|-|240.02|120.0834.2013|299.3.2.3 PDF999<nowiki>&</A-1a-Vorschrift hinzugefügt|-nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>|2.02 </ValueList>|13.08.2013 </Slot>|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF </ExtrinsicObject></A-1a-|-|2pre>Siehe auch IHE RAD TF3 4.02|1768.094.1.2013|Typos, Formatierung und Seitenumbrüche ausgebessert|-|2.02a|064.02.20141 "Linking Report to Set of DICOM Instances"|Beispiele in Tabelle 3 korrigiert<br />|-|2.03|26.02.2014|Definition von ReferenceIdList eingefügt====Verlinkung via Aufenthaltszahl (encounterId)====Durch encounterId wird die Verlinkung sämtlicher Befunde oder Bilddaten (siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#referenceIdList|referenceIdList]] für Dicom KOS-|2Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-Metadaten unterstützt.03|03.03Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-/XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.2014|Definition von intendedRecipient eingefügt|-|2.03|03.03.2014|Änderungen in Tabelle 3: <<br /> LegalAuthenticator – von [R] auf [R2] geändert<br =====Spezifikation=====encounterId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: concat ( ClinicalDocument/componentOf/encompassingEncounter/id/> IntendedRecipient – von @extension, "-^^^" auf [O] geändert, für Verwendung mit XDW vorgesehen<br "&amp;", ClinicalDocument/componentOf/encompassingEncounter/> ReferenceIdList hinzugefügt<br id/> Den Namen des Value Sets von „ELGA-PracticeSettingCode“ auf „ELGA-PracticeSettingCode-vs“ geändert@root, "&amp;ISO", "^", |-|2.03.|03.03.2014|Anhang gelöscht"<nowiki>urn:ihe:iti:xds:2015: encounterId<br /nowiki> 3.1. IHE ITI-TF3" ) Bitte beachten Sie, Kapitel 4.1.7 „Document Definition Metadata“<br dass die ClinicalDocument/componentOf/encompassingEncounter/id/> 3.2. IHE PCC@root in der Schreibweise "&", OID-TF2Wert, Kapitel 4"&ISO" anzugeben ist.1.1 „XDSDocumentEntry Metadata“ Wie oben angeführt wird folgender CXi Wert erstellt:<br /pre class="ilfbox_code"> 3.3. IHE XDS Data Types| <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"|2.03|03.03.2014 status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"|Korrekturen id="<nowiki>urn:uuid: 1e2ede82-8570-4be2-bd46-de986a4333be<br /nowiki> ITI Version einheitlich geändert auf “(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09."> <Slot name="<nowiki>urn:ihe:iti:xds:2013)“.:referenceIdList<br /nowiki> 1.1.3 Hinweis auf Terminologieserver hinzugefügt<br /"> Tabelle 3 angepasst: <br /ValueList> EntryUUID Beschreibung geändert <br /Value> patientId Beschreibung geändert|-|Az123456^^^&amp;1.2.03|0640.0.34.99.4613.033.2014|Eigene URN für die ReferenceId eingefügt: 4&amp;ISO^<nowiki>urn:elgaihe:iti:xds:20142015:ownDocument_setIdencounterId</nowiki>|- </Value>|2.03 </ValueList>|21.03.2014 </Slot>|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt </ExtrinsicObject>|-</pre> |2.03|26.03.2014|Kapitel 1.4. Korrektur von Dokumentverweisen|-<br />|2.03a|28.03.2014===intendedRecipient===|Kapitel 2.1 Korrektur Für die spätere Verwendung von Fußnotennummern|-|2IHE Cross Enterprise Document Workflow (XDW) ist der intendedRecipient notwendig.03a|28Derzeit wird dieses Element in ELGA nicht verwendet.03Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.2014|Kapitel 2Der intendedRecipient entfällt bei On-Demand Documents. ==XDS Metadaten 2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000: explizit zu setzen (ELGA relevant)=====availabilityStatus===|Das availabilityStatus-|2Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments.03b|1.7.2014|Den Namen des Value Sets von „ELGA-PracticeSetting Code-vs“ auf „ELGA_Practicesetting_VS“ korrigiertMögliche Werte laut IHE sind: |-*Approved|2.03b*Deprecated|11.07.2014|2.3Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten ("Submission") durch die empfangende XDS Registry immer auf "'''Approved'''" gesetzt.2 availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.5 OID in der Spezifikation ergänzt|-|2.03b<pre class="ilfbox_code">|11.07.2014<ExtrinsicObject mimeType="text/xml"|2.3.6 OID in der Spezifikation ergänzt| objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"|2.03b|05.08.2014|2.3.2.2 FormatCode status="urn:oasis:names:tc: Angabe des Codesystems ELGA_FormatCode präzisiert|ebxml-regrep:StatusType:Approved"|2.03b id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/></pre>|06.08.2014|2.1 Überblickstabelle: ParentDocumentId ===formatCode (und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]formatCodeDisplayName)===|-|2Das ''formatCode'' Element beschreibt das Format des Dokuments bezüglich seiner semantischen Interoperabilität.03b|06.08Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments.2014|Referenzen auf Im CDA Implementierungsleitfäden aktualisiert|-| colspan=Schema wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "3hl7at:formatCode" |Version 2.05|-|2.05====Spezifikation====|03.11.2014|EntryUUID als „ELGA-Relevant“ klassifiziert.'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br /> Darstellung der Übersichtstabelle geändert|-|2.05|03.11.2014<span>$code</span> = ClinicalDocument/hl7at:formatCode/@code <br />|2.2.15 TypeCode<span>$displayName</span> = ClinicalDocument/hl7at: ClassificationScheme im Beispiel korrigiert von "formatCode/@displayName <br /><span>$codeSystem</span> = ClinicalDocument/hl7at:formatCode/@codeSystem<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:41a5887fa09d5840-8865386c-4c0946f2-adf7b5ad-e362475b143a9c3699a4309d" (falsch) auf classifiedObject="urn:uuid:f0306f51f0573b34-975fea9a-434e4c6d-a61c8556-c59651d339835cffbe50f027" (richtig)| id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"|2.05 nodeRepresentation="$code">|19.11.2014 <Name>|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht <LocalizedString value="$displayName"/>|- </Name>|2.05 <Slot name="codingScheme">|19.11.2014 <ValueList>|2.2.2. authorPerson <Value>urn:oid: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.$codeSystem</Value>|- </ValueList> </Slot></Classification>|2.05</pre>|19.11.2014|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===|-|2Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA.05|19.11Es wird der Code aus dem CDA Header Element "healthCareFacility" genutzt.2014|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software|-====Spezifikation==== |2.05'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:|24.11.2014|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]<span>$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code <span>$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName|-|2.05<span>$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem |26.11.2014<pre class="ilfbox_code"><Classification|2.4 ELGA-spezifische Erweiterungen hinzugeügt classificationScheme="urn: ELGAuuid:f33fb8ac-18af-42cc-Hash und ELGAae0e-Flag. Auch in 2.1 entsprechend angegeben.ed0b0bdb91e1"| classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"|2.05|12.03.2014|Seite 2 id="urn:uuid:63134a8d-9d4c-4fe0-3: Absätze „Verbindlichkeit“, „Hinweise zur Verwendung“ und „Erarbeitung des Implementierungsleitfadens“ hinzugefügt.|ad9b-9198b6deeddf"| colspan nodeRepresentation="3$code" |Version 2.06>|- <Name>|2.06 <LocalizedString value="$displayName"/>|19.05.2015 </Name>|1.2.2. Codesysteme und <Slot name="codingScheme"> <ValueList> <Value Sets>urn:oid: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.$codeSystem</Value>|- </ValueList>|2.06 </Slot>|13.10.2015</Classification>|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch|-</pre>|2.06|13.10.2015===mimeType===|1Das ''mimeType'' Element beschreibt den "Internet Media Type" des Dokuments gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommenDer Standard wird beschrieben in RFC 2045 bis RFC 2049.<ref name="RFC2045"/>|-|2<ref name="RFC2046">Multipurpose Internet Mail Extensions (MIME) Part Part Two: Media Types [http://tools.06|07ietf.10.2015org/html/rfc2046 IETF RFC 2046]</ref>|1.4.3. Kapitel „Metadaten aus „On-Demand Documents“ <ref name="RFC2047">Multipurpose Internet Mail Extensions (ODDMIME)“ eingefügt|Part Three: Message Header Extensions for Non-|2ASCII Text [http://tools.06|10ietf.09.2015org/html/rfc2047 IETF RFC 2047]</ref>|2.1 Tabelle 3<ref name="RFC2048">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [http: Beschreibung der entryUUID ergänzt|-|2//tools.06|07ietf.10.2015org/html/rfc2048 IETF RFC 2048]</ref><ref name="RFC2049"/> |2.1 Tabelle 3: Spalte „Optionalität IHE“ gelöscht, Spalte zur Definition Im Fall von On-Demand-Documents eingefügtCDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml". objectType hinzugefügt patientid als E1 „ELGA relevant“ deklariert (war E2)|-|2.06====Spezifikation====|30.10.2015|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt '''mimeType''' wirdim Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, falls mehrere ID-Elemente angegeben sindwelches das DocumentEntry repräsentiert.|Folgende Mime-Types sind für Dokumente zugelassen:<br />|2.06|19.05.2015CDA R2: '''text/xml'''<br />|2.2.5. und 2.2.15<pre class="ilfbox_code"><ExtrinsicObject id="urn:uuid: Typos verbessert|f0573b34-ea9a-4c6d-8556-5cffbe50f027"|2.06 mimeType="text/xml"|29.10.2015|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt| objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"|2.06 status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/></pre>|21.07.2015|2.2.10. legalAuthenticator: Hinweis===parentDocumentId, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar istparentDocumentRelationship===Das ''parentDocumentId'' Element verweist auf das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation steht.|-|2.06|08.10Das ''parentDocumentRelationship'' Element beschreibt den Typ der Relation (Versionierung, Transformation).2015|2.3.7 objectType hinzugefügt|-| colspan="3" |'''Version 2.06Da nicht alle lokalen und temporären Versionen eines Dokuments veröffentlicht werden müssen, können die tatsächlichen und technischen Dokumentenverweise in XDS nicht über die parentDocumentId erfasst werden, sondern über Association-Objekte.2 (Nebenversion)'''<br /> x …betrifft Implementierung (erste Spalte)|-||01.08.2016|Kapitel VerbindlichkeitIm Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen: Definition der Angabe verbindlicher Vorgaben.|-||18.5.2016#Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.##ClinicalDocument/relatedDocument|-#Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:|##ClinicalDocument/relatedDocument/@typeCode##Folgende Relationen sind in ELGA erlaubt (siehe "[[ILF:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]" [01.08.2016|2.1. Tabelle 3]): Korrektur ###Versionierung (RPLC)#Das zugrundeliegende Dokument (auf welches die Art der Optionalität von eventCodeList auf [R2]Relation wirkt), wie im Text bei 2.2.8 wird in folgendem Element angegeben:|-##ClinicalDocument/relatedDocument/parentDocument|x|14.6.2016====Spezifikation==== |creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie '''parentDocumentId''' MUSS immer entsprechen der Angabe mit folgenden Elementen in CDA entweder 8 oder 14-stellig angegeben werden.übereinstimmen:|-|concat(|03.08.2016|2.2.5ClinicalDocument/relatedDocument/parentDocument/id/@root, 2.3.2.2"^", 2.3.2.5, 2.3.5, 2.3.5ClinicalDocument/relatedDocument/parentDocument/id/@extension) '''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen: ClinicalDocument/relatedDocument/@typeCode ===practiceSettingCode (und practiceSettingCodeDisplayName)===Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Dokumentes.1Es SOLL den Fachbereich wiedergeben, 2.3.5.1dem der Inhalt des Dokuments am besten entspricht, 2unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung.1 Im CDA-Schema wurde für die HL7-Austria Domäne ein entsprechendes Element in den CDAs geschaffen, 1"hl7at:practiceSettingCode".4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben|-||05.01.2017====Spezifikation==== '''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt: <span>$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br />|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.<span>$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br />|-||y<span>$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br />|Korrektur der Strukturierung von <pre class="&ilfbox_code" innerhalb der XML Beispiel-Snippets zu ><Classification classificationScheme="&amp;urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"| classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"||y|Kapitel 4.2.14 "referenceIdList" id="urn:uuid: Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId|63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"| nodeRepresentation="$code">|y <Name>|Kapitel 4.1 <LocalizedString value="Überblickstabelle der XDS Metadaten$displayName": Optionalitäten von /> </Name> <Slot name="parentDocumentIdcodingScheme" und "parentDocumentRelationship" zu O angepasst.>|- <ValueList>| <Value>urn:oid:$codeSystem</Value>|y </ValueList>|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt. </Slot>|-</Classification>|</pre>||Kapitel 4.1 ===objectType===Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "Überblickstabelle der XDS Metadatenstabiles Dokument": Optionalität von (stable document, SD) und "sourcePatientInfoOn-demand Dokument" zu X angepasst(on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.|-|Für "Stable Document" DocumentEntry:||Kapitel <pre class="ilfbox_code"4.2.10 sourcePatientInfo><ExtrinsicObject mimeType="text/xml" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich|-| objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"| status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"|Kapitel id="4.2.7 legalAuthenticatorurn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.>|-</pre>|||Kapitel Für "4.2.4 creationTimeOn-Demand Document"DocumentEntry: Bedeutung von ClinicalDocument.effectiveTime präzisiert|-<pre class="ilfbox_code">|<ExtrinsicObject mimeType="text/xml"|y|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName) objectType="urn:uuid: Ableitungsvorschrift aus dem CDA34268e47-fdf5-41a6-ba33-Header Element 82133c465248"healthCareFacility status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" hinzugefügt.| id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>|</pre>|y|Kapitel "4.3.2 formatCode (==ELGA-spezifische Erweiterungen der XDS-Metadaten==Die folgenden Daten erweitern den IHE-Standard und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDAwerden vom ELGA-Header Element "hl7at:formatCode" hinzugefügtBerechtigungssteuerungssystem automatisch gesetzt.|-|===elgaFlag===||Kapitel Das elgaFlag dient zur Kennzeichnung eines Dokuments als "ELGA-Dokument"4.2<sup>18</sup>.2.1 Spezifikation": Ableitungsvorschrift aus dem CDAEin XDS Source des ELGA-Header Element "ClinicalDocument/code/translationBereiches sendet eine " für XDS DocumentEntry.classCode hinzugefügtb 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*"false"<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 auftreten, die NICHT für ELGA vorgesehen sind.====Spezifikation==== <pre class="ilfbox_code"><Slot name="urn:elga-bes:elgaFlag"> <ValueList> <Value>true</Value> </ValueList></Slot></pre> ===elgaHash===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.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "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-Hash" gespeichert. Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist. ====Spezifikation====<pre class="ilfbox_code"> <rim:Slot name="urn:elga-bes:elgaHash"> <rim:ValueList> <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value> </rim:ValueList> </rim:Slot></pre> <!--Anhänge--> =Anhänge= ==Einzelnachweise==<references />==Literatur und Weblinks ==* IHE International https://www.ihe.net/* HL7® International http://www.hl7.org/* Clinical Document Architcture (CDA®) Release 2.0 https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7* DICOM® — Digital Imaging and Communications in Medicine https://www.dicomstandard.org/* Österreichische CDA Implementierungsleitfäden [https://wiki.hl7.at/index.php?title=Implementierungsleitf%C3%A4den HL7 Austria Wiki] ==Revisionsliste== ===Hauptversion 3.0.0 (2021)===Diese Hauptversion wurde auf Basis der neuen Vorgaben aus dem Allgemeinen Implementierungsleitfaden 3.0.0 grundlegend überarbeitet und umstrukturiert. Hinzugekommen sind die Vorgaben für die Registrierung von DICOM KOS-Objekten. Auf eine Revisionsliste mit direktem Vergleich zur Vorversion wurde daher verzichtet. Die relevanten Änderungen sind:{| class="wikitable"|-|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"|-|"referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId|-|"Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.|-|"Spezifikation": Verbot von CR und LF hinzugefügt.|-|"Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.|-|"sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich|-|"legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.|-|"creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert|-|"healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.|-|"formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.|-|"Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.|-|"XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.|-|"referenceIdList": Ergänzung der Verwendung der encounterId
|}
===Hauptversion 2.06===
Eine Liste vorherigen Revisionen findet sich auf der '''[[ILF_Diskussion:XDS_Metadaten_(Version_3)|Diskussionsseite]]'''.
==Erratum==
Weitere Probleme und allfällige Korrekturen werden auf der [[ILF_Diskussion:XDS_Metadaten_(Version_3)|Diskussionsseite]] im Wiki gesammelt.
