Änderungen

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 nullFlavors ausgedrückt werden).

* MUSS bedeutet eine verpflichtend einzuhaltende Vorschrift (Gebot). Entspricht den Konformitätskriterien '''''[R 1..*M]''''' und '''''[MR]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 Konformtätskriterium Konformitätskriterium '''''[O]'''''.

===Legende Kardinalität===Die Kardinalität beschreibt, wie oft ein Element innerhalb einer Struktur auftreten kann. Die Kardinalität wird durch ein Intervall zwischen der Konformitätskriterien (Optionalität)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..* ===Umgang mit optionalen Elementen===Siehe auch 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 '''''[[#Umgang_mit_optionalen_ElementenDer_nullFlavor|“Umgang mit optionalen Elementen“nullFlavor]]''''' zu erfolgen. ===Legende der Konformitätskriterien=======Optionalitäten von CDA-Elementen====

! 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 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''("mandatory")''. NullFlavor <br />nullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.|- style="background:#FFFFFF"| '''''[NP]''''' || 0..0 || ''nicht erlaubt'' || Das '''Element ist i'''st NICHT ERLAUBT''("not permitted")''.|- style="background:#FFFFFF"| rowspan="2" | '''''[R]''''' || 1..1<br /> 1..* || ''erlaubt'' || Das '''Element ''' MUSS in der Instanz vorhanden sein''("required")''. Wenn ein Element nicht bekanntist, ist die Verwendung eines NullFlavors nullFlavors vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT.|- style="background:#FFFFFF"| 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 seinund MUSS weggelassen werden. NullFlavor 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 ''("optional")''. Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird. |- style="background:#FFFFFF"| '''''[FC]''''' || 1..1|| || Für das Element ist ein fixer Wert vorgeschrieben. |- style="background:#FFFFFF"| Die Optionalität des '''Elements''[C]''''' || || || KONDITIONALES Konformitätskriterium. Die Konformität des Elements variiert in Abhängigkeit von anderen Elementen, Situationen oder Zuständen(''"conditional"''). Die konkreten Abhängigkeiten sind in Folge angegeben.

<ref group="Tabelle">Legende der Optionalitäten von Elementen</ref>:''Tabelle 2: Legende der Optionalitätenvon Elementen''

===Kardinalität=Optionalitäten von CDA-Attributen====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..*{| class="wikitable" width="100%"|- ! style="text-align:left" width="15%" |Konformitäts-Kriterium|| style=Maximum"text-Setalign:left" width="15%" |Mögliche Kardinalität|| style="text-align:left" width=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 "55%" |Beschreibung und Definition aller Elemente in einem Implementierungsleitfaden wäre daher äußerst aufwändig und kann im vorliegenden Implementierungsleitfäden nicht erfolgen.|- Vielmehr werden lediglich jene Elemente, für die es Vorgaben gibt beschrieben|'''''[NP]'''''||0.. Die Verwendung aller nicht angegebenen Elemente und Attribute 0||Das '''Attribut''' ist NICHT ERLAUBT. Die e''("not permitted")''|-Impfpass Templates sind daher „closed templates“|'''''[R]'''''|1..1{| style=Das '''Attribut''' MUSS in der Instanz vorhanden sein. ''("required"background)''|-color:#ffffcc;|'''''[O]'''''||0..1||Das '''Attribut''' ist OPTIONAL. ''(" cellpadding="20" cellspacing=optional")''|- |'''''[F]'''''||0" border="..11..1"|Wenn das '''Elemente oder AttributeAttribut''' angegeben wird, die nicht im e-Impfpass Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBTist ein fixer Wert vorgeschrieben. ''("fixed")''Für das '''Attribut''' ist ein fixer Wert vorgeschrieben.''("fixed")'' |-

Diese beschreiben daher ein sogenanntes '''''„Maximum-Set“'<ref group="Tabelle">Legende der Optionalitäten von Attributen</ref>:''Legende der Optionalitäten von Attributen''. Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:

====Ausnahme: Fixierte Attribute=Der nullFlavor===AttributeDas Attribut @''nullFlavor'' dient zur Kennzeichnung, die gem. CDA-Schema mit default („fixed“) angegeben sind, haben einen festen Wert, daher können diese Attribute auch weggelassen dass ein Element nicht seiner Entsprechung gemäß befüllt werdenkann. Diese Attribute werden daher üblicherweise nicht beschrieben und angegeben. Die Angabe von fixierten Attributen oder Attributen mit ihrem gem. CDA-Schema definierten Default-Wert konkrete Anwendung des @''nullFlavor'' Attributs ist im Rahmen dieser Implementierungsleitfäden nur erlaubt, auch wenn diese nicht er explizit im Leitfaden beschrieben sindin 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").

Beispiel für ein Element, welches mit dem @''nullFlavor'' versehen wurde:<pre class="ilfbox_code"><id nullFlavor===Hinweis zur Implementierung weiterverarbeitender Software===="UNK" />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). </pre>Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden seinWenn in einem Element ein nullFlavor angegeben wurde, soll weiterverarbeitende Software so implementiert sein, dass dies kann nicht zu Fehlern in der Weiterverarbeitung der Dokumente führtgleichzeitig ein anderes Attribut eingetragen werden.

'''nullFlavor Beispiele''':{| class====Umgang mit Ausnahmen bei der Konformitätsprüfung ===="wikitable" |-! nullFlavor! displayName! Deutsche Übersetzung! Anwendung|-| '''NI'''| NoInformation| keine Information vorhanden| wenn es keine Informationen gibt|-| '''UNK'''| Unknown| unbekanntNur Elemente| wenn es Informationen gibt, die im „Maximumdiese aber unbekannt sind|-Set“ beschrieben sind| '''MSK'''| Masked| maskiert | wenn es Informationen gibt, können zuverlässig geprüft 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. „Fremde“ Elemente oder Attribute werden daher von den Konformitätsprüfmechanismen im Sinne der „closed templates“ grundsätzlich als falsch erkanntelga. Zusätzliche Entries oder TemplateIds können daher Fehlermeldungen auslösengv. Attribute, die im CDAat/ValueSet/elga-Schema als „fixed“ definiert sind oder mit ihrem Default-Wert angegeben sind, dürfen angegeben werden und werden auch nicht als Fehler bewertet.nullflavor ELGA_NullFlavor]

===Umgang mit optionalen ElementenMaximum-Set===Sind Das CDA-Modell beschreibt ein höchst umfangreiches Schema von Informationselementen und bietet in manchen Bereichen über rekursive, beliebig tief verschachtelbare Elemente bzweine theoretisch unendlich hohe Anzahl von Möglichkeiten, Informationen abzulegen. Attribute als „optional“ gekennzeichnet ('''''[O]''''') so Die vollständige Beschreibung und Definition aller Elemente in einem Implementierungsleitfaden wäre daher äußerst aufwändig und ist ihre Verwendung OPTIONAL, aber es ist NICHT ERLAUBT, dass sie, wenn sie verwendet werden, leer sindin den ELGA Implementierungsleitfäden nicht erfolgt. 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 Vielmehr beschreiben die ELGA Implementierungsleitfäden lediglich jene Elemente, die erlaubt sind. Die Verwendung aller nicht angegebenen Elemente und Verwendung siehe Attribute ist NICHT ERLAUBT. Für alle Templates gelten die im [[#Der_nullFlavorDatentypen|Der nullFlavorKapitel 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}}Elemente oder Attribute, die nicht vom Allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT.{{EndYellowBox}}====Ausnahmen====Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:

===Value Sets==Ausnahme: "templateId"=====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 ''templateId''-Elemente KÖNNEN bei Bedarf an allen laut CDA-Schema möglichen Stellen verwendet werden. Ein Value Set enthält die Codes selbst und die Information über die Herkunft des Codes (das SourceWenn bereits templateId-Elemente laut Spezifikation vorgeschrieben sind, KÖNNEN beliebig viele weitere ''templateId''-Codesystem)Elemente angegeben werden.

Beispiele für Value=====Ausnahme: Fixierte Attribute=====Attribute, die gem. CDA-Sets: „ELGA_NullFlavor“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, „ELGA_Dokumentenklassen“auch wenn diese nicht explizit im Leitfaden beschrieben sind.

Wo immer in den CDA Implementierungsleitfäden eine Werteauswahl getroffen =====Explizit angegebene Ausnahmen=====Im speziellen Implementierungsleitfaden KÖNNEN bestimmte Sektionen als "offene Templates" definiert 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/und Ausnahmen für Subsektionen und Entries zulassen.

Value Sets sind nicht nur durch einen eindeutigen Namen, sondern auch durch eine OID====Hinweis zur Implementierung weiterverarbeitender Software====CDA-Dokumente können unter Umständen "fremde" Elemente oder Attribute enthalten, und eine Versionsnummer gekennzeichnet. Weiters werden Gültigkeitsstatus und ein die der "Gültig abMaximum-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-Datum angegebenDokumente führt.

Hinweise zum korrekten Umgang mit Terminologien finden sich im „Leitfaden für den Umgang mit Terminologien in ELGA“ [TERMLEIT]===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".

====Änderbarkeit von Value Sets====Inhalte von Value Sets können sich ändernWo immer in den CDA-Implementierungsleitfäden eine Werteauswahl getroffen werden kann, der Name und die OID eines wird ein passendes Value Sets bleiben aber gleich. Bei neuen Versionen werden Versionsnummer, Änderungsdatum und „Gültig ab“-Datum (effectiveDate) Set mit einem eindeutigen Namen angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden. In Ausnahmen kann bei der Definition eines Sämtliche in den Implementierungsleitfäden verwendeten Value Sets angegeben werden, dass es nicht geändert oder versioniert werden darf (Property „Immutability“)am österreichischen Terminologieserver publiziert: https://termgit.elga.gv.at/.

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 („Gültig ab“"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.

Value Sets können auch STATISCH an ein CodeIm CDA-Element gebunden Dokument KANN über die Attribute @ValueSet und @ValueSetVersion angegeben werden. Das wird gekennzeichnet durch , welches Value Set in welcher Version als Basis für die Angabe Befüllung des Value Sets mit Name, OID, Version und "Gültig ab"-Datum (effectiveDate) sowie dem Schlüsselwort STATICjeweiligen Datenelements verwendet wurde.

===Der nullFlavor=Änderbarkeit von Value Sets====Das Attribut @''nullFlavor'' dient zur KennzeichnungInhalte von Value Sets können sich ändern, wenn das Element nicht seiner Entsprechung gemäß befüllt werden kannder Name und die OID eines Value Sets bleiben aber gleich.  Obwohl dieses Attribut vom CDA-Schema bei prinzipiell jedem CDA-Element erlaubt wäreAlle ValueSets, ist die konkrete Anwendung für ein CDA des @''nullFlavor'' Attributs im Rahmen dieser Implementierungsleitfäden nur eingeschränkt erlaubtImplementierungsleitfadens verwendet werden, sollen periodisch gemeinsam aktualisiert werden. Ein entsprechender Vermerk ist im jeweiligen Abschnitt angeführt. Beispiel für ein ElementDas Datum, welches an dem die lokal zur Implementierung verwendeten Value Sets mit dem @''nullFlavor'' versehen wurde:{{BeginOrangeBox}}<id nullFlavor=österreichischen Terminologieserver abgeglichen wurden, wird im Terminologiedatum-Header-Element "'''UNK'''terminologyDate" />{{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, Damit kann nicht gleichzeitig ein anderes Attribut eingetragen die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden.

PDF-Attachments kommen im e-Impfpass nicht zur Anwendung.<!-- Standardtext: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-1a 1b bzw. PDF/A-3b entsprechen MUSS<sup>5<sup>. 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-1a 1b bzw. PDF/A3-b (gemäß „ISO "ISO 19005-1:2005 Level A conformance“conformance") entsprechen. Die Umsetzung von PDF/A-1a bzw. PDF/A-3a ist EMPFOHLEN.

In CDA -Dokumenten können verschiedene Objekte (z.B. PDF-Dokumente, Bilder) eingebettet werden (siehe „"[[ILF:Allgemeiner Implementierungsleitfaden#ELGA_EingebettetesObjekt-EntryEingebettetes_Objekt_Entry|ELGA EingebettetesObjekt-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 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 des CDA-Dokuments 20 MB nicht überschreiten.⁶ ⁶ Aktuell wird von ELGA die Größe von Doumenten auf 20MB beschränkt.{{EndYellowBox}}

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'''.