Änderungen

ILF:XDS Metadaten (Version 3)

52.024 Bytes hinzugefügt, 16:38, 24. Jan. 2021

K

→‎Überblickstabelle der XDS Metadaten

=Überblickstabelle der XDS Metadaten=

14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.

=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 (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/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)

## '''name''' … Name der Organisation als String 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. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz"

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

# Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.

Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.

=====Spezifikation=====

'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

* Fall 1:

Element $inst/id[1] ist vorhanden

Attribut $inst/id[1]/@root ist vorhanden

Attribut $inst/id[1]/@extension ist nicht vorhanden

concat(

$inst/name,"^^^^^^^^^",

$inst/id[1]/@root

)

<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="">

<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>

</ValueList>

</Slot>

</Classification>

</pre>

*Fall 2:

Element $inst/id[1] ist vorhanden

Attribut $inst/id[1]/@root ist vorhanden

Attribut $inst/id[1]/@extension ist vorhanden

concat(

$inst/name,"^^^^^&",

$inst/id[1]/@root,"&ISO^^^^"

$inst/id[1]/@extension

)

<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="">

<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>

</ValueList>

</Slot>

</Classification>

</pre>

Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß [IHE ITI-TF3].

====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). Mindestens eine Person

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

=====Spezifikation für Personen=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$person = ClinicalDocument/author/assignedAuthor

concat(

$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"],"^^^&amp;",

$person/id/@root,"&amp;ISO"

)

<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="">

<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO

</Value>

</ValueList>

</Slot>

</Classification></pre>

Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].

=====Spezifikation für Software und Geräte=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$person = ClinicalDocument/author/assignedAuthor

concat(

"^",

$person/assignedAuthoringDevice/manufacturerModelName,"^",

$person/assignedAuthoringDevice/softwareName

)

<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="">

<Value>^Good Health System^Best Health Software Application</Value>

</ValueList>

</Slot>

</Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].

====authorRole====

Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

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''

# 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.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName

<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="">

<Value>Diensthabender Oberarzt</Value>

</ValueList>

</Slot>

</Classification>

</pre>

Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer

====authorSpeciality====

Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

* „Facharzt für Gynäkologie“

* „Facharzt für interne Medizin“

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

# 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 '''''[R2]'''''.

# Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

======Spezifikation======

'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/assignedAuthor/code/@displayName

<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="">

<Value>Anästhesiologie und Intensivmedizin</Value>

</ValueList>

</Slot>

</Classification>

</pre>

Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer

===classCode (und classCodeDisplayName)===

Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:

{| class="wikitable"

|- style="background:white"

|'''''classCode'''''

|'''''Dokumentenklasse in grober Granularität'''''

|- style="background:white"

|''typeCode''

|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten 2020#typeCode_.28und_typeCodeDisplayName.29|4.2.15]]

|}

====Spezifikation====

'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: TODO: translation/@displayName ist im CDA optional, in XDS jedoch 1..1 M

$code = ClinicalDocument/code/translation/@code

$displayName = ClinicalDocument/code/translation/@displayName

$codeSystem = ClinicalDocument/code/translation/@codeSystem

<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"

classifiedObject="theDocument" nodeRepresentation="$code">

<Name>

</Name>

<Value>urn:oid:$codeSystem</Value>

</ValueList>

</Slot>

</Classification>

</pre>

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).

===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:

<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"

classifiedObject="theDocument" nodeRepresentation="N">

<Name>

</Name>

</ValueList>

</Slot>

</Classification></pre>

===creationTime===

Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

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 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:20:14, Zeitzone GMT+1

CreationTime entfällt bei On-Demand Documents.

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/effectiveTime/@value = "20200511193000+0200"

<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">

</ValueList>

</Slot>

</ExtrinsicObject>

</pre>

Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3].

creationTime 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).

===eventCodeList (und eventCodeListDisplayName)===

Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt.

Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:

# Im CDA wird die Liste der Service-Events wie folgt abgelegt:

## 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 angibt

Die 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.

====Spezifikation====

'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Für jedes documentationOf Element 1..n:

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code

$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName

$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem

<Classification

classificationScheme=

"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"

classifiedObject="theDocument"

nodeRepresentation="$code">

<Value>urn:oid:$codeSystem</Value>

</ValueList>

</Slot>

<Name>

</Name>

</Classification>

</pre>

====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''' angewandt.

===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====

'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/languageCode/@code = "de-AT"

<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">

</ValueList>

</Slot>

</ExtrinsicObject>

</pre>

===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“).

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

'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.

# 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

====Spezifikation====

'''legalAuthenticator''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$person = ClinicalDocument/legalAuthenticator/assignedEntity

concat(

$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"],"^^^&amp;",

$person/id/@root,"&amp;ISO"

)

<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">

<Value>1234^Musterdoktor^Herbert^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</Value>

</ValueList>

</Slot>

</ExtrinsicObject>

</pre>

Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].

===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 '''''[R2]'''''.

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.

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 (HL7 IVL_TS) in wie folgt angeordnet werden:

### low … enthält das Startdatum

### high … enthält das Endedatum

### Andere im CDA möglichen Angaben (low/width, width/high, ...) sind nicht gestattet

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====Spezifikation====

'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value = "20200511193000+0200"

<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">

</ValueList>

</Slot>

</ExtrinsicObject>

</pre>

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).

