Änderungen

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen. <br />

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

# GDAsDie ''authorInstitution'' benötigt einen Namen und eine OID, in dessen Gültigkeitsbereich Dokumente erstellt die aus dem GDA-Index abgleitet werden können sind seitens der Basiskomponente „GDA Index“ mit einer eindeutigen OID ausgestattet. kann# Falls mehrere ID*''id'' OID der Organisation aus dem GDA-Elemente angegeben sind, ist id[1] Index (die erste IDmuss ermittelt werden) zu verwenden. #*''name'' Name der Organisation als String

<span >$instname</span> … ClinicalDocument/author/assignedAuthor/representedOrganizationName der Organisation, die die Studie erstellt hat

* Fall 1:<br/>Element $inst/id[1] ist vorhanden<br/>Attribut $inst/id[1]/@root ist vorhanden<br/>Attribut $inst/id[1]/@extension ist nicht vorhanden<br/> concat(<br/><span>$inst</span>/name,"^^^^^^^^^",<br/><span>$inst</span>/id[1]/@root<br/>)<br/>

====authorPerson====Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (also nicht die Schreibkraftoptionalen). Mindestens eine PersonDICOM Attributen:

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:# Laut Festlegung wird Die Person kann aus den DICOM Attributen der Autor im Header-Element „author“ abgelegt:Studie abgleitet werden#*Identifikator: Code aus Attribut „Performing Physicians Identification Sequence“, (0008,1052), Datentyp SQ[[# ClinicalDocument/author/assignedAuthor%20ftn1|[1]]], wenn vorhanden# Der Autor *Name: Attribut „Performing Physicians Name“, (0008,1050), Datentyp PN (Personentspricht den ersten 5 Feldern von HL7 V2 Datenyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen)## Ein Personenelement enthält unter anderem die folgenden Unterelemente:### id … ID . Wenn mehrere Namen vorhanden sind, ist der Person mit den folgenden Attributen:erste zu übernehmen.#### @root … *Root : OID des ID Pools, oder direkte die -Unterknoten für Personen (entsprechend der Organisations-OID der Person (ohne @extensionaus dem GDA-AttributIndex)----[[#### @extension … Eigentliche ID aus dem gegebenen ID Pool %20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (falls die @root nicht direkt die Person identifiziert0008,0100)### assignedPerson#### Enthält ein HL7 Personen-ElementCode in (0040, welches das Namen-Element zur 1101) Person enthältIdentification Code Sequence##### name# Gerät oder Software als Autor ## Alternativ zu einer Falls die durchführende Person nicht ermittelt werden kann auch ein , soll das 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 aus den DICOM Attribut Modality der Software Studie abgleitet werden#*Modalität[[#### manufacturerModelName%20ftn1|[2]]]: Attribut „Modality“, (0008,0060)#### Enthält ein Element mit dem Namen des Geräts oder der Software *Hersteller: Attribut „Manufacturer“, (0008,0070)#*Modellname: Attribut „ Manufacturer's Model Name“, (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html### softwareNamesect_C.7.3.1.1.1</nowiki>

<span > $person</span> id = ClinicalDocument/author/assignedAuthorCode #1 aus (0008,1052) Performing Physicians Identification Sequence

