ELGA XDS-Metadaten für CDA-Dokumente - ELGA GmbH

ELGA CDAImplementierungsleitfädenRegistrierung von CDA Dokumenten fürELGA mit IHE Cross-EnterpriseDocument Sharing:XDS Metadaten (XDSDocumentEntry)[1.2.40.0.34.7.6.1]Datum: 12.04.2013Version: 2.01a

DokumenteninformationenIntention und Abgrenzung5Dieses Dokument beschreibt den dokumentspezifischen Teil der Metadaten für dieRegistrierung von CDA-Dokumenten über IHE XDS in ELGA unter dem Aspekt derAbleitung von XDS Metadaten aus CDA Dokumenten und der Etablierung von einheitlichenVokabularen.Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) sind nicht Teil dieser Spezifikation.10StatusDieses Dokument wurde von der offenen Arbeitsgruppe „ELGA CDA Entlassungsbrief“ undeiner „Technischen Untergruppe“ im Konsens erarbeitet. Von Oktober bis Dezember 2011folgte eine öffentliche Kommentierungsphase.15Anregungen für die Weiterentwicklung dieses Dokuments und Kommentare zu diesemkönnen an office@elga.gv.at gesendet werden. Weitere Informationen dazu finden sie Sieunter www.elga.gv.at, wo auch die Value Sets und die jeweils aktuelle Fassung derSpezifikationen sowie weiterführende Informationen verfügbar sind.RevisionslisteDie Revisionsliste ersehen Sie im Anhang 3.5, „Revisionsliste“.20Kürzel Organisation Person (ohne Titel)Herausgeber, ProjektleiterSSA ELGA GmbH Stefan SabutschAutor, Fachkoordinator und ModeratorJB CodeWerk Software Services and Development GmbH Jürgen BrandstätterELGA XDS Metadaten.docx 2/64

InhaltsverzeichnisDokumenteninformationen 2Inhaltsverzeichnis 325301. Einleitung 51.1. Gegenstand dieses Dokuments 51.2. Hinweise zur Verwendung des Dokuments 61.2.1. Farbliche Hervorhebungen 61.2.2. Codesysteme und Value-Sets 61.2.3. OID 61.3. Allgemeines zu XDS-Metadaten 71.3.1. Metadaten aus unstrukturierten Dokumenten 71.3.2. Metadaten aus strukturierten Dokumenten (CDA) 81.3.3. XDS Metadaten im Vergleich IHE/ELGA 835404550552. XDS Metadaten für CDA Dokumente 92.1. Überblickstabelle 92.2. XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet 122.2.1. authorInstitution 122.2.2. authorPerson 142.2.3. authorRole 152.2.4. authorSpeciality 162.2.5. classCode (und classCodeDisplayName) 172.2.6. confidentialityCode 192.2.7. creationTime 202.2.8. eventCodeList (und eventCodeListDisplayName) 212.2.9. languageCode 232.2.10. legalAuthenticator 242.2.11. serviceStartTime / serviceStopTime 252.2.12. sourcePatientId 272.2.13. sourcePatientInfo 282.2.14. title 302.2.15. typeCode (und typeCodeDisplayName) 312.2.16. uniqueId 332.3. XDS Metadaten 2: Explizit zu setzen (ELGA relevant) 342.3.1. availabilityStatus 34ELGA XDS Metadaten.docx 3/64

602.3.2. formatCode (und formatCodeDisplayName) 342.3.3. healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName) 372.3.4. mimeType 382.3.5. parentDocumentId, parentDocumentRelationship 392.3.6. practiceSettingCode (und practiceSettingCodeDisplayName) 40653. Anhänge 413.1. IHE ITI-TF3, Kapitel 4.1.7 „Document Definition Metadata“ 413.2. IHE PCC-TF2, Kapitel 4.1.1 „XDSDocumentEntry Metadata“ 543.3. IHE XDS Data Types 603.4. Tabellenverzeichnis 633.5. Revisionsliste 63ELGA XDS Metadaten.docx 4/64

1. Einleitung70751.1. Gegenstand dieses DokumentsDieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten 1 in dieösterreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing(XDS) 2 . Die hier definierten Regeln sind von den folgenden „Technical Frameworks“ der IHEabgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfädenabgestimmt:• Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alleDokumentarten (Metadaten der XDSDocumentEntry Objekte)• IT Infrastructure (ITI), Volume 3• Darüber hinaus gehende Spezifikation speziell für CDA Dokumente80• Patient Care Coordination (PCC), Volume 2Ausgehend von obiger Basis definiert das vorliegende Dokument die genaue Spezifikationder Befüllung der XDS Metadaten speziell für die Anwendung im Rahmen derösterreichischen Gesundheitsakte ELGA.85Die vorliegende Spezifikation wurde im Zusammenhang mit den „ELGA CDAImplementierungsleitfäden“ erstellt. Zum Zeitpunkt der Erstellung liegen folgendeImplementierungsleitfäden vor:• ELGA CDA Implementierungsleitfäden (HL7 Implementation Guide for CDA® R2):• „Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente“,OID 1.2.40.0.34.7.1.190• „Entlassungsbrief (Ärztlich)“, OID 1.2.40.0.34.7.1.2• Entlassungsbrief (Pflege), OID 1.2.40.0.34.7.1.3• Laborbefund, OID 1.2.40.0.34.7.1.4• Befund bildgebende Diagnostik, OID 1.2.40.0.34.7.1.5951 HL7 Clinical Document Architecture, Release 2.0 (www.hl7.org)2 IHE IT Infrastructure Technical Framework (http://www.ihe.net)ELGA XDS Metadaten.docx 5/64

1.2. Hinweise zur Verwendung des Dokuments1.2.1. Farbliche HervorhebungenThemenbezogene Hinweise zur besonderen Beachtung:100authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):105$inst … ClinicalDocument/author/assignedAuthor/representedOrganizationVerweis auf ELGA Value-Set:Zulässige Werte gemäß Value-Set „ELGA_FormatCode“.1101.2.2. Codesysteme und Value-SetsDie in diesem Dokument erwähnten Codesysteme bzw. Value-Sets werden auf der Websiteder ELGA GmbH (www.elga.gv.at) veröffentlicht.1.2.3. OID115In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OIDsind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen fürInformationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung undRegistrierung von OID sind im „OID-Portal für das Österreichische Gesundheitswesen“publiziert (https://www.gesundheit.gv.at/OID_Frontend/).120ELGA XDS Metadaten.docx 6/64

1.3. Allgemeines zu XDS-Metadaten125Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumenteentsprechend klassifiziert und beschrieben werden. Diese beschreibenden „Metadaten“werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repositorymitgegeben. 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 Systembeinhalten Informationen130• über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung desDokumenteninhalts zu ermöglichen• über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen einesDokuments)• über den Speicherort des Dokuments• über den GDA, welcher das Dokument erstellt hat135• über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werdenmüssen, ist im IHE „IT-Infrastructure“ (ITI) Technical Framework, Volume 3 festgelegt (IHEITI-TF3).140145Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die dasDokument einbringt. Die Metadaten sind die ausschließliche Grundlage für das Suchenund Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGAVerweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit denMetadaten eine notwendige Voraussetzung.Hinweis: Sehen Sie im Anhang 3.1 dieses Dokuments den Original-Auszug der Vorschrift zurBefüllung der Dokument-Metadaten aus Dokumenten des IHE „IT Infrastructure“ (ITI)Technical Frameworks Version 7.0, Volume 3.1.3.1. Metadaten aus unstrukturierten Dokumenten150Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nichtautomatisiert aus dem Dokument entnommen werden und müssen daher von dererstellenden Anwendung mitgegeben werden. Es entsteht dadurch ein zusätzlicher Aufwandinsbesondere hinsichtlich der Qualität der Daten. Die Metadaten müssen das beiliegendeDokument korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregisterverfälscht werden.ELGA XDS Metadaten.docx 7/64

1.3.2. Metadaten aus strukturierten Dokumenten (CDA)155160Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beimEinbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zuentnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oderermittelt werden muss.Die IHE hat im Rahmen des „Patient Care Coordination“ (PCC) Technical Frameworks einegenaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadatenentnommen werden sollen.Die genaue Beschreibung der einzelnen XDS Metadaten Bindings sind im PCC TechnicalFramework, Volume 2 [IHE PCC-TF2], Kapitel 4.1.1 XDSDocumentEntry Metadatabeschrieben.165Hinweis: Sehen Sie im Anhang 3.2 dieses Dokuments den Original-Auszug der Vorschrift zurBefüllung der Dokument-Metadaten aus CDA Dokumenten des IHE „Patient CareCoordination“ (PCC) Technical Frameworks Version 6.0, Volume 2.1.3.3. XDS Metadaten im Vergleich IHE/ELGA170Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten vonElementen unterteilen:• Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS DocumentRepository)• Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS DocumentRegistry)175• Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiertwerden können• Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)• ELGA relevante• Nicht ELGA relevante180Dieses Dokument behandelt nur XDS Metadaten Elemente der rot markierten Kategorien.ELGA XDS Metadaten.docx 8/64

