320
Bearbeitungen
Änderungen
→creationTime
{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
}}
{{#customtitle:XDS Metadaten 1}}
==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#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.
=====Spezifikation=====
{{BeginYellowBox}}
'''authorInstitution''' wird gemäß folgender Vorschrift zusammengesetzt:
{{BeginOrangeBox}}
<span style="color:red;">$inst </span> … ClinicalDocument/author/assignedAuthor/representedOrganization
{{EndOrangeBox}}
Attribut &inst/id[1]/@extension ist nicht vorhanden<br/>
{{BeginOrangeBox}}
concat(<br/><span style="color:red;">$inst</span>/name,"^^^^^^^^^",<br/><span style="color:red;">$inst</span>/id[1]/@root<br/>
)<br/>
Bsp: Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45
Attribut &inst/id[1]/@extension ist vorhanden<br/>
{{BeginOrangeBox}}
concat(<br/><span style="color:red;">$inst</span>/name,"^^^^^&",<br/><span style="color:red;">$inst</span>/id[1]/@root,"&ISO^^^^"<br/><span style="color:red;">$inst</span>/id[1]/@extension<br/>)<br/>
Bsp: Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^45
{{EndOrangeBox}}
{{EndYellowBox}}
====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:
# Der Autor (Person)
# Gerät oder Software als Autor
=====Spezifikation für Personen=====
{{BeginYellowBox}}
'''authorPerson''' wird gemäß folgender Vorschrift zusammengesetzt:
{{BeginOrangeBox}}
<span style="color:red"> $person </span> = ClinicalDocument/author/assignedAuthor
{{EndOrangeBox}}
{{BeginOrangeBox}}
concat(<br/>
<span style="color:red"> $person</span>/id/@extension,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/family,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/given[1],"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/given[2],"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/suffix,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br/><span style="color:red"> $person</span>/id/@root,"&amp;ISO"<br/>
)<br/>
Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO
{{EndOrangeBox}}
{{EndYellowBox}}
=====Spezifikation für Software und Geräte=====
{{BeginYellowBox}}
'''authorPerson''' wird gemäß folgender Vorschrift zusammengesetzt:
{{BeginOrangeBox}}
<span style="color:red"> $person </span> = ClinicalDocument/author/assignedAuthor
{{EndOrangeBox}}
concat(<br/>
"^",<br/>
<span style="color:red"> $person</span>/assignedAuthoringDevice/manufacturerModelName,"^",<br/><span style="color:red"> $person</span>/assignedAuthoringDevice/softwareName<br/>
)<br/>
Bsp: ^Good Health System^Best Health Software Application
{{EndYellowBox}}
====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.
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:
# 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=====
{{BeginYellowBox}}
'''authorRole''' wird gemäß folgender Vorschrift zusammengesetzt:
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:
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:
# 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======
{{BeginYellowBox}}
'''authorSpeciality''' wird gemäß folgender Vorschrift zusammengesetzt:
===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"
| ''typeCode''
| Dokumentenklasse in feiner Granularität.<br/> Siehe Kapitel 2[[ILF:XDS Metadaten#typeCode_.28und_typeCodeDisplayName.29|4.2.15]]
|}
! Code (LOINC)
! DisplayName
! Deutsche Sprachvariante<sup>1415</sup>
! Element in XDS
|- style="background:white"
| ''' 0-S'''| ''' 18842-5'''
| Discharge summary
| Entlassungsbrief
| '''classCode'''
|-style="background:white"
| 1-L
<sup>1415</sup> Die deutsche Sprachvariante wird im SVS Format als Attribut „deutsch“ geführt, im CSV-Export als Spalte „meaning“.
====Spezifikation====
{{EndYellowBox}}
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===
<span style="color:red;">$codeSystem</span> = ClinicalDocument/confidentialityCode/@codeSystem<br/>
<spre pre class="orange">
<rim:Classification
classificationScheme=
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/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====
{{BeginYellowBox}}
'''creationTime''' wird gemäß folgender Vorschrift zusammengesetzt:<br/>
<pre class="orange">
ClinicalDocument/effectiveTime/@value
</pre>
'''Hinweis: '''<br/>
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.
===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:
# 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:
====Spezifikation====
Für jedes documentationOf Element 1..n:<br/>
<span style="color:red;">$code </span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code<br/><span style="color:red;">$displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName<br/><span style="color:red;">$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem<br/>
<pre class="orange">
<rim:Classification
nodeRepresentation="$code">
<rim:Slot name="codingScheme">
<rim:ValueList>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString value="$displayName"/>
</rim:Name>
</rim:Classification>
</pre>
===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====
{{BeginYellowBox}}
===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[1]/assignedEntity<br/> '''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====
{{BeginYellowBox}}
'''legalAuthenticator''' wird gemäß folgender Vorschrift zusammengesetzt:<br/>{{BeginOrangeBox}}<pre classspan style="orangecolor:red">$person </span>= ClinicalDocument/legalAuthenticator[1]/assignedEntity{{EndOrangeBox}}{{BeginOrangeBox}}concat(<br /pre><pre classspan style="orangecolor:red">concat($person</span>/id/@extension,"^",<br /><span style="color:red"> $person</span>/assignedPerson/name/family,"^",<br /><span style="color:red"> $person</span>/assignedPerson/name/given[1],"^",<br /><span style="color:red"> $person</span>/assignedPerson/name/given[2],"^",<br /><span style="color:red"> $person</span>/assignedPerson/name/suffix,"^",<br /><span style="color:red"> $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br /><span style="color:red"> $person</span>/id/@root,"&amp;ISO"<br />)<br />Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</pre>{{EndOrangeBox}}
Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
{{EndYellowBox}}
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:
# Das Element serviceEvent beinhaltet unter anderem die folgenden Unterelemente:
====Spezifikation====
===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:
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wenn bekannt:
====Spezifikation====
<pre class="orange">
concat(
ClinicalDocument/recordTarget/patientRole/id[1]/@extension, "^^^&amp;",ClinicalDocument/recordTarget/patientRole/id[1]/@root, "&amp;ISO"
)
Bsp: 4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO
</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.Im Fall eines CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:# Laut Vorgabe der ELGA Gesundheitsdaten ist beim Patienten die Angabe der folgenden Elemente verpflichtend:* Verpflichtend** Lokale ID des Patienten aus dem System (id[1])** Patientenname (name)** Geschlecht (administrativeGender)** Geburtsdatum (birthTime)* Verpflichtend wenn bekannt** Sozialversicherungsnummer des Patienten (id[2])<br/><span style="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>** Adresse (addr)*** Beliebige Granularität
{{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 Sicherheits- und Schutzbedarf der Registry unnötig. Von einer Eine Speicherung in der Registry wird daher abgeratenist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}
===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 (empfohlene Variante)====
{{BeginYellowBox}}
'''sourcePatientInfotitle''' wird gemäß folgender Vorschrift zusammengesetzt:{{BeginOrangeBox}}$patientRole = ClinicalDocument/recordTarget/patientRole{{EndOrangeBox}}
<pre class="orange">
====Spezifikation===={{BeginYellowBox}}'''typeCode (und typeCodeDisplayName)''' wird gemäß folgender Vorschrift zusammengesetzt: <rim:Slot namespan style="sourcePatientInfocolor:red"> $code</span> = ClinicalDocument/code/@code<br/> <rimspan style="color:ValueListred"> $displayName</span> = ClinicalDocument/code/@displayName<br/> <rimspan style="color:Valuered">PID-3|$idcodeSystem</rim:Valuespan> = ClinicalDocument/code/@codeSystem<br/><pre class="orange"> <rim:Value>PIDClassification classificationScheme= "urn:uuid:f0306f51-975f-434e-a61c-5|c59651d33983" classifiedObject="theDocument" nodeRepresentation="$namecode"> </rim:ValueName> <rim:ValueLocalizedString value="$displayName"/>PID-7|$birthtime </rim:ValueName> <rim:ValueSlot name="codingScheme">PID-8|$gender </rim:ValueValueList> <rim:Value>PID-11|urn:oid:$addrcodeSystem</rim:Value> </rim:ValueList> </rim:Slot></rim:Classification>
</pre>
{{EndYellowBox}}
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 [R] des SubmissionSets soll wie der typeCode befüllt werden. ===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. 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 ====Optionale Spezifikation (mit demografischen Patientendaten)====
{{BeginYellowBox}}
<pre class="orange">
</pre>
Fall 2<br/>
Attribut ClinicalDocument/id/@extension ist vorhanden
<pre class="orange">
)
Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO^0815</pre>{{EndYellowBox}} ===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
{{BeginYellowBox}}
referenceIdList wird gemäß folgender Vorschrift zusammengesetzt:
<pre class="orange">
<rim:Slot nameClinicalDocument xmlns="sourcePatientInfo"> <rim„urn:ValueList> <rim:Value>PIDhl7-3|$id</rimorg:Valuev3“> <rim:Value>PID-5|$name…<id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBBBBB"/rim:Value> <rim:Value>PID-7|$birthtime</rim:Value>… <rim:Value>PID-8|$gender<setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZZZZZ"/rim:Value> <rim:Value>PID-11|$addr<versionNumber value="2"/rim:Value> </rim:ValueList>…</rim:SlotClinicalDocument>
</pre>
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.
Aus dem Beispiel oben wird daher folgender CXi Wert erstellt:
"ZZZZZZZZZZZZZZZZZZZ^^^&amp;1.2.40.0.34.99.111.1.1&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
{{EndYellowBox}}
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
{{BeginYellowBox}}
<pre class="orange">
<ClinicalDocumentxmlns=„urn:hl7-org:v3“>…<id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBBBBB"/title>Bsp…<setId root="2.25" extension="urn: Entlassungsbrief der chirurgischen Abteilunguuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2"/><versionNumber value="2"/> …</ClinicalDocument>
</pre>
Wiederum gilt die Vorgabe:
concat(ClinicalDocument/setId/@extension, "^^^", ClinicalDocument/setId/@root,
"^", "urn:elga:iti:xds:2014:ownDocument_setId", "^", homeCommunityId)
Daher würde sich in diesem Fall folgender CXi Wert ergeben:
"<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"
{{EndYellowBox}}
===typeCode (und typeCodeDisplayName)intendedRecipient===Das ''typeCode'' Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der intendedRecipient notwendig. Derzeit wird dieses Element beschreibt den Dokumententypin ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, dem das Dokument angehört. Der Dokumententyp ist folgt die Spezialisierung einer Dokumentenklasse, jeder Dokumententyp gehört zu genau einer DokumentenklasseSpezifikation dieses Elementes.