concat(<br/><span > $person</span>/id/@extension= (0008,"^",<br/>1050) Performing Physicians Name <span > $person</span>/assignedPerson/name/family,"^",<br/>root = OID-Knoten für den Personenidentifikator <span > $person</span>/assignedPerson/name/given[1],"^",<br/><span > $person</span>/assignedPerson/name/given[2],"^",concat(<br/><span > $personid</span>/assignedPerson/name/suffix,"^",<br/><span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;amp;",<br/><span > $person</span>/id/@root,"&amp;amp;ISO"<br/>)<br/>

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

<span > $person</span> Modality = ClinicalDocument/author/assignedAuthorModality (0008,0060)  $Manufacturer = Manufacturer (0008,0070) $ManufacturersModelName = Manufacturer's Model Name (0008,1090)  concat( "^", $Modality,"^", $Manufacturer,"^",

concat(<br/>"^",<br/><span > $person</span>/assignedAuthoringDevice/manufacturerModelName,"^",<br/>ManufacturersModelName <span > $person</span>/assignedAuthoringDevice/softwareName<br/>)<br/><pre class="ilfbox_code">

<Value>^Good Health SystemCT^Best Health Software ApplicationGeräthersteller^Gerätename</Value>

Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments (bzw. das erstellende Gerät) zum Zeitpunkt der Dokumentation innehatte.  Dieser Leitfaden beschreibt keine Einschränkungen für die Verwendung.

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:*„Radiologie“ ClinicalDocument/author/functionCode/@displayName<br/><pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation=""> <Slot name="authorRole"> <ValueList> <Value>Diensthabender Oberarzt</Value> </ValueList> </Slot> </Classification></pre>{{BeginYellowBox}}Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer{{EndYellowBox}}*„Modalität“

ClinicalDocumentBsp: Fachärztin/author/assignedAuthor/code/@displayNameFacharzt für Radiologie<br/>

<Value>Anästhesiologie und IntensivmedizinFachärztin/Facharzt für Radiologie</Value>

Wenn eine Person als Autor vorhanden ist, MUSS der Wert einem DisplayName aus dem Value Set „ELGA_AuthorSpeciality“ entsprechen.  Im Fall von Geräten oder Software als Autor sowie in ODD bleibt MUSS das Element leerbleiben. 

Das ''classCode'' Element beschreibt die Dokumentenklasse klassifiziert (grobe Granularität) der das Dokument angehört registrierte Objekt und ist relevant für das BerechtigungssystemBerechti-gungssystem.

TODOEs wird ein fester Wert gesetzt: <span>translation/@displayName</span> ist im CDA optional, in XDS jedoch 55113-5 „Key images Document Radiology“ (LOINC: 2.16.840.1.113883.6.1 M)

$code = ClinicalDocument/code/translation/@code"55113-5"<br />$displayName = ClinicalDocument/code/translation/@displayName"Key images Document Radiology"<br />$codeSystem = ClinicalDocument/code/translation/@codeSystem"2.16.840.1.113883.6.1"<br />

Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DokumentsDICOM KOS Objektes.

Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich aus-schließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf „normal“ (N) gesetzt. Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich und . Es wird fix auf "N" (normal) gesetzt.der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:

Es wird der Vertraulichkeitscode aus dem CDA Header Element Zulässige Werte gemäß folgender Spezifikation übernommenValue Set „[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]“.

confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildetfolgender Vorschrift zusammengesetzt: $code = "N"<br />$displayName = "normal"<br />$codeSystem = "2.16.840.1.113883.5.25" <br/>

Das creationTime Element beschreibt den Zeitpunkt der DokumentenerstellungErstellung des registrieren Doku-ments oder Objektes. Das XDS Profil schreibt vorEs soll die Zeit angegeben werden, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.die diese Erstellungszeit am besten beschreibt:

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Im CDA wird Erstellungsdatum der Zeitpunkt Studie (aus dem KOS Objekt oder der Dokumentenerstellung wie folgt abgelegtDICOM Studie):## ClinicalDocument/effectiveTime*Study Date (0008,0020)# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.*Study Time (0008,0030)#Im CDA wird jeweils Sollten das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das medizinisch zutreffendste Datum angeführt. Die Bedeutung Erstellungsdatum des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert KOS Objektes verwendet werden.:# Ein einfaches Zeitelement *Content Date (HL7 TS0008,0023) in CDA beinhaltet unter anderem die folgenden Attribute:# @value … enthält das Datum in folgenden möglichen Formen*Content Time (0008,0033)## YYYYMMDDDas XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''[[## YYYYMMDDhhmmss%20ftn1|[+/-3]]]HHMM berücksichtigt werden, falls angegeben: *Timezone Offset From UTC (Zeitzone0008,0201)### Bsp*Es DÜRFEN NUR folgende Datumsformen verwendet werden: 20081224082015+0100*#YYYYMMDD*## Für: 24.12.2008, 08:20:14, Zeitzone GMT+1{{BeginYellowBox}}CreationTime entfällt bei On-Demand Documents.{{EndYellowBox}}YYYYMMDDhhmmss

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>ClinicalDocument/effectiveTime/@value $date = (0008,0020) Study Date – oder (0008,0023) Content Date $time = "20200511193000(0008,0030) Study Time - oder (0008,0033) Content Time +0200"(0008,0201) Timezone Offset from UTC   concat( @date, @time )<br /><pre class="ilfbox_code">

<Value>2020051117300020100511134500</Value>

creationTime Das Datum MUSS – entsprechend der tatsächlichen Angabe in CDA – immer entweder mit 8 Stellen (YYYYMMDD) -stellig oder 14 -stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (YYYYMMDDhhmmssz.B. 20160518 in 20160518000000) 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, '''daher MUSS '''diese eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000)Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3]. <br />{{EndYellowBox}}