2. XDS Metadaten für CDA Dokumente2.1. Überblickstabelle185Die folgende Tabelle gibt einen Überblick über alle XDS Metadaten Elemente. Die Spaltenzeigen jeweils den Namen des Metadaten Elements, dessen Optionalität in IHE bzw. ELGAfür das Einbringen von Dokumenten, sowie die Quelle aus der die Informationen stammen.Tabelle 1: Legende zur Spalte „Quelle“ der folgenden TabelleCodeCE1E2ABedeutungAus CDA-Inhalt abgeleitet (direkt oder indirekt)Explizit gesetzt (ELGA relevant)Explizit gesetzt (nicht ELGA relevant)Von Registry oder Repository automatisch gesetzt190Tabelle 2: Legende zur Spalte „Optionalität“ der folgenden Tabelle (IHE Optionalitäten)CodeRR2OBedeutungVerpflichtend („Required”)Verpflichtend wenn bekannt („Required if Known“)OptionalELGA XDS Metadaten.docx 9/64

Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)Metadaten Element Optionalität Beschreibung Que-IHE ELGAlleAus dem CDA-Inhalt ableitbare MetadatenR2 R Die Person, welche das -author (besteht aus den folgendenDokument verfasst hatUnterkomponenten)authorInstitution R2 R ID der Organisation der die CPerson angehört.(OID aus dem GDA-Index)authorPerson R2 R Daten der Person.C(Name, ID, etc.)authorRole R2 R2 Rolle der Person CauthorSpeciality R2 R2 Funktionscode der Person CclassCodeR R Dokumentenklasse (Oberklasse) Cz.B.: 11490-0,„Entlassungsbrief aus stationärerBehandlung (Arzt)“confidentialityCodeR R Vertraulichkeitscode des CDokumentscreationTimeR R Zeitpunkt der CDokumentenerstellungeventCodeListO O Liste von CGesundheitsdienstleistungen3intendedRecipientO - Wird in XDS nicht verwendet ClanguageCodeR R Sprachcode des Dokuments Cz.B.: "de-AT"legalAuthenticatorO R Rechtlicher Unterzeichner des CDokumentsserviceStartTimeR2 R2 Beginn-Datum der CGesundheitsdienstleistungz.B.: Datum der AufnahmeserviceStopTimeR2 R2 Ende-Datum der CGesundheitsdienstleistungz.B.: Datum der EntlassungsourcePatientIdR R Patienten ID im CInformationssystem des GDA.z.B.: im KIS des KHsourcePatientInfoR R Demographische Daten des CPatienten im Informationssystemdes GDA.z.B.: im KIS des KHTitleO R Titel des Dokuments CtypeCodeR R Dokumententyp (Unterklasse) Ccodierter WertuniqueIdR R Global eindeutige ID des CDokuments3 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.ELGA XDS Metadaten.docx 10/64

195availabilityStatusformatCodehealthcareFacilityTypeCodemimeTypeparentDocumentIdparentDocumentRelationshippracticeSettingCodecommentsentryUUIDpatientIdExplizit zu setzende Metadaten (ELGA relevant)R R Gültigkeit des Dokuments E1R R Format des Dokumenteninhalts E1R R Klassifizierung des GDA E1R R Mime Type des Dokumentsz.B.: „text/xml“ für CDAR 4 R 2 Identifikation eines referenziertenDokumentsR 5 R 3 Typ der Relation zu demreferenzierten Dokument.z.B.: RPLC, XFRMR R Fachliche Zuordnung desDokumentsExplizit zu setzende Metadaten (nicht ELGA relevant)O O Kommentar zum Dokument E2R R Global eindeutiger Identifier desDokumentsR R Globale Patienten ID in der XDSAffinity DomainVon Registry oder Repository automatisch befüllte MetadatenhashR R Hash Wert des Dokuments. Wird Avom Repository befüllt.homeCommunityIdR R Gemäß ITI XCA: Eine eindeutige AIdentifikation (OID) für eine„Community“, die in weitererFolge dazu verwendet wird, denentsprechenden WebServiceEndpoint (URI des/der XCAResponding Gateway(s)) zuerhalten.repositoryUniqueIdR R Die eindeutige Identifikation (OID) Ades Document Repositories, inwelchem das Dokument abgelegtist. Wird vom Repository befüllt.sizeR R Größe des Dokuments in Bytes. AWird vom Repository befüllt.6URIO - Wird in XDS nicht verwendet AE1E1E1E1E2E24 Muss vorhanden sein, wenn eine „parentDocumentRelationship“ existiert.5 Muss gemeinsam mit einer „parentDocumentId“ angegeben sein.6 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.ELGA XDS Metadaten.docx 11/64

2.2. XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet2.2.1. authorInstitution200Das authorInstitution Element beschreibt die Organisation (GDA), in dessenGültigkeitsbereich das Dokument erstellt wurde.Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:2051. Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autordes Dokuments angehört grundsätzlich in folgendem Element abgelegt:a. ClinicalDocument/author/assignedAuthor/representedOrganization2. Ein Organisationselement in CDA beinhaltet unter anderem die folgendenUnterelemente:a. id … ID der Organisation mit den folgenden Attributen:210i. @root … Root OID des ID Pools, oder direkte die OID derOrganisation (ohne @extension-Attribut)ii. @extension … Eigentliche ID des Elements aus dem gegebenen IDPool (falls die @root nicht direkt die Organisation identifiziert)b. name … Name der Organisation als String2153. GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitensder Basiskomponente „GDA Index“ mit einer eindeutigen OID ausgestattet.2.2.1.1. SpezifikationauthorInstitution wird gemäß folgender Vorschrift zusammengesetzt:220$inst … ClinicalDocument/author/assignedAuthor/representedOrganizationFall 1225Element $inst/id ist nicht vorhandenconcat($inst/name)Bsp: Unfallkrankenhaus NeusiedlELGA XDS Metadaten.docx 12/64

Fall 2230Element $inst/id ist vorhandenAttribut &inst/id/@root ist vorhandenAttribut &inst/id/@extension ist nicht vorhanden235concat($inst/name,"^^^^^^^^^",$inst/id/@root)Bsp: Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45240Fall 3Element $inst/id ist vorhandenAttribut &inst/id/@root ist vorhandenAttribut &inst/id/@extension ist vorhanden245concat($inst/name,"^^^^^&",$inst/id/@root,"&ISO^^^^"$inst/id/@extension)Bsp: Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^45250Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß [IHE ITI-TF3].ELGA XDS Metadaten.docx 13/64

