1.104
Bearbeitungen
Änderungen
→Publikation der Value Sets am Terminologieserver
| wenn eine Codierung nur in einem alternativen Codesystem verfügbar ist
|}
<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]
===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 [[#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.
====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.
===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".
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.
====Ä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 Alle ValueSets, die für ein CDA des Implementierungsleitfadens verwendet werden, sollen periodisch gemeinsam aktualisiert werden Versionsnummer. Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, Änderungsdatum und wird im Terminologiedatum-Header-Element "Gültig abterminologyDate"-Datum (effectiveDate) 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).
====Terminologiedatum====Das Datum, an dem sämtliche lokal zur Implementierung verwendeten Value Sets können auch STATISCH an ein Code-mit dem österreichischen Terminologieserver abgeglichen wurden, wird über das "Terminologiedatum" angegeben: Dieses Datum wird in der Notation "YYYYMMDD" im eigenen Element gebunden werden"terminologyDate" angegeben. Das wird gekennzeichnet durch die Angabe des Beim Abgleich der Terminologien müssen immer alle Value Sets mit Name, OIDdie 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 "Gültig ab"-Datum (effectiveDate) sowie dem Schlüsselwort STATICMÜSSEN vermieden werden.
===PDF Format-Vorschrift===
{{BeginYellowBox}}
Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1a 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}}
===Größenbeschränkung von eingebetteten Objekten===
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.
{{BeginYellowBox}}
Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße der Datei des CDA-Dokuments 20 MB nicht überschreiten.<sup>6</sup>
{{EndYellowBox}}
===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'''.