Änderungen

==Allgemeine Richtlinien für die Implementierung des e-Impfpasses=====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 nullFlavors ausgedrückt werden).

* MUSS bedeutet eine verpflichtend einzuhaltende Vorschrift (Gebot). Entspricht den Konformitätskriterien '''''[RM]''''' 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 '''''[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 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ätenUmgang 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| rowspan="background:#FFFFFF2"| '''''[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"| '''''[R2]''''' || 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"| '''''[C]''''' || || || KONDITIONALES Konformitätskriterium. Die Konformität Optionalitä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''

== Maximum==Optionalitäten von CDA-SetAttributen===={| 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 CDA Modell beschreibt ein höchst umfangreiches Schema von Informationselementen und bietet '''Attribut''' MUSS in manchen Bereichen über rekursiveder Instanz vorhanden sein. ''("required")''|- |'''''[O]'''''||0..1||Das '''Attribut''' ist OPTIONAL. ''("optional")''|- |'''''[F]'''''||0..11..1|Wenn das '''Attribut''' angegeben wird, beliebig tief verschachtelbare Elemente eine theoretisch unendlich hohe Anzahl von Möglichkeiten, Informationen abzulegenist ein fixer Wert vorgeschrieben. Die vollständige Beschreibung und Definition aller Elemente in einem Implementierungsleitfaden wäre daher äußerst aufwändig und ''("fixed")''Für das '''Attribut''' ist in den ELGA Implementierungsleitfäden nicht erfolgtein 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===Der nullFlavor===Das Attribut @''nullFlavor'' dient zur Kennzeichnung, für die es Vorgaben gibt. Die Verwendung aller dass ein Element nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Die ELGA Templates können demnach als „closed templates“ betrachtet seiner Entsprechung gemäß befüllt werdenkann.{{BeginYellowBox}}Elemente oder Attribute, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT. {{EndYellowBox}}Die ELGA Implementierungsleitfäden beschreiben daher ein sogenanntes '''''„Maximum-Set“'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 diese Regel existieren nur [[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 im Folgenden genannten Ausnahmen:Verwendung eines Codes mit demselben Informationsgehalt (etwa für "keine Allergie bekannt" das SNOMED Konzept 716186003 "No known allergy").

===Ausnahme: „entry“===Die Vorschrift des „Maximums-Sets“ gilt Beispiel für alle Bereiche des CDA-Dokuments ein Element, welches mit dem @''nullFlavor'' versehen wurde:<upre class="ilfbox_code">außer der Ebene der maschinenlesbaren Elemente („entry“, CDA-Level 3) von Sektionen.<id nullFlavor="UNK" /u>''{{BeginYellowBox}}</pre>Selbst-definierte maschinenlesbare Elemente KÖNNEN bei allen Sektionen zusätzlich angewandt Wenn in einem Element ein nullFlavor angegeben wurde, kann nicht gleichzeitig ein anderes Attribut eingetragen werden (sowohl jene, die keine Entries vorsehen, als auch jene, die bereits Entries definieren)!.

'''Achtung:nullFlavor Beispiele''' Für bereits in Implementierungsleitfäden definierte Entries gilt jedoch die Regelung des „Maximum:{| class="wikitable" |-Sets“! nullFlavor! displayName! Deutsche Übersetzung! Ihre Erweiterung oder Veränderung ist NICHT ERLAUBT.Anwendung|-| '''NI'''| NoInformation| keine Information vorhanden{{EndYellowBox}}| wenn es keine Informationen gibtDiese Ausnahmeregelung soll eine erweiterte Nutzung der CDA|-Dokumente ermöglichen und Innovationen bei der Weiterentwicklung der Spezifikationen zu fördern.| '''UNK'''| Unknown| unbekannt| wenn es Informationen gibt, diese aber unbekannt sindEs wäre dadurch erlaubt selbst|-definierte Entries zu verwenden| '''MSK'''| Masked| maskiert | wenn es Informationen gibt, um einen bestimmten Prozess in der eigenen Domäne oder im eigenen Einflussbereich maschinell abwickeln zu können. Die Gültigkeit 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 ELGA wäre bei einem derartigen Dokument dennoch gewährleistet.alternativen Codesystem verfügbar ist|}Beispiel:<brref group="Tabelle">nullFlavor-Beispiele aus Value Set ELGA_NullFlavor</ref>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: nullFlavor-EntlassungsbriefenBeispiele aus Value Set [https://termgit.elga.gv.at/ValueSet/elga-nullflavor ELGA_NullFlavor]

Leser aus anderen Gebieten können diese Strukturen zwar nicht interpretieren ===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 auch nicht nützen, allerdings beeinflusst dies die normale Nutzung der Dokumente äußerst aufwändig und ist in den ELGA Implementierungsleitfäden nichterfolgt.

====Meldepflicht von selbstVielmehr 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-definierten maschinenlesbaren Elementen====Set"''''', Die ELGA Templates sind demnach als "closed templates" entsprechend dem HL7 Templates Standard zu betrachten.

Werden selbst-definierte maschinenlesbare Elemente zur Anwendung gebrachtoder Attribute, MÜSSEN die entsprechenden Spezifikationen der nicht vom Allgemeinen oder einem speziellen ELGA GmbH gemeldet werden-Implementierungsleitfaden definiert wurden, sind NICHT ERLAUBT.

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.{{BeginILFBox}}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/>====Ausnahmen====Siehe dazu Für diese Regel existieren nur die entsprechende Regelung im Leitfaden „[[ILFFolgenden genannten Ausnahmen: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“"templateId"=====

=====Ausnahme: Verfasser von CDA-SektionenFixierte Attribute=====Der Verfasser von Sektionen KANN mittels des Elements „''author''“ innerhalb einer Sektion („''section''“Attribute, die gem. CDA-Element) abgebildet Schema mit "fixed" angegeben sind, haben einen festen Wert, daher können diese Attribute auch weggelassen werden. Diese „''author''“Attribute werden daher üblicherweise nicht beschrieben und angegeben. Die Angabe von fixierten Attributen oder Attributen mit ihrem gem. CDA-Elemente sind bei Bedarf OPTIONAL bei allen CDASchema definierten Default-Sektionen zusätzlich zu verwendenWert ist erlaubt, sofern die Spezifikation der Sektion dies auch wenn diese nicht explizit ausschließtim Leitfaden beschrieben sind.

Siehe auch ''„[[ILF:Allgemeiner =====Explizit angegebene Ausnahmen=====Im speziellen Implementierungsleitfaden#KÖNNEN bestimmte Sektionen|Sektionen]]“''als "offene Templates" definiert werden und Ausnahmen für Subsektionen und Entries zulassen.

===Ausnahme: Zusätzliche weitere Beteiligte=Hinweis zur Implementierung weiterverarbeitender Software====Die möglichen Arten für CDA-Dokumente können unter Umständen "fremde" Elemente oder Attribute enthalten, die Dokumentation von wichtigen beteiligten Personen oder Organisationen der "Maximum-Set" Vorschrift dieses Leitfadens widersprechen (z.B. Angehörige, Verwandte, Versicherungsträger, etc.aufgrund von Software-Fehlern) sind in diesem Leitfaden in [[ILF:Allgemeiner Implementierungsleitfaden#Weitere_Beteiligte_.28.E2.80.9Eparticipant.E2.80.9C.29|Weitere Beteiligte („participant“)]] definiert. Es ist daher NICHT ERLAUBTSollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, darüberhinausgehende Arten von Beteiligten anzugebensoll weiterverarbeitende Software so implementiert sein, ausgenommen die entsprechende Art von Beteiligten ist dass dies nicht zu Fehlern in einem speziellen Implementierungsleitfaden explizit definiertder Weiterverarbeitung der CDA-Dokumente führt.

===Ausnahme: Fixierte AttributeValue Sets===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 Ein Value Set ist eine eindeutig durch Name oder OID identifizierbare und angegebenversionierte Sicht auf ein oder mehrere Codesysteme. Die Angabe Es kann als Zusammenstellung von fixierten Attributen einem oder Attributen mit ihrem gemmehreren Codes aus einem oder mehreren Codesystemen gesehen werden. CDAEin Value Set enthält die Codes selbst und die Information über die Herkunft des Codes (das Source-Schema definierten Default-Wert ist erlaubtCodesystem), auch wenn diese nicht explizit im Leitfaden beschrieben sindz.B. "ELGA_NullFlavor" oder "ELGA_Dokumentenklassen".

===Hinweis zur Implementierung weiterverarbeitender Software===Wo immer in den CDA-Dokumente können unter Umständen „fremde“ Elemente oder Attribute enthaltenImplementierungsleitfäden eine Werteauswahl getroffen werden kann, die der „Maximum-Set“ Vorschrift dieses Dokumentleitfadens widersprechen (zwird 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.Belga. aufgrund von Software-Fehlern)gv. Darüber hinaus können CDA-Dokumente ebenfalls selbst-definierte maschinenlesbare Elemente beinhaltenat/.

Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, soll weiterverarbeitende Software so implementiert sein====Value Set Binding====Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value Sets. Das bedeutet, dass dies nicht zu Fehlern immer die aktuell am Terminologieserver publizierte Version eines Value Sets anzuwenden ist. (Das Setzen des entsprechenden Schlüsselworts DYNAMIC ist daher in der Weiterverarbeitung der Dokumente führtden Leitfäden optional, aktuell gibt es auch keine ValueSets die statisch gebunden sind).

===Umgang mit Ausnahmen bei der Konformitätsprüfung ===Nur ElementeFü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 im „Maximum-Set“ beschrieben schon vor ihrem Inkrafttreten veröffentlicht werden. Value Sets sindso lange gültig, können zuverlässig geprüft werden. „Fremde“ Elemente oder Attribute⁴ werden daher von den Konformitätsprüfmechanismen im Sinne der „closed templates“ grundsätzlich als falsch erkannt. Selbst bis das Gültigkeitsdatum einer neueren Version dieses Value Sets erreicht wird – dann gilt 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 werdenneuere Version.

⁴Attribute====Ä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 CDATerminologiedatum-Schema als „fixed“ definiert sind oder mit ihrem DefaultHeader-Wert Element "terminologyDate" angegeben sind, dürfen angegeben werden und . Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden auch nicht als Fehler bewertet.

==Umgang mit optionalen Elementen==Publikation der Value Sets am Terminologieserver====Sind Elemente bzwSä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. Attribute als „optional“ gekennzeichnet ('''''[O]''''') so ist ihre Verwendung OPTIONAL, aber es ist NICHT ERLAUBTat</ref>Damit die jeweils aktuelle Version der Value Sets angewendet werden kann, dass sie, wenn sie verwendet soll der Terminologieserver regelmäßig auf Update abgeprüft werden, leer sind. Möchte man ein optionales Element explizit mit einem leeren Wert angeben, so hat dies durch Kennzeichnung mit '''''[[ILF:Allgemeiner Implementierungsleitfaden#Der_nullFlavor|nullFlavor]]''''' zu erfolgen, zum Beispiel:* '''NI''': wenn es keine Informationen gibt* '''UNK''': wenn es Informationen gibtEs wird EMPFOHLEN, diese aber unbekannt sindÜberprüfung täglich durchzuführen.

Zur genauen Definition ====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 Verwendung siehe [[ILF:Allgemeiner Implementierungsleitfaden#Der_nullFlavor|Der nullFlavor]]MÜSSEN vermieden werden.

==ELGA Value Sets=PDF Format-Vorschrift===Ein Value Set ist 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 identifizierbare und versionierte Sicht auf ein oder mehrere Codesystemevisuell reproduzierbar sind. Es Dies 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 Einhaltung der Mindestkriterien der Norm ISO 19005-1:2005 sichergestellt werden (das SourcePDF/A-Codesystem)1b Basic bzw.  Beispiele für ELGA ValuePDF/A-Sets: „ELGA_NullFlavor“, „ELGA_Dokumentenklassen“3b Basic).  Wo immer in den ELGA CDA Implementierungsleitfäden eine Werteauswahl getroffen werden kannDie Norm beschreibt zusätzlich die Barrierefreiheit der Dokumente, wird ein passendes Value Set mit sodass sie von einem eindeutigen Namen angegeben. Sämtliche in den Implementierungsleitfäden verwendeten Value Sets Screenreader vorgelesen werden am österreichischen Terminologieserver publiziert: https:können (PDF//termpub.gesundheit.gvA-1a Accessible bzw.atPDF/A-3a Accessible).  Value Sets sind nicht nur durch einen eindeutigen NamenDieser Implementierungsleitfaden schreibt daher als Minimalanforderung vor, sondern auch durch eine OID, und eine Versionsnummer gekennzeichnetdass jedes eingebettete PDF-Dokument dem Standard PDF/A-1b bzw. Weiters werden Gültigkeitsstatus und ein "Gültig ab"PDF/A-Datum angegeben3b entsprechen MUSS.  Hinweise zum korrekten Umgang mit Terminologien finden sich im „Leitfaden für den Umgang mit Terminologien in ELGA“ [TERMLEIT]. ===Änderbarkeit von Value Sets===Inhalte von Value Sets können sich ändern, Im Sinne der Name und Barrierefreiheit ist die OID eines Value Sets bleiben aber gleichUmsetzung von PDF/A-1a bzw. Bei neuen Versionen werden Versionsnummer, Änderungsdatum und „Gültig ab“PDF/A-Datum (effectiveDate) angegeben. Damit kann die Gültigkeit zu einer bestimmten Zeit rekonstruiert werden3a EMPFOHLEN.{{BeginYellowBox}}In Ausnahmen kann bei der Definition eines Value Sets angegeben werden, dass es nicht geändert oder versioniert werden darf Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1b bzw. PDF/A3-b (Property „Immutability“gemäß "ISO 19005-1:2005 Level A conformance")entsprechen.  ===Value Set Binding===Für ELGA gilt grundsätzlich eine DYNAMISCHE Bindung an Value SetsDie Umsetzung von PDF/A-1a bzw. Das bedeutet, dass immer die aktuell am Terminologieserver publizierte Version eines Value Sets anzuwenden ist. (Das Setzen des entsprechenden Schlüsselworts DYNAMIC PDF/A-3a ist daher in den Leitfäden optional)EMPFOHLEN. 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. {{EndYellowBox}}

Value Sets ===Größenbeschränkung von eingebetteten Objekten===In CDA-Dokumenten können auch STATISCH an ein Codeverschiedene Objekte (z.B. PDF-Element gebunden Dokumente, Bilder) eingebettet werden. Das wird gekennzeichnet durch die Angabe des Value Sets mit Name, OID, Version und (siehe "Gültig ab[[#Eingebettetes_Objekt_Entry|Eingebettetes Objekt Entry]]"-Datum (effectiveDate) sowie dem Schlüsselwort STATIC.

==PDF Format-Vorschrift==In CDA Dokumenten können Dokumente im PDF Format an verschiedensten Stellen eingebettet werdenDieser Implementierungsleitfaden schreibt keine Größenbeschränkung für diese Objekte vor, es wird allerdings EMPFOHLEN, entweder als gesamter CDA-Body oder als eingebetteter Inhalt diese in gewissen CDA-SektionenBezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Im Hinblick auf eine dauerhafte Verfügbarkeit Es liegt in der Daten muss mindestens gewährleistet werdenVerantwortung des Erstellers, dass diese PDFdie Größe der über ELGA bereitgestellten CDA-Dokumente zuverlässig und eindeutig visuell reproduzierbar sind. Dies kann über die Einhaltung etwa durch Verringerung der Mindestkriterien Auflösung oder der Norm ISO 19005-1:2005 sichergestellt werden (PDF/A-1b Basic). Die Norm beschreibt zusätzlich Barrierefreiheit Anzahl 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>Einzelbilder auf eine sinnvolle und angemessene Größe zu beschränken.

Alle in ELGA-Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße des CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1a (gemäß „ISO 19005-1:2005 Level A conformance“) entsprechenDokuments 20 MB nicht überschreiten.

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