Im Fall eines Entlassungsbriefs beschreibt dieses Dieses Element die enthält eine Liste der vollbrachten erbrachten Gesundheitsdienstleistungen für den im , die das registrierte Dokument dokumentierten Patientenkontaktoder Objekt beschreibt.  Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:# Im CDA von Bilddaten findet der APPC Anwendung. (Die korrekte Verwendung von APPC in DICOM Objekten wird die Liste im entsprechenden Leitfaden der Service-Events wie folgt abgelegtDICOM Austria spezifiziert:„Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten“.[[## ClinicalDocument/documentationOf/serviceEventftn4|[4]]]) # Mehrere dieser Service-Es können mehrere APPC bzw. Events können durch beliebig viele „documentationOf“ Elemente ausgedrückt (und displayNames) angegeben werden.# Laut Vorgabe Sind mehrere Events vorhanden, muss die Reihenfolge der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2]und zugehörigen displayNames gleich sein.----[[# Ein serviceEvent Element ftnref4|[4]]] DICOM Austria: „Leitfaden zur Ermittlung und Speicherung des APPC in CDA beinhaltet unter anderem die folgenden ElementeDICOM Daten“, 22.01.2020, <nowiki>https:## code … ein Code//collab.dicom-Element, welches die Art des ServiceEvents angibtDie Vorschriften austria.at/display/OBD/Leitfaden+zur Befüllung der CDA R2 ServiceEvents leiten sich vom Allgemeinen +Ermittlung+und vom jeweiligen speziellen CDA Implementierungsleitfäden ab+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12. In den speziellen Implementierungsleitfäden wird definiert, ob im Service Event eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat3. 2020)

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

Für jedes documentationOf Element 1..n:<br/>

<span >$code </span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@APPC code(alle Achsen) z.B. "2.4.0.5-3-3"<br/><span >$displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@APPC displayNamez.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule"<br/><span >$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystemOID des Codesystems APPC: 1.2.40.0.34.5.38<br/>

Das ''languageCode'' Element beschreibt den Sprachcode in dem das ein Dokument oder Objekt verfasst bzw. beschlagwortet ist. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header ElementenDerzeit wird ein fester Wert vorgeschrieben:'''de-AT'''

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

Das Dieses Element darf für XDS-I nicht verwendet werden [NP].  ===serviceStartTime / serviceStopTime===Die ''legalAuthenticatorserviceStartTime/serviceStopTime'' Element beschreibt Elemente beschreiben die Identifikation Zeitpunkte des Beginns und demographische Informationen Beendigung des Patientenkontakts bzw. der PersonUntersuchung. Für KOS-Objekte kann die ''serviceStartTime'' aus dem Objekt gemappt werden:  #Das Erstellungsdatum des DICOM Objektes aus den Attributen des KOS Objektes:#*Study Date (0008, welche das Dokument rechtlich verbindlich unterzeichnet hat. Entfällt bei automatisch erstellten und nicht durch natürliche Personen freigegebenen Dokumenten 0020)#*Study Time (0008,0030)#Alle Zeiten müssen in XDS in UTC konvertiert werden, daher sollte Timezone Offset From UTC berücksichtigt werden, falls angegeben:#*Timezone Offset From UTC (z.B. On-Demand Documents wie der „Medikationsliste“0008,0201).

