320
Bearbeitungen
Änderungen
→Legende der Konformitätskriterien (Optionalität)
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 '''''[R1..*]''''' und '''''[M]'''''.
* 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 '''''[R2R 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]'''''.
===Kardinalität===Die Kardinalität beschreibt, wie oft ein Element innerhalb einer Struktur auftreten kann. Die Kardinalität wird durch ein Intervall zwischen Legende 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..*Konformitätskriterien (Optionalität)==Legende der Optionalitäten==
Siehe auch [[#Umgang_mit_optionalen_Elementen|“Umgang mit optionalen Elementen“]].
{| class="wikitable" width="100%"
| '''''[M]''''' || 1..1<br/> 1..* || ''nicht erlaubt'' || Das Element MUSS mit einem korrekten "echten" Wert angegeben werden. NullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.
|- style="background:#FFFFFF"
| '''''[NP]''''' || 0..0 || ''nicht erlaubt'' || Das Element oder Attribut ist NICHT ERLAUBT.
|- style="background:#FFFFFF"
| rowspan="2" | '''''[R]''''' || 1..1<br /> 1..* || ''erlaubt'' || Das Element oder Attribut MUSS in der Instanz vorhanden sein. Wenn ein Element nicht bekanntist, ist die Verwendung eines NullFlavors vorgeschrieben, "Dummy"-Werte sind NICHT ERLAUBT.
|- style="background:#FFFFFF"
|- style="background:#FFFFFF"
| '''''[O]''''' || 0..1<br /> 0..* || ''erlaubt'' || Das Element oder Attribut ist OPTIONAL. Sender können das Element angeben. Leere optionale Elemente sind nicht zugelassen, sofern kein nullFlavor angewandt wird. Nur die jeweils im Template explizit angegebenen nullFlavors sind erlaubt. Ist kein nullFlavor angegeben, darf kein nullFlavor angewendet werden.
|- style="background:#FFFFFF"
| '''''[F]''''' || 0..1<br /> 1..1|| || Für das Element Attribut ist ein fixer Wert vorgeschrieben.
|- 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.
|-
|}
''Tabelle 2: Legende der Optionalitäten. Attribute dürfen höchstens ein mal pro Element vorkommen'' ===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..*
===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 kann im vorliegenden Implementierungsleitfäden Implementierungsleitfaden nicht erfolgen.
Vielmehr werden lediglich jene Elemente, für die es Vorgaben gibt beschrieben. Die Verwendung aller nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Die e-Impfpass Templates sind daher „closed templates“.
{{BeginYellowBox}}
'''Elemente oder Attribute, die nicht im e-Impfpass Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT. '''
{{EndYellowBox}}
Diese beschreiben daher ein sogenanntes '''''„Maximum-Set“'''''. Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:
====Ausnahme: Fixierte Attribute====
Attribute, die gem. CDA-Schema mit default („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.
====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.
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.
====Umgang mit Ausnahmen bei der Konformitätsprüfung ====
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 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. <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.
===Umgang mit optionalen Elementen===
Zur genauen Definition und Verwendung siehe [[#Der_nullFlavor|Der nullFlavor]].
===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.
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.
===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.
===PDF Format-Vorschrift===
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). 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>.
{{BeginYellowBox}}
{{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===
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 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>
{{EndYellowBox}}
<sup>6</sup> Aktuell wird von ELGA die Größe von Doumenten auf 20MB beschränkt.
===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'''.
