Allgemeine Richtlinien für die Implementierung des e-Impfpasses

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
(Betrachte alle ausstehenden Änderungen)
[unmarkierte Version][Markierung ausstehend]
(→‎Publikation der Value Sets am Terminologieserver)
 
(46 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 19: Zeile 19:
 
==Allgemeine Richtlinien für die Implementierung des e-Impfpasses==
 
==Allgemeine Richtlinien für die Implementierung des e-Impfpasses==
 
===Verwendung von Schlüsselwörtern===
 
===Verwendung von Schlüsselwörtern===
−
Wenn im Text die Verbindlichkeit von Vorgaben angegeben wird, wird das durch Schlüsselwörter gekennzeichnet [gemäß RFC 2119], die in Majuskeln (Großbuchstaben) geschrieben werden. Die Angabe der Verbindlichkeit ersetzt nicht die Angabe von Kardinalität oder Nullwerten (die in HL7 Version 3 als NullFlavors ausgedrückt werden).
+
Wenn im Text die Verbindlichkeit von Vorgaben angegeben wird, wird das durch Schlüsselwörter gekennzeichnet [gemäß RFC 2119], die in Majuskeln (Großbuchstaben) geschrieben werden. Die Angabe der Verbindlichkeit ersetzt nicht die Angabe von Kardinalität oder Nullwerten (die in HL7 Version 3 als nullFlavors ausgedrückt werden).
  
−
* MUSS bedeutet eine verpflichtend einzuhaltende Vorschrift (Gebot). Entspricht den Konformitätskriterien '''''[R]''''' und '''''[M]'''''.
+
*MUSS bedeutet eine verpflichtend einzuhaltende Vorschrift (Gebot). Entspricht den Konformitätskriterien '''''[M]''''' und '''''[R] 1..'''''.
−
* NICHT ERLAUBT formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht dem Konformitätskriterium '''''[NP]'''''.
+
*NICHT ERLAUBT formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht dem Konformitätskriterium '''''[NP]'''''.
−
* SOLL oder EMPFOHLEN steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht dem Konformitätskriterium '''''[R2]'''''.
+
*SOLL oder EMPFOHLEN steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht dem Konformitätskriterium '''''[R] 0..'''''.
−
* KANN oder OPTIONAL (engl. MAY, OPTIONAL) Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Konformtätskriterium '''''[O]'''''.
+
*KANN oder OPTIONAL (engl. MAY, OPTIONAL) Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Konformitätskriterium '''''[O]'''''.
  
 
===Kardinalität===
 
===Kardinalität===
−
Die Kardinalität beschreibt, wie oft ein Element innerhalb einer Struktur auftreten kann. Die Kardinalität wird durch ein Intervall zwischen der minimalen und maximalen Anzahl angegeben, getrennt durch „..“. Eine unbegrenzte Anzahl wird durch ein „*“ angegeben. Daraus ergeben sich mindestens folgende Möglichkeiten:  0..1;  0..*;    1..1;    1..*
+
Die Kardinalität beschreibt, wie oft ein Element innerhalb einer Struktur auftreten kann. Die Kardinalität wird durch ein Intervall zwischen der minimalen und maximalen Anzahl angegeben, getrennt durch "..". Eine unbegrenzte Anzahl wird durch ein "*" angegeben. Daraus ergeben sich mindestens folgende Möglichkeiten:  0..1;  0..*;    1..1;    1..*
−
==Legende der Optionalitäten==
+
 
−
Siehe auch [[#Umgang_mit_optionalen_Elementen|“Umgang mit optionalen Elementen“]].
+
===Umgang mit optionalen Elementen===
 +
Sind Elemente bzw. Attribute als "optional" gekennzeichnet ('''''[O]''''') so ist ihre Verwendung OPTIONAL, aber es ist NICHT ERLAUBT, dass sie, wenn sie verwendet werden, leer sind. Möchte man ein optionales Element explizit mit einem leeren Wert angeben, so hat dies durch Kennzeichnung mit '''''[[#Der_nullFlavor|nullFlavor]]''''' zu erfolgen.
 +
 
 +
===Legende der Konformitätskriterien===
 +
====Optionalitäten von CDA-Elementen====
 
{| class="wikitable" width="100%"
 
{| class="wikitable" width="100%"
 
|-  
 
|-  
−
! style="text-align:left" width="15%" | Konformitäts-Kriterium ||style="text-align:left" width="15%" | Mögliche Kardinalität ||style="text-align:left" width="15%" | Verwendung von NullFlavor ||style="text-align:left" width="55%" | Beschreibung
+
! style="text-align:left" width="15%" |Konformitäts-Kriterium|| style="text-align:left" width="15%" |Mögliche Kardinalität|| style="text-align:left" width="15%" |Verwendung von nullFlavor|| style="text-align:left" width="55%" |Beschreibung
−
|- style="background:#FFFFFF"
+
|-  
−
| '''''[M]''''' || 1..1<br/> 1..* || ''nicht erlaubt'' || Das Element MUSS mit einem korrekten "echten" Wert angegeben werden. NullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.
+
|'''''[M]'''''||1..1<br /> 1..*||''nicht erlaubt''||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden ''("mandatory")''.<br />nullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.
−
|- style="background:#FFFFFF"
+
|-  
−
| '''''[NP]''''' || 0..0 || ''nicht erlaubt'' || Das Element ist NICHT ERLAUBT.
+
|'''''[NP]'''''||0..0||''nicht erlaubt''||Das '''Element i'''st NICHT ERLAUBT ''("not permitted")''.
−
|- style="background:#FFFFFF"
+
|-  
−
| '''''[R]''''' || 1..1<br /> 1..* || ''erlaubt'' || Das Element MUSS in der Instanz vorhanden sein. Wenn nicht bekannt, ist die Verwendung eines NullFlavors vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT.
+
| rowspan="2" |'''''[R]'''''||1..1<br />1..*||''erlaubt''||Das '''Element''' MUSS in der Instanz vorhanden sein ''("required")''. Wenn ein Element nicht bekannt ist, ist die Verwendung eines nullFlavors vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT.
−
|- style="background:#FFFFFF"
+
|-  
−
| '''''[R2]''''' || 0..1<br /> 0..* || ''nicht erlaubt'' || Das Element SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein. NullFlavor ist NICHT ERLAUBT.
+
|0..1<br />0..*||''nicht erlaubt''||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt ''("required")''. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und MUSS weggelassen werden. Ein nullFlavor ist daher NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2]  ''("required if known")''.
−
|- style="background:#FFFFFF"
+
|-  
−
| '''''[O]''''' || 0..1<br /> 0..* || ''erlaubt'' || Das Element ist OPTIONAL. Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird.  
+
|'''''[O]'''''||0..1<br />0..*||''erlaubt''||Das '''Element''' ist OPTIONAL ''("optional")''. Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird.
−
|- style="background:#FFFFFF"
+
|-  
−
| '''''[C]''''' || || || KONDITIONALES Konformitätskriterium. Die Konformität des Elements variiert in Abhängigkeit von anderen Elementen, Situationen oder Zuständen. Die konkreten Abhängigkeiten sind in Folge angegeben.
+
|'''''[C]'''''|| || ||Die Optionalität des '''Elements''' variiert in Abhängigkeit von anderen Elementen, Situationen oder Zuständen (''"conditional"''). Die konkreten Abhängigkeiten sind in Folge angegeben.
 
|-
 
|-
 
|}
 
|}
−
''Tabelle 2: Legende der Optionalitäten''
+
<ref group="Tabelle">Legende der Optionalitäten von Elementen</ref>:''Legende der Optionalitäten von Elementen''
  
−
===Maximum-Set===
+
====Optionalitäten von CDA-Attributen====
−
Das CDA Modell beschreibt ein höchst umfangreiches Schema von Informationselementen und bietet in manchen Bereichen über rekursive, beliebig tief verschachtelbare Elemente eine theoretisch unendlich hohe Anzahl von Möglichkeiten, Informationen abzulegen. Die vollständige Beschreibung und Definition aller Elemente in einem Implementierungsleitfaden wäre daher äußerst aufwändig und ist in den ELGA Implementierungsleitfäden nicht erfolgt.
+
{| class="wikitable" width="100%"
 +
|-
 +
! style="text-align:left" width="15%" |Konformitäts-Kriterium|| style="text-align:left" width="15%" |Mögliche Kardinalität|| style="text-align:left" width="55%" |Beschreibung
 +
|-
 +
|'''''[NP]'''''||0..0||Das '''Attribut'''  ist NICHT ERLAUBT. ''("not permitted")''
 +
|-
 +
|'''''[R]'''''
 +
|1..1
 +
|Das '''Attribut''' MUSS in der Instanz vorhanden sein. ''("required")''
 +
|-
 +
|'''''[O]'''''||0..1||Das '''Attribut''' ist OPTIONAL. ''("optional")''
 +
|-
 +
|'''''[F]'''''||0..1
 +
1..1
 +
|Wenn das '''Attribut''' angegeben wird, ist ein fixer Wert vorgeschrieben. ''("fixed")''
 +
Für das '''Attribut''' ist ein fixer Wert vorgeschrieben. ''("fixed")''
 +
|-
 +
|}
 +
<ref group="Tabelle">Legende der Optionalitäten von Attributen</ref>:''Legende der Optionalitäten von Attributen''
  
−
Vielmehr beschreiben die ELGA Implementierungsleitfäden lediglich jene Elemente, für die es Vorgaben gibt. Die Verwendung aller nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Die ELGA Templates können demnach als „closed templates“ betrachtet werden.
+
===Der nullFlavor===
−
{{BeginYellowBox}}
+
Das Attribut @''nullFlavor'' dient zur Kennzeichnung, dass ein Element nicht seiner Entsprechung gemäß befüllt werden kann.  
−
Elemente oder Attribute, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT.
+
Die konkrete Anwendung des @''nullFlavor'' Attributs ist im Rahmen dieser Implementierungsleitfäden nur erlaubt, wenn er explizit in der Spezifikation eines Elementes angegeben ist. Für [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Codierungs-Elemente|codierte Elemente]] ist ein nullFlavor für unbekannte und fehlende Information nach Möglichkeit zu vermeiden, bevorzugt ist die Verwendung eines Codes mit demselben Informationsgehalt (etwa für "keine Allergie bekannt" das SNOMED Konzept 716186003 "No known allergy").
−
{{EndYellowBox}}
 
−
Die ELGA Implementierungsleitfäden beschreiben daher ein sogenanntes '''''„Maximum-Set“'''''. Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:
 
  
−
====Ausnahme: „entry“====
+
Beispiel für ein Element, welches mit dem @''nullFlavor'' versehen wurde:
−
Die Vorschrift des „Maximums-Sets“ gilt für alle Bereiche des CDA-Dokuments ''<u>außer der Ebene der maschinenlesbaren Elemente („entry“, CDA-Level 3) von Sektionen.</u>''
+
<pre class="ilfbox_code">
−
{{BeginYellowBox}}
+
<id nullFlavor="UNK" />
−
Selbst-definierte maschinenlesbare Elemente KÖNNEN bei allen Sektionen zusätzlich angewandt werden (sowohl jene, die keine Entries vorsehen, als auch jene, die bereits Entries definieren)!
+
</pre>
 +
Wenn in einem Element ein nullFlavor angegeben wurde, kann nicht gleichzeitig ein anderes Attribut eingetragen werden.
  
−
'''Achtung:''' Für bereits in Implementierungsleitfäden definierte Entries gilt jedoch die Regelung des „Maximum-Sets“! Ihre Erweiterung oder Veränderung ist NICHT ERLAUBT.
+
'''nullFlavor Beispiele''':
−
{{EndYellowBox}}
+
{| class="wikitable"
−
Diese Ausnahmeregelung soll eine erweiterte Nutzung der CDA-Dokumente ermöglichen und Innovationen bei der Weiterentwicklung der Spezifikationen zu fördern.
+
|-
 +
! nullFlavor
 +
! displayName
 +
! Deutsche Übersetzung
 +
! Anwendung
 +
|-
 +
| '''NI'''
 +
| NoInformation
 +
| keine Information vorhanden
 +
| wenn es keine Informationen gibt
 +
|-
 +
| '''UNK'''
 +
| Unknown
 +
| unbekannt
 +
| wenn es Informationen gibt, diese aber unbekannt sind
 +
|-
 +
| '''MSK'''
 +
| Masked
 +
| maskiert
 +
| wenn es Informationen gibt, diese aber nicht bekannt gegeben werden (vertraulich, nicht freigegeben)
 +
|-
 +
| '''NA'''
 +
| Not applicable
 +
| nicht anwendbar
 +
| wenn keine Codierung verfügbar ist
 +
|-
 +
| '''OTH'''
 +
| Other
 +
| Andere
 +
| wenn eine Codierung nur in einem alternativen Codesystem verfügbar ist
 +
|}
 +
<ref group="Tabelle">nullFlavor-Beispiele aus Value Set ELGA_NullFlavor</ref>: nullFlavor-Beispiele aus Value Set [https://termgit.elga.gv.at/ValueSet/elga-nullflavor ELGA_NullFlavor]
  
−
Es wäre dadurch erlaubt selbst-definierte Entries zu verwenden, um einen bestimmten Prozess in der eigenen Domäne oder im eigenen Einflussbereich maschinell abwickeln zu können. Die Gültigkeit in ELGA wäre bei einem derartigen Dokument dennoch gewährleistet.
+
===Maximum-Set===
−
 
+
Das CDA-Modell beschreibt ein höchst umfangreiches Schema von Informationselementen und bietet in manchen Bereichen über rekursive, beliebig tief verschachtelbare Elemente eine theoretisch unendlich hohe Anzahl von Möglichkeiten, Informationen abzulegen. Die vollständige Beschreibung und Definition aller Elemente in einem Implementierungsleitfaden wäre daher äußerst aufwändig und ist in den ELGA Implementierungsleitfäden nicht erfolgt.
−
Beispiel:<br/>
 
−
Ein Krankenhausträger möchte eine maschinenunterstützte Terminkoordination mit seinen Pflegediensten in einem bestimmten Gebiet etablieren, benötigt jedoch für diesen Zweck zusätzliche maschinenlesbare Einträge in den CDA Pflege-Entlassungsbriefen.
 
−
 
 
−
Leser aus anderen Gebieten können diese Strukturen zwar nicht interpretieren und daher auch nicht nützen, allerdings beeinflusst dies die normale Nutzung der Dokumente nicht.
 
  
−
=====Meldepflicht von selbst-definierten maschinenlesbaren Elementen=====
+
Vielmehr beschreiben die ELGA Implementierungsleitfäden lediglich jene Elemente, die erlaubt sind. Die Verwendung aller nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Für alle Templates gelten die im [[#Datentypen|Kapitel Datentypen]] angegebenen Einschränkungen. Die ELGA Implementierungsleitfäden beschreiben daher ein sogenanntes '''''"Maximum-Set"''''', Die ELGA Templates sind demnach als "closed templates" entsprechend dem HL7 Templates Standard zu betrachten.
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
−
Werden selbst-definierte maschinenlesbare Elemente zur Anwendung gebracht, MÜSSEN die entsprechenden Spezifikationen der ELGA GmbH gemeldet werden.
+
Elemente oder Attribute, die nicht vom Allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT.  
 
{{EndYellowBox}}
 
{{EndYellowBox}}
−
Die Strukturen werden in Folge in die CDA Arbeitsgruppen zur Weiterentwicklung der Leitfäden eingebracht. Bei allgemeiner Akzeptanz ermöglicht dies eine spätere Integration in die Implementierungsleitfäden.
+
====Ausnahmen====
−
{{BeginILFBox}}
+
Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:
−
Wenn in einem Dokument selbst-definierte maschinenlesbare Elemente vorhanden sind, MUSS das bei der Registrierung in der XDS-Registry mit einem zusätzlichen Plus-Zeichen („+“) am Ende des Strings im XDS-FormatCode angezeigt werden. <br/>
 
−
Beispiel: urn:elga:lab:2011:EIS_FullSupport+<br/>
 
−
Siehe dazu die entsprechende Regelung im Leitfaden „[[ILF:XDS Metadaten#Zusatz_bei_selbst-definierten_maschinenlesbaren_Elementen_.28Dokumente_in_EIS_.E2.80.9EEnhanced.E2.80.9C_oder_.E2.80.9EFull_Support.E2.80.9C.29|ELGA XDS Metadaten (XDSDocumentEntry)“, [OID Root 1.2.40.0.34.7.6], Kapitel Zusatz bei selbst-definierten maschinenlesbaren Elementen (Dokumente in EIS „Enhanced“ oder „Full Support“]]).
 
−
{{EndILFBox}}
 
  
−
====Ausnahme: „templateId“====
+
=====Ausnahme: "templateId"=====
 
''templateId''-Elemente KÖNNEN bei Bedarf an allen laut CDA-Schema möglichen Stellen verwendet werden. Wenn bereits templateId-Elemente laut Spezifikation vorgeschrieben sind, KÖNNEN beliebig viele weitere ''templateId''-Elemente angegeben werden.
 
''templateId''-Elemente KÖNNEN bei Bedarf an allen laut CDA-Schema möglichen Stellen verwendet werden. Wenn bereits templateId-Elemente laut Spezifikation vorgeschrieben sind, KÖNNEN beliebig viele weitere ''templateId''-Elemente angegeben werden.
  
−
====Ausnahme: Verfasser von CDA-Sektionen====
+
=====Ausnahme: Fixierte Attribute=====
−
Der Verfasser von Sektionen KANN mittels des Elements „''author''“ innerhalb einer Sektion („''section''“-Element) abgebildet werden. Diese „''author''“-Elemente sind bei Bedarf OPTIONAL bei allen CDA-Sektionen zusätzlich zu verwenden, sofern die Spezifikation der Sektion dies nicht explizit ausschließt.
+
Attribute, die gem. CDA-Schema mit "fixed" angegeben sind, haben einen festen Wert, daher können diese Attribute auch weggelassen werden. Diese Attribute werden daher üblicherweise nicht beschrieben und angegeben. Die Angabe von fixierten Attributen oder Attributen mit ihrem gem. CDA-Schema definierten Default-Wert ist erlaubt, auch wenn diese nicht explizit im Leitfaden beschrieben sind.
−
 
 
−
Siehe auch ''„[[#Sektionen|Sektionen]]“''.
 
−
 
 
−
====Ausnahme: Zusätzliche weitere Beteiligte====
 
−
Die möglichen Arten für die Dokumentation von wichtigen beteiligten Personen oder Organisationen (z.B. Angehörige, Verwandte, Versicherungsträger, etc.) sind in diesem Leitfaden in [[#Weitere_Beteiligte_.28.E2.80.9Eparticipant.E2.80.9C.29|Weitere Beteiligte („participant“)]] definiert. Es ist daher NICHT ERLAUBT, darüberhinausgehende Arten von Beteiligten anzugeben, ausgenommen die entsprechende Art von Beteiligten ist in einem speziellen Implementierungsleitfaden explizit definiert.
 
  
−
====Ausnahme: Fixierte Attribute====
+
=====Explizit angegebene Ausnahmen=====
−
Attribute, die gem. CDA-Schema mit „fixed“ angegeben sind, haben einen festen Wert, daher können diese Attribute auch weggelassen werden. Diese Attribute werden daher üblicherweise nicht beschrieben und angegeben. Die Angabe von fixierten Attributen oder Attributen mit ihrem gem. CDA-Schema definierten Default-Wert ist erlaubt, auch wenn diese nicht explizit im Leitfaden beschrieben sind.
+
Im speziellen Implementierungsleitfaden KÖNNEN bestimmte Sektionen als "offene Templates" definiert werden und Ausnahmen für Subsektionen und Entries zulassen.
  
 
====Hinweis zur Implementierung weiterverarbeitender Software====
 
====Hinweis zur Implementierung weiterverarbeitender Software====
−
CDA-Dokumente können unter Umständen „fremde“ Elemente oder Attribute enthalten, die der „Maximum-Set“ Vorschrift dieses Dokumentleitfadens widersprechen (z.B. aufgrund von Software-Fehlern). Darüber hinaus können CDA-Dokumente ebenfalls selbst-definierte maschinenlesbare Elemente beinhalten.
+
CDA-Dokumente können unter Umständen "fremde" Elemente oder Attribute enthalten, die der "Maximum-Set" Vorschrift dieses Leitfadens widersprechen (z.B. aufgrund von Software-Fehlern). Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, soll weiterverarbeitende Software so implementiert sein, dass dies nicht zu Fehlern in der Weiterverarbeitung der CDA-Dokumente führt.
  
−
Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, soll weiterverarbeitende Software so implementiert sein, dass dies nicht zu Fehlern in der Weiterverarbeitung der Dokumente führt.
+
===Value Sets===
 +
Ein Value Set ist eine eindeutig durch Name oder OID identifizierbare und versionierte Sicht auf ein oder mehrere Codesysteme. Es kann als Zusammenstellung von einem oder mehreren Codes aus einem oder mehreren Codesystemen gesehen werden. Ein Value Set enthält die Codes selbst und die Information über die Herkunft des Codes (das Source-Codesystem), z.B. "ELGA_NullFlavor" oder "ELGA_Dokumentenklassen".
  
−
====Umgang mit Ausnahmen bei der Konformitätsprüfung ====
+
Wo immer in den CDA-Implementierungsleitfäden eine Werteauswahl getroffen werden kann, wird ein passendes Value Set mit einem eindeutigen Namen angegeben. Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert: https://termgit.elga.gv.at/.  
−
Nur Elemente, die im „Maximum-Set“ beschrieben sind, können zuverlässig geprüft werden. „Fremde“ Elemente oder Attribute<sup>4</sup>  werden daher von den Konformitätsprüfmechanismen im Sinne der „closed templates“ grundsätzlich als falsch erkannt. Selbst die genannten Ausnahmen, v.a. zusätzliche Entries oder TemplateIds, können daher falsche Fehlermeldungen auslösen. Diese Ausnahmen sollten entsprechend nur, wenn unbedingt notwendig und mit Vorsicht eingesetzt werden.
 
  
 +
====Value Set Binding====
 +
Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets. Das bedeutet, dass immer die aktuell am Terminologieserver publizierte Version eines Value Sets anzuwenden ist. (Das Setzen des entsprechenden Schlüsselworts DYNAMIC ist daher in den Leitfäden optional, aktuell gibt es auch keine ValueSets die statisch gebunden sind).
  
−
<sup>4</sup>Attribute, die im CDA-Schema als „fixed“ definiert sind oder mit ihrem Default-Wert angegeben sind, dürfen angegeben werden und werden auch nicht als Fehler bewertet.
+
Für jedes Value Set ist am Terminologieserver auch ein Zeitpunkt angegeben, an dem es Gültigkeit erlangt ("Status: Active as of"), das ist speziell für Value Sets wichtig, die schon vor ihrem Inkrafttreten veröffentlicht werden. Value Sets sind so lange gültig, bis das Gültigkeitsdatum einer neueren Version dieses Value Sets erreicht wird – dann gilt die neuere Version.
−
 
 
−
===Umgang mit optionalen Elementen===
 
−
Sind Elemente bzw. Attribute als „optional“ gekennzeichnet ('''''[O]''''') so ist ihre Verwendung OPTIONAL, aber es ist NICHT ERLAUBT, dass sie, wenn sie verwendet werden, leer sind. Möchte man ein optionales Element explizit mit einem leeren Wert angeben, so hat dies durch Kennzeichnung mit '''''[[#Der_nullFlavor|nullFlavor]]''''' zu erfolgen, zum Beispiel:
 
−
* '''NI''': wenn es keine Informationen gibt
 
−
* '''UNK''': wenn es Informationen gibt, diese aber unbekannt sind
 
  
−
Zur genauen Definition und Verwendung siehe [[#Der_nullFlavor|Der nullFlavor]].
+
Im CDA-Dokument KANN über die Attribute @ValueSet und @ValueSetVersion angegeben werden, welches Value Set in welcher Version als Basis für die Befüllung des jeweiligen Datenelements verwendet wurde.
−
 
 
−
===ELGA Value Sets===
 
−
Ein Value Set ist eine eindeutig identifizierbare und versionierte Sicht auf ein oder mehrere Codesysteme. Es kann als Zusammenstellung von einem oder mehreren Codes aus einem oder mehreren Codesysteme gesehen werden. Ein Value Set enthält die Codes selbst und die Information über die Herkunft des Codes (das Source-Codesystem).
 
−
 
 
−
Beispiele für ELGA Value-Sets: „ELGA_NullFlavor“, „ELGA_Dokumentenklassen“.
 
−
 
 
−
Wo immer in den ELGA CDA Implementierungsleitfäden eine Werteauswahl getroffen werden kann, wird ein passendes Value Set mit einem eindeutigen Namen angegeben. Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert: https://termpub.gesundheit.gv.at/.
 
−
 
 
−
Value Sets sind nicht nur durch einen eindeutigen Namen, sondern auch durch eine OID, und eine Versionsnummer gekennzeichnet. Weiters werden Gültigkeitsstatus und ein "Gültig ab"-Datum angegeben.
 
−
 
 
−
Hinweise zum korrekten Umgang mit Terminologien finden sich im „Leitfaden für den Umgang mit Terminologien in ELGA“ [TERMLEIT].
 
  
 
====Änderbarkeit von Value Sets====
 
====Änderbarkeit von Value Sets====
−
Inhalte von Value Sets können sich ändern, der Name und die OID eines Value Sets bleiben aber gleich. Bei neuen Versionen werden Versionsnummer, Änderungsdatum und „Gültig ab“-Datum (effectiveDate) angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden.
+
Inhalte von Value Sets können sich ändern, der Name und die OID eines Value Sets bleiben aber gleich. Alle ValueSets, die für ein CDA des Implementierungsleitfadens verwendet werden, sollen periodisch gemeinsam aktualisiert werden. Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird im Terminologiedatum-Header-Element "terminologyDate" angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden.
−
 
 
−
In Ausnahmen kann bei der Definition eines Value Sets angegeben werden, dass es nicht geändert oder versioniert werden darf (Property „Immutability“).
 
−
 
 
−
====Value Set Binding====
 
−
Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets. Das bedeutet, dass immer die aktuell am Terminologieserver publizierte Version eines Value Sets anzuwenden ist. (Das Setzen des entsprechenden Schlüsselworts DYNAMIC ist daher in den Leitfäden optional).
 
  
−
Für jedes Value Set ist auch ein Zeitpunkt angegeben, an dem es Gültigkeit erlangt („Gültig ab“), das ist für Value Sets wichtig, die schon vor ihrem Inkrafttreten veröffentlicht werden.  
+
====Publikation der Value Sets am Terminologieserver====
 +
Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert.<ref name="Terminologieserver">Österreichischer e-Health-Terminologie-Browser https://termgit.elga.gv.at</ref>
 +
Damit die jeweils aktuelle Version der Value Sets angewendet werden kann, soll der Terminologieserver regelmäßig auf Update abgeprüft werden. Es wird EMPFOHLEN, diese Überprüfung täglich durchzuführen.
  
−
Value Sets können auch STATISCH an ein Code-Element gebunden werden. Das wird gekennzeichnet durch die Angabe des Value Sets mit Name, OID, Version und "Gültig ab"-Datum (effectiveDate) sowie dem Schlüsselwort STATIC.
+
====Terminologiedatum====
 +
Das Datum, an dem sämtliche lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird über das "Terminologiedatum" angegeben: Dieses Datum wird in der Notation "YYYYMMDD" im eigenen Element "terminologyDate" angegeben.
 +
Beim Abgleich der Terminologien müssen immer alle Value Sets, die für ein CDA-Dokument notwendig sind, auf die am Terminologieserver aktuelle Version aktualisiert werden. Dokumente, die nur teilweise auf dem aktuellen Stand beruhen, könnten inkonsistent sein und MÜSSEN vermieden werden.
  
 
===PDF Format-Vorschrift===
 
===PDF Format-Vorschrift===
−
In CDA Dokumenten können Dokumente im PDF Format an verschiedensten Stellen eingebettet werden, entweder als gesamter CDA-Body oder als eingebetteter Inhalt in gewissen CDA-Sektionen. Im Hinblick auf eine dauerhafte Verfügbarkeit der Daten muss mindestens gewährleistet werden, dass diese PDF-Dokumente zuverlässig und eindeutig visuell reproduzierbar sind. Dies kann über die Einhaltung der Mindestkriterien der Norm ISO 19005-1:2005 sichergestellt werden (PDF/A-1b Basic). Die Norm beschreibt zusätzlich Barrierefreiheit der Dokumente, sodass sie von einem Screenreader vorgelesen werden können (PDF/A-1a Accessible). Dieser Implementierungsleitfaden schreibt daher vor, dass jedes eingebettete PDF-Dokument dem Standard PDF/A-1a entsprechen MUSS<sup>5<sup>.
+
In CDA Dokumenten können Dokumente im PDF Format an verschiedensten Stellen eingebettet werden, entweder als gesamter CDA-Body oder als eingebetteter Inhalt in gewissen CDA-Sektionen. Im Hinblick auf eine dauerhafte Verfügbarkeit der Daten muss mindestens gewährleistet werden, dass diese PDF-Dokumente zuverlässig und eindeutig visuell reproduzierbar sind. Dies kann über die Einhaltung der Mindestkriterien der Norm ISO 19005-1:2005 sichergestellt werden (PDF/A-1b Basic bzw. PDF/A-3b Basic). Die Norm beschreibt zusätzlich die Barrierefreiheit der Dokumente, sodass sie von einem Screenreader vorgelesen werden können (PDF/A-1a Accessible bzw. PDF/A-3a Accessible). Dieser Implementierungsleitfaden schreibt daher als Minimalanforderung vor, dass jedes eingebettete PDF-Dokument dem Standard PDF/A-1b bzw. PDF/A-3b entsprechen MUSS. Im Sinne der Barrierefreiheit ist die Umsetzung von PDF/A-1a bzw. PDF/A-3a EMPFOHLEN.
 
{{BeginYellowBox}}
 
{{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.
+
Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1b bzw. PDF/A3-b (gemäß "ISO 19005-1:2005 Level A conformance") entsprechen. Die Umsetzung von PDF/A-1a bzw. PDF/A-3a ist EMPFOHLEN.
 
{{EndYellowBox}}
 
{{EndYellowBox}}
−
{{Informationsbox|Änderung|Für die nächste Version des Leitfadens ist geplant, die Vorschrift auf PDF/A-1b zu senken. PDF/A-1a bleibt erlaubt.}}
 
−
 
−
 
−
 
−
<sup>5</sup> Bis zum Vorliegen von Dokumenten in EIS Full Support wird mindestens PDF/A-1b vorgeschrieben.
 
  
 
===Größenbeschränkung von eingebetteten Objekten===
 
===Größenbeschränkung von eingebetteten Objekten===
−
In CDA Dokumenten können verschiedene Objekte (z.B. PDF-Dokumente, Bilder) eingebettet werden (siehe „[[ILF:Allgemeiner Implementierungsleitfaden#ELGA_EingebettetesObjekt-Entry|ELGA EingebettetesObjekt-Entry]]“).
+
In CDA-Dokumenten können verschiedene Objekte (z.B. PDF-Dokumente, Bilder) eingebettet werden (siehe "[[#Eingebettetes_Objekt_Entry|Eingebettetes Objekt Entry]]").
  
−
Dieser Implementierungsleitfaden schreibt keine Größenbeschränkung für diese Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers, die Größe der über ELGA bereitgestellten CDA-Dateien etwa durch Verringerung der Auflösung oder der Anzahl der Einzelbilder auf eine sinnvolle und angemessene Größe zu beschränken.
+
Dieser Implementierungsleitfaden schreibt keine Größenbeschränkung für diese Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers, die Größe der über ELGA bereitgestellten CDA-Dokumente etwa durch Verringerung der Auflösung oder der Anzahl der Einzelbilder auf eine sinnvolle und angemessene Größe zu beschränken.
−
 
+
{{BeginYellowBox}}
−
Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße der Datei 20 MB nicht überschreiten.<sup>6</sup>
+
Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße des CDA-Dokuments 20 MB nicht überschreiten.
−
 
+
{{EndYellowBox}}
−
 
 
−
<sup>6</sup> Aktuell wird von ELGA die Größe von Doumenten auf 20MB beschränkt.
 
−
 
 
−
===Der nullFlavor===
 
−
Das Attribut @''nullFlavor'' dient zur Kennzeichnung, wenn das Element nicht seiner Entsprechung gemäß befüllt werden kann.
 
−
 
 
−
Obwohl dieses Attribut vom CDA-Schema bei prinzipiell jedem CDA-Element erlaubt wäre, ist die konkrete Anwendung des @''nullFlavor'' Attributs im Rahmen dieser Implementierungsleitfäden nur eingeschränkt erlaubt. Ein entsprechender Vermerk ist im jeweiligen Abschnitt angeführt.
 
−
 
 
−
Beispiel für ein Element, welches mit dem @''nullFlavor'' versehen wurde:
 
−
{{BeginOrangeBox}}
 
−
<id nullFlavor="'''UNK'''" />
 
−
{{EndOrangeBox}}
 
−
Zulässig sind Werte gemäß Value-Set „'''ELGA_NullFlavor'''“, solange nicht eine weitere Einschränkung beim jeweiligen Element angegeben wird.
 
−
 
 
−
Wenn in einem Element ein NullFlavor angegeben wurde, kann nicht gleichzeitig ein anderes Attribut eingetragen werden.
 
  
 
===Verbot von CDATA===
 
===Verbot von CDATA===
−
Die Verwendung von CDATA-Abschnitten (<![CDATA[…]]>), also von Zeichenketten, die vom Parser nicht als XML-Quellcode interpretiert werden können, ist für ELGA CDA Dokumente generell '''NICHT ERLAUBT'''.
+
Die Verwendung von CDATA-Abschnitten (<![CDATA[…]]>), also von Zeichenketten, die vom Parser nicht als XML-Quellcode interpretiert werden können, ist für ELGA CDA-Dokumente generell '''NICHT ERLAUBT'''.

Aktuelle Version vom 3. Mai 2023, 07:12 Uhr

1 Allgemeine Richtlinien für die Implementierung des e-Impfpasses

1.1 Verwendung von Schlüsselwörtern

Wenn im Text die Verbindlichkeit von Vorgaben angegeben wird, wird das durch Schlüsselwörter gekennzeichnet [gemäß RFC 2119], die in Majuskeln (Großbuchstaben) geschrieben werden. Die Angabe der Verbindlichkeit ersetzt nicht die Angabe von Kardinalität oder Nullwerten (die in HL7 Version 3 als nullFlavors ausgedrückt werden).

  • MUSS bedeutet eine verpflichtend einzuhaltende Vorschrift (Gebot). Entspricht den Konformitätskriterien [M] und [R] 1...
  • NICHT ERLAUBT formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht dem Konformitätskriterium [NP].
  • SOLL oder EMPFOHLEN steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht dem Konformitätskriterium [R] 0...
  • KANN oder OPTIONAL (engl. MAY, OPTIONAL) Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Konformitätskriterium [O].

1.2 Kardinalität

Die Kardinalität beschreibt, wie oft ein Element innerhalb einer Struktur auftreten kann. Die Kardinalität wird durch ein Intervall zwischen der minimalen und maximalen Anzahl angegeben, getrennt durch "..". Eine unbegrenzte Anzahl wird durch ein "*" angegeben. Daraus ergeben sich mindestens folgende Möglichkeiten: 0..1; 0..*; 1..1; 1..*

1.3 Umgang mit optionalen Elementen

Sind Elemente bzw. Attribute als "optional" gekennzeichnet ([O]) so ist ihre Verwendung OPTIONAL, aber es ist NICHT ERLAUBT, dass sie, wenn sie verwendet werden, leer sind. Möchte man ein optionales Element explizit mit einem leeren Wert angeben, so hat dies durch Kennzeichnung mit nullFlavor zu erfolgen.

1.4 Legende der Konformitätskriterien

1.4.1 Optionalitäten von CDA-Elementen

Konformitäts-Kriterium Mögliche Kardinalität Verwendung von nullFlavor Beschreibung
[M] 1..1
1..*		 nicht erlaubt Das Element MUSS mit einem korrekten "echten" Wert angegeben werden ("mandatory").
nullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.
[NP] 0..0 nicht erlaubt Das Element ist NICHT ERLAUBT ("not permitted").
[R] 1..1
1..*		 erlaubt Das Element MUSS in der Instanz vorhanden sein ("required"). Wenn ein Element nicht bekannt ist, ist die Verwendung eines nullFlavors vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT.
0..1
0..*		 nicht erlaubt Das Element SOLL in der Instanz vorhanden sein, sofern bekannt ("required"). Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und MUSS weggelassen werden. Ein nullFlavor ist daher NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ("required if known").
[O] 0..1
0..*		 erlaubt Das Element ist OPTIONAL ("optional"). Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird.
[C] Die Optionalität des Elements variiert in Abhängigkeit von anderen Elementen, Situationen oder Zuständen ("conditional"). Die konkreten Abhängigkeiten sind in Folge angegeben.

[Tabelle 1]:Legende der Optionalitäten von Elementen

1.4.2 Optionalitäten von CDA-Attributen

Konformitäts-Kriterium Mögliche Kardinalität Beschreibung
[NP] 0..0 Das Attribut ist NICHT ERLAUBT. ("not permitted")
[R] 1..1 Das Attribut MUSS in der Instanz vorhanden sein. ("required")
[O] 0..1 Das Attribut ist OPTIONAL. ("optional")
[F] 0..1

1..1

Wenn das Attribut angegeben wird, ist ein fixer Wert vorgeschrieben. ("fixed")

Für das Attribut ist ein fixer Wert vorgeschrieben. ("fixed")

[Tabelle 2]:Legende der Optionalitäten von Attributen

1.5 Der nullFlavor

Das Attribut @nullFlavor dient zur Kennzeichnung, dass ein Element nicht seiner Entsprechung gemäß befüllt werden kann. Die konkrete Anwendung des @nullFlavor Attributs ist im Rahmen dieser Implementierungsleitfäden nur erlaubt, wenn er explizit in der Spezifikation eines Elementes angegeben ist. Für codierte Elemente ist ein nullFlavor für unbekannte und fehlende Information nach Möglichkeit zu vermeiden, bevorzugt ist die Verwendung eines Codes mit demselben Informationsgehalt (etwa für "keine Allergie bekannt" das SNOMED Konzept 716186003 "No known allergy").

Beispiel für ein Element, welches mit dem @nullFlavor versehen wurde: 

<id nullFlavor="UNK" />

Wenn in einem Element ein nullFlavor angegeben wurde, kann nicht gleichzeitig ein anderes Attribut eingetragen werden.

nullFlavor Beispiele:

nullFlavor displayName Deutsche Übersetzung Anwendung
NI NoInformation keine Information vorhanden wenn es keine Informationen gibt
UNK Unknown unbekannt wenn es Informationen gibt, diese aber unbekannt sind
MSK Masked maskiert wenn es Informationen gibt, diese aber nicht bekannt gegeben werden (vertraulich, nicht freigegeben)
NA Not applicable nicht anwendbar wenn keine Codierung verfügbar ist
OTH Other Andere wenn eine Codierung nur in einem alternativen Codesystem verfügbar ist

[Tabelle 3]: nullFlavor-Beispiele aus Value Set ELGA_NullFlavor

1.6 Maximum-Set

Das CDA-Modell beschreibt ein höchst umfangreiches Schema von Informationselementen und bietet in manchen Bereichen über rekursive, beliebig tief verschachtelbare Elemente eine theoretisch unendlich hohe Anzahl von Möglichkeiten, Informationen abzulegen. Die vollständige Beschreibung und Definition aller Elemente in einem Implementierungsleitfaden wäre daher äußerst aufwändig und ist in den ELGA Implementierungsleitfäden nicht erfolgt.

Vielmehr beschreiben die ELGA Implementierungsleitfäden lediglich jene Elemente, die erlaubt sind. Die Verwendung aller nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Für alle Templates gelten die im Kapitel Datentypen angegebenen Einschränkungen. Die ELGA Implementierungsleitfäden beschreiben daher ein sogenanntes "Maximum-Set", Die ELGA Templates sind demnach als "closed templates" entsprechend dem HL7 Templates Standard zu betrachten.

Elemente oder Attribute, die nicht vom Allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT.

1.6.1 Ausnahmen

Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:

1.6.1.1 Ausnahme: "templateId"

templateId-Elemente KÖNNEN bei Bedarf an allen laut CDA-Schema möglichen Stellen verwendet werden. Wenn bereits templateId-Elemente laut Spezifikation vorgeschrieben sind, KÖNNEN beliebig viele weitere templateId-Elemente angegeben werden.

1.6.1.2 Ausnahme: Fixierte Attribute

Attribute, die gem. CDA-Schema mit "fixed" angegeben sind, haben einen festen Wert, daher können diese Attribute auch weggelassen werden. Diese Attribute werden daher üblicherweise nicht beschrieben und angegeben. Die Angabe von fixierten Attributen oder Attributen mit ihrem gem. CDA-Schema definierten Default-Wert ist erlaubt, auch wenn diese nicht explizit im Leitfaden beschrieben sind.

1.6.1.3 Explizit angegebene Ausnahmen

Im speziellen Implementierungsleitfaden KÖNNEN bestimmte Sektionen als "offene Templates" definiert werden und Ausnahmen für Subsektionen und Entries zulassen.

1.6.2 Hinweis zur Implementierung weiterverarbeitender Software

CDA-Dokumente können unter Umständen "fremde" Elemente oder Attribute enthalten, die der "Maximum-Set" Vorschrift dieses Leitfadens widersprechen (z.B. aufgrund von Software-Fehlern). Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, soll weiterverarbeitende Software so implementiert sein, dass dies nicht zu Fehlern in der Weiterverarbeitung der CDA-Dokumente führt.

1.7 Value Sets

Ein Value Set ist eine eindeutig durch Name oder OID identifizierbare und versionierte Sicht auf ein oder mehrere Codesysteme. Es kann als Zusammenstellung von einem oder mehreren Codes aus einem oder mehreren Codesystemen gesehen werden. Ein Value Set enthält die Codes selbst und die Information über die Herkunft des Codes (das Source-Codesystem), z.B. "ELGA_NullFlavor" oder "ELGA_Dokumentenklassen".

Wo immer in den CDA-Implementierungsleitfäden eine Werteauswahl getroffen werden kann, wird ein passendes Value Set mit einem eindeutigen Namen angegeben. Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert: https://termgit.elga.gv.at/.

1.7.1 Value Set Binding

Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets. Das bedeutet, dass immer die aktuell am Terminologieserver publizierte Version eines Value Sets anzuwenden ist. (Das Setzen des entsprechenden Schlüsselworts DYNAMIC ist daher in den Leitfäden optional, aktuell gibt es auch keine ValueSets die statisch gebunden sind).

Für jedes Value Set ist am Terminologieserver auch ein Zeitpunkt angegeben, an dem es Gültigkeit erlangt ("Status: Active as of"), das ist speziell für Value Sets wichtig, die schon vor ihrem Inkrafttreten veröffentlicht werden. Value Sets sind so lange gültig, bis das Gültigkeitsdatum einer neueren Version dieses Value Sets erreicht wird – dann gilt die neuere Version.

Im CDA-Dokument KANN über die Attribute @ValueSet und @ValueSetVersion angegeben werden, welches Value Set in welcher Version als Basis für die Befüllung des jeweiligen Datenelements verwendet wurde.

1.7.2 Änderbarkeit von Value Sets

Inhalte von Value Sets können sich ändern, der Name und die OID eines Value Sets bleiben aber gleich. Alle ValueSets, die für ein CDA des Implementierungsleitfadens verwendet werden, sollen periodisch gemeinsam aktualisiert werden. Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird im Terminologiedatum-Header-Element "terminologyDate" angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden.

1.7.3 Publikation der Value Sets am Terminologieserver

Sämtliche in den Implementierungsleitfäden verwendeten Value Sets werden am österreichischen Terminologieserver publiziert.[1] Damit die jeweils aktuelle Version der Value Sets angewendet werden kann, soll der Terminologieserver regelmäßig auf Update abgeprüft werden. Es wird EMPFOHLEN, diese Überprüfung täglich durchzuführen.

1.7.4 Terminologiedatum

Das Datum, an dem sämtliche lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird über das "Terminologiedatum" angegeben: Dieses Datum wird in der Notation "YYYYMMDD" im eigenen Element "terminologyDate" angegeben. Beim Abgleich der Terminologien müssen immer alle Value Sets, die für ein CDA-Dokument notwendig sind, auf die am Terminologieserver aktuelle Version aktualisiert werden. Dokumente, die nur teilweise auf dem aktuellen Stand beruhen, könnten inkonsistent sein und MÜSSEN vermieden werden.

1.8 PDF Format-Vorschrift

In CDA Dokumenten können Dokumente im PDF Format an verschiedensten Stellen eingebettet werden, entweder als gesamter CDA-Body oder als eingebetteter Inhalt in gewissen CDA-Sektionen. Im Hinblick auf eine dauerhafte Verfügbarkeit der Daten muss mindestens gewährleistet werden, dass diese PDF-Dokumente zuverlässig und eindeutig visuell reproduzierbar sind. Dies kann über die Einhaltung der Mindestkriterien der Norm ISO 19005-1:2005 sichergestellt werden (PDF/A-1b Basic bzw. PDF/A-3b Basic). Die Norm beschreibt zusätzlich die Barrierefreiheit der Dokumente, sodass sie von einem Screenreader vorgelesen werden können (PDF/A-1a Accessible bzw. PDF/A-3a Accessible). Dieser Implementierungsleitfaden schreibt daher als Minimalanforderung vor, dass jedes eingebettete PDF-Dokument dem Standard PDF/A-1b bzw. PDF/A-3b entsprechen MUSS. Im Sinne der Barrierefreiheit ist die Umsetzung von PDF/A-1a bzw. PDF/A-3a EMPFOHLEN.

Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1b bzw. PDF/A3-b (gemäß "ISO 19005-1:2005 Level A conformance") entsprechen. Die Umsetzung von PDF/A-1a bzw. PDF/A-3a ist EMPFOHLEN.

1.9 Größenbeschränkung von eingebetteten Objekten

In CDA-Dokumenten können verschiedene Objekte (z.B. PDF-Dokumente, Bilder) eingebettet werden (siehe "Eingebettetes Objekt Entry").

Dieser Implementierungsleitfaden schreibt keine Größenbeschränkung für diese Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers, die Größe der über ELGA bereitgestellten CDA-Dokumente etwa durch Verringerung der Auflösung oder der Anzahl der Einzelbilder auf eine sinnvolle und angemessene Größe zu beschränken.

Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße des CDA-Dokuments 20 MB nicht überschreiten.

1.10 Verbot von CDATA

Die Verwendung von CDATA-Abschnitten (<![CDATA[…]]>), also von Zeichenketten, die vom Parser nicht als XML-Quellcode interpretiert werden können, ist für ELGA CDA-Dokumente generell NICHT ERLAUBT.


Referenzfehler: Es sind <ref>-Tags für die Gruppe „Tabelle“ vorhanden, jedoch wurde kein dazugehöriges <references group="Tabelle" />-Tag gefunden oder ein schließendes </ref> fehlt.
  1. ↑ Österreichischer e-Health-Terminologie-Browser https://termgit.elga.gv.at
Abgerufen von „http://wiki.hl7.at/index.php?title=ILF:EImpfpass_Allgemeine_Richtlinien&oldid=154888“