2.2.2. authorPerson255Das authorPerson Element beschreibt die Identifikation und demographische Informationender Person, welche das Dokument erstellt hat.Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:2601. Laut Festlegung wird die Person, welche das Dokument inhaltlich erstellt hat (alsonicht die Schreibkraft), als Autor bezeichnet und im Element „author“ abgelegt:a. ClinicalDocument/author/assignedAuthor2. Der Autora. Ein Personenelement in CDA beinhaltet unter anderem die folgendenUnterelemente:i. id … ID der Person mit den folgenden Attributen:2651. @root … Root OID des ID Pools, oder direkte die OID derPerson (ohne @extension-Attribut)2. @extension … Eigentliche ID des Elements aus demgegebenen ID Pool (falls die @root nicht direkt die Personidentifiziert)270ii. assignedPerson1. Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthälta. name2.2.2.1. Spezifikation275authorPerson wird gemäß folgender Vorschrift zusammengesetzt:$person = ClinicalDocument/author/assignedAuthor280285concat($person/id/@extension,"^",$person/assignedPerson/name/family,"^",$person/assignedPerson/name/given[1],"^",$person/assignedPerson/name/given[2],"^",$person/assignedPerson/name/suffix,"^",$person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&",$person/id/@root,"&ISO")Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&1.2.3.4.5.6.7.8.9&ISODies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].ELGA XDS Metadaten.docx 14/64

2902.2.3. authorRoleDas authorRole Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zumZeitpunkt der Dokumentation innehatte.Beispiel:• „Diensthabender Oberarzt“295300• „Verantwortlicher diensthabender Arzt für die Dokumenterstellung“Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Laut Festlegung wird die „Rolle“ der Person, welche das Dokument inhaltlich erstellt hatim Element functionCode des Autors abgelegt:a. ClinicalDocument/author/functionCode2. Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wennvorhanden [R2].3. Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayNameerwartet.3052.2.3.1. SpezifikationauthorRole wird gemäß folgender Vorschrift zusammengesetzt:ClinicalDocument/author/functionCode/@displayNameBsp: Diensthabender Oberarzt310ELGA XDS Metadaten.docx 15/64

2.2.4. authorSpecialityDas authorSpeciality Element beschreibt die Fachrichtung der Person, welche dasDokument verfasst hat.Beispiel:315• „Facharzt für Gynäkologie“• „Facharzt für interne Medizin“Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:3201. Laut Festlegung wird die „Fachrichtung“ der Person, welche das Dokument inhaltlicherstellt hat im Element code des Autors abgelegt:a. ClinicalDocument/author/assignedAuthor/code2. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung desAutors ein verpflichtendes Element, wenn vorhanden [R2].3253. Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut@displayName erwartet.2.2.4.1. SpezifikationauthorSpeciality wird gemäß folgender Vorschrift zusammengesetzt:330ClinicalDocument/author/assignedAuthor/code/@displayNameBsp: Anästhesiologie und IntensivmedizinELGA XDS Metadaten.docx 16/64

2.2.5. classCode (und classCodeDisplayName)335Das classCode Element beschreibt die Dokumentenklasse (grobe Granularität) der dasDokument angehört und ist relevant für das Berechtigungssystem.Unterscheidung classCode/typeCode:classCodetypeCodeDokumentenklasse in grober GranularitätDokumentenklasse in feiner Granularität.Siehe Kapitel 2.2.15340Ausgangsbasis dieses Werts ist das Element ClinicalDocument/code, welches ELGAauf hierarchische Überbegriffe (die Dokumentenklasse) gemappt werden kann. Der Wert fürclassCode ergibt sich aus dieser Zusammenfassung.Vorschrift für die Zusammenfassung ClassCode - TypeCode:345Als classCode muss dasjenige Element des Lvl-Typ „0“ des Value-Sets„ELGA_Dokumentklassen“ angegeben werden, in dessen Unterelementen sich der Wertder Ausgangsbasis (ClinicalDocument/code) befindet. Weitere Informationen findensich in den ELGA CDA Implementierungsleitfäden.Beispiel:350Die Spezialisierungen des Entlassungsbriefes „Ärztlich“ und „Pflege“ werden unter demSammelbegriff „Entlassungsbrief“ zusammengefasst:Lvl-Typ Code (LOINC) DisplayName Element in XDS0-S 18842-5 Discharge summarization note classCode1-L 11490-0 Discharge summarization note (physician) typeCode1-L 34745-0 Discharge summarization note (nursing) typeCodeAls typeCode wird 11490-0 oder 34745-0 angegeben, als classCode entsprechend18842-5.ELGA XDS Metadaten.docx 17/64

2.2.5.1. Spezifikation355classCode (und classCodeDisplayName) wird gemäß folgender Vorschriftzusammengesetzt:$typeCode = ClinicalDocument/code/@code360Mapping der Dokumentenklasse (feine Granularität) auf Sammelbegriff:$code = Mapping-Tabelle($typeCode)$displayName = displayName($code)$codeSystem = fixe OID aus der Mapping-Tabelle365classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"classifiedObject="theDocument"nodeRepresentation="$code"urn:oid:$codeSystem380ELGA XDS Metadaten.docx 18/64

2.2.6. confidentialityCodeDas confidentialityCode Element beschreibt die Vertraulichkeitsstufe des Dokuments.385Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumenteausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird diesesElement vorerst nicht genutzt.Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Eswird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikationübernommen:390Zulässige Werte gemäß Value-Set „ELGA_Confidentiality“.2.2.6.1. SpezifikationconfidentialityCode wird gemäß folgender Vorschrift zusammengesetzt:395$code = ClinicalDocument/confidentialityCode/@code$displayName = ClinicalDocument/confidentialityCode/@displayName$codeSystem = ClinicalDocument/confidentialityCode/@codeSystem405410urn:oid:$codeSystemELGA XDS Metadaten.docx 19/64

4152.2.7. creationTimeDas creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDSProfil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen.420Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:a. ClinicalDocument/effectiveTime2. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatumsein verpflichtendes Element.4253. Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgendenAttribute:a. @value … enthält das Datum in folgenden möglichen Formeni. YYYYMMDDii. YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)1. Bsp: 20081224082015+01004302. Für: 24.12.2008, 08:20:14, Zeitzone GMT+12.2.7.1. SpezifikationcreationTime wird gemäß folgender Vorschrift zusammengesetzt:435ClinicalDocument/effectiveTime/@valueBsp: 20100511134500440Hinweis: Wenn Datumselemente in CDA mit Zeit angegeben sind, so muss gemäßELGA Leitfaden ebenfalls eine Zeitzone mit angegeben werden (z.B.20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzoneabgebildet werden, daher muss diese vor Weiterverarbeitung entfernt werden (z.B.20100511193000)Falls eine Zeit angegeben ist, muss diese gemäß der Zeitzone in UTC Zeit konvertiertwerden!445Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3].ELGA XDS Metadaten.docx 20/64

2.2.8. eventCodeList (und eventCodeListDisplayName)450Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachtenGesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt.Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgendeVerknüpfung mit den CDA Header Elementen:1. Im CDA wird die Liste der Service-Events wie folgt abgelegt:a. ClinicalDocument/documentationOf/serviceEvent4552. Mehrere dieser Service-Events können durch beliebig viele „documentationOf“Elemente ausgedrückt werden.3. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2].4. Ein serviceEvent Element in CDA beinhaltet unter anderem die folgenden Elemente:460a. code … ein Code-Element, welches die Art des ServiceEvents angibtDie Vorschriften zur Befüllung der CDA R2 ServiceEvents leiten sich vom Allgemeinen undvom jeweiligen speziellen CDA Implementierungsleitfäden ab. In den speziellenImplementierungsleitfäden wird definiert, ob im Service Event eine Gesundheitsdienstleistungangegeben werden muss, und welche Bedeutung dieses Element hat.4652.2.8.1. SpezifikationeventCodeList (und eventCodeListDisplayName) wird gemäß folgender Vorschriftzusammengesetzt:Für jedes documentationOf Element 1..n:470$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem475classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"classifiedObject="theDocument"nodeRepresentation="$code"ELGA XDS Metadaten.docx 21/64

485urn:oid:$codeSystem4902.2.8.2. Spezielle Vorschriften laut IHE PCCDas PCC Profil definiert in Kapitel „Medical Document Bindings“ Spezialbehandlungen fürgewissen Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).Diese speziellen Vorschriften werden in ELGA nicht angewandt.495ELGA XDS Metadaten.docx 22/64

2.2.9. languageCodeDas languageCode Element beschreibt den Sprachcode in dem das Dokument verfasst ist.Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:5002.2.9.1. SpezifikationlanguageCode wird gemäß folgender Vorschrift zusammengesetzt:ClinicalDocument/languageCode/@codeBsp: de-AT505ELGA XDS Metadaten.docx 23/64