Für CDA R2 Dokumente gilt folgende Verknüpfung mit den CDA Header Elementen:# Laut Festlegung die serviceStopTime steht kein Mapping zur Verfügung und wird die Person, welche das Dokument vidiert hat, im Element „legalAuthenticator“ abgelegt:## ClinicalDocument/legalAuthenticator/assignedEntity{{BeginYellowBox}}'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticatordaher nicht angegeben [1NP]) übernommen werden.{{EndYellowBox}}# Die vidierende Person## Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente:### id … ID der Person mit den folgenden Attributen:#### @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)#### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)### assignedEntity#### Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält##### Name

'''legalAuthenticatorserviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>

concat(<br/>Study Time + Timezone Offset from UTC<span > $person</span>/id/@extension,"^",<br/><span > $person</span>/assignedPerson/name/family,"^",<br/><span > $person</span>/assignedPerson/name/given[1],"^",<br/><span > $person</span>/assignedPerson/name/given[2],"^",<br/>)<span > $person</span>/assignedPerson/name/suffix,"^",<br/><span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;amp;",<br/><span > $person</span>/id/@root,"&amp;amp;ISO"<br/>)<br/><pre class="ilfbox_code">

<Slot name="legalAuthenticatorserviceStartTime">

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

Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI{{BeginYellowBox}}Das Datum '''MUSS''' immer entweder 8-TF3]stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 20160518 in 20160518000000).

===serviceStartTime / serviceStopTime===Die In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher ''serviceStartTime/serviceStopTime'MUSS' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlung. '' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!

Wenn vorhanden, beinhaltet dieses ===sourcePatientId===Das ''sourcePatientId'' Element beschreibt die semantisch korrekten Informationen zu Start- und Enddatum gemäß der jeweiligen Fachdomäne (z.B.: das Aufnahme/Entlassungsdatum Patienten ID des Patienten im Falle von Entlassungsbriefen aus stationärer Behandlung). Die relevanten Informationen dazu finden sich in den speziellen ELGA CDA Implementierungsleitfädenlokalen Informationssystem des GDA.

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 Für ein Zeitintervall (HL7 IVL_TS) in wie folgt angeordnet werdenMapping aus KOS steht folgendes Attribut zur Verfügung:### low … enthält das Startdatum### high … enthält das Endedatum### Andere im CDA möglichen Angaben (low/width, width/high, ...) sind nicht gestattet

TODO(0010,0020) Patient ID (VR: '''Welches serviceEvent''' für das Mapping verwendet wirdLO, muss im Speziellen Leitfaden angegeben sein.VM:1)

'''serviceStartTimesourcePatientId''' wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value = "20200511193000+0200"<pre class$patientID ="ilfbox_code">(0010,0020) Patient ID<ExtrinsicObject mimeType="text/xml" objectType$oid ="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"OID des lokalen Patientenidentifikators status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"> <Slot name="serviceStartTime"> <ValueList> <Value>20200511173000</Value> </ValueList> </Slot></ExtrinsicObject></pre>{{BeginYellowBox}}Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen concat(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$patientID, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000). {{EndYellowBox}}

<Slot name="serviceStopTimesourcePatientId">

<Value>202005161130004711^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO</Value>

{{BeginYellowBox}}Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ Dies entspricht einer Transformation auf andere Formate ist nicht zulässigden HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].

Wenn Datumselemente ===sourcePatientInfo===Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (zKapitel 3.2.12 sourcePatientId gemappt und verwendet[[#%20ftn1|[5]]].----[[#%20ftnref1|[5]]] IHE RAD TF vol3 Vorgaben Table 4.68.4.1.B2. 20200516133000+0200)3-1: XDS-I. b-specific Metadata Requirements{{BeginYellowBox}}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 XDS Metadaten können jedoch keine Zeitzonen abgebildet werdenSicherheits- und Schutzbedarf der Registry unnötig. Falls eine Zeit angegeben Eine Speicherung in der Registry ist, '''MUSS''' diese zuvor gemäß im Sinne der Zeitzone in UTC Zeit konvertiert werden! Datenminimierung (z.B. in 20200516113000DSGVO)NICHT ERLAUBT.

===sourcePatientId=Spezifikation (empfohlene Variante)====Das ''sourcePatientId'sourcePatientInfo''' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

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 = concat(nur wenn bekannt)<br/><span style="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>