'''serviceStopTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value = "20200516133000+0200"

<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">

</ValueList>

</Slot>

</ExtrinsicObject>

</pre>

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, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200516113000).

===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:

# 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) Achtung: Diese ID gelangt nicht in die Metadaten!

====Spezifikation====

'''sourcePatientId''' wird gemäß folgender Vorschrift zusammengesetzt:

concat(

ClinicalDocument/recordTarget/patientRole/id[1]/@extension,

"^^^&amp;",

ClinicalDocument/recordTarget/patientRole/id[1]/@root,

"&amp;ISO"

)

<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">

</ValueList>

</Slot>

</ExtrinsicObject>

</pre>

Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].

===sourcePatientInfo===

Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.

In 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. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.

===title===

Das ''title'' Element beschreibt den lesbaren Titel des Dokuments.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:

## ClinicalDocument/title

====Spezifikation====

'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/title

<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>

</Name>

</ExtrinsicObject>

</pre>

Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.

===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. 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.

====Spezifikation====

'''typeCode (und typeCodeDisplayName)''' wird wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:

$code = ClinicalDocument/code/@code

$displayName = ClinicalDocument/code/@displayName

$codeSystem = ClinicalDocument/code/@codeSystem

<Classification

classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"

classifiedObject="theDocument"

nodeRepresentation="$code">

<Name>

</Name>

<Value>urn:oid:$codeSystem</Value>

</ValueList>

</Slot>

</Classification>

</pre>

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).

====submissionSet.contentTypeCode====

Der contentTypeCode des SubmissionSets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.

$code = ClinicalDocument/code/@code

$displayName = ClinicalDocument/code/@displayName

$codeSystem = ClinicalDocument/code/@codeSystem

<RegistryPackage

status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"

<Classification

classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"

classifiedObject="theDocument"

nodeRepresentation="$code">

<Name>

</Name>

<Value>urn:oid:$codeSystem</Value>

</ValueList>

</Slot>

</Classification>

</RegistryPackage>

</pre>

===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

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====

uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:

Fall 1

Attribut ClinicalDocument/id/@extension ist nicht vorhanden

$value = concat(ClinicalDocument/id/@root)

Fall 2

Attribut ClinicalDocument/id/@extension ist vorhanden

$value = concat(

ClinicalDocument/id/@root, "^",

ClinicalDocument/id/@extension

)

<ExternalIdentifier

registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"

identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"

value="$value">

<Name>

</Name>

</ExternalIdentifier></pre>

===referenceIdList===

Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.

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 Vorgaben.

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

====Spezifikation====

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="IHE ITI TF-3"></ref>

{| 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.

Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO 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:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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.

…

…

</ClinicalDocument>

</pre>

Wie oben angeführt wird folgender CXi Wert erstellt:

<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>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

…

…

</ClinicalDocument>

</pre>

Wie oben angeführt wird folgender CXi Wert erstellt:

"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"

<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>">

<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.0.34.99.999&amp;amp;ISO</Value>

</ValueList>

</Slot>

</ExtrinsicObject>

</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 nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

Der intendedRecipient entfällt bei On-Demand Documents.

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==

===availabilityStatus===

Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments.

Mögliche Werte laut IHE sind:

* Approved

* Deprecated

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

availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.

<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:

$code = ClinicalDocument/hl7at:formatCode/@code

$displayName = gemäß Liste der in ELGA gültigen FormatCodes

$codeSystem = 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]

<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>

</Name>

<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" genutzt.

====Spezifikation====

'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem

<Classification

classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"

classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"

id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"

nodeRepresentation="$code">

<Name>

</Name>

<Value>urn:oid:$codeSystem</Value>

</ValueList>

</Slot>

</Classification>

</pre>

===mimeType===

Das ''mimeType'' 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 (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 Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen:

CDA R2: '''text/xml'''

DICOM/KOS: '''application/dicom'''

<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-Objekte.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

# Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in 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 für ELGA CDA Dokumente]]“ [1]):

### Versionierung (RPLC)

# Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:

## ClinicalDocument/relatedDocument/parentDocument

====Spezifikation====

'''parentDocumentId''' MUSS mit folgenden Elementen in CDA übereinstimmen:

concat(

ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",

ClinicalDocument/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. Es SOLL 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 wurde für die HL7-Austria Domäne wurde ein genau entsprechendes Element geschaffen, "hl7at:practiceSettingCode".

====Spezifikation====

'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:

$code = ClinicalDocument/hl7at:practiceSettingCode/@code

$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName

$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem

<Classification

classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"

classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"

id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"

nodeRepresentation="$code">

<Name>

</Name>

<Value>urn:oid:$codeSystem</Value>

</ValueList>

</Slot>

</Classification>

</pre>

===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 ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Für "Stable Document" DocumentEntry:

<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>

Für "On-Demand Document" DocumentEntry:

<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.

===elgaFlag===

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

* "true" oder

* "false"

====Spezifikation====

</ValueList>

</Slot>

</pre>

18 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.

===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====

<rim:Slot name="urn:elga-bes:elgaHash">

<rim:ValueList>

<rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>

</rim:ValueList>

</rim:Slot>

</pre>

=XDS Metadaten für CDA Dokumente=

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

Sabutsch

Passive Sichter, Bürokraten, Sichter, maintenanceshell, Prüfer, Administratoren

2.168

Bearbeitungen

Änderungen

ILF:XDS Metadaten (Version 3)

Navigationsmenü

Meine Werkzeuge

Namensräume

Varianten

Ansichten

Mehr

Suche

Navigation

Leitfäden

Wissensbasis

Hilfe

Werkzeuge