2.2.10. legalAuthenticatorDas legalAuthenticator Element beschreibt die Identifikation und demographischeInformationen der Person, welche das Dokument rechtlich verbindlich unterzeichnet hat.510515Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element„legalAuthenticator“ abgelegt:a. ClinicalDocument/legalAuthenticator/assignedEntity2. Die vidierende Persona. Ein Personenelement in CDA beinhaltet unter anderem die folgendenUnterelemente:i. id … ID der Person mit den folgenden Attributen:5201. @root … Root OID des ID Pools, oder direkte die OID derPerson (ohne @extension-Attribut)2. @extension … Eigentliche ID des Elements aus demgegebenen ID Pool (falls die @root nicht direkt die Personidentifiziert)ii. assignedEntity5251. Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthälta. Name2.2.10.1. Spezifikation530legalAuthenticator wird gemäß folgender Vorschrift zusammengesetzt:$person = ClinicalDocument/legalAuthenticator/assignedEntity535540concat($person/id/@extension,"^",$person/assignedPerson/name/family,"^",$person/assignedPerson/name/given[1],"^",$person/assignedPerson/name/given[2],"^",$person/assignedPerson/name/suffix,"^",$person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&",$person/id/@root,"&ISO")Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&1.2.3.4.5.6.7.8.9&ISODies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].ELGA XDS Metadaten.docx 24/64

2.2.11. serviceStartTime / serviceStopTime545Die serviceStartTime/serviceStopTime Elemente beschreiben die Zeitpunkte des Beginnsund Beendigung des Patientenkontakts/Behandlung.Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe vonmindestens einer Gesundheitsdienstleistung (“documentationOf/serviceEvent“)verpflichtend, wenn bekannt [R2].550Wenn vorhanden, beinhaltet dieses Element die semantisch korrekten Informationen zuStart- und Endedatum gemäß der jeweiligen Fachdomäne (z.B.: dasAufnahme/Entlassungsdatum im Falle von Entlassungsbriefen aus stationärer Behandlung).555Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einemService-Event verpflichtend:a. ClinicalDocument/documentationOf/serviceEvent5602. Das Element serviceEvent beinhaltet unter anderem die folgendenUnterelemente:a. effectiveTime gibt das Zeitintervall an, in dem dieGesundheitsdienstleistung durchgeführt wurdeb. Laut Vorgabe der ELGA Gesundheitsdaten soll ein Zeitintervall (HL7 IVL_TS)in wie folgt angeordnet werden:565i. low … enthält das Startdatumii. high … enthält das Endedatumiii. Andere im CDA möglichen Angaben (low/width, width/high, ...)sind nicht gestattet2.2.11.1. Spezifikation570serviceStartTime wird gemäß folgender Vorschrift zusammengesetzt:ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@valueBsp: 20110504120000575Hinweis: Wenn Datumselemente in CDA mit Zeit angegeben sind, so muss gemäßELGA Leitfaden ebenfalls eine Zeitzone mit angegeben werden (z.B.ELGA XDS Metadaten.docx 25/64

20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzoneabgebildet werden, daher muss diese vor Weiterverarbeitung entfernt werden (z.B.20100511193000)580Falls eine Zeit angegeben ist, muss diese gemäß der Zeitzone in UTC Zeit konvertiertwerden!serviceStopTime wird gemäß folgender Vorschrift zusammengesetzt:585ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@valueBsp: 20110510173000590Hinweis: Wenn Datumselemente in CDA mit Zeit angegeben sind, so muss gemäßELGA Leitfaden ebenfalls eine Zeitzone mit angegeben werden (z.B.20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzoneabgebildet werden, daher muss diese vor Weiterverarbeitung entfernt werden (z.B.20100511193000)Falls eine Zeit angegeben ist, muss diese gemäß der Zeitzone in UTC Zeit konvertiertwerden!595ELGA XDS Metadaten.docx 26/64

2.2.12. sourcePatientIdDas sourcePatientId Element beschreibt die Patienten ID des Patienten im lokalenInformationssystem des GDA.600Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Im CDA wird die ID des Patienten in folgendem Element abgelegt:a. ClinicalDocument/recordTarget/patientRole/id6052. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens denfolgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wennbekannt:a. id[1] … Lokale ID des Patienten vom einbringenden Systemb. id[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)Achtung: Diese ID gelangt nicht in die Metadaten!2.2.12.1. Spezifikation610sourcePatientId wird gemäß folgender Vorschrift zusammengesetzt:615concat(ClinicalDocument/recordTarget/patientRole/id[1]/@extension, "^^^&",ClinicalDocument/recordTarget/patientRole/id[1]/@root, "&ISO")Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISODies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].620ELGA XDS Metadaten.docx 27/64

2.2.13. sourcePatientInfoDas sourcePatientInfo Element beschreibt die demographischen Daten des Patienten.625Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Laut Vorgabe der ELGA Gesundheitsdaten ist beim Patienten die Angabe derfolgenden Elemente verpflichtend:a. Verpflichtendi. Lokale ID des Patienten aus dem System (id[1])ii. Patientenname (name)630iii. Geschlecht (administrativeGender)iv. Geburtsdatum (birthTime)b. Verpflichtend wenn bekannti. Sozialversicherungsnummer des Patienten (id[2])Achtung: Diese ID gelangt nicht in die Metadaten!635ii. Adresse (addr)1. Beliebige Granularität2.2.13.1. SpezifikationsourcePatientInfo wird gemäß folgender Vorschrift zusammengesetzt:640$patientRole = ClinicalDocument/recordTarget/patientRole645$id = concat($patientRole/id[1]/@extension, "^^^&",$patientRole/id[1]/@root, "&ISO")Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO650655$name = concat($patientRole/patient/name/family,"^",$patientRole/patient/name/given[1],"^",$patientRole/patient/name/given[2],"^",$patientRole/patient/name/suffix,"^",$patientRole/patient/name/prefix[@qualifier="AC"])Bsp: Mustermann^Herbert^^^Ing.ELGA XDS Metadaten.docx 28/64

$birthtime = $patientRole/patient/birthtime/@value660Bsp: 19650120$gender = $patientRole/patient/administrativeGenderCode/@codeBsp: M665670675680$addr = concat($patientRole/addr/streetAddressLine,"^^",$patientRole/addr/city,"^",$patientRole/addr/state,"^",$patientRole/addr/postalCode,"^",$patientRole/addr/country)… oder …$addr = concat(concat($patientRole/addr/streetName," ",$patientRole/addr/houseNumber),"^^",$patientRole/addr/city,"^",$patientRole/addr/state,"^",$patientRole/addr/postalCode,"^",$patientRole/addr/country)Bsp: Mustergasse 11^^Wien^W^1230^AustriaBemerkung: Wenn die Adresse nicht in der erforderlichen Granularität zurVerfügung steht, dann wird dieses Element (PID-11) nicht angegeben.685PID-3|$idPID-5|$namePID-7|$birthtimePID-8|$gender690PID-11|$addrELGA XDS Metadaten.docx 29/64

2.2.14. titleDas title Element beschreibt den lesbaren Titel des Dokuments.695Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitelsverpflichtend:a. ClinicalDocument/title7002.2.14.1. Spezifikationtitle wird gemäß folgender Vorschrift zusammengesetzt:ClinicalDocument/titleBsp: Entlassungsbrief der chirurgischen Abteilung705ELGA XDS Metadaten.docx 30/64

2.2.15. typeCode (und typeCodeDisplayName)Das typeCode Element beschreibt den Dokumententyp, dem das Dokument angehört. DerDokumententyp ist die Spezialisierung einer Dokumentenklasse, jeder Dokumententypgehört zu genau einer Dokumentenklasse.710Unterscheidung typeCode/classCode:typeCodeclassCodeDokumentenklasse in feiner Granularität (Spezialisierung).Dokumentenklasse in grober Granularität.Siehe Kapitel 2.2.5Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:7151. Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:a. ClinicalDocument/code2. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes einverpflichtendes Element.3. Ein Code-Element in CDA beinhaltet unter anderem die folgenden Attribute:720a. @code … Codierter Wert der Dokumentenklassei. Bsp: Code „11490-0“b. @displayName … Lesbarer Wert der Dokumentenklassei. Bsp: „Discharge summarization note (physician)”c. @codeSystem … Codierter Wert des zugrundliegenden Codesystems725i. Bsp: „2.16.840.1.113883.6.1“4. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute desElements code verpflichtend.Zulässige Werte gemäß Value-Set „ELGA_ Dokumentenklassen“.730Als typeCode soll das passende Element aus dem Lvl-Typ „1“ des Value-Sets„ELGA_Dokumentklassen“ angegeben werden, weitere Informationen finden sich in denELGA CDA Implementierungsleitfäden.ELGA XDS Metadaten.docx 31/64

2.2.16. uniqueId760Das uniqueId Element beschreibt den global eindeutigen Identifier des Dokuments. DieserIdentifier wird entweder vom Document Source Actor erzeugt oder im Fall eines evtl.verwendeten Adapters vom Informationssystem des GDA übernommen.765Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokumentverpflichtend:a. ClinicalDocument/id2.2.16.1. SpezifikationuniqueId wird gemäß folgender Vorschrift zusammengesetzt:770Fall 1Attribut ClinicalDocument/id/@extension ist nicht vorhandenconcat(ClinicalDocument/id/@root)Bsp: 1.2.3.4.5.6.7.8.9775Fall 2Attribut ClinicalDocument/id/@extension ist vorhandenconcat(780ClinicalDocument/id/@root,"^",ClinicalDocument/id/@extension)Bsp: 1.2.3.4.5.6.7.8.9^0815ELGA XDS Metadaten.docx 33/64

7852.3. XDS Metadaten 2: explizit zu setzen (ELGA relevant)2.3.1. availabilityStatusDas availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit deseingebrachten Dokuments.790Mögliche Werte laut IHE sind:ApprovedDeprecated795Dieses Attribut ist im Zuge des Einbringens von neuen Dokumenten („Submission“)immer auf “Approved” gesetzt.2.3.2. formatCode (und formatCodeDisplayName)800Das formatCode Element beschreibt das (semantische) Format des Dokuments. Esermöglicht einem, das Dokument zur Weiterverarbeitung empfangenden System (DocumentConsumer Actor) die Identifizierung des zu erwartenden Dokumentenformats und somit diekorrekte Darstellung des Dokuments.Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zurVerfügung.2.3.2.1. Dokumente in ELGA Interoperabilitätsstufe „Enhanced“ oder höher805Die Angabe erfolgt gemäß der Liste der in ELGA gültigen Formatcodes mit zusätzlicherAngabe der ELGA-Interoperabilitäts-Stufe (EIS „Enhanced“, …).Zulässige Werte gemäß Value-Set „ELGA_FormatCode“.810Beispiele:• urn:elga:dissum:2011:EIS_Enhanced• Gemäß dem Implementierungsleitfaden „Entlassungsbriefe“, im ELGA-Interoperabilitätsstufe „Enhanced“ (Mindest-Stufe für strukturierte Dokumentinhalte).ELGA XDS Metadaten.docx 34/64

• urn:elga:lab:2011:EIS_FullSupport815• Gemäß dem Implementierungsleitfaden „Laborbefund“, im ELGA-Interoperabilitätsstufe „Full Support“..2.3.2.2. Dokumente in ELGA Interoperabilitätsstufe „Basic“ (Zusatz erforderlich)820Folgt ein ELGA CDA Dokument einem Implementierungsleitfaden einer Fachdomäne inELGA-Interoperabilitätsstufe „Basic“, so enthält dieses Dokument entweder unstrukturiertenoder strukturierten Text gemäß CDA Level 1 oder ein eingebettetes Objekt (PDF, Bild, etc.).Bemerkung: Folgt das Dokument lediglich dem Basis-Implementierungsleitfaden „CDADokumente im österreichischen Gesundheitswesen“, so liegt das Dokument implizit immerim ELGA Interoperabilitätslevel „Basic“ vor.825Im Fall eines Dokuments in ELGA Interoperabilitätsstufe „Basic“ muss der formatCodeebenfalls das „Format“ des unstrukturierten/eingebetteten Inhalts beinhalten. Das Formatmuss mittels „:“ (Doppelpunkt) am Ende angefügt werden.Zulässige Zusätze gemäß Value-Set „ELGA_FormatCodeZusatz“.830Beispiele:• urn:elga:dissum:2011:EIS_Basic:PDF• Gemäß dem Implementierungsleitfaden „Entlassungsbriefe“, im ELGA-Interoperabilitätslevel „Basic“, das eingebettete Objekt ist im PDF Format.• urn:elga:2011:EIS_Basic:JPG835• Gemäß dem Basis-Implementierungsleitfaden „CDA Dokumente im österreichischenGesundheitswesen“ (und daher implizit im ELGA-Interoperabilitätslevel „Basic“), daseingebettete Objekt ist ein eingescanntes Dokument als Bild im JPG Format.8402.3.2.3. Dokumente in ELGA Interoperabilitätsstufe „Enhanced“ oder „Full Support“(Zusatz bei selbst-definierten maschinenlesbaren Elementen)Liegt ein CDA Dokument in ELGA Interoperabilitätsstufe „Enhanced“ oder „Full Support“ vorund enthält das Dokument zusätzliche selbst-definierte maschinenlesbare Elemente,so ist dies durch einen Zusatz im Formatcode zu kennzeichnen.Der anzuwendende Zusatz ist ein „+“ (Plus-Zeichen) am Ende des Formatcodes.ELGA XDS Metadaten.docx 35/64

845Beispiele:• urn:elga:dissum:2011:EIS_Enhanced+• urn:elga:lab:2011:EIS_FullSupport+8502.3.2.4. SpezifikationformatCode (und formatCodeDisplayName) wird gemäß folgender Vorschriftzusammengesetzt:855$code = gemäß Liste der in ELGA gültigen FormatCodes$displayName = gemäß Liste der in ELGA gültigen FormatCodes$codeSystem = OID der Liste der in ELGA gültigen FormatCodes865870urn:oid:$codeSystemELGA XDS Metadaten.docx 36/64

2.3.3. healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)875Das healthcareFacilityTypeCode Element beschreibt die Klassifizierung des GDAs.Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zurVerfügung.Zulässige Werte gemäß Value-Set „ELGA_ HealthcareFacilityTypeCode“.8802.3.3.1. SpezifikationhealthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName) wirdgemäß folgender Vorschrift zusammengesetzt:885$code = Klassifizierung des GDA (Code)$displayName = Klartext des angegebenen Codes$codeSystem = OID der ausgebenden Stelle890classifiedObject="theDocument"nodeRepresentation="$code"urn:oid:$codeSystemELGA XDS Metadaten.docx 37/64

