Änderungen

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

Sind Elemente bzw. Attribute als „optional“ "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.

|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 MUSS weggelassen werden. Ein nullFlavor ist daher NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.

<pre class="ILFgreenilfbox_code">

<ref group="Tabelle">nullFlavor-Beispiele aus Value-Set ELGA_nullFlavorELGA_NullFlavor</ref>: nullFlavor-Beispiele aus ValueSet [https://termgit.elga.gv.at/ValueSet/elga-Set ELGA_nullFlavornullflavor ELGA_NullFlavor]

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 [[#Datentypen|Kapitel Datentypen]] angegebenen Einschränkungen. Die ELGA Implementierungsleitfäden beschreiben daher ein sogenanntes '''''„Maximum"Maximum-Set“Set"''''', Die ELGA Templates sind demnach als „closed templates“ "closed templates" entsprechend dem HL7 Templates Standard zu betrachten.

=====Ausnahme: „templateId“"templateId"=====

Attribute, die gem. CDA-Schema mit „fixed“ "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 zum XDS-Mapping:''' Beim XDS-Attribut XDSDocumentEntry.formatCode muss ein zusätzliches Plus-Zeichen („+“) am Ende des Strings hinzugefügt werden, wenn in einem Dokument selbst-definierte maschinenlesbare Elemente vorhanden sind. <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“]]). =====Hinweis zur Implementierung weiterverarbeitender Software=====CDA-Dokumente können unter Umständen „fremde“ "fremde" Elemente oder Attribute enthalten, die der „Maximum"Maximum-Set“ 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.

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 Codesysteme 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".

Beispiele für 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-Setswerden am österreichischen Terminologieserver publiziert: „ELGA_NullFlavor“, „ELGA_Dokumentenklassen“https://termgit.elga.gv.at/.

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 Binding====Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets werden . Das bedeutet, dass immer die aktuell am österreichischen Terminologieserver publiziert: https://termpubpublizierte Version eines Value Sets anzuwenden ist.gesundheit.gv.at/(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 Sets sind nicht nur durch einen eindeutigen Namen, sondern Set ist am Terminologieserver auch durch eine OIDein Zeitpunkt angegeben, und eine Versionsnummer gekennzeichnet. Weiters werden Gültigkeitsstatus und ein an dem es Gültigkeit erlangt ("Gültig abStatus: Active as of"-Datum angegeben), 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.

Hinweise zum korrekten Umgang mit Terminologien finden sich im „Leitfaden Im CDA-Dokument KANN über die Attribute @ValueSet und @ValueSetVersion angegeben werden, welches Value Set in welcher Version als Basis für den Umgang mit Terminologien in ELGA“ [TERMLEIT]die Befüllung des jeweiligen Datenelements verwendet wurde.

Inhalte von Value Sets können sich ändern, der Name und die OID eines Value Sets bleiben aber gleich. Bei neuen Versionen werden VersionsnummerAlle ValueSets, Änderungsdatum und „Gültig ab“-Datum (effectiveDate) angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden. In Ausnahmen kann bei der Definition eines Value Sets angegeben für ein CDA des Implementierungsleitfadens verwendet werden, dass es nicht geändert oder versioniert sollen periodisch gemeinsam aktualisiert werden darf (Property „Immutability“).  ====Value Set Binding====Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets. Das bedeutetDatum, dass immer an dem die aktuell am Terminologieserver publizierte Version eines lokal zur Implementierung verwendeten 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 mit dem es Gültigkeit erlangt („Gültig ab“)österreichischen Terminologieserver abgeglichen wurden, das ist für Value Sets wichtig, die schon vor ihrem Inkrafttreten veröffentlicht werden.  Value Sets können auch STATISCH an ein Codewird im Terminologiedatum-Header-Element gebunden werden"terminologyDate" angegeben. Das wird gekennzeichnet durch Damit kann die Angabe des Value Sets mit Name, OID, Version und "Gültig ab"-Datum (effectiveDate) sowie dem Schlüsselwort STATICGü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 „"[[#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 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 der Datei des CDA-Dokuments 20 MB nicht überschreiten.⁶

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