2.168
Bearbeitungen
Änderungen
K
<br />
<p style="page-break-before: always"></p>
<br />
*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>concat
<br />
Um 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. Für CDA-Befunde sind zwei unterschiedliche Einträge in referenceIdList vorgesehen: #eindeutige Identifikation aller Dokumente eines Dokumentenstammes (, d.h. vorhergehende und auch zukünftige Versionen(ownDocument_setId) innerhalb der XDS#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinichen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendigObjekte für Bilddaten (encounterId).
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.
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====
'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den entsprechenden CDA Header 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 =====Spezifikation=====ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
keine Bearbeitungszusammenfassung
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.79.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.79.3
|Realm = Austria
}}
Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt. <br />
Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> . <br />
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}
==Bedienungshinweise==
<br />
<p style="page-break-before: always"></p>
'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
{{EndYellowBox}}
'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<span>$name</span> … Name der Organisation, die die Studie erstellt hat
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß [IHE ITI-TF3].
{{BeginYellowBox}}
'''Achtung:''' Die Identifikationsdaten und Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
$root = OID-Knoten für den Personenidentifikator
concat(<br />
</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 Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).
In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!
{{EndYellowBox}}
)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel [[ILF:XDS_Metadaten_(Version_3)#sourcePatientId|SourcePatientId]] gemappt und verwendet.
{{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. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
#Wenn mehrere Modailty Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}<br />
====Spezifikation====
#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)
#Verlinkung zwischen DICOM KOS-Objekten und einer Aufenthaltszahl (encounterId)
'''Weitere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.'''
Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />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.'''
|}
{{BeginYellowBox}}
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList> <Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999
<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
====Referenz zwischen Dokument und Studie ('''Accession Number''')====
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList> <Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
</ValueList>
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"
====Weitere Einträge Referenz zwischen Aufenthaltszahl und Studie (encounterId)====Durch encounterId wird die Verlinkung sämtlicher Bilddaten (Dicom KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-I Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-I Metadaten der referenceIDListzu gruppierenden Objekte strukturiert wird. =====Spezifikation=====Über die bereits genannten Einträge hinaus sind weitere Einträge Bei der Registrierung von KOS Objekten KANN eine encounterId in den XDS-I Metadaten in der referenceIdList erlaubtReferenceIdList angegeben werden. encounterId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: $id = Aufenthaltszahl z.B. Az123456 $root = OID der Liste der Aufenthaltszahlen der Organisation, z.B. 1.2.40.0.34.99.4613.3.4
( $id, "^^^", "&amp;" $root, "&amp;ISO", "^", "<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>" )<pre class="ilfbox_code"> <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>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki></Value> </ValueList> </Slot> </ExtrinsicObject></pre> ====Weitere Einträge der referenceIDList====Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt: *'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki> Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code"> <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>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^amp;1.2.40.0.34.99.999
</ExtrinsicObject>
</pre>
<references />
===intendedRecipient===
Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}
Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}
CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.
====authorInstitution====
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}
=====Spezifikation=====
'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<span>$inst</span> … ClinicalDocument/author/assignedAuthor/representedOrganization
|Dokumentenklasse in feiner Granularität.<br /> Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}
====Spezifikation====
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).
{{EndYellowBox}}
'''serviceStopTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
===referenceIdList===
{{BeginYellowBox}}
Im Rahmen von ELGA ist MUSS die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringenstrukturiert sein. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
Dieser Datentyp ist in IHE ITI TF vol3 Data Types in folgender Weise spezifiziert:<ref name="IHE ITI TF-3"></ref>
{| class="wikitable" width="100%"
Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />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.'''
|}
{{BeginYellowBox}}
'''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.{{EndYellowBox}}
====Versionierung bzw. Versionsklammer (ownDocument_setId)====
Um eine eindeutige Identifikation aller registrierten Versionen eines CDA R2 Dokumentes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines CDA R2 Dokuments mit derselben ID eindeutig zu kennzeichnen. Für ELGA wird dazu ownDocument_setId definiert, die auf dem CDA Header-Element "setId" basiert.
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).''"
#Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend:
#*ClinicalDocument/setId [M]
concat
(
ClinicalDocument/setId/@extension, "^^^", "&amp;",
ClinicalDocument/setId/@root, "&amp;ISO", "^",
"urn:elga:iti:xds:2014:ownDocument_setId", "^", "&amp;",
homeCommunityId, "&amp;ISO"
)
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>
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<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>
====Verlinkung via Aufenthaltszahl (encounterId)====
Durch encounterId wird die Verlinkung sämtlicher Befunde oder Bilddaten (siehe [[ILF:XDS_Metadaten_(Version_3)#referenceIdList|hier]] für Dicom KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-/XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.
<br />
=====Spezifikation=====
encounterId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
concat
(
ClinicalDocument/componentOf/encompassingEncounter/id/@extension, "^^^", "&amp;",
ClinicalDocument/componentOf/encompassingEncounter/id/@root, "&amp;ISO", "^",
"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"
)
Bitte beachten Sie, dass die ClinicalDocument/componentOf/encompassingEncounter/id/@root
in der Schreibweise "&", OID-Wert, "&ISO" anzugeben ist.
Wie oben angeführt wird folgender CXi Wert erstellt:<pre class="ilfbox_code">
<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>Az123456^^^&amp;1.2.40.0.34.99.4613.3.4
&amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki></ValueList>
</Slot>
</ExtrinsicObject>
</pre>
<br />
===intendedRecipient===
ClinicalDocument/relatedDocument/parentDocument/id/@extension
)
'''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen:
ClinicalDocument/relatedDocument/@typeCode
===practiceSettingCode (und practiceSettingCodeDisplayName)===
</Slot>
</pre>
<sup>18</sup> 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.
</rim:Slot>
</pre>
<!--Anhänge-->
=Anhänge=
