| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA. z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''RX'''||'''RX'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
# Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element „legalAuthenticator“ abgelegt:
## ClinicalDocument/legalAuthenticator/assignedEntity
{{BeginYellowBox}}
'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.
{{EndYellowBox}}
# Die vidierende Person
## Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente:
===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 Speicherung in der Registry wird daher abgeraten.
{{EndYellowBox}}
====Spezifikation (empfohlene Variante, ohne demografischen Patientendaten)====
'''sourcePatientInfo''' wirdwird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
$patientRole = ClinicalDocument/recordTarget/patientRole
<span>$id </span>= concat(
$patientRole/id[1]/@extension, "^^^&amp;",
$patientRole/id[1]/@root, "&amp;ISO"
)
Bsp: 4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO
<span>$name </span>= ""
<span>$birthtime </span>= ""
<span>$gender </span> = ""
<span>$addr </span>= ""
<pre class="ILFgreen">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
====Optionale Spezifikation (mit demografischen Patientendaten)====
'''sourcePatientInfo''' wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
$patientRole = ClinicalDocument/recordTarget/patientRole
$id = concat(
$patientRole/id[1]/@extension, "^^^&amp;",
$patientRole/id[1]/@root, "&amp;ISO"
)
Bsp: 4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO
$name = concat(
$patientRole/patient/name/family,"^",
$patientRole/patient/name/given[1],"^",
$patientRole/patient/name/given[2],"^",
$patientRole/patient/name/suffix,"^",
$patientRole/patient/name/prefix[@qualifier="AC"]
)
Bsp: Mustermann^Herbert^^^Ing.
$birthtime = $patientRole/patient/birthtime/@value
Bsp: 19650120
$gender = $patientRole/patient/administrativeGenderCode/@code
Bsp: M
$addr = concat(
$patientRole/addr/streetAddressLine,"^^",
$patientRole/addr/city,"^",
$patientRole/addr/state,"^",
$patientRole/addr/postalCode,"^",
$patientRole/addr/country
)
… oder …
$addr = concat(
concat(
$patientRole/addr/streetName," ",$patientRole/addr/houseNumber
),"^^",
$patientRole/addr/city,"^",
$patientRole/addr/state,"^",
$patientRole/addr/postalCode,"^",
$patientRole/addr/country
)
Bsp: Mustergasse 11^^Wien^W^1230^Austria
{{BeginYellowBox}}
Bemerkung: Wenn In ELGA werden die Adresse nicht in der erforderlichen Granularität Elemente name, administrativeGender, birthTime und addr NICHT zur Verfügung stehtIdentifikation des Patienten benötigt, dann wird das Element PIDdie Speicherung dieser Daten erhöht aber den Sicherheits-11 nicht angeführtund Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}
<pre class="ILFgreen">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
===title===