ClinicalDocument/recordTarget/patientRole/id[Bsp: 4711^^^&1]/@extension,.2.3.4.5.6.7.8.9&ISO

$name = "^^^&amp;amp;",

$gender = "&amp;amp;ISO"

)$addr = "" <br /><pre class="ilfbox_code">

<Slot name="sourcePatientIdsourcePatientInfo">

<Value>4711^^^&amp;amp;1.2.PID-3.4.|$id</Value><Value>PID-5.6.|$name</Value><Value>PID-7.|$birthtime</Value><Value>PID-8.9&amp;amp;ISO|$gender</Value><Value>PID-11|$addr</Value>

</pre><br />Dies entspricht einer Transformation auf ===title===Das ''title'' Element beschreibt den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3]lesbaren Titel des registrierten Objektes.

{{BeginYellowBox}}#Wenn die Informationen aus der Studie verfügbar sind: Study Description#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +In ELGA werden die Elemente name#*(0008, administrativeGender1030) Study Description, birthTime und addr NICHT zur Identifikation des Patienten benötigtDatentyp LO#Wenn mehrere Modailty Codes in der Studie verfügbar sind, soll entweder die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötigrelevante Modality verwendet werden oder alle zum Titel hinzugefügt werden. Eine Speicherung in der Registry #Wenn Study Description nicht angegeben ist im Sinne der Datenminimierung , muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. (DSGVO) NICHT ERLAUBT„CT.Unpaarig.Unbestimmte Proze-dur.{{EndYellowBox}}Lendenwirbelsäule“

===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<br /title>

ClinicalDocument/title concat(  Modality, " ", Study Description )<pre class="ilfbox_code">

<LocalizedString charset="UTF-8" value="Entlassungsbrief der chirurgischen AbteilungDX Digitales Röntgen des Schädels" xml:lang="de-AT" />

| '''typeCode'''| '''Dokumentenklasse in feiner Granularität (Spezialisierung).'''

| classCode| Dokumentenklasse in grober Granularität.<br/> Siehe Kapitel [[ILF:XDS Metadaten 2020#classCode_.28und_classCodeDisplayName.29|classCode]]

 # Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:## ClinicalDocument/code# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.# Ein Code-Element in CDA beinhaltet unter anderem die folgenden Attribute:## @code … Codierter Wert der Dokumentenklasse### Bsp: Code „11490-0“## @displayName … Lesbarer Wert der Dokumentenklasse### Bsp: „Discharge summarization note (physician)”## @codeSystem … Codierter Wert des zugrundliegenden Codesystems### Bsp: „2.16.840.1.113883.6.1“# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.

<span > $code</span> = ClinicalDocument/code/@code<br/><span > $displayName</span> = ClinicalDocument/code/@displayName<br/><span > $codeSystem</span> = ClinicalDocument/code/@codeSystem<br/>

 # Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:## ClinicalDocument/id

uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br/>

Fall 1<br/>

Fall 2<br/>

 # Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend: ## ClinicalDocument/setId

 * Approved* Deprecated

====Bildungsregel für den formatCodeDisplayName ====

 * '''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''* '''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''* '''ELGA Laborbefund, EIS Full Support v2.06+'''

'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br/><span >$code</span> = ClinicalDocument/hl7at:formatCode/@code <br/><span >$displayName</span> = gemäß Liste der in ELGA gültigen FormatCodes<br/><span >$codeSystem</span> = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]

<span >$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

<span >$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

<span >$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem

Folgende Mime-Types sind für Dokumente zugelassen:<br/>CDA R2: '''text/xml'''<br/>DICOM/KOS: '''application/dicom'''<br/>

# 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

<span >$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br/><span >$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br/><span >$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br/>

===objectType ===

 * "true" oder* "false"