5.399
Bearbeitungen
Änderungen
→typeCode (und typeCodeDisplayName)
| Dokumentenklasse in grober Granularität.<br/> Siehe Kapitel 2.2.5
|}
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.
{{BeginValueSetBox}}
Zulässige Werte gemäß Value Set „'''ELGA_ Dokumentenklassen'''“. <br/>
Als typeCode MUSS das passende Element aus dem Lvl-Typ „1“ des Value Sets „'''ELGA_Dokumentklassen'''“ angegeben werden, weitere Informationen finden sich in den ELGA CDA Implementierungsleitfäden.
{{EndValueSetBox}}
====Spezifikation====
{{BeginYellowBox}}
'''typeCode (und typeCodeDisplayName)''' wird gemäß folgender Vorschrift zusammengesetzt:
$code = ClinicalDocument/code/@code
$displayName = ClinicalDocument/code/@displayName
$codeSystem = ClinicalDocument/code/@codeSystem
<pre class="orange">
<rim:Classification
classificationScheme=
"urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="theDocument"
nodeRepresentation="$code"
>
<rim:Name>
<rim:LocalizedString value="$displayName"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>urn:oid:$codeSystem</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
====Spezifikation====
{{BeginYellowBox}}
uniqueId wird gemäß folgender Vorschrift zusammengesetzt:<br/>
Fall 1<br/>
<pre class="orange">
Attribut ClinicalDocument/id/@extension ist nicht vorhanden
concat(ClinicalDocument/id/@root)
Bsp: 1.2.3.4.5.6.7.8.9
</pre>
Fall 2<br/>
Attribut ClinicalDocument/id/@extension ist vorhanden
<pre class="orange">
concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)
Bsp: 1.2.3.4.5.6.7.8.9^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
====Spezifikation====
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
Dieser Datentyp ist in IHE_ITI_TF_Rev10.0_Vol3_FT_2013-09-27 in der Table 4.2.3.1.7-2: Data Types in folgender Weise spezifiziert:
{| 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.<br/>
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}}
'''Beispiel:'''<br/>
Daten aus dem Beispiel 2 aus dem “Allgemeinen Implementierungsleitfaden“ [1]:
{{BeginYellowBox}}
referenceIdList wird gemäß folgender Vorschrift zusammengesetzt:
<pre class="orange">
<ClinicalDocument xmlns=„urn:hl7-org:v3“>
…
<id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBBBBB"/>
…
<setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZZZZZ"/>
<versionNumber value="2"/>
…
</ClinicalDocument>
</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, „&ISO“ anzugeben sind.
Daher würde sich aus dem Beispiel 2 aus dem Allgemeinen CDA ILF folgender CXi Wert ergeben:
"ZZZZZZZZZZZZZZZZZZZ^^^&1.2.40.0.34.99.111.1.1&ISO^urn:elga:iti:xds:2014:ownDocument_setId^&1.2.40.0.34.99.999&ISO"
{{EndYellowBox}}
Die homeCommunityId ist die eindeutige OID unter welcher die ELGA Affinity Domäne registriert ist.
===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 ist im Zuge des Einbringens von neuen Dokumenten („Submission“) immer auf “'''Approved'''” gesetzt.
===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 steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung, die Information lässt sich aber gegebenenfalls aus dem Element clinicalDocument.templateId ableiten.
====Dokumente in ELGA Interoperabilitätsstufe „Basic“ und „Structured“====
Die Angabe der ELGA-Interoperabilitäts-Stufe erfolgt durch den entsprechenden Formatcode (EIS_Basic) gemäß der in ELGA gültigen Formatcodes, beschrieben im Value Set „ELGA_FormatCode_VS“ (OID 1.2.40.0.34.10.61).
In den XDS-Metadaten wird '''nicht''' zwischen den EIS Basic“ und „Structured“ unterschieden, da sie sich hinsichtlich der technischen und semantischen Interoperabilität gleich verhalten.
Die Angabe des eingebetteten Dokuments ist zusätzlich notwendig, siehe 2.3.2.3.
====Dokumente in ELGA Interoperabilitätsstufe „Enhanced“ und „Full Support“====
Die Angabe erfolgt gemäß der Liste der in ELGA gültigen Formatcodes mit zusätzlicher Angabe der ELGA-Interoperabilitäts-Stufe (EIS „Enhanced“, …).
{{BeginValueSetBox}}
Zulässige Werte gemäß Value Set '''„ELGA_FormatCode_VS“'''. <br/>(aus der Codeliste ELGA_FormatCode 1.2.40.0.34.5.37)
{{EndValueSetBox}}
Beispiele:
* '''urn:elga:dissum:2011:EIS_Enhanced'''
** Gemäß dem Implementierungsleitfaden „Ärztlicher Entlassungsbrief“ [2], im ELGA-Interoperabilitätsstufe „Enhanced“ (Mindest-Stufe für strukturierte Dokumentinhalte).
* '''urn:elga:lab:2011:EIS_FullSupport'''
** Gemäß dem Implementierungsleitfaden „Laborbefund“ [4], im ELGA-Interoperabilitätsstufe „Full Support“..
====Dokumente in ELGA Interoperabilitätsstufe „Basic“: Zusatz erforderlich====
Folgt ein ELGA CDA Dokument einem Implementierungsleitfaden einer Fachdomäne in ELGA-Interoperabilitätsstufe „Basic“, so enthält dieses Dokument entweder unstrukturierten oder strukturierten Text gemäß CDA Level 1 oder ein eingebettetes Objekt (PDF, JPEG-Grafik, etc.).
{{BeginYellowBox}}
Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A 1a (gemäß „ISO 19005-1:2005 Level A conformance“) entsprechen.
{{EndYellowBox}}
'''Bemerkung:''' Folgt das Dokument lediglich den Basisanforderungen im Allgemeinen Implementierungsleitfaden „CDA Dokumente im österreichischen Gesundheitswesen“ [1], so liegt das Dokument implizit immer in der ELGA Interoperabilitätsstufe „Basic“ vor.
Im Fall eines Dokuments in ELGA Interoperabilitätsstufe „Basic“ MUSS der formatCode ebenfalls das „Format“ des unstrukturierten/eingebetteten Inhalts beinhalten. Das Format MUSS mittels „:“ (Doppelpunkt) am Ende angefügt werden.
{{BeginValueSetBox}}
Zulässige Zusätze gemäß Value Set '''„ELGA_FormatCodeZusatz_VS“'''.
{{EndValueSetBox}}
'''Beispiel:'''
* '''urn:elga:dissum:2015-v2.06:EIS_Basic:PDF'''<br/>
Gemäß dem Implementierungsleitfaden „Entlassungsbrief Ärztlich“ [2], im ELGA-Interoperabilitätslevel „Basic“/„Structured“, das eingebettete Objekt liegt als im PDF/A vor.
====Zusatz bei selbst-definierten maschinenlesbaren Elementen (Dokumente in EIS „Enhanced“ oder „Full Support“)====
Liegt ein CDA Dokument in ELGA Interoperabilitätsstufe „Enhanced“ oder „Full Support“ vor '''''und enthält das Dokument zusätzliche selbst-definierte maschinenlesbare Elemente (CDA Level 3 oder „Entries“)'''''', so ist dies durch den Zusatz eines Plus-Zeichens („+“) im Formatcode zu kennzeichnen.
{{BeginYellowBox}}
Die Kennzeichnung von Dokumenten mit selbst-definierten maschinenlesbaren Elementen ist ein „+“ (Plus-Zeichen) am Ende des Formatcodes.
{{EndYellowBox}}
'''Beispiele:'''
* '''urn:elga:dissum-n:2015-v2.06:EIS_Enhanced+'''
* '''urn:elga:lab:2015-v2.06:EIS_FullSupport+'''
====Bildungsregel für den formatCodeDisplayName ====
Der formatCodeDisplayName ist analog zum formatCode aus den displayNames der entsprechenden Value Sets 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====
{{BeginYellowBox}}
'''formatCode (und formatCodeDisplayName) '''wird gemäß folgender Vorschrift zusammengesetzt:
<span style="color:red;">$code</span> = gemäß Liste der in ELGA gültigen FormatCodes
<span style="color:red;">$displayName</span> = gemäß Liste der in ELGA gültigen FormatCodes
<span style="color:red;">$codeSystem</span> = OID der Liste der in ELGA gültigen FormatCodes,
fixiert mit OID 1.2.40.0.34.5.37
<pre class="orange">
<rim:Classification
classificationScheme=
"urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="theDocument"
nodeRepresentation="$code"
>
<rim:Name>
<rim:LocalizedString value="$displayName"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>urn:oid:$codeSystem</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
</pre>
{{EndYellowBox}}
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA.
Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginValueSetBox}}
Zulässige Werte gemäß Value Set „'''ELGA_ HealthcareFacilityTypeCode'''“.
{{EndValueSetBox}}
====Spezifikation====
{{BeginYellowBox}}
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird gemäß folgender Vorschrift zusammengesetzt:
<pre class="orange">
<span style="color:red;">$code </span>= Klassifizierung des GDA (Code)
<span style="color:red;">$displayName </span>= Klartext des angegebenen Codes
<span style="color:red;">$codeSystem </span>= OID der ausgebenden Stelle
<rim:Classification
classificationScheme=
"urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="theDocument"
nodeRepresentation="$code"
>
<rim:Name>
<rim:LocalizedString value="$displayName"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>urn:oid:$codeSystem</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
</pre>
{{EndYellowBox}}
===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<sup>15</sup> bis RFC 2049<sup>16</sup>.
Im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".
====Spezifikation====
{{BeginYellowBox}}
'''mimeType''' wird gemäß folgender Vorschrift gespeichert.
Folgende Mime-Types sind für Dokumente zugelassen:
CDA R2: '''text/xml'''
DICOM/KOS: '''application/dicom'''
<pre classs="orange">
<rim:ExtrinsicObject mimeType="text/xml"
id="urn:uuid:<entryUUID>"
objectType=
"urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
>
</pre>
{{EndYellowBox}}
===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 „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
<sup>15</sup> http://tools.ietf.org/html/rfc2045
<sup>16</sup> http://tools.ietf.org/html/rfc2049
====Spezifikation====
{{BeginYellowBox}}
'''parentDocumentId''' MUSS mit folgenden Elementen in CDA übereinstimmen:
<pre class="orange">
concat(
ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",
ClinicalDocument/relatedDocument/parentDocument/id/@extension
)
</pre>
{{EndYellowBox}}
{{BeginYellowBox}}
'''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen:
<pre class="orange">
ClinicalDocument/relatedDocument/@typeCode
</pre>
{{EndYellowBox}}
===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 steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginValueSetBox}}
Zulässige Werte gemäß Value Set '''„ELGA_PracticeSetting_VS“'''.
{{EndValueSetBox}}
====Spezifikation====
{{BeginYellowBox}}
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird gemäß folgender Vorschrift zusammengesetzt:
<span style="color:red;">$code</span> = Code aus ELGA_PracticeSetting
<span style="color:red;">$displayName</span> = Klartext des angegebenen Codes (displayName)
<span style="color:red;">$codeSystem</span> = OID des Codesystems (1.2.40.0.34.5.12)
<pre class="orange">
<rim:Classification
classificationScheme=
"urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="theDocument"
nodeRepresentation="$code"
>
<rim:Name>
<rim:LocalizedString value="$displayName"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>urn:oid:$codeSystem</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>
</pre>
{{EndYellowBox}}
===objectType ===
Das objectType Element gibt den Typ des Dokuments wieder, entweder ein „stabiles Dokument“ (stable document, SD) oder ein „On-demand Dokument“ (on-demand document, ODD). Der Datentyp ist eine UUID.
{{BeginValueSetBox}}
Zulässige Werte:<br/>
'''urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1''' (Stable Document)
'''urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248''' (On-Demand Document)
{{EndValueSetBox}}
2.4. 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.
2.4.1. elgaFlag
Das elgaFlag dient zur Kennzeichnung eines Dokuments als „ELGA-Dokument“ . 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-Zugriffs¬steuerungs¬fassade (ZGF) explizit gesetzt. „elgaFlag“ kann folgende Werte annehmen:
"true" oder
"false"
2.4.1.1. Spezifikation
<rim:Slot name="urn:elga-bes:elgaFlag">
<rim:ValueList>
<rim:Value>true</rim:Value>
</rim:ValueList>
</rim:Slot>
2.4.2. 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.
2.4.2.1. Spezifikation
<rim:Slot name="urn:elga-bes:elgaHash">
<rim:ValueList>
<rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
</rim:ValueList>
</rim:Slot>