9052.3.4. mimeTypeDas mimeType Element beschreibt den „Internet Media Type“ des Dokuments gemäß dem„Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard wird beschrieben inRFC 2045 7 bis RFC 2049 8 .Im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".9102.3.4.1. SpezifikationmimeType wird gemäß folgender Vorschrift gespeichert.Folgende Mime-Types sind für Dokumente zugelassen:915CDA R2: text/xmlDICOM/KOS: application/dicom7http://tools.ietf.org/html/rfc20458http://tools.ietf.org/html/rfc2049ELGA XDS Metadaten.docx 38/64

2.3.5. parentDocumentId, parentDocumentRelationship925Das parentDocumentId Element kennzeichnet das Dokument, zu dem das eingebrachteDokument in einer bestimmten Relation steht.Das parentDocumentRelationship Element beschreibt den Typ der Relation (Ergänzung,Versionierung, Transformation).930Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA HeaderElementen:1. Im CDA werden die Informationen über Dokumente, die mit dem eingebrachtenDokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:a. ClinicalDocument/relatedDocument9352. Der Typ der Relation muss verpflichtend in folgendem Attribut angegeben werden:a. ClinicalDocument/relatedDocument/@typeCodeb. Folgende Relationen sind in ELGA erlaubt (siehe „AllgemeinerImplementierungsleitfaden für ELGA CDA Dokumente“, Version 2.01, OID:1.2.40.0.34.7.1.1):940i. Versionierung (RPLC)ii. Transformation (XFRM)3. Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird infolgendem Element angegeben:a. ClinicalDocument/relatedDocument/parentDocument9452.3.5.1. SpezifikationparentDocumentId muss mit folgender Elementen des CDA übereinstimmen:concat(950ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",ClinicalDocument/relatedDocument/parentDocument/id/@extension)parentDocumentRelationship muss mit folgender Elementen des CDAübereinstimmen:955ClinicalDocument/relatedDocument/@typeCodeELGA XDS Metadaten.docx 39/64

2.3.6. practiceSettingCode (und practiceSettingCodeDisplayName)960Das practiceSettingCode Element beschreibt die fachliche Zuordnung des Dokumentes. Essoll den Fachbereich wiedergeben, dem der Inhalt des Dokuments am besten entspricht,unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung.Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zurVerfügung.965Zulässige Werte gemäß Value-Set „ELGA_ PracticeSetting“.2.3.6.1. SpezifikationpracticeSettingCode (und practiceSettingCodeDisplayName) wird gemäßfolgender Vorschrift zusammengesetzt:970$code = Code aus ELGA_PracticeSetting$displayName = Klartext des angegebenen Codes$codeSystem = OID der ausgebenden Stelle975classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"classifiedObject="theDocument"nodeRepresentation="$code"urn:oid:$codeSystem990ELGA XDS Metadaten.docx 40/64

3. Anhänge3.1. IHE ITI-TF3, Kapitel 4.1.7 „Document Definition Metadata“995Die folgende Tabelle ist der Original-Auszug der Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE „IT Infrastructure“ (ITI) Technical Frameworks Version7.0, Volume 3.Quelle: IHE ITI Technical Framework 7.0, Volume 3 9Tabelle 4: IHE Original Tabelle: “Table 4.1-4 Codes for Source/Query Column”CodeRR2OPCpCgCxMeaningRequiredRequired if KnownOptionalRegistry is not required to support query of this attribute.Computed/Assigned by Repository, required in register transaction.Computed/Assigned by RegistryOptionally Computed/Assigned by a Document Registry1000Tabelle 5: IHE Original Tabelle: „Table 4.1-5 Document Metadata Attribute Definition”XDSDocumentEntryAttributeauthorDefinition Source ConstraintsRepresents the humans and/or machines that authored the document.This attribute contains the following sub-attributes: authorInstitution authorPerson authorRole authorSpecialtywhich are individually defined below.R2ebRIMThe author attribute is defined as a Classification which contains theabove sub-attributes. The author attribute itself does not have asimple value. It defines a structure to hold its sub-attributes. Aninstance of this Classification shall be considered a single value ofthe author attribute. If present, the author attribute shall have one ormore values. Each instance of this Classification shall contain: One instance of the authorPerson sub-attribute Zero or more instances of the authorInstitution subattribute Zero or more instances of the authorRole sub-attribute Zero or more instances of the authorSpecialty sub-attribute9http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev7-0_Vol3_FT_2010-08-10.pdfELGA XDS Metadaten.docx 41/64

XDSDocumentEntryAttributeDefinition Source ConstraintsThe following example shows the definition of a single author. Theclassification shows the required authorPerson Slot holding therequired single value. Single values are shown for authorInstitution,authorRole, and authorSpecialty. Multiple values for these three subattributes,if present, shall be coded as additional Value elementswithin the Slot/ValueList having the correct name.name ofauthor SomeHospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45name ofrolespecialty ofauthorauthorInstitution(sub-attribute ofauthor)Represents a specific healthcare facility under which the humanand/or machines authored the document. A specific case is that ofhomecare. This is a sub-attribute of the author attribute. See theauthor attribute for definition of the requirements of usage.R2XONSee author for example.authorPerson(sub-attribute ofauthor)Represents the humans and/or machines that authored the documentwithin the authorInstitution. The document author may be thepatient itself. This is a sub-attribute of the author attribute. See theauthor attribute for definition of the requirements of usage.R2XCNSee author for example.ELGA XDS Metadaten.docx 42/64

XDSDocumentEntryAttributeDefinition Source ConstraintsauthorRole (subattributeofauthor)A code that represents the role of the author with respect to thepatient when the document was created. This is a sub-attribute of theauthor attribute. See the author attribute for definition of therequirements of usage.See author for example.R2authorSpecialty(sub-attribute ofauthor)Represents a specific specialty within a healthcare facility underwhich the human and/or machines authored the document. This is asub-attribute of the author attribute. See the author attribute fordefinition of the requirements of usage.R2See author for example.availabilityStatusAn XDS Document shall have one of two availability statuses:Approved available for patient careDeprecated obsoleteThis attribute is always set to Approved as part of the submission ofnew XDS Documents. It may be changed to Deprecated under theprimary responsibility of the Document Source with possible patientsupervision.Although XDS supports the ability to delete documents, there is nosuch state as “the Document Entry is removed” (only an audit trail iskept if such a deletion is allowed).This list may be extended in the future. See ITI TF-3: 4.1.3.3Atomicity Requirements for XDS Submission Requests foradditional details.If present, shall have a single value.The example below shows the status attribute, however, thisattribute is only returned on query, not set during any registry orrepository transaction.CgclassCode …The code specifying the particular kind of document (e.g.Prescription, Discharge Summary, Report). It is suggested that theXDS Affinity Domain draws these values from a coding schemeproviding a coarse level of granularity (about 10 to 100 entries).Shall have a single value.R XDS AffinityDomainspecific

XDSDocumentEntryAttributeclassCodeDisplayNameDefinition Source Constraintsvalue="classCodeDisplayName"/>XDS Affinity DomainSpecific ValueThe name to be displayed for communicating to a human themeaning of the classCode. Shall have a single value for each valueof classCode.See classCode for example.R XDS AffinityDomainspecificcommentsComments associated with the Document. Free form text with anXDS Affinity Domain specified usage.O XDS AffinityDomainspecificconfidentialityCodecreationTimeThe code specifying the level of confidentiality of the XDSDocument. These codes are specific to an XDS Affinity Domain.Enforcement and issues related to highly sensitive documents arebeyond the scope of XDS (see security section). These issues areexpected to be addressed in later years. confidentialityCode is partof a codification scheme and value set enforced by the DocumentRegistry. Shall have one or more values. Code multiple values bycreating multiple classification objects.XDS Affinity DomainSpecific ValueRepresents the time the author created the document in theDocument Source. Shall have a single value.R XDS AffinityDomainspecificR DTM20041225212010entryUUIDThis globally unique identifier is primarily intended for use as adocument registry management identifier. It is not meant to be anexternal reference (outside of the Document Registry) for XDSDocuments (e.g. in links within other documents). The uniqueId ismeant for that purpose so that such links remain valid beyond theXDS Affinity Domain. Values of this attribute are in one of twoRUUIDELGA XDS Metadaten.docx 44/64

XDSDocumentEntryAttributeDefinition Source Constraintsformats: properly formatted UUID (including urn:uuid: prefix) orsymbolic name (anything that does not have the urn:uuid: prefix).Provide and Register Document Set-b [ITI-41] and RegisterDocument Set-b [ITI-42] transactions may carry UUID or symbolicformats. All other transactions shall carry only the UUID format. Inprocessing the Register Document Set-b [ITI-42] transaction, theDocument Registry actor shall accept and store the offered UUIDvalues and assign UUID values to all symbolic values.In the XML form, entryUUID is represented by the id attribute. Inthe example below, the entryUUID is a6e06ca8-0c75-4064-9e5c-88b9045a96f6eventCodeList …This list of codes represents the main clinical acts, such as acolonoscopy or an appendectomy, being documented. In some cases,the event is inherent in the typeCode, such as a "History andPhysical Report" in which the procedure being documented isnecessarily a "History and Physical" act.An event can further specialize the act inherent in the typeCode,such as where it is simply "Procedure Report" and the procedure wasa "colonoscopy". If one or more eventCodes are included, they shallnot conflict with the values inherent in the classCode,practiceSettingCode or typeCode, as such a conflict would create anambiguous situation.This short list of codes is provided to be used as “key words” forcertain types of queries. If present, shall have one or more values.Code multiple values by creating multiple classification objects.O XDS AffinityDomainspecificeventCodeListDisplayXDS Affinity DomainSpecific ValueThe list of names to be displayed for communicating to humanreader the meaning of the eventCode. If present, shall have a singleO 10 XDS Affinity10Required if eventCode has a value.ELGA XDS Metadaten.docx 45/64

XDSDocumentEntryAttributeNamevalue corresponding to each value in eventCodeList.See eventCodeList for an example.Definition Source ConstraintsDomainspecificformatCodeCode globally uniquely specifying the format of the document.Along with the typeCode, it should provide sufficient information toallow any potential XDS Document Consumer to know if it will beable to process the document. The formatCode shall be sufficientlyspecific to ensure processing/display by identifying a documentencoding, structure and template (e.g. for a CDA Document, the factthat it complies with a CDA schema, possibly a template and thechoice of a content-specific style sheet). Shall have a single value.Format codes may be specified by multiple organizations. Formatcodes defined by ITI shall have names with the prefixurn:ihe:iti:Format codes defined by other IHE domains shall have names withthe prefixurn:ihe:’domain initials’:Format codes defined by the Affinity Domain shall have names withthe prefixurn:ad:’name of affinity domain’:Affinity Domains shall be unique.The prefixes described here are not assumed to be exhaustive.R XDS AffinityDomainspecificformatCodeDisplayNameXDS Affinity DomainSpecific ValueThe name to be displayed for communicating to human reader themeaning of the formatCode. Shall have a single valuecorresponding to the value in formatCode.See formatCode for an example.R XDS AffinityDomainspecifichashHash key of the XDS Document itself. This value is computed bythe Document Repository and used by the Document Registry fordetecting the improper resubmission of XDS Documents. If present,shall have a single value.If this attribute is received in a Provide & Register Document Set-b[ITI-41] transaction, it shall be verified by the repository with theactual hash value of the submitted document; anXDSRepositoryMetadataError shall be returned on mismatch.CpSHA1 hashSee Table4.1-3ELGA XDS Metadaten.docx 46/64

XDSDocumentEntryAttributeDefinition Source ConstraintshealthcareFacilityTypeCodeda39a3ee5e6b4b0d3255bfef95601890afd80709This code represents the type of organizational setting of the clinicalencounter during which the documented act occurred.In some cases, the setting of the encounter is inherent in thetypeCode, such as "Diabetes Clinic Progress Note".healthcareFacilityTypeCode shall be equivalent to or furtherspecialize the value inherent in the typeCode; for example, wherethe typeCode is simply "Clinic Progress Note" and the value ofhealthcareFacilityTypeCode is "private clinic". The value shall notconflict with the value inherent in the typeCode, as such a conflictwould create an ambiguous situation. Shall have a single value.R XDS AffinityDomainspecific

XDSDocumentEntryAttributelegalAuthenticatorDefinition Source Constraintsen-usRepresents a participant who has legally authenticated or attested thedocument within the authorInstitution. Legal authentication impliesthat a document has been signed manually or electronically by thelegalAuthenticator. This attribute may be absent if not applicable. Ifpresent, shall have a single valueOXCN^Welby^Marcus^^^Dr^MDMIME type of the document in the Repository. Shall have a singlevalue.mimeTypeR …patientIdThe patientId represents the subject of care of the document. Thisidentifier shall be from the Assigning Authority Domain supportingthe XDS Affinity Domain in which the Document Registry operates.It shall contain two parts:Authority Domain Id (enforced by the Registry)An Id in the above domain.No other values are allowed, as specified for the CX type in Table4.1-3 above. Using HL7 terminology, no other values are allowed inthe components of the coded value, nor are further subcomponentsallowed.The value of the patientId shall be the same for all new documentsof a Submission Set.Shall have a single value.RCX

XDSDocumentEntryAttributeDefinition Source ConstraintsclassificationScheme="urn:uuid:cccf5598-8b07-4b77-a05eae952c785ead"classifiedObject="theDocument"id=”ID_052"objectType="urn:oasis:names:tc:ebxmlregrep:ObjectType:RegistryObject:Classification"nodeRepresentation="practiceSettingCode">XDS Affinity DomainSpecific ValueThe name to be displayed for communicating to a human themeaning of the practiceSettingCode. Shall have a single value foreach value of practiceSettingCode.See practiceSettingCode for an example.R XDS AffinityDomainspecificrepositoryUniqueIdThe globally unique identifier of the repository where the documentis stored, assigned by the Document Repository. This uniqueidentifier for the Document Repository may be used to identify andconnect to the specific Document Repository where the document isstored once its metadata has been retrieved from a DocumentRegistry.This repositoryUniqueId is intended to respond to the followingtypes of usage:The means to reference the Document Repository where this XDSdocument is stored. The repositoryUniqueId represents animmutable id for the Document Repository.The means to ensure that a XDS Document is retrieved from theappropriate Document Repository.Shall have a single value.CpITI TF-2b:3.41.4.13.42.4.1.21.3.6.1.4…Represents the start time the service being documented took place(clinically significant, but not necessarily when the document wasproduced or approved). This may be the same as the encounter timein case the service was delivered during an encounter. Encountertime is not coded in XDS metadata but may be coded in documentsmanaged by XDS. This time is expressed as (date/time/UTC). Ifpresent, shall have a single value.Note: Other times, such as document creation or approval are to berecorded, if needed, within the document.serviceStartTimeR2HL7 V2 DTM20041225212010ELGA XDS Metadaten.docx 49/64

XDSDocumentEntryAttributeserviceStopTimeDefinition Source ConstraintsRepresents the stop time the service being documented took place(clinically significant, but not necessarily when the document wasproduced or approved). This may be the same as the encounter timein case the service was delivered during an encounter. Encountertime is not coded in XDS metadata but may be coded in documentsmanaged by XDS. This time is expressed as (date/time/UTC). If theService happens at a point in time, this attribute shall contain thesame value as the serviceStartTime. If present, shall have a singlevalue.R2HL7 V2 DTM20041225232010Size in bytes of the byte stream that was provided in the Registerand Provide Transaction and stored by the XDS DocumentRepository. This value is computed by the Document Repositoryand included in the Register Documents Set Transaction. If present,shall have a single value.If this attribute is received in a Provide & Register Document Set-b[ITI-41] transaction, it shall be verified by the repository with theactual size of the submitted document; anXDSRepositoryMetadataError shall be returned on mismatch.SizeCpIntegerITI TF-2b:3.41.4.13654sourcePatientIdThe sourcePatientId represents the subject of care medical recordIdentifier (e.g. Patient Id) in the local patient Identifier Domain ofthe Document Source. It shall contain two parts:Authority Domain IdAn Id in the above domain (e.g. Patient Id).This sourcePatientId is not intended to be updated once theDocument is registered (just as the Document content and metadataitself will not be updated without replacing the previous document).As this sourcePatientId may have been merged by the source actor,it may no longer be in use within the Document Source (EHR-CR).It is only intended as an audit/checking mechanism and hasoccasional use for Document Consumer Actors. There can be onlyone Slot named sourcePatientId.RCXj98789^^^id.domainsourcePatientInfoThis attribute should contain demographics information of thepatient to whose medical record this document belongs, as theDocument Source knew it at the time of Submission.This information typically includes: the patient first and last name,sex, and birth date. The Clinical XDS Affinity Domain policies mayrequire more or less specific information and format.This patient information is not intended to be updated once theDocument is registered (just as the Document content and metadataitself will not be updated without replacing the previous document).OELGA XDS Metadaten.docx 50/64

XDSDocumentEntryAttributeDefinition Source ConstraintsAs sourcePatientInfo may have been updated by the source actor, itmay no longer be in use within the Document Source (EHR-CR). Itis only intended as an audit/checking mechanism and has occasionaluse for Document Consumer actors. Shall have a single value (onlya single sourcePatientInfo slot may be present).PID-3|DTP-1^^^&1.3.6.1.4.1.21367.2005.3.7&ISOPID-5|DICTAPHONE^ONE^^^PID-7|19650120PID-8|MPID-11|100 MainSt^^BURLINGTON^MA^01803^USAPID-3 should include the source patient identifier.PID-5 should include the patient name.PID-8 should code the patient gender asM – Male F – FemaleO – Other U – UnknownPID-7 should include the patient date of birth.PID-11 should include the patient address.PID-2, PID-4, PID-12 and PID-19 should not be used.TitleRepresents the title of the document. Clinical documents often donot have a title, and are collectively referred to by the display nameof the classCode (e.g. a "consultation" or "progress note"). Wherethese display names are rendered to the clinician, or where thedocument has a unique title, the title component shall be used. Maxlength, 128 bytes, UTF-8. If present, shall have a single value.OtypeCode…The code specifying the precise kind of document (e.g. PulmonaryHistory and Physical, Discharge Summary, Ultrasound Report). It issuggested that the XDS Affinity Domain draw these values from acoding scheme providing a fine level of granularity. Shall have asingle value.

XDSDocumentEntryAttributetypeCodeDisplayNameDefinition Source Constraintsvalue="typeCodeDisplayName"/>XDS Affinity DomainSpecific ValueThe name to be displayed for communicating to a human themeaning of the typeCode. Shall have a single value for each valueof typeCode.See typeCode for an example.R XDS AffinityDomainspecificuniqueIdThe globally unique identifier assigned by the document creator tothis document. This unique identifier may be used in the body ofother XDS Documents to reference this document. The length ofUnique Identifier shall not exceed 128 bytes. The structure andformat of this Id shall be consistent with the specificationcorresponding to the format attribute. (e.g. for a DICOM standarddocument a 64 character numeric UID, for an HL7 CDA format aserialization of the CDA Document id extension and root in the formoid^extension, where OID is a 64 digits max, and the ID is a 16UTF-8 char max). If the oid is coded without the extension then the'^' character shall not be included.This uniqueId is intended to respond to the following types of usage:The means to reference this XDS document from within the contentof another document. Neither the XDS Registry nor the Repositoryis aware of such references, but the Document Sources andConsumers are.Shall have a single value.RSee ITI TF-3:4.1.7.2URI

XDSDocumentEntryAttributeDefinition Source Constraints1|http://www.ihe.net/IHERetrieveDocument?=1.2.32|requestType=DOCUMENT&documentUID3|&preferredContentType=application%2fpdfEach Value is composed of an ordering prefix followed by a portionof the actual URI string. The ordering prefix shall be sequentialstarting at the value 1. When the long format is used, all Values shallhave an ordering prefix.Each value is ordered by its ordering prefix:ordering-prefix :== digit vertical-bardigit :== ‘1’ | ‘2’ | ‘3’ | ‘4’ | ‘5’ | ‘6’ | ‘7’ | ‘8’ | ‘9’vertical-bar :== ‘|’The long version may be used for URIs of less than 129 characters.This profile does not specify how a URI is to be broken up intopieces. The following example is valid.1|http://www.ihe.netThe long version is assembled into a URI by concatenating theValues without the ordering prefixes in the order specified by theordering-prefixes.ELGA XDS Metadaten.docx 53/64

3.2. IHE PCC-TF2, Kapitel 4.1.1 „XDSDocumentEntry Metadata“1005Die folgende Tabelle ist der Original-Auszug der Vorschrift zur Befüllung der Dokument-Metadaten aus CDA Dokumenten des IHE „Patient Care Coordination“ (PCC) TechnicalFrameworks Version 6.0, Volume 2.Quelle: IHE PCC Technical Framework 6.0, Volume 2 111010Tabelle 6: IHE Original Tabelle: „Codes for Source Type column“SourceTypeSASATFMFADCADCADTn/aDSODescriptionSource document Attribute – value is copied directly from source document. The Source/Value columnidentifies where in the source document this attribute comes from. Specify the location in XPath whenpossible.Source document Attribute with Transformation – value is copied from source document and transformed.The Source/Value column identifies where in the source document this attribute comes from. Specify thelocation in XPath when possible. Extended Discussion column must not be empty and the transform must bedefined in the extended discussionFixed (constant) by Mapping - for all source documents. Source/Value column contains the value to be usedin all documents.Fixed by Affinity Domain – value configured into Affinity Domain, all documents will use this value.Coded in Affinity Domain – a list of acceptable codes are to be configured into Affinity Domain. The valuefor this attribute shall be taken from this list.Coded in Affinity Domain with Transform - a list of acceptable codes are to be configured into AffinityDomain. The value for this attribute shall be taken from this list.Not Applicable – may be used with an optionality R2 or O attribute to indicate it is not to be used.Document Source – value comes from the Document Source actor. Use Source/Value column or ExtendedDiscussion to give details.Other – Extended Discussion must be 'yes' and details given in an Extended Discussion.11http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Rev6-0_Vol_2_2010-08-30.pdfELGA XDS Metadaten.docx 54/64

1015Tabelle 7: IHE Original Tabelle: „XDSDocumentEntry Metadata“XDSDocumentEntryAttributeOptional?Source TypeSource/ ValueavailabilityStatus R DS$inst

Must be Consitent with /ClinicalDocument/code/@codeDerived from a mapping of/ClinicalDocument/confidentialityCode/@code to anAffinity Domain specified coded value and codingsystem. When using the BPPC profile, theconfidentialyCode may also be obtained from the element.confidentialityCode R CADT/ClinicalDocument/confidentialityCode/@code-AND/OR-/ClinicalDocument/authorization/consent[templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.2.5'] /code/@codecomments O DS/ClinicalDocument/effectiveTimecreationTime R SATTimes specified in clinical documents may be specifiedwith a precision in fractional sections, and may contain atime zone offset. In the XDS Metadata, it can be preciseto the second, and is always given in UTC, so thetimezone offset if present must be added to the currenttime to obtain the UTC time.entryUUID R DSeventCodeList O CADTThese values express a collection of keywords that maybe relevant to the consumer of the documents in theregistry. They may come from anywhere in the CDAdocument, according to its purpose.eventCodeDisplayNameListR(if eventCode isvalued)CADTThese are the display names for the collection ofkeywords described above.formatCode R FMhealthcareFacilityTypeCode R CADThe format code for each PCC Document content profileis provided within the document specifications.A fixed value assigned to the Document Source andconfigured form a set of Affinity Domain definedvalues. Must be concistent with /clinicalDocument/codehealthcareFacilityTypeCodeDisplayNameR CAD Must be concistent with /clinicalDocument/codeintendedRecipient (for XDR,XDM)OSAT$person

$person/id/@extension,"^",$person/informationRecipient/name/family,"^",$person/informationRecipient/name/given[1],"^",$person/informationRecipient/name/given[2],"^",$person/informationRecipient/name/suffix,"^",$person/informationRecipient/name/prefix,"^","^^^&", $person/id/@root,"&ISO","|"$inst/name)"^^^^^&",$inst/id/@root, "&ISO", "^^^^", $inst/id/@extension)-->languageCode R SA /ClinicalDocument/languageCode$person

