Änderungen

ALT Implementierungsleitfaden "Allgemeiner Implementierungsleitfaden 2020" ALT

<nowiki>{{#css:

.orange{</nowiki>

}}</nowiki> {{Infobox Dokument|Group = ELGA CDA<br/>Implementierungsleitfäden|Title = HL7 Implementation Guide for CDA^&reg; R2:<br/>Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente|Subtitle = Zur Anwendung im österreichischen<br/>Gesundheitswesen [1.2.40.0.34.7.1.6.2]|Short = Allgemeiner Implementierungsleitfaden |Namespace = ILF|Type = Implementierungsleitfaden|Version = 2020|Submitted = HL7 Austria|Date = 14. Jänner 2020|Copyright = 2020-2025|Status = Entwurf|Period = n.a.|OID = n.n.|Realm = Österreich

'''<BEISPIEL>'''<br Diese Seite wurde verschoben. Neuer Link: https:/>Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden /wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_2020

''<u>Hinweis auf anderen Implementierungsleitfaden:</u>''{{BeginILFBox}}'''<BEISPIEL>'''<br />Verweis auf Allgemeinen Leitfaden:…{{EndILFBox}}''<u>Themenbezogenes CDA Beispiel-Fragment im XML Format:</u>''{{BeginOrangeBox}}'''<BEISPIEL>'''<br /><languageCode code="de-AT" />{{EndOrangeBox}} <div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">===PDF-Navigation===<div class="mw-collapsible-content">Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern: *Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts*Seitenweise blättern: "Bild" Tasten*Scrollen: Pfeil nach oben bzw. unten*Zoomen: Strg + Mouserad drehen*Suchen im Dokument: Strg + F</div></div> <!-- Seitenumbruch --><p style="page-break-before: always"></p><!-- Tatsächlicher Inhalt --> =Einleitung===Ausgangslage und Motivation=='''(vorher Dokumente im Gesundheitswesen)'''In der medizinischen Welt ist es üblich, klinische Sachverhalte und Beobachtungen mit ihrem Kontext in Dokumente zusammenfassen. Der Kontext – z.B. das Ergebnis einer Laboruntersuchung nach einer speziellen Medikamentenbehandlung – wird durch das Dokument etabliert und muss dauerhaft erhalten bleiben, da er wichtige medizinische Zusammenhänge zwischen Einzelinformationen darstellt. Gleichzeitig muss der medizinische Inhalt leicht verfügbar sein und ohne große technische Barrieren sichtbar gemacht werden können. Dies ist unabdingbar für die Akzeptanz von und das Vertrauen in Technologie bei den Endbenutzern, den GDA (Gesundheitsdiensteanbieter). Was mit der Papierwelt bis zu einem gewissen Grade erreicht wurde, muss auch für die elektronische Entsprechung des Papierdokuments gelten.  Die Elektronische Gesundheitsakte (ELGA) ermöglicht den durch das ELGA-Gesetz berechtigten Personen, entsprechend ihren Rollen, den Zugriff auf relevante Gesundheitsdaten, die in bedarfsgerecht elektronisch aufbereiteter Form online zur Verfügung gestellt werden.  Die zentrale Anwendung von ELGA ist die Bereitstellung von medizinischen Dokumenten (e-Befunde) der ELGA-Teilnehmer, die in vielen unterschiedlichen Informationssystemen der verschiedenen ELGA-Gesundheitsdiensteanbieter erstellt werden. Diese Dokumente sollen nicht nur von Benutzern gelesen, sondern auch wieder in die IT-Systeme integriert und dort weiterverwendet werden können („Semantische Interoperabilität“). Beispielsweise können für den Arzt aus ELGA-Dokumenten automatisch Warnungen, Erinnerungen und Zusammenfassungen generiert und weitere Informationen berechnet sowie kontextbezogen angezeigt werden. Die Elektronische Gesundheitsakte (ELGA) ermöglicht den durch das ELGA-Gesetz berechtigten Personen, entsprechend ihren Rollen, den Zugriff auf relevante Gesundheitsdaten der ELGA-Teilnehmer. Die Dokumente werden in vielen unterschiedlichen Informationssystemen der verschiedenen ELGA-Gesundheitsdiensteanbieter erstellt und durch ELGA in bedarfsgerecht elektronisch aufbereiteter Form online zur Verfügung gestellt. Diese Dokumente sollen allerdings nicht nur von Benutzern gelesen, sondern auch wieder in die IT-Systeme integriert und dort weiterverwendet werden können („Semantische Interoperabilität“). Beispielsweise können für den Arzt aus ELGA-Dokumenten automatisch Warnungen, Erinnerungen und Zusammenfassungen generiert und weitere Informationen berechnet sowie kontextbezogen angezeigt werden. ==Zweck des Dokuments==Das Ziel dieses Dokuments ist die Beschreibung der Struktur von medizinischen Dokumenten der Elektronischen Gesundheitsakte ELGA (entsprechend ELGA-G, BGBl. I Nr. 111/2012). Insbesondere behandelt das Dokument '''alle Dokumentenklassen-übergreifend gültigen Strukturen'''. Um dieses Ziel zu erreichen, wird der [[ILF:Allgemeiner Implementierungsleitfaden#CDA_Standard|CDA-Standard]] für die Verwendung in ELGA im Detail ausspezifiziert. Vorgaben für einheitliche Dokumentation und Codierung der Information werden festgelegt und in implementierbaren Leitfäden veröffentlicht. Der vorliegende „Allgemeine Implementierungsleitfaden für CDA-Dokumente“ stellt eine grundlegende Implementierungsvorschrift für alle CDA-Dokumente im österreichischen Gesundheitswesen dar. Dieser Vorschrift haben alle über ELGA vermittelten CDA-Dokumente im österreichischen Gesundheitswesen zu folgen.  '''TODO: Neue Version von 2.06, Hinweis auf Revisionsliste.''' Darüber hinaus kann auf Basis des vorliegenden allgemeinen Implementierungsleitfadens ein spezieller Implementierungsleitfaden definiert sein (z.B. Entlassungsbrief, Laborbefund, etc.).[[Datei:Zusammenspiel der Implementierungsleitfäden .png|350px|thumb|center|Abbildung 2:Zusammenspiel der Implementierungsleitfäden.]] Die administrativen Daten im Dokumentheader und grundsätzliche Vorgaben für den medizinischen Inhalt werden vom „Allgemeinen Implementierungsleitfaden“ definiert. Der jeweilige „Spezielle Implementierungsleitfaden“ enthält die Vorgaben für die medizinischen Inhalte und ergänzt gegebenenfalls die Header-Vorgaben.  Jeder spezielle Implementierungsleitfaden basiert auf diesem vorliegenden Allgemeinen Implementierungsleitfaden. Diese speziellen ELGA CDA Implementierungsleitfäden sind bereits für folgende Dokumentenklassen definiert (Liste kann erweitert werden): *[[ILF:Entlassungsbrief (Ärztlich)|Entlassungsbrief (Ärztlich)]], [OID Root 1.2.40.0.34.7.2]*[[ILF:Entlassungsbrief (Pflege)|Entlassungsbrief (Pflege)]], [OID Root 1.2.40.0.34.7.3]*[[ILF:Pflegesituationsbericht|Pflegesituationsbericht]], [OID Root 1.2.40.0.34.7.12]*[[ILF:Laborbefund|Laborbefund]], [OID Root 1.2.40.0.34.7.4]*[[ILF:Befund bildgebende Diagnostik|Befund bildgebende Diagnostik]], [OID Root 1.2.40.0.34.7.5]*[[ILF:e-Medikation|e-Medikation]], [OID Root 1.2.40.0.34.7.8] Die Beschreibung des Zusammenhangs von ELGA CDA-Dokumenten und den zur Registrierung von CDA in ELGA notwendigen „XDS-Metadaten“ finden Sie im Dokument *[[ILF:XDS Metadaten|ELGA XDS Metadaten (XDSDocumentEntry)]], [OID Root 1.2.40.0.34.7.6] ==Zielgruppe==Anwender dieses Dokuments sind Softwareentwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld der ELGA, insbesondere der ELGA-Gesundheitsdaten, betraut sind.Eine weitere Zielgruppe sind alle an der Erstellung von CDA-Dokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen. =Leitfadenerstellungs- und Harmonisierungsprozess='''(vorher unter "Vorgehensweise")'''Stärker als die Infrastrukturelemente von ELGA sind die Gesundheitsdaten im täglichen medizinischen Geschehen sichtbar. Daher ist in der Ausgestaltung der Gesundheitsdaten die breite Beteiligung der Stakeholder wesentlich, um die praktische Nutzbarkeit und die Akzeptanz durch die ELGA-Benutzer sicherzustellen. Es stehen dabei nicht die technischen, sondern vor allem medizinisch-inhaltliche Aspekte im Vordergrund.  Bis 2009 wurden erste Vorgaben für die Dokumentenklassen Entlassungsbrief (ärztlich), Entlassungsbrief (Pflege), Laborbefund und Radiologiebefund für ELGA erstellt. Diese wurden 2011 aktualisiert. Die Vorgaben wurden als sogenannte „CDA Implementierungsleitfäden“ in interdisziplinären Expertengruppen unter Einbeziehung von Vertretern aller wesentlichen Stakeholder erarbeitet („Harmonisierung“). Bei der Erstellung der Inhalte der Leitfäden wurden daher vor allem medizinische Experten aktiv eingebunden. Die technischen Inhalte wurden großteils von den Redaktionsteams beigetragen. Ein wesentlicher Schritt auf dem Weg zur Interoperabilität der IT-Systeme im Gesundheitswesen ist die Einigung auf Vorgaben für einheitliche Dokumentation und Codierung der Information. Diese durch die Arbeitsgruppen erreichte „Harmonisierung“ etabliert neue nationale Qualitätsstandards der medizinischen Dokumentation.Die Leitfäden werden über ein reguläres Standardisierungsverfahren ("Ballot") durch die HL7 Anwendergruppe Österreich (HL7 Austria) zu einem nationalen HL7 Standard. ===Vorgehensmodell===Der Initialisierungsschritt für neue CDA Implementierungsleitfäden wird im ELGA-Koordinierungsausschuss auf Basis eines Vorschlages der ELGA GmbH gesetzt. Die Planung umfasst die Einladung der Experten und die Beauftragung eines Redaktionsteams zur Erstellung des Leitfadens durch die ELGA GmbH.  Für die Erarbeitung der Vorgaben einer Dokumentenklasse ist jeweils eine Arbeitsgruppe verantwortlich. Jede Arbeitsgruppe wird von einem Redaktionsteam moderiert, das aus einem AG-Leiter und weiteren Redaktionsteammitgliedern besteht. Die zentrale Koordination der Arbeitsgruppen erfolgt durch die ELGA GmbH. Die typische Team-Struktur wird anhand der bisher konstituierten Arbeitsgruppen veranschaulicht:[[Datei:Koordination_der_Harmonisierungsarbeit_in_interdisziplinären_Arbeitsgruppen_02.png|500px|thumb|center|Abbildung 1: Koordination der Harmonisierungsarbeit in interdisziplinären Arbeitsgruppen.]]Die Mitglieder der Arbeitsgruppen werden von den maßgeblichen Stakeholdern des österreichischen Gesundheitswesens gestellt, die an der Erstellung und Verwendung der jeweiligen Dokumentenklassen partizipieren. Folgende Stakeholder-Gruppen werden speziell zur Teilnahme motiviert:  *Ärzteschaft (Ärztekammer)*Krankenhaus-Trägergesellschaften*Pflegeorganisationen*Befundprovider*Hersteller von Krankenhausinformationssystemen bzw. Arztpraxissoftware*Bürgerinitiativen*Standardisierungsorganisationen Die Arbeitsgruppen werden von der CDA Koordinationsstelle der ELGA GmbH einberufen. Sie koordiniert die Sitzungen und übernimmt die Kommunikationsaufgaben. Jede Arbeitsgruppe wird durch ein Redaktionsteam unterstützt, welches folgende Tätigkeiten durchzuführen hat: *Erheben, Auswerten, Analysieren, Zusammenfassen und Aufarbeiten der eingegangenen Anforderungen*Fachliche Vorbereitung der Arbeitsgruppensitzungen*Erstellung der Leitfadendokumente und ergänzender Materialien (etwa Beispiel-CDA-Dateien) Von der Arbeitsgruppe und dem Redaktionsteam wird eine erste Version eines CDA Implementierungsleitfadens vorgelegt, mit der die Umsetzbarkeit getestet werden kann. Diese Leitfadenversion wird dann in einem HL7 „DSTU-Ballot“ abgestimmt (Draft Standard – Trial Implementation). Die Ergebnisse der Testphase laufen bei der ELGA CDA Koordination zusammen, die den Leitfaden freigibt.  Für eine verpflichtende Anwendung eines Leitfadens ist ein „normativer Ballot“ durch die HL7 Austria durchzuführen. Über die hier geschilderten „internen“ Abstimmungsarbeiten hinaus wird eine Kooperation mit den betroffenen Standardisierungsorganisationen angestrebt, etwa mit dem Österreichischen Normungsinstitut, der HL7 Anwendergruppe Österreich und auch mit anderen nationalen und internationalen Normengremien. ===Revision der Leitfäden===Neue und geänderte Anforderungen sowie Verbesserungen können neue Versionen der bestehenden Spezifikationen notwendig machen.  Der CDA-Koordinator evaluiert in regelmäßigen Abständen, ob und welche Änderungen (etwa durch neue medizinische oder gesetzliche Anforderungen) notwendig sind. Aufgrund des Berichtes des CDA-Koordinators empfiehlt die ELGA GmbH die Erstellung von Revisionsversionen der bestehenden Leitfäden. Die geplanten Änderungen sollen mit den maßgeblichen Stakeholdern abgestimmt werden. Neue Versionen, die „verpflichtende Elemente“ (Sections oder Entries) neu einführen oder entfernen, sind „Hauptversionen“, die jedenfalls über eine Durchführungsverordnung verbindlich gemacht und veröffentlicht werden. Andere Versionen sind „Nebenversionen“. Alle verbindlichen Versionen sind auf http://www.gesundheit.gv.at zu veröffentlichen. ==Autoren und Mitwirkende=='''Erarbeitung des Implementierungsleitfadens''' <br />Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der „Arbeitsgruppe“ in den Jahren 2008-2012, bestehend aus nachfolgend genannten Personen:TODO =Technischer Hintergrund= ==Grundlagen==Für XML als grundsätzliches Format spricht die Flexibilität nicht nur bei der Länge einzelner darzustellender Texte sondern auch bezüglich der a priori unbegrenzten Möglichkeit, weitere Elemente beliebig tief zu verschachteln.  HL7 bezeichnet eine Gruppe von Standards für den Austausch von Daten zwischen Computersystemen im Gesundheitswesen. HL7 wird als Kommunikationsprotokoll vornehmlich zum Datenaustausch zwischen Abteilungssystemen in Krankenhäusern eingesetzt. Mittlerweile wird HL7 in über 50 Ländern eingesetzt. Die ursprünglich in den USA von der Organisation „Health Level Seven International“ (HL7) (http://www.hl7.org) entwickelten Spezifikationen sind im Laufe der Zeit zu einem internationalen Standard geworden, auch dank vieler internationaler Benutzergruppen, die seit langem an der Weiterentwicklung von HL7 mitwirken.  Die HL7 Standards in Version 3 sind auf die Kommunikationsbedürfnisse des gesamten Gesundheitswesens abgestimmt. HL7 V3 bietet eine konzeptuelle Grundlage in einem gemeinsamen, umfassenden „Reference Information Model“ (RIM) für alle Teile von HL7 V3.  Dieses RIM ist ANSI- und ISO-Standard (ISO/HL7 21731:2006) und bietet:  *ein festes semantisches Fundament*ausgewählte standardisierte Terminologien, die semantische [[ILF:Allgemeiner Implementierungsleitfaden#ELGA_Interoperabilit.C3.A4tsstufen|Interoperabilität]] ermöglichen*die Trennung von Inhalten und Syntax HL7 Version 3 basiert auf XML und wird für die Übermittlung von Nachrichten genutzt. HL7 stellt außerdem einen Standard zur Strukturierung, zum Inhalt und zum Austausch medizinischer Dokumente, die so genannte Clinical Document Architecture (CDA), zur Verfügung. Dabei steht der Informationsaustausch im gesamten Gesundheitswesen im Vordergrund (also nicht beschränkt auf Krankenhäuser).  Als Grundlage für ELGA-Dokumente wurde der Standard HL7 Clinical Document Architecture, Release 2.0 ausgewählt. Der Standard kann über die HL7 Anwendergruppe Österreich (http://www.hl7.at) bezogen werden. ==CDA Standard==Die „Clinical Document Architecture“ (CDA) ist ein Standard für den Austausch und die Speicherung von klinischer Dokumentation, wie zum Beispiel Entlassungsbriefe, Überweisungen, Behandlungsdokumentation oder OP-Berichte. Dabei wird die „Extensible Markup Language“ (XML) benutzt. CDA wird von „Health Level Seven“ ([http://www.hl7.at HL7]), einem der bedeutendsten internationalen Standardentwickler für das Gesundheitswesen, entwickelt und stellt einen XML-basierten Dokumenten-Markup Standard zur strukturierten klinischen Dokumentation zur Verfügung. Der CDA Standard definiert ein Informationsobjekt, das außerhalb einer Nachricht existieren kann und neben (strukturiertem) Text auch Bilder, Töne, Biosignale usw. enthalten bzw. referenzieren kann.'''einfügen'''CDA-Dokumente sind XML-Dateien und bestehen aus einem Header mit Metadaten und einem Body mit dem eigentlichen Inhalt. ===Version===CDA ist Teil der [http://www.hl7.at HL7] Version 3 Standardsfamilie. Die erste Version von CDA (CDA Release 1) wurde bereits im September 2000 als offizieller Standard verabschiedet (CDA Level One ANSI/HL7 CDA R1.0-2000). Damit gilt CDA als erster offizieller XML-basierter Standard im Gesundheitswesen.  Die Erfahrungen und weitergehende Bedürfnisse sind in die Entwicklung von CDA Release 2.0 eingegangen. CDA Release 2.0 als Fortentwicklung dieses Standards wurde nach beinahe fünf Jahren weiterer Entwicklungsarbeit am Standard, im Juli 2005 als ANSI Standard verabschiedet. In diese Entwicklungen sind zahlreiche Erfahrungen aus weltweit mehr als 15 größeren, teilweise nationenweiten Projekten eingeflossen, die sich intensiv um CDA Rel. 1 und der Weiterentwicklung verdient gemacht haben. Im Jahr 2008 wurde CDA Rel. 2 als ISO-Standard anerkannt (ISO/HL7 27932:2008). Mittlerweile wird Release 2 in unzähligen Projekten rund um die Welt genutzt. ===Eigenschaften von CDA-Dokumenten===Die Clinical Document Architecture wird zum Austausch von medizinischen Dokumenten verwendet, die typischerweise folgende Eigenschaften aufweisen: *'''Persistenz''': Medizinische Dokumente sind durch Persistenz, also dauerhafte Existenz in den sendenden oder empfangenden Systemen gekennzeichnet, wo sie für einen bestimmten Zeitraum in einem unveränderten Zustand bleiben. Dieser Zeitraum wird durch lokale Regelungen definiert.*'''Verwaltung''' (engl. „stewardship“): Für die Verwaltung des Dokuments ist eine bestimmte Organisation verantwortlich (der „Custodian“).*'''Kontext''': Medizinische Dokumente etablieren den Standard-Kontext für die in ihnen gespeicherten Inhalte (z.B. den „Entlassungsbrief“).*'''Authentisierung''' (engl. „potential für authentication“): Medizinische Dokumente werden authentisiert. Im medizinischen Alltag entspricht das der Signierung, Vidierung oder Validierung.*'''Ganzheit''' (engl. „wholeness“): Die Authentisierung eines medizinischen Dokumentes bezieht sich auf das Dokument als Ganzes und nicht nur auf einzelne aus dem Kontext gelöste Teile.*'''Lesbarkeit''' (engl. „human readability“): Medizinische Dokumente sind für Menschen lesbar. ===Bedingungen===Eine grundsätzliche Bedingung für CDA ist die Sicherstellung der Lesbarkeit für Menschen in einem „normalen“ Webbrowser (mit der üblichen Basisfunktionalität zum Browsen im Internet).  Dafür gilt zudem: *Es muss einen eindeutig festgelegten Weg für einen Empfänger geben, den authentisierten Inhalt sichtbar zu machen².*Es ist nicht zulässig, dass die Darstellung im Browser nur mithilfe eines bestimmten Stylesheets bewerkstelligt werden kann, das dann zusammen mit dem CDA-Dokument gesendet werden muss. Es muss auch möglich sein, den Inhalt mit einem beliebigen Stylesheet und marktüblichen Browsern darzustellen.*Lesbarkeit bezieht sich auf den authentisierten Inhalt. Zusätzlich kann weitere Information im Dokument vorhanden sein („CDA Level 3“), die auf Auswertbarkeit durch Anwendungssysteme abzielt, die aber nicht authentisiert oder lesbar dargestellt werden muss.*Wenn strukturierter Inhalt vom narrativen Text abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde, z. B. durch den Autor, durch eine Person, die eine Codierung vorgenommen hat, durch automatisierte Verarbeitung der natürlichen Sprache, durch eine spezifische Software.*Wenn narrativer Text von strukturierter Information abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde.  ² Für ELGA wird ein „Referenz-Stylesheet“ bereitgestellt. Das Referenz-Stylesheet ist eine XSLT-Datei zur Transformation der CDA-XML-Datei in HTML. Zur Darstellung von CDA Dokumenten im Browser wird die Verwendung des Referenz-Stylesheets empfohlen. ===CDA Levels===CDA bietet drei verschiedene Varianten, wie Inhalte transportiert werden können; diese Varianten (die so genannten „CDA-Levels“) ermöglichen unterschiedliche Interoperabilität.  '''„CDA-Level 1“''' ist ausschließlich auf die Lesbarkeit durch Menschen ausgelegt. Medizinische Inhalte werden als Text, Bilder oder auch nur als „eingebettetes PDF“ (als unstrukturierter „NonXMLBody“) transportiert.  '''„CDA-Level 2“''' ermöglicht eine Strukturierung der Inhalte nach Abschnitten („Sections“) mit festgelegter Bedeutung, z.B. „Anamnese“, „Diagnosen“. Die Abschnitte sind mit einem vereinbarten Code versehen, der es ermöglicht, dass EDV-Programme diese eindeutig erkennen und als Block verarbeiten können.  '''„CDA-Level 3“''' ist eine Technik zur Anreicherung eines lesbaren Dokuments mit medizinischen Einzelinformationen (z.B. „diastolischer Blutdruck“, „ICD-10 Entlassungs-diagnose“, „Körpergewicht in kg“), die gemäß einer Vereinbarung maschinenlesbar codiert sind und daher automatisch in medizinische Informationssysteme integriert werden können. Die Vereinbarungen für die Codierung in den CDA-Levels 2 und 3 werden durch [[CDA_Templates|Templates]] definiert und in Implementierungsleitfäden veröffentlicht. Die CDA-Levels können aufeinander aufbauend verwendet werden, ein Dokument kann gleichzeitig Informationen in allen drei CDA-Levels enthalten.  Eine detailliertere Beschreibung der CDA-Levels findet sich in „[[ILF:Allgemeiner_Implementierungsleitfaden#CDA_Level_1_bis_3|CDA Level 1 bis 3]]“.  ===CDA Levels===CDA bietet drei verschiedene Varianten, wie Inhalte transportiert werden können; diese Varianten (die so genannten „CDA-Levels“) ermöglichen unterschiedliche Interoperabilität.  '''„CDA-Level 1“''' ist ausschließlich auf die Lesbarkeit durch Menschen ausgelegt. Medizinische Inhalte werden als Text, Bilder oder auch nur als „eingebettetes PDF“ (als unstrukturierter „NonXMLBody“) transportiert. '''„CDA-Level 2“''' ermöglicht eine Strukturierung der Inhalte nach Abschnitten („Sections“) mit festgelegter Bedeutung, z.B. „Anamnese“, „Diagnosen“. Die Abschnitte sind mit einem vereinbarten Code versehen, der es ermöglicht, dass EDV-Programme diese eindeutig erkennen und als Block verarbeiten können. '''„CDA-Level 3“''' ist eine Technik zur Anreicherung eines lesbaren Dokuments mit medizinischen Einzelinformationen (z.B. „diastolischer Blutdruck“, „ICD-10 Entlassungs-diagnose“, „Körpergewicht in kg“), die gemäß einer Vereinbarung maschinenlesbar codiert sind und daher automatisch in medizinische Informationssysteme integriert werden können. Die Vereinbarungen für die Codierung in den CDA-Levels 2 und 3 werden durch Templates definiert und in Implementierungsleitfäden veröffentlicht. Die CDA-Levels können aufeinander aufbauend verwendet werden, ein Dokument kann gleichzeitig Informationen in allen drei CDA-Levels enthalten.  Eine detailliertere Beschreibung der CDA-Levels findet sich in „[[ILF:Allgemeiner Implementierungsleitfaden#CDA_Level_1_bis_3|CDA Level 1 bis 3]]“. ===ELGA Interoperabilitätsstufen===Der zukünftige Nutzen von Dokumenten in ELGA hängt von ihrem Strukturierungsgrad ab: Je einheitlicher und strukturierter die Informationen vorliegen, desto besser können die Daten durch EDV-Systeme verarbeitet und ausgewertet werden. Die so genannten „ELGA Interoperabilitätsstufen“ (EIS) definieren eine bestimmte Menge von Vorgaben aus den CDA Levels 2 und 3. Die Mindeststandards für die Datenstruktur der CDA-Dokumente und die Zeitpunkte für die verbindliche Verwendung werden per bundesministerielle Verordnung festgelegt. *'''EIS „Basic“ und EIS „Structured“:''' EIS „Basic“ beschreibt die für alle Dokumente in ELGA verpflichtende Mindeststrukturierung. Dokumente auf dieser Stufe müssen nur die Daten codiert enthalten, die unter anderem für das Dokumentenregister und das Berechtigungssystem unbedingt benötigt werden ([[ILF:Allgemeiner Implementierungsleitfaden#CDA_Header|CDA HeaderAllgemeiner_Implementierungsleitfaden_2020]]). Dieser Mindeststrukturierungsgrad und die Zuordnung zu einer definierten Dokumentenklasse sind die Voraussetzung für die Verwendung der Dokumente in ELGA. CDA-Dokumente auf dieser Stufe folgen den Anforderungen des ''„Allgemeinen Implementierungsleitfaden für CDA-Dokumente“'' und allfälliger [[ILF:Allgemeiner Implementierungsleitfaden#CDA_Header|Header]]-Spezifikationen eines speziellen Leitfadens. In EIS „Basic“ ist zusätzlich die Möglichkeit gegeben, ein Organisations-Logo in Level 3 Codierung einzubetten. Die Herausforderung für die Dokumentenersteller beziehungsweise die dokumentenerstellenden EDV-Systeme ist auf dieser Stufe minimal, medizinische Inhalte sollen als XML-Textelemente vorhanden sein, können aber auch als PDF in die CDA-Dokumente eingebettet werden (eingebettetes PDF oder XML ohne Templates).<br />EIS „Structured“ ist eine Erweiterung der verpflichtenden Mindeststrukturierung EIS „Basic“. Die medizinischen Inhalte folgen auf dieser Stufe der Gliederung und dem Aufbau, den der Leitfaden für die höheren EIS „Enhanced“ und „Full Support“ vorgibt, sie folgen aber nicht der entsprechenden technischen Struktur und Codierung. EIS „Structured“ Dokumente decken sich technisch mit EIS „Basic“, erscheinen dem Leser inhaltlich wie EIS „Enhanced“ und „Full Support“ Dokumente, ohne deren semantische Interoperabilität zu unterstützen. *'''EIS „Enhanced“ und EIS „Full Support“''' ermöglichen eine einheitliche Darstellung und barrierefreie Anzeige der Daten im ELGA Portal, die mit PDF nicht erreichbar ist. CDA-Dokumente dieser Stufen folgen zusätzlich den Anforderungen eines speziellen Implementierungsleitfadens, der für die jeweilige Stufe angeführt wird. Die Anforderungen betreffen vorwiegend Vorgaben für die Gliederung und Strukturierung des lesbaren Textes, Verwendung und Codierung der CDA Sektionen (CDA-Level 2), können aber auch CDA Level-3 Vorgaben enthalten.**'''EIS „Enhanced“''' stellt eine Zwischenstufe auf dem Weg zu „Full Support“ dar. Die Vorgaben betreffen eine kleinere Anzahl an maschinenlesbaren Elementen und sind weniger streng als bei „Full Support“.**'''EIS „Full Support“''' kann gegenüber EIS „Enhanced“ zusätzliche maschinenlesbar codierte medizinische Inhalte enthalten, die in ELGA CDA-Dokumenten anzugeben sind. {| class="wikitable" |- | style="background:#E9FCDF" |ELGA Interoperabilitätsstufe '''„BASIC“''' und '''„STRUCTURED“'''||Einheitlicher CDA-[[ILF:Allgemeiner Implementierungsleitfaden#CDA_Header|Header]]. Verwendung der Dokumente in ELGA (Aufnahme in Dokumentregister, Anzeige für Berechtigte). Minimale Anforderungen an erstellende Systeme („eingebettetes PDF“ oder XML ohne Templates)  EIS „Structured“ erfüllt die fachlich-inhaltlichen, aber nicht die technischen Vorgaben für den Aufbau und die Gliederung des Dokuments aus den speziellen Leitfäden.|- | style="background:#CBE5BE" |ELGA Interoperabilitätsstufe '''„ENHANCED“'''||Einheitliche Dokumentation (Strukturierung, Gliederung), barrierefreie Darstellung. Minimale Anforderungen an Level-3 Codierung, gemäß den speziellen Leitfäden. |- | style="background:#78BA58" |ELGA Interoperabilitätsstufe '''„FULL SUPPORT“'''||Maschinenlesbare Inhalte, automatische Übernahme der Daten in ein medizinisches Informationssystem möglich. Volle Unterstützung der Level 3-Codierung, gemäß den speziellen Leitfäden.|-|}''Tabelle 1: ELGA Interoperabilitätsstufen'' Die ELGA Interoperabilitätsstufen beschreiben einen ansteigenden Grad der Strukturierung und Codierung der medizinischen Inhalte unabhängig von CDA-Levels. Die Harmonisierungsgruppen legen aufgrund ihrer fachlichen Expertise fest, welche Inhalte der Dokumente in welcher Form sinnvollerweise strukturiert und codiert werden müssen. Es werden nur Daten codiert, die auch medizinisch relevant sind und die mit einem vertretbaren Umsetzungsaufwand von den IT-Systemen der Gesundheitsdiensteanbieter zur Verfügung gestellt werden können.  Um codierte und damit weiter maschinell verarbeitbare strukturierte Dokumente erzeugen zu können, müssen die IT-Systeme der meisten Gesundheitsdiensteanbieter erst umgestellt werden. Die Anpassungen können in der heterogenen IT-Landschaft der Gesundheitsdiensteanbieter unterschiedlich schnell umgesetzt werden.  Zur koordinierten stufenweisen Einführung von CDA bei den verschiedenen ELGA-Gesundheitsdiensteanbietern werden die „ELGA Interoperabilitätsstufen“ als Zwischenziele definiert.  Neben den im ELGA-Gesetz definierten Dokumentenklassen können zukünftige Dokumentenklassen mit ihrer Struktur und Format für ELGA per Verordnung festgelegt werden. Auch für diese Dokumentenklassen gilt zumindest die unterste Interoperabilitätsstufe „EIS Basic“. Wenn ein CDA Implementierungsleitfaden für die Dokumentenklasse harmonisiert wurde, ist es möglich, Dokumente in den höheren Interoperabilitätsstufen „EIS Structured“, „EIS Enhanced“ und „EIS Full Support“ auszutauschen. ===Aufbau eines CDA-Dokument===Grob gesprochen besteht ein CDA-Dokument aus einem [[#CDA_Header|Header]] und einem [[#CDA_Body|Body]]. Der [[#CDA_Header|Header]] trägt Informationen über das Dokument sowie deren Beteiligte, einschließlich dem Patient. Der [[#CDA_Body|Body]] besteht wiederum aus Body Structures (Abschnitte und narrativer Text) und Body Entries (maschinenauswertbare Detailinformationen). An die Entries können externe Referenzen (External References) geknüpft sein. Der folgende Überblick zeigt die Hauptkomponenten des CDA R2 Modells auf, in der darauffolgenden Abbildung ist die Struktur in XML-artiger Darstellung gezeigt. [[Datei:CDA_R2_Modell_mit_Header_und_Body_Structures_(vereinfachte Übersicht).png|500px|thumb|center|Abbildung 1: CDA R2 Modell mit [[ILF:Allgemeiner Implementierungsleitfaden#CDA_Header|Header]] und [[ILF:Allgemeiner Implementierungsleitfaden#CDA_Body|Body]] Structures (vereinfachte Übersicht).]] Je nach Leitfaden variiert [[#CDA_Header|Header]] und [[#CDA_Body|Body]] aus verschiedenen [[CDA_Templates|Templates]]. Die nachfolgenden Links geben einen Überblick über die jeweiligen [[CDA_Templates|Templates]] nach Implementierungsleitfaden: *[[ILF:Entlassungsbrief_(Ärztlich)_Alle_Templates|Templates Entlassungsbrief (Ärztlich)]]*[[ILF:Entlassungsbrief_(Pflege)_Alle_Templates|Templates Entlassungsbrief (Pflege)]]*[[ILF:Pflegesituationsbericht_Alle_Templates|Templates Pflegesituationsbericht]]*[[ILF:Befund_bildgebende_Diagnostik_Alle_Templates|Templates Befund bildgebende Diagnostik]]*[[ILF:Laborbefund_Alle_Templates|Templates Laborbefund]] Die administrativen Daten im Dokumentheader und grundsätzliche Vorgaben für den medizinischen Inhalt werden vom „[[ILF:Allgemeiner Implementierungsleitfaden|Allgemeinen Implementierungsleitfaden]]“ definiert.  Der jeweilige „[[Implementierungsleitfäden|Spezielle Implementierungsleitfaden]]“ enthält die Vorgaben für die medizinischen Inhalte und ergänzt gegebenenfalls die Header-Vorgaben. [[Datei:Zusammenspiel der Implementierungsleitfäden .png|350px|thumb|center|Abbildung 2:Zusammenspiel der Implementierungsleitfäden.]] ===CDA Header===Die Informationen zum Patienten, zum Dokument selbst, zu den weiteren beteiligten Personen und Organisationen sowie der dokumentierten Episode (Zeitereignisse) sind zum '''''CDA Header''''' zusammengefasst, hochstrukturiert und von der Semantik her festgelegt. Die Informationen im Header unterstützen einen Austausch klinischer Dokumente über Institutionsgrenzen hinweg. Er trägt Informationen über das Dokument selbst (eine eineindeutige Identifikation, die Art des Dokuments), über „Teilnehmer“ am Dokument (an der Dokumentation beteiligte Behandler, Autoren, und natürlich den Patienten selbst), sowie über Beziehungen zu Dokumenten (zu Anforderungen und anderen Dokumenten). Mit den Informationen des Headers werden Dokumentenmanagement-Systeme unterstützt, der Header stellt dafür entsprechende Mechanismen zur Verfügung. Damit werden die Zusammenführung und das Wiederfinden der Dokumente in ELGA oder in lokalen Patientenakten wesentlich erleichtert.  ===CDA Body===Die eigentliche klinische Dokumentation wird im so genannten '''''CDA Body''''' festgehalten. Im Vordergrund steht hier „lesbarer“ (narrativer) Text, der verpflichtender Bestandteil von CDA R2 Dokumenten ist und die Interoperabilität zwischen den menschlichen Kommunikationspartnern garantiert.Hier sind Möglichkeiten gegeben, diesen Text grob zu strukturieren und formatieren, wie man dies von den Möglichkeiten der Textverarbeitung her kennt. Zur Strukturierung stellt die Standardspezifikation eine Reihe von XML-Elementen zur Verfügung, die als Body Structures zusammengefasst werden können. Der Body enthält ein oder mehrere Abschnitte (sections). Diese können auch ineinander geschachtelt sein, so wie Kapitel und Unterkapitel in einem Buch. Zudem sind Strukturierungen im Sinne von Tabellen oder Listen möglich. *Abschnitte <section>*Paragrafen <paragraph>*Kennzeichnung von bestimmten Inhalten <content>*Überschriften < caption>*Tabellen < table>*Listen <list> Sections enthalten immer einen narrativen Block und erfüllen damit eine der oben genannten Maximen von CDA: die Mensch-zu-Mensch-Interoperabilität, die Lesbarkeit der Informationen für den Menschen. Im narrativen Block wird, durch das Textattribut in der section-Klasse repräsentiert, eingebetteter Text innerhalb eines Abschnittes angegeben. Dabei kann mit oben genanntem content-Element bestimmter Inhalt gesondert gekennzeichnet werden. Zusammengefasst sind im Fließtextblock u.a. folgende Möglichkeiten der Struktur- und Formgebung des Textes gegeben:  *Zeilenumbrüche < br>*Stilistische Angaben (unterstrichen, fett, kursiv etc.)*Hoch- und Tiefstellung von Text*Fußnoten, Symbole*Revisionsmarken im Text mit <content revised=delete> und <content revised=insert> Mit den beschriebenen Body Strukturen können '''''CDA Entries''''' verbunden sein. Diese repräsentieren den „computerlesbaren Teil“ innerhalb eines Dokumentenabschnitts. Body Entries sind im Prinzip eine Auswahl aus Klassen mitsamt Attributen aus dem HL7 Referenz-Informationsmodell (RIM). In der folgenden Abbildung ist ein Ausschnitt daraus gezeigt.[[Datei:R-MIM-Ausschnitt-Auswahlliste der CDA Body Entries.png|500px|thumb|center|Abbildung 3: R-MIM-Ausschnitt: Auswahlliste der CDA Body Entries .]] Diese Auswahlliste von Entries wird auch als Clinical Statements bezeichnet und findet sich in gleicher oder ähnlicher Form auch in HL7-Version 3 Nachrichten zu Anforderungen und Befunden etc. wieder. Insgesamt sind in der Auswahl folgende Klassen verfügbar. *''observation'', eine (codierte) Beobachtung, z.B. ein Befund oder eine Diagnose*''procedure'', eine Prozedur, z. B. eine Operation, eine andere Behandlung, rein diagnostischer Eingriff*''encounter'', Angaben zu früheren, jetzigen oder geplanten Patientenkontakten*''substanceAdministration'', medikamenten-bezogene Angaben im Sinne von stattgefundenen (Medikamentenanamnese) oder geplanten Medikamentengaben*''supply'', zur Verfügungstellung von Material oder Medikamentenverabreichungen*''organizer'', zur Gruppierung von anderen CDA Entries (Batterien, Cluster)*''observationMedia'', multimedialer Inhalt als Teil des Dokuments*''regionOfInterest'', Kennzeichnung einer Hervorhebung eines Teilaspekts eines Bildes Alle diese Entries können untereinander linear oder rekursiv hierarchisch verbunden sein. Es sind gleichstufige Beziehungen möglich (zum Beispiel eine Liste von Beobachtungen), aber auch die Wiedergabe einer Hierarchie (z. B. „kleines Blutbild“, bestehend aus „Erythrozyten“, „Leukozyten“, ...). [[Datei:Grundsätzlicher Aufbau eines CDA-Dokuments aus XML Sicht.png|center|Abbildung 4: Grundsätzlicher Aufbau eines CDA-Dokuments aus XML Sicht.]]Für das komplette dem CDA Release 2.0 zugrundeliegende Referenzmodell (R-MIM POCD_RM000040) wird auf den publizierten Standard verwiesen (http://www.hl7.at). ==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⁴ 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.  ⁴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==Das Thema „Zertifizierung“ (etwa die Zertifizierung von Softwaresystemen) wird von diesem Implementierungsleitfaden nicht behandelt. ==Datentypen== =Terminologien===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.  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, der Name und die OID eines Value Sets bleiben aber gleich. Bei neuen Versionen werden Versionsnummer, Ä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 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). 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.  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. ==PDF Format-Vorschrift==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}}Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1a (gemäß „ISO 19005-1:2005 Level A conformance“) entsprechen.{{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.}}   ⁵ 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-Entry|ELGA EingebettetesObjekt-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. Damit beim Download keine unnötigen Verzögerungen verursacht werden, SOLL die Gesamtgröße der Datei 20 MB nicht überschreiten.⁶  ⁶ Aktuell wird von ELGA die Größe von Doumenten auf 20MB beschränkt. ==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. ==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'''. =Funktionale Anforderungen===Darstellung====Verwendung in der ELGA Infrastruktur=====Vorgaben zu Dokument-Metadaten (XDS-Metadaten)=====Versionierung & Stornierung von Dokumenten====Mehrsprachigkeit und grenzüberschreitender Austausch===User Storys ("Anwendungsfälle")==Dataset==Technische Spezifikation===Übersicht CDA Strukturen (Header & Body)====CDA Templates==  ==Document Level Templates====Header Level Templates== ===Document Realm==={{:1.2.40.0.34.6.0.11.1.10/dynamic}}===typeId==={{:1.2.40.0.34.6.0.11.1.30/dynamic}} ===templateId===im DLT ===Document Id==={{:1.2.40.0.34.6.0.11.1.1/dynamic}} ===Document Code==={{:1.2.40.0.34.6.0.11.1.16/dynamic}} ===Document Effective Time==={{:1.2.40.0.34.6.0.11.1.11/dynamic}} ===Document Confidentiality Code==={{:1.2.40.0.34.6.0.11.1.12/dynamic}} ===Document Language==={{:1.2.40.0.34.6.0.11.1.13/dynamic}} ===Document Set Id and Version Number==={{:1.2.40.0.34.6.0.11.1.15/dynamic}} ===Record Target=== {{:1.2.40.0.34.6.0.11.1.3/dynamic}}===Author==={{:1.2.40.0.34.6.0.11.1.2/dynamic}}===Data Enterer==={{:1.2.40.0.34.6.0.11.1.22/dynamic}}===Custodian=== {{:1.2.40.0.34.6.0.11.1.4/dynamic}}===Information Recipient==={{:1.2.40.0.34.6.0.11.1.24/dynamic}}===Legal Authenticator=== {{:1.2.40.0.34.6.0.11.1.5/dynamic}}===Authenticator=== {{:1.2.40.0.34.6.0.11.1.6/dynamic}} ===Participant Ansprechpartner=== ====Participant Fachlicher Ansprechpartner===={{:1.2.40.0.34.6.0.11.1.20/dynamic}}====Participant Zuweiser===={{:1.2.40.0.34.6.0.11.1.21/dynamic}}====Participant Hausarzt===={{:1.2.40.0.34.6.0.11.1.23/dynamic}}====Participant Auskunftsberechtigte Person (Notfallkontakt)===={{:1.2.40.0.34.6.0.11.1.27/dynamic}} ====Participant Angehörige===={{:1.2.40.0.34.6.0.11.1.25/dynamic}}====Participant Versicherung===={{:1.2.40.0.34.6.0.11.1.26/dynamic}}====Participant Betreuungsorganisation===={{:1.2.40.0.34.6.0.11.1.29/dynamic}}====Participant Weitere Behandler===={{:1.2.40.0.34.6.0.11.1.28/dynamic}} ===In Fulfillment Of=== {{:1.2.40.0.34.6.0.11.1.9/dynamic}}===Documentation Of Service Event=== {{:1.2.40.0.34.6.0.11.1.17/dynamic}} ===Document Replacement - Related Document==={{:1.2.40.0.34.6.0.11.1.14/dynamic}}===Authorization==={{:1.2.40.0.34.6.0.11.1.18/dynamic}}  ===Component Of - Encompassing Encounter=== {{:1.2.40.0.34.6.0.11.1.7/dynamic}} ===Encounter Location=== {{:1.2.40.0.34.6.0.11.1.8/dynamic}}===Encounter Location with addr, telecom=== {{:1.2.40.0.34.6.0.11.1.19/dynamic}} ==Section Level Templates=====Brieftext=== {{:1.2.40.0.34.6.0.11.2.69/dynamic}}Der Titel dieser Sektion wird vom ELGA Referenz-Stylesheet nicht angezeigt, das Logo wird speziell platziert. Andere CDA-Stylesheets könnten den Titel der Sektion anzeigen und das Logo direkt im Text der Sektion darstellen.===Abschließende Bemerkung=== {{:1.2.40.0.34.6.0.11.2.70/dynamic}}Der Titel dieser Sektion wird vom ELGA Referenz-Stylesheet nicht angezeigt. Andere CDA-Stylesheets könnten den Titel der Sektion anzeigen. ===Beilagen=== {{:1.2.40.0.34.6.0.11.2.71/dynamic}}  ==Entry Level Template=====Comment Entry=== {{:1.2.40.0.34.6.0.11.3.11/dynamic}}===External Document Entry=== {{:1.2.40.0.34.6.0.11.3.14/dynamic}}===Problem Concern Entry=== {{:1.2.40.0.34.6.0.11.3.7/dynamic}}===Problem Entry=== {{:1.2.40.0.34.6.0.11.3.6/dynamic}} ==Sonstige Templates (Fragmente)== ===Address Compilation=== {{:1.2.40.0.34.6.0.11.9.25/dynamic}}===Address Compilation Minimal=== {{:1.2.40.0.34.6.0.11.9.10/dynamic}}===Assigned Entity==={{:1.2.40.0.34.6.0.11.9.22/dynamic}}===Assigned Entity Body==={{:1.2.40.0.34.6.0.11.9.16/dynamic}}===Author Body=== {{:1.2.40.0.34.6.0.11.9.2/dynamic}}===Device Compilation=== {{:1.2.40.0.34.6.0.11.9.18/dynamic}}===Informant Body=== {{:1.2.40.0.34.6.0.11.9.3/dynamic}}===Narrative Text Reference=== {{:1.2.40.0.34.6.0.11.9.1/dynamic}}===Organization Compilation with name=== {{:1.2.40.0.34.6.0.11.9.9/dynamic}}===Organization Compilation with id, name=== {{:1.2.40.0.34.6.0.11.9.5/dynamic}}===Organization Compilation with id, name, tel, addr=== {{:1.2.40.0.34.6.0.11.9.7/dynamic}}===Organization Compilation with name, addr minimal=== {{:1.2.40.0.34.6.0.11.9.20/dynamic}}===Organization Name Compilation==={{:1.2.40.0.34.6.0.11.9.27/dynamic}} ===Original Text Reference=== {{:1.2.40.0.34.6.0.11.9.8/dynamic}}===Participant Body==={{:1.2.40.0.34.6.0.11.9.13/dynamic}}===Participant Body Transcriber==={{:1.2.40.0.34.6.0.11.9.14/dynamic}}===Performer Body=== {{:1.2.40.0.34.6.0.11.9.21/dynamic}}===Performer Body - Impfende Person (2019)==={{:1.2.40.0.34.6.0.11.9.17/dynamic}}===Person Name Compilation G1==={{:1.2.40.0.34.6.0.11.9.26/dynamic}}===Person Name Compilation G1 M==={{:1.2.40.0.34.6.0.11.9.12/dynamic}}===Person Name Compilation G2==={{:1.2.40.0.34.6.0.11.9.6/dynamic}}===Person Name Compilation G2 M==={{:1.2.40.0.34.6.0.11.9.11/dynamic}}===Time Interval Information==={{:1.2.40.0.34.6.0.11.9.15/dynamic}} =Terminologien==Anhang===Begriffsdefintionen/Glossar====Abbildungsverzeichnis====Abkürzungsverzeichnis====Literaturverzeichnis====Revisionsliste==Diese Version ist eine Nebenversion zur Hauptversion 2.06 und ersetzt diese. Die durchgeführten Änderungen ersehen Sie der '''Link zur Revisionsliste TODO'''