3.869
Bearbeitungen
Änderungen
→Allgemeine Richtlinien
==Allgemeine Richtlinien==
==Verwendung von Schlüsselwörtern und farblichen Hervorhebungen==
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 '''''[R]''''' 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 '''''[R2]'''''.
* KANN oder OPTIONAL (engl. MAY, OPTIONAL) Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Konformtä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äten==
Siehe auch [[ILF:Allgemeiner Implementierungsleitfaden#Umgang_mit_optionalen_Elementen|“Umgang mit optionalen Elementen“]].
{| 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="15%" | Verwendung von 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. NullFlavor oder "Dummy"-Werte sind NICHT ERLAUBT.
|- style="background:#FFFFFF"
| '''''[NP]''''' || 0..0 || ''nicht erlaubt'' || Das Element ist NICHT ERLAUBT.
|- style="background:#FFFFFF"
| '''''[R]''''' || 1..1<br /> 1..* || ''erlaubt'' || Das Element MUSS in der Instanz vorhanden sein. Wenn nicht bekannt, ist die Verwendung eines 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. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein. NullFlavor ist NICHT ERLAUBT.
|- style="background:#FFFFFF"
| '''''[O]''''' || 0..1<br /> 0..* || ''erlaubt'' || Das Element ist 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 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''
== 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, für die es Vorgaben gibt. Die Verwendung aller nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Die ELGA Templates können demnach als „closed templates“ betrachtet werden.
{{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“'''''. Für diese Regel existieren nur die im Folgenden genannten Ausnahmen:
===Ausnahme: „entry“===
Die Vorschrift des „Maximums-Sets“ gilt für alle Bereiche des CDA-Dokuments ''<u>außer der Ebene der maschinenlesbaren Elemente („entry“, CDA-Level 3) von Sektionen.</u>''
{{BeginYellowBox}}
Selbst-definierte maschinenlesbare Elemente KÖNNEN bei allen Sektionen zusätzlich angewandt werden (sowohl jene, die keine Entries vorsehen, als auch jene, die bereits Entries definieren)!
'''Achtung:''' Für bereits in Implementierungsleitfäden definierte Entries gilt jedoch die Regelung des „Maximum-Sets“! Ihre Erweiterung oder Veränderung ist NICHT ERLAUBT.
{{EndYellowBox}}
Diese Ausnahmeregelung soll eine erweiterte Nutzung der CDA-Dokumente ermöglichen und Innovationen bei der Weiterentwicklung der Spezifikationen zu fördern.
Es wäre dadurch erlaubt selbst-definierte Entries zu verwenden, um einen bestimmten Prozess in der eigenen Domäne oder im eigenen Einflussbereich maschinell abwickeln zu können. Die Gültigkeit in ELGA wäre bei einem derartigen Dokument dennoch gewährleistet.
Beispiel:<br/>
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-Entlassungsbriefen.
Leser aus anderen Gebieten können diese Strukturen zwar nicht interpretieren und daher auch nicht nützen, allerdings beeinflusst dies die normale Nutzung der Dokumente nicht.
====Meldepflicht von selbst-definierten maschinenlesbaren Elementen====
{{BeginYellowBox}}
Werden selbst-definierte maschinenlesbare Elemente zur Anwendung gebracht, MÜSSEN die entsprechenden Spezifikationen der ELGA GmbH gemeldet werden.
{{EndYellowBox}}
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/>
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“]]).
{{EndILFBox}}
===Ausnahme: „templateId“===
''templateId''-Elemente KÖNNEN bei Bedarf an allen laut CDA-Schema möglichen Stellen verwendet werden. Wenn bereits templateId-Elemente laut Spezifikation vorgeschrieben sind, KÖNNEN beliebig viele weitere ''templateId''-Elemente angegeben werden.
===Ausnahme: Verfasser von CDA-Sektionen===
Der Verfasser von Sektionen KANN mittels des Elements „''author''“ innerhalb einer Sektion („''section''“-Element) abgebildet werden. Diese „''author''“-Elemente sind bei Bedarf OPTIONAL bei allen CDA-Sektionen zusätzlich zu verwenden, sofern die Spezifikation der Sektion dies nicht explizit ausschließt.
Siehe auch ''„[[ILF:Allgemeiner Implementierungsleitfaden#Sektionen|Sektionen]]“''.
===Ausnahme: Zusätzliche weitere Beteiligte===
Die möglichen Arten für die Dokumentation von wichtigen beteiligten Personen oder Organisationen (z.B. Angehörige, Verwandte, Versicherungsträger, etc.) 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 ERLAUBT, darüberhinausgehende Arten von Beteiligten anzugeben, ausgenommen die entsprechende Art von Beteiligten ist in einem speziellen Implementierungsleitfaden explizit definiert.
===Ausnahme: Fixierte Attribute===
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 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 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==
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 '''''[[ILF:Allgemeiner Implementierungsleitfaden#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 und Verwendung siehe [[ILF:Allgemeiner Implementierungsleitfaden#Der_nullFlavor|Der nullFlavor]].
==Zertifizierung/Abnahmeprüfung==