$patID

$docID

3.3. IHE XDS Data TypesDie folgende Tabelle ist der Original-Auszug der Tabelle der XDS Data Typen des IHE „ITInfrastructure“ (ITI) Technical Frameworks Version 7.0, Volume 3.1020Quelle: IHE ITI Technical Framework 7.0, Volume 3 12Tabelle 8: IHE Original Tabelle: „Table 4.1-3 Data Types“XDS Data TypeSourceStandardEncoding SpecificationCX HL7 V2 Identifier This is an identifier. HL7 Identifier type CX consist of severalcomponents, but this specification restricts them to the use of twocomponents, the ID Number, and the Assigning Authority (AA). TheAssigning Authority identifies the "domain" over which the ID Numberrepresents a unique entity. Furthermore, the AA is represented using aUniversal ID and Universal ID Type. In XDS specification, ISO ObjectIdentifiers (see OID below) must be used as Universal ID. Therefore,Universal ID Type is always ISO. The required format is:IDNumber^^^&OIDofAA&ISONo other values/modifications in other components or subcomponents areallowed. Specifically, components 2 and 3 shall be empty as listed above.An explicit example is:543797436^^^&1.2.840.113619.6.197&ISONote that the '&' character must be properly encoded in the XML content.See the examples in the tables below for the appropriate representation.DTMOIDHL7 V2Date TimeISO ObjectIdentifierThis is a date/time value, represented as precisely as possible. All datetime values in the registry are stored using universal coordinated time[UTC]."UTC" implies that the source and the consumer shall convert the timefrom/to the local time.The format of these values is defined as the following regular expression:YYYY[MM[DD[hh[mm[ss]]]]]Where:YYYY is the four digit year i.e. 2006MM is the two digit month 01-12, where Jan is 01, Feb is 02, etc.DD is the two digit day of the month 01-31HH is the two digit hour, 00-23, where 00 is midnight, 01 is 1 am, 12 isnoon, 13 is 1 pm, etc.mm is the two digit minute, 00-59ss is the two digit seconds, 00-59The following are legal date time values with increasing precisionrepresenting the date and time January 2, 2005, 3:04:05am200520050120050102200501020320050102030420050102030405An ISO Object identifier. Limited in length to 64 characters, and made upof characters from the set [0-9.]. It must start with an integer, and is12http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev7-0_Vol3_FT_2010-08-10.pdfELGA XDS Metadaten.docx 60/64

followed by one or more additional integer values, separated by periods.Integers are represented without leading 0 digits unless the value is zero.1.3.6.1.4.1.21367.2005.3.7FieldSHA1URIUUIDXCNXONHL7 V2 MessageSegmentDocument hashcalculated withSHA1 algorithmUniformResourceIdentiferUniversallyUnique IdentifierHL7 V2 ExtendedPerson NameHL7 V2OrganizationNameIn the attribute tables below, when an OID format is specified, it shallfollow the assignment and format rules defined for document UID in ITITF-2x: Appendix BSpecified as the Field identifier, followed by a pipe (|) and then the datavalue represented with corresponding HL7 V2 data type as defined in HL7standard. Note that if a HL7 data type is used to derive XDS data type (asshown in this table), the derived XDS data type shall be used to representthe value.An example of field Patient Identifier List (the third field of PID segment)is as follows:PID-3|DTP-1^^^&1.3.6.1.4.1.21367.2005.3.7& ISOSee RFC 3174 US Secure Hash Algorithm 1 (SHA1), September 2001The encoding is the Lexical Representation of hexBinary ([0-9a-fA-F]).See RFC 2616A DCE Universally Unique Identifier, represented in registry attributesusing the URN syntax for UUIDs:urn:uuid:9e0110f8-4748-4f1e-b0a8-cecae32209c7This data type describes a person along with the identifier by which he isknown in some domain (either the source domain or the XDS affinitydomain), using the HL7 v2.5 XCN data type. This data type contains,amongst others,IdentifierLast NameFirst NameSecond and Further Given NamesSuffixPrefixAssigning AuthorityAll of the HL7 v2.5 fields may be specified as optional components withthe following restrictions:Either name or an identifier shall be present. Inclusion of othercomponents is optional provided the slot value length restrictions imposedby ebXML3.0, 256 bytes, is not exceeded.If component 1 (ID Number) is specified, component 9 (AssigningAuthority) shall be present if available.The XDS XCN Component 9 is subject to the same the restrictions asdefined for the XDS CX data type component 4. Thus: the firstsubcomponent shall be empty, the second subcomponent must be an ISOOID (e.g., 1.2.840.113619.6.197), and the third subcomponent shall read‘ISO’.Any empty component shall be treated by the Document Registry as notspecified. This is in compliance with HL7 v2.5.Trailing delimiters are recommended to be trimmed off. DocumentRegistries shall ignore trailing delimiters. This is in compliance with HL7v2.5.A example of person name with ID number using this data type is asfollows:11375^Welby^Marcus^J^Jr. MD^Dr^^^&1.2.840.113619.6.197&ISOThis type provides the name and identification of an organization. Thisspecification restricts the coding to the following fields:XON.1 – Organization Name – this field is requiredXON.6.2 – Assigning Authority Universal Id – this field is required ifELGA XDS Metadaten.docx 61/64

XON.10 is valued and not an OIDXON.6.3 – Assigning Authority Universal Id Type – this field is requiredif XON.10 is valued and not an OID and shall have the value “ISO”XON.10 – Organization Identifier – this field is optionalNo other fields shall be specified. The XON data type in XDS Metadataresults in a valid encoding of an HL7 V2.5 XON encoding, with theexception of length limitations. Component lenth restrictions areunobserved, however, the total length including delimiters shall not exceedthe limit of the ebXML Slot Value.It is common for organizations to be uniquely identified by an OID. Insuch cases, the Organization Identifier(component 10) may contain theorganization’s OID. If the Organization Identifier is not an OID, themetadata use assumes that it has been assigned so that the composite IDcreated by combining components 6 and 10 is a unique identifier for theorganization. The XDS affinity domain must ensure that this assumptionis correct, through appropriate policies for assigning authorities.Examples:Some HospitalSome Hospital^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45Some Hospital^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^451025ELGA XDS Metadaten.docx 62/64

3.4. Tabellenverzeichnis1030Tabelle 1: Legende zur Spalte „Quelle“ der folgenden Tabelle 9Tabelle 2: Legende zur Spalte „Optionalität“ der folgenden Tabelle (IHE Optionalitäten) 9Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch) 10Tabelle 4: IHE Original Tabelle: “Table 4.1-4 Codes for Source/Query Column” 41Tabelle 5: IHE Original Tabelle: „Table 4.1-5 Document Metadata Attribute Definition” 41Tabelle 6: IHE Original Tabelle: „Codes for Source Type column“ 54Tabelle 7: IHE Original Tabelle: „XDSDocumentEntry Metadata“ 55Tabelle 8: IHE Original Tabelle: „Table 4.1-3 Data Types“ 6010353.5. RevisionslisteVers. Datum Autor Änderungsgrund0.05 16.05.2011 JB Ergebnisse aus dem technischen Online-Meeting2.00Beta2.00rc12.00FWGD12.08.2011 JB Erster „Release candidate“ des Dokuments für internenReview innerhalb der Arbeitsgruppe.30.08.2011 SSA Redaktionelle Überarbeitung.10.10.2011 JB Fertigstellung des „Final Working Group Draft“.Veröffentlicht für öffentlichen Review.2.01 11.06.2012 SSA Fertigstellung der gültigen Version 2.01 „Final“.Abgrenzung des Geltungsbereiches (XDSDocument-Entry), Überarbeitung „PracticeSettingCode“, Hinweis zuOID eingefügt (1.2.3), Überarbeitung der „parent-DocumentRelationship“, Typos ausgebessert2.01 21.12.2012 SSA Layout-Anpassung2.01a 07.03-2013 CSE Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16:"dieses Dokuments“ eingefügt; 363:displayNameOf($code), „Of“ gelöscht; 364: "aus"eingefügt; 814 und 818: ELGA-Interoperabilitätslevel ->Interoperabilitätsstufe (auch „2“-> „Enhanced“ etc.)Tabelle ab 357: classcode/typeCode "Spalte" eingefügtund erste Zeile eingefügtELGA XDS Metadaten.docx 63/64

Allgemein: Typos ausgebessertELGA XDS Metadaten.docx 64/64