Änderungen

Die erste Version dieses Implementierungsleitfadens wurde bereits 2009 erstellt und 2012 als gültiger Standard publiziert. Der Leitfaden wurde wesentlich durch den von HL7 Deutschland erstellten Leitfaden „"'''VHitG-Arztbrief''' 2006"<ref>VHitG (jetzt bvitg): "Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen" Version 1.5 (2006) [http://download.hl7.de/documents/cdar2-arztbrief/Leitfaden-VHitG-Arztbrief-v150.pdf PDF]</ref> inspiriert, von dem einige Ausführungen direkt übernommen wurden. Seither wurde dieser Leitfaden kontinuierlich weiterentwickelt und verbessert.

Der Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten („Mandatory“ "Mandatory" (M), „Required“ "Required" (R) und „Fixed“ "Fixed" (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht 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. Diese medizinischen Dokumente (e-Befunde) 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“"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.

Der vorliegende „Allgemeine "Allgemeine Implementierungsleitfaden für CDA-Dokumente“ Dokumente" stellt eine grundlegende Implementierungsvorschrift für alle CDA-Dokumente im österreichischen Gesundheitswesen dar. Dies umfasst ELGA e-Befunde, also jene Dokumente, die für Patienten und deren Behandler über die ELGA Infrastruktur abrufbar sind (z.B. ELGA Portal), als auch jene e-Health Dokumente, die zwar die ELGA Infrastruktur (wie Berechtigungssystem, Zentraler Patienten-Index, Gesundheitsdiensteanbieter-Index, Protokollierung, ...) nutzen, für die aber andere gesetzliche Grundlagen gelten. Dieser Vorschrift müssen daher alle über ELGA vermittelten CDA-Dokumente folgen. Andere CDA-Dokumente im österreichischen Gesundheitswesen sollen ebenfalls dieser Vorschrift folgen, der Leitfaden wurde daher entsprechend offen ausgelegt.

Für die Ausgestaltung der Inhalte von „CDA Implementierungsleitfäden“ "CDA Implementierungsleitfäden" ist eine breite Beteiligung der Stakeholder wesentlich, um die praktische Nutzbarkeit und die Akzeptanz durch die ELGA-Benutzer sicherzustellen.

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“ "Harmonisierung" etabliert neue nationale Qualitätsstandards der medizinischen Dokumentation.

Optional kann für eine Überprüfung der Implementierbarkeit vor dem normativen Ballot ein „STU"STU-Ballot“ Ballot" (Standard for Trial Use Ballot) durchgeführt werden, mit dem dann eine Testphase durchgeführt werden kann.

Über die hier geschilderten „internen“ "internen" Abstimmungsarbeiten hinaus wird eine Kooperation mit den betroffenen Standardisierungsorganisationen angestrebt, etwa mit dem Österreichischen Normungsinstitut, IHE Austria, DICOM Austria und auch mit weiteren nationalen und internationalen Normengremien.

Für die Annahme von neuen nationalen HL7 Standards und Richtlinien existiert eine formelle Prozedur, das so genannte Abstimmungsverfahren oder „Ballot“"Ballot". Der Leitfaden wird dafür einem breiten Teilnehmerkreis zur Kommentierung vorgelegt. Die Kommentare werden gesammelt und bearbeitet, wobei negative Kommentare im Einvernehmen zwischen dem Autor des Leitfadens und dem Kommentierenden aufgelöst werden. Eine ausreichende Anzahl an stimmberechtigten Teilnehmern muss der Freigabe des Dokuments zustimmen. Eine genaue Beschreibung des Abstimmungsverfahrens ist auf der Website von HL7 Austria publiziert<ref>HL7 Austria Abstimmungsverfahren („Ballots“"Ballots"): https://hl7.at/technische-komitees/ballots/</ref>.

Neue Versionen, die „verpflichtende Elemente“ "verpflichtende Elemente" (Sections oder Entries) neu einführen oder entfernen, sind „Hauptversionen“"Hauptversionen", die jedenfalls über eine Durchführungsverordnung verbindlich gemacht und veröffentlicht werden. Andere Versionen sind „Nebenversionen“"Nebenversionen". Alle verbindlichen Versionen sind auf http://www.gesundheit.gv.at zu veröffentlichen.

Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der „Arbeitsgruppe“ "Arbeitsgruppe" bestehend aus nachfolgend genannten Personen:

Milan Kornfeind (Österreichische Ärztekammer), Robert Hawliczek (Österreichische Ärztekammer), Jürgen Schwaiger (Österreichische Ärztekammer), Gerhard Holler (Österreichische Ärztekammer), Ludwig Gruber (Ärztekammer Tirol) Christian Husek (Initiative-ELGA), Susanna Michalek (Initiative-ELGA), Michael Hubich (Barmherzige Schwestern Linz), Tilman Königswieser (Oberösterreichische Gesundheits- u. Spitals AG), Josef Hamedinger (Oberösterreichische Gesundheits- u. Spitals AG), Ingrid Wimmer (Oberösterreichische Gesundheits- u. Spitals AG), Hubert Leitner (Steiermärkische Krankenanstalten-ges. m.b.H.), Walter Schwab-Ganster (Steiermärkische Krankenanstalten-ges. m.b.H.), Birgit Fürst (Steiermärkische Krankenanstalten-ges. m.b.H.), Monika Hoffberger (Steiermärkische Krankenanstalten-ges. m.b.H.), Daniela Sturm (Steiermärkische Krankenanstalten-ges. m.b.H.), Brigitte Walzl (Steiermärkische Krankenanstalten-ges. m.b.H.),Konrad Hölzl (Wiener Krankenanstaltenverbund), Reinhard Eberl (Salzburger Landeskliniken), Stefan Rausch-Schott (Vinzenz Gruppe Krankenhausbeteiligungs- und Management GmbH), Benedikt Aichinger (e-Care Projekt), Eva Friedler (Projekt “PatientInnenorientierte "PatientInnenorientierte integrierte Krankenbetreuung“Krankenbetreuung"), Vera Em (FSW), Robert Em (WISO), Wolfgang Pfleger (FSW), Allg. Unfallversicherungsanstalt (Sozialversicherung), Gudrun Seiwald, Hubert Fankhauser (Sozialversicherung), Michael Szivak (Sozialversicherung), Barbara Kaller (Hauptverband der österreichischen Sozialversicherungsträger), Martin Asenbaum (Sozialversicherungs-Chipkarten Betriebs- und Errichtungsgesellschaft), Eduard Schebesta, Christoph Unfried (Health Communication Service GmbH), Jochen Peter Gallob (shm sana health management GmbH), Reinhard Egelkraut (Systema Human Information Systems GmbH), Peter Uher (Telekom Austria), Arnold Lengauer (Telekom Austria), Karl Holzer (T-Systems Austria GesmbH), Christian Ametz (x-tention), Matthias Frohner (Fachhochschule Technikum Wien), Ferenc Gerbovics (Fachhochschule Technikum Wien), Babette Dörr (Austrian Standards Institute - Österreichisches Normungsinstitut, Experte der Arbeitsgruppe 250.03 “Qualitätsmanagement "Qualitätsmanagement in der Pflege”Pflege"), Natalie Lottersberger (Austrian Standards Institute - Österreichisches Normungsinstitut, Experte der Arbeitsgruppe 250.03 “Qualitätsmanagement "Qualitätsmanagement in der Pflege”Pflege"), Andrea Klostermann (ELGA GmbH), Carina Seerainer (ELGA GmbH), Oliver Kuttin (ELGA GmbH), Stefan Sauermann (Fachhochschule Technikum Wien), Alexander Mense (Fachhochschule Technikum Wien), Martin Weigl (AIMC), Andreas Lindner (Lindner TAC)

Die ursprünglich in den USA von der Organisation „Health "Health Level Seven International“ International" (HL7) (http://www.hl7.org) entwickelten Spezifikationen sind durch die Weiterentwicklung internationaler Benutzergruppen zu einem internationalen Standard geworden, der in über 55 Ländern eingesetzt wird.

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 "Reference Information Model“ Model" (RIM) für alle Teile von HL7 V3.

Die „Clinical "Clinical Document Architecture“ 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 steht der Informationsaustausch im gesamten Gesundheitswesen im Vordergrund (also nicht beschränkt auf Krankenhäuser).

*'''Verwaltung''' (engl. „stewardship“"stewardship"): Für die Verwaltung des Dokuments ist eine bestimmte Organisation verantwortlich (der „Custodian“"Custodian").*'''Kontext''': Medizinische Dokumente etablieren den Standard-Kontext für die in ihnen gespeicherten Inhalte (z.B. den „Entlassungsbrief“"Entlassungsbrief").*'''Authentisierung''' (engl. „potential "potential für authentication“authentication"): Medizinische Dokumente werden authentisiert. Im medizinischen Alltag entspricht das der Signierung, Vidierung oder Validierung.*'''Ganzheit''' (engl. „wholeness“"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“"human readability"): Medizinische Dokumente sind für Menschen lesbar.

Eine grundsätzliche Bedingung für CDA ist die Sicherstellung der Lesbarkeit für Menschen in einem „normalen“ "normalen" Webbrowser (mit der üblichen Basisfunktionalität zum Browsen im Internet).

*Es muss einen eindeutig festgelegten Weg für einen Empfänger geben, den authentisierten Inhalt sichtbar zu machen (Für ELGA wird ein „Referenz"Referenz-Stylesheet“ Stylesheet" bereitgestellt, siehe Kapitel [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Darstellung_von_CDA_Dokumenten_mittels_ELGA_Referenzstylesheet|Darstellung von CDA Dokumenten mittels ELGA Referenzstylesheet]]).

*Lesbarkeit bezieht sich auf den authentisierten Inhalt. Zusätzlich kann weitere Information im Dokument vorhanden sein („CDA "CDA Level 3“3"), die auf Auswertbarkeit durch Anwendungssysteme abzielt, die aber nicht authentisiert oder lesbar dargestellt werden muss.

Die Beschreibung des Zusammenhangs von ELGA CDA-Dokumenten und den zur Registrierung von CDA in ELGA notwendigen „XDS"XDS-Metadaten“ Metadaten" finden Sie im Dokument

Die eigentliche klinische Dokumentation wird im so genannten '''''CDA Body''''' festgehalten. Im Vordergrund steht hier „lesbarer“ "lesbarer" (narrativer) Text, der verpflichtender Bestandteil von CDA R2 Dokumenten ist und die Interoperabilität zwischen den menschlichen Kommunikationspartnern garantiert.

Mit den beschriebenen Body Strukturen können '''''CDA Entries''''' verbunden sein (Kapitel '''[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Strukturen in Level 3|Strukturen in Level 3]]'''). Diese repräsentieren den „computerlesbaren Teil“ "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.

Alle diese Entries können untereinander linear oder rekursiv hierarchisch verbunden sein. Es sind gleichstufige Beziehungen möglich (z.B. eine Liste von Beobachtungen), aber auch die Wiedergabe einer Hierarchie (z.B. „kleines Blutbild“"kleines Blutbild", bestehend aus „Erythrozyten“"Erythrozyten", „Leukozyten“"Leukozyten", usw.).

Im CDA Body können Inhalte auf mehreren Strukturierungsebenen transportiert werden; diese Ebenen (umgangssprachlich „CDA"CDA-Levels“Levels") erlauben eine flexible Erweiterung der Interoperabilität von CDA Dokumenten.

* "Unstrukturierter Body" ('''„CDA"CDA-Level 1“1"''') ist ausschließlich auf die Lesbarkeit durch Menschen ausgelegt. Medizinische Inhalte werden als Text, Bilder oder auch nur als „eingebettetes PDF“ "eingebettetes PDF" (als unstrukturierter „NonXMLBody“"NonXMLBody") transportiert. * "Section-strukturierter Body" ('''„CDA"CDA-Level 2“2"''') ermöglicht eine Strukturierung der Inhalte nach Abschnitten („Sections“"Sections") mit festgelegter Bedeutung (z.B. „Anamnese“"Anamnese", „Diagnosen“"Diagnosen") durch Anwendung von Section-Templates. Die Abschnitte sind mit einem vereinbarten Code versehen, der es ermöglicht, dass EDV-Programme diese eindeutig erkennen und als Block verarbeiten können. * "Entry-strukturierter Body" ('''„CDA"CDA-Level 3“3"''') ist eine Technik zur Anreicherung eines lesbaren Dokuments mit medizinischen Einzelinformationen (z.B. „diastolischer Blutdruck“"diastolischer Blutdruck", „ICD"ICD-10 Entlassungsdiagnose“Entlassungsdiagnose", „Körpergewicht "Körpergewicht in kg“kg") durch Anwendung von Entry-Templates, die gemäß einer Vereinbarung maschinenlesbar codiert sind und daher automatisch in medizinische Informationssysteme integriert werden können.

Die Kardinalität beschreibt, wie oft ein Element innerhalb einer Struktur auftreten kann. Die Kardinalität wird durch ein Intervall zwischen der minimalen und maximalen Anzahl angegeben, getrennt durch „"..“". Eine unbegrenzte Anzahl wird durch ein „"*“ " angegeben. Daraus ergeben sich mindestens folgende Möglichkeiten: 0..1; 0..*; 1..1; 1..*

Sind Elemente bzw. Attribute als „optional“ "optional" gekennzeichnet ('''''[O]''''') so ist ihre Verwendung OPTIONAL, aber es ist NICHT ERLAUBT, dass sie, wenn sie verwendet werden, leer sind. Möchte man ein optionales Element explizit mit einem leeren Wert angeben, so hat dies durch Kennzeichnung mit '''''[[#Der_nullFlavor|nullFlavor]]''''' zu erfolgen.

Vielmehr beschreiben die ELGA Implementierungsleitfäden lediglich jene Elemente, die erlaubt sind. Die Verwendung aller nicht angegebenen Elemente und Attribute ist NICHT ERLAUBT. Für alle Templates gelten die im [[#Datentypen|Kapitel Datentypen]] angegebenen Einschränkungen. Die ELGA Implementierungsleitfäden beschreiben daher ein sogenanntes '''''„Maximum"Maximum-Set“Set"''''', Die ELGA Templates sind demnach als „closed templates“ "closed templates" entsprechend dem HL7 Templates Standard zu betrachten.

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

Attribute, die gem. CDA-Schema mit „fixed“ "fixed" angegeben sind, haben einen festen Wert, daher können diese Attribute auch weggelassen werden. Diese Attribute werden daher üblicherweise nicht beschrieben und angegeben. Die Angabe von fixierten Attributen oder Attributen mit ihrem gem. CDA-Schema definierten Default-Wert ist erlaubt, auch wenn diese nicht explizit im Leitfaden beschrieben sind.

'''↔ Hinweis zum XDS-Mapping:''' Beim XDS-Attribut XDSDocumentEntry.formatCode muss ein zusätzliches Plus-Zeichen („"+“") am Ende des Strings hinzugefügt werden, wenn in einem Dokument selbst-definierte maschinenlesbare Elemente vorhanden sind. <br/>

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“ "Enhanced" oder „Full Support“"Full Support"]]).

CDA-Dokumente können unter Umständen „fremde“ "fremde" Elemente oder Attribute enthalten, die der „Maximum"Maximum-Set“ Set" Vorschrift dieses Leitfadens widersprechen (z.B. aufgrund von Software-Fehlern). Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, soll weiterverarbeitende Software so implementiert sein, dass dies nicht zu Fehlern in der Weiterverarbeitung der Dokumente führt.

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 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 Value-Sets „ELGA_MaritalStatus“"ELGA_MaritalStatus", „ELGA_Laborparameter“"ELGA_Laborparameter".

Für jedes Value Set ist auch ein Zeitpunkt angegeben, an dem es Gültigkeit erlangt („Gültig ab“"Gültig ab"), das ist 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.

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“"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“"Immutability").

Weitere Hinweise zum korrekten Umgang mit Terminologien finden sich im „Leitfaden "Leitfaden für den Umgang mit Terminologien in ELGA“ELGA"<ref>Sabutsch, S. & C. Seerainer: Leitfaden zur Nutzung von ELGA-Terminologien http://elga.gv.at/CDA</ref>.

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 (siehe Kapitel [[#Terminologiedatum_.28.E2.80.9Ehl7at:terminologyDate.E2.80.9C.29|Terminologiedatum („hl7at"hl7at:terminologyDate“terminologyDate")]]).

Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A-1b bzw. PDF/A3-b (gemäß „ISO "ISO 19005-1:2005 Level A conformance“conformance") entsprechen. Die Umsetzung von PDF/A-1a bzw. PDF/A-3a ist EMPFOHLEN.

In CDA Dokumenten können verschiedene Objekte (z.B. PDF-Dokumente, Bilder) eingebettet werden (siehe „"[[#Eingebettetes_Objekt_Entry|Eingebettetes Objekt-Entry]]“").

Der zukünftige Nutzen von e-Befunden in ELGA hängt von ihrem Strukturierungsgrad ab: Je einheitlicher und strukturierter die Informationen vorliegen, desto besser können die Daten durch IT-Systeme verarbeitet und ausgewertet werden. Die „ELGA Interoperabilitätsstufen“ "ELGA Interoperabilitätsstufen" (EIS) definieren eine bestimmte Menge von Vorgaben für Section und Entry-Level Templates ("CDA Levels" 2 und 3). Die Mindeststandards für die Datenstruktur der CDA-Dokumente und die Zeitpunkte für die verbindliche Verwendung werden per Verordnung des für Gesundheit zuständigen Ministers festgelegt.

*'''EIS „Basic“ "Basic" und EIS „Structured“"Structured":''' EIS „Basic“ "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 ([[#CDA_Header|CDA Header]]). 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 "Allgemeinen Implementierungsleitfaden für CDA-Dokumente“Dokumente"'' und allfälliger [[#CDA_Header|Header]]-Spezifikationen eines speziellen Leitfadens. In EIS „Basic“ "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“ "Structured" ist eine Erweiterung der verpflichtenden Mindeststrukturierung EIS „Basic“"Basic". Die medizinischen Inhalte folgen auf dieser Stufe der Gliederung und dem Aufbau, den der Leitfaden für die höheren EIS „Enhanced“ "Enhanced" und „Full Support“ "Full Support" vorgibt, sie folgen aber nicht der entsprechenden technischen Struktur und Codierung. EIS „Structured“ "Structured" Dokumente decken sich technisch mit EIS „Basic“"Basic", erscheinen dem Leser inhaltlich wie EIS „Enhanced“ "Enhanced" und „Full Support“ "Full Support" Dokumente, ohne deren semantische Interoperabilität zu unterstützen.

*'''EIS „Enhanced“ "Enhanced" und EIS „Full Support“"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“"Enhanced"''' stellt eine Zwischenstufe auf dem Weg zu „Full Support“ "Full Support" dar. Die Vorgaben betreffen eine kleinere Anzahl an maschinenlesbaren Elementen und sind weniger streng als bei „Full Support“"Full Support".**'''EIS „Full Support“"Full Support"''' kann gegenüber EIS „Enhanced“ "Enhanced" zusätzliche maschinenlesbar codierte medizinische Inhalte enthalten, die in ELGA CDA-Dokumenten anzugeben sind.

| style="background:#E9FCDF" |'''„EIS BASIC“"EIS BASIC"''' und '''„EIS STRUCTURED“"EIS STRUCTURED"'''||Einheitlicher CDA-[[#CDA_Header|Header]]. Verwendung der Dokumente in ELGA (Aufnahme in Dokumentregister, Anzeige für Berechtigte). Minimale Anforderungen an erstellende Systeme („eingebettetes PDF“ "eingebettetes PDF" oder XML ohne Templates)

EIS „Structured“ "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" |'''„EIS ENHANCED“"EIS ENHANCED"'''

| style="background:#78BA58" |'''„EIS "EIS FULL SUPPORT“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.

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 bestimmte „ELGA Interoperabilitätsstufen“ "ELGA Interoperabilitätsstufen" als Zwischenziele definiert. Seit 2018 gilt EIS Full Support als Mindeststandard für die verordneten ELGA Implementierungsleitfäden.

Neben den im ELGA-Gesetz definierten Dokumentenklassen können zukünftige Dokumentenklassen mit ihrer Struktur und ihrem Format für ELGA per Verordnung festgelegt werden. Auch für diese Dokumentenklassen gilt zumindest die unterste Interoperabilitätsstufe „EIS Basic“"EIS Basic". Wenn ein CDA Implementierungsleitfaden für die jeweilige Dokumentenklasse harmonisiert wurde, ist es möglich, Dokumente in den höheren Interoperabilitätsstufen „EIS Structured“"EIS Structured", „EIS Enhanced“ "EIS Enhanced" und „EIS "EIS Full Support“ Support" auszutauschen.

Ein zu diesem Implementierungsleitfaden konformes CDA-Dokument ist zunächst ein valides CDA Release 2.0 XML-Dokument mit [[#CDA_Header|Header]] und [[#CDA_Body|Body]]. Darüber hinaus erfüllt es alle in diesem Leitfaden festgelegten „Geschäftsregeln“"Geschäftsregeln".

Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten wider: die Validierung in zwei Schritten. Im ersten Schritt stellt dies die Validierung gegen zugehörige '''W3C Schemas''' dar. Das verwendete Schema ist das geringfügig erweiterte offizielle CDA Release 2.0 Schema (siehe [[#Schema-Pr.C3.BCfung|Schema-Prüfung]]). Darüber hinaus existieren eine Reihe von '''Schematron''' Regeln, die für einen zweiten Validierungsschritt genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben, sowie die Einhaltung der Geschäftsregeln (Optionalität, Kardinalität/Multiplizität, Datentypen, Wertebereiche, Abhängigkeiten) sicherstellen (siehe [[#Schematron-Pr.C3.BCfung|Schematron-Prüfung]]). Geschäftsregeln für Abschnitte oder Elemente werden auch technisch zu '''„Templates“"Templates"''' zusammengefasst. Eine XML-Instanz, die kein valides CDA-Dokument ist oder sich nicht gegen das XSD-Schema validieren lässt, oder im Widerspruch zu den angegebenen Geschäftsregeln steht, ist kein gültiges CDA-Dokument im Sinne dieses Implementierungsleitfadens.

Eine Prüfung gegen das CDA Schema prüft die gültige „Struktur“ "Struktur" eines CDA-Dokuments, wie beispielsweise

Die Gültigkeit der „Inhalte“ "Inhalte" wird nur in Bezug auf den erforderlichen Datentyp der Elemente geprüft. Hiermit kann beispielsweise sichergestellt werden, dass ein „id“"id"-Element (technisch) immer eine gültige ID enthält.

Die Mindestvoraussetzung, damit ein CDA-Dokument als „gültig“ "gültig" erachtet wird, ist die fehlerfreie Validierung mit dem CDA-Schema.

Das Absolvieren der Schematron-Prüfung ist der zweite Teil der technischen Konformitätsprüfung und stellt sicher, dass das geprüfte Dokument die in den Implementierungsleitfäden beschriebenen „Geschäftsregeln“ "Geschäftsregeln" befolgt.

'''ELGA Konformität:''' Damit ein CDA-Dokument als vollständig „gültig“ "gültig" hinsichtlich der ELGA Implementierungsleitfäden erachtet wird, ist die fehlerfreie Konformitätsprüfung mit den entsprechenden Schematron-Prüfregeln vorausgesetzt. Eine vollständige Prüfung der Geschäftsregeln kann nur durch einen menschlichen Prüfer erfolgen (siehe Kapitel [[#Abnahmepr.C3.BCfung_f.C3.BCr_ELGA_e-Befunde|Abnahmeprüfung]]). Die ELGA GmbH kann auf Anfrage an [mailto:cda@elga.gv.at cda@elga.gv.at] eine solche Prüfung durchführen.

Attribute oder Elemente eines CDA-Dokuments, die den Datentyp-Definitonen und den Template-Spezifikationen widersprechen oder darin nicht beschrieben wurden (also fremde Inhalte im Sinne der „closed templates“ "closed templates" Elemente, die der „Maximum"Maximum-Set“ Set" Vorschrift widersprechen), werden von den Schematron-Regeln grundsätzlich als falsch erkannt. Nicht als falsch erkannt werden Elemente und Attribute, die entsprechend den HL7 V3 Datentypen erlaubt sind, aber in den ELGA-Datentyp-Definitionen nicht enthalten oder verboten sind. Diese können nur durch die Schematron-Prüfmechanismen entdeckt werden, wenn sie im Template explizit als verboten modelliert wurden (was nicht immer der Fall ist).

Das Thema „Zertifizierung“ "Zertifizierung" (etwa die Zertifizierung von Softwaresystemen) wird von diesem Implementierungsleitfaden nicht behandelt.

Identifikationselemente (II Instance Identifier) erlauben die global eindeutige Identifikation durch Verwendung von Objektidentifikatoren (kurz „OID“"OID"), gemäß dem in ISO/IEC 9834-1 normierten Mechanismus zur weltweit eindeutigen Kennzeichnung von Informationsobjekten (siehe OID-Konzept <ref name="OID">Object Identifier (OID) Konzept für das österreichische Gesundheitswesen https://www.gesundheit.gv.at/OID_Frontend/OID_Konzept_1-1-0.pdf </ref>). Die relevanten OID werden im OID-Portal für das Österreichische Gesundheitswesen<ref>OID Portal für das Österreichische Gesundheitswesen: https://www.gesundheit.gv.at/OID_Frontend/ </ref> registriert und veröffentlicht.

Die Vorgaben für IDs aus dem GDA-Index sind in der Basiskomponente „GDA"GDA-Index“ Index" beschrieben.

Informationen zum österreichischen OID-Konzept finden Sie online auf dem „OID "OID Portal Österreich“Österreich": https://www.gesundheit.gv.at/OID_Frontend/index.jsp?section=1

Für eine detaillierte Beschreibung der Abbildung von Referenzen in den narrativen Bereich siehe [[#Spezifikation_4|Spezifikation]] und [[#Zusammenhang_Text_und_Entry|„Zusammenhang "Zusammenhang Text und Entry“Entry"]].

| || colspan="3" |originalText||ED||0..1||O||OriginalText ist ein Element, dass die sprachliche Repräsentation eines Codes in der originalen Sprache des Dokuments enthält. Der Inhalt dieses Elements darf für die menschenlesbare Anzeige des Codes verwendet werden. <br />Entweder direkt angegeben als „String“ "String" oder indirekt als „Referenz“ "Referenz" auf eine Textstelle im narrativen Bereich.<br />Im Falle der direkten Angabe als „String“"String", z.B. '''Diabetes mellitus Typ 1'''

| || || || colspan="2" |''Konditionale Konformität:''<br />Wenn indirekte Angabe als „Referenz“"Referenz"<br />Wenn direkte Angabe||<br /> 1..1<br /> 0..0||<br />M <br /> NP||

| || || ||@value||url||1..1||R||'''''#{generierter_ref_string}-{generierteID}'''''<br />z.B.: '''#entldiag-1''', verweist auf die Textstelle im narrativen Block:<td id="“'''entldiag-1'''“">'''Diabetes mellitus Typ 1'''</td>

| || @value|| url || 1..1 || R || Die Kontaktadresse (Telefonnummer, Email, etc.)<br/>Formatkonvention siehe „"[[#telecom_.E2.80.93_Format_Konventionen_f.C3.BCr_Telekom-Daten|telecom – Format Konventionen für Telekom-Daten]]“"<br/> Bsp: ''tel'':+43.1.1234567<br/>Zulässige Werteliste für telecom Präfixe gemäß Value-Set „"'''ELGA_URLScheme'''“"

| || @use|| cs|| 0..1 ||O || Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …)<br/>Bsp: WP<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_TelecomAddressUse'''“"

* MUSS das URI Schema „"''tel:''“", „"''mailto:''“", etc. aufweisen** Zulässige Werteliste für telecom Präfixe gemäß Value-Set „"'''ELGA_URLScheme'''“"

** … MUSS im Falle von internationalen Telefonnummern mit einem „"+“ " beginnen

Die Bedeutung des Namen-Elements KANN mit dem Attribut @use angegeben werden. Fehlt das Attribut, wird der Name als „rechtlicher Name“ "rechtlicher Name" (Realname bzw. bürgerlicher Name) angenommen (entsprechend @use=“L“"L", ''legal name'').

| || @use|| cs||0..1 || O || Die genaue Bedeutung des angegebenen Namens, beispielsweise, dass der angegebene Personen-Name ein „Künstlername“ "Künstlername" ist. Weitere Bsp: L (rechtlicher Name), A (Künstlername), R (Ordensname)<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_EntityNameUse'''“"<br/>Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“"L").

| || colspan="2" style="text-align:left" | @use|| cs|| 0..1 || O || Die genaue Bedeutung des angegebenen Namens, beispielsweise, dass der angegebene Personen-Name ein „Künstlername“ "Künstlername" ist.<br/>Bsp: L (rechtlicher Name), A (Künstlername), R (Ordensname)<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_EntityNameUse'''“"<br/>Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“"L").

| || colspan="2" style="text-align:left" | prefix|| en.prefix|| 0..* || O || Beliebig viele Präfixe zum Namen<br/>z.B. Akademische Titel, Adelstitel<br/>{{BeginYellowBox}}Achtung: Die Angabe der Anrede („Frau“"Frau", „Herr“"Herr"), ist im CDA nicht vorgesehen!{{EndYellowBox}}

| || || @qualifier|| cs|| 0..1 || O || Die genaue Bedeutung eines ''prefix''-Elements, beispielsweise, dass das angegebene Präfix einen akademischen Titel darstellt.<br/>z.B.: AC („Akademischer Titel“"Akademischer Titel")<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_EntityNamePartQualifier'''“"

| || || @qualifier|| cs|| 0..1 || O || Die genaue Bedeutung eines ''given''-Elements, beispielsweise, dass das angegebene Element eine Initial (z.B. ''middle initial'') bezeichnet.<br/>z.B.: IN („Initial“"Initial")<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_EntityNamePartQualifier'''“"

| || || @qualifier|| cs|| 0..1 || O || Die genaue Bedeutung eines ''family''-Elements, beispielsweise, dass das angegebene Element einen Geburtsnamen bezeichnet.<br/>z.B.: BR („Geburtsname“"Geburtsname")<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_EntityNamePartQualifier'''“"

| || || @qualifier|| cs|| 0..1 || O || Die genaue Bedeutung eines ''suffix''-Elements, beispielsweise, dass das angegebene Suffix einen akademischen Titel darstellt.<br/>z.B.: AC („Akademischer Titel“"Akademischer Titel")<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_EntityNamePartQualifier'''“"

* Nachnamen (family) und ein eventuelles Trennzeichen (meistens ‘"-‘") MÜSSEN in der offiziellen Sequenz stehen, abhängig von der Wahl bei der Eheschließung.

Für die Namenselemente kann zur näheren Bestimmung ein Qualifier angegeben werden (aus dem Value Set "ELGA_EntityNamePartQualifier“ELGA_EntityNamePartQualifier"), v.a. für Prefix/Suffix.

Hinweis: Diese Granularitätsstufe ist ausdrücklich „nicht empfohlen“ "nicht empfohlen" und SOLL nur in EIS [[#ELGA_Interoperabilit.C3.A4tsstufen|Basic]] angewandt werden, wenn eine feinere Granularität nicht möglich ist.<br/>

| || style="text-align:left" | @use|| cs|| 0..1 || O || Die genaue Bedeutung der angegebenen Adresse, beispielsweise, dass die angegebene Adresse die Wohn-Adresse ist, z.B. HP („Home primary“"Home primary")<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_AddressUse'''“"<br/>Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als „Wohnadresse“ "Wohnadresse" („H“"H") und bei Organisationen als Büroadresse („WP“"WP").<br/>Der Hauptwohnsitz wird mit „HP“ "HP" gekennzeichnet. Weitere Adressen mit dem Kennzeichen „H“ "H" gelten dann als Zweit- oder Nebenwohnsitz.

| || style="text-align:left" | @use|| cs|| 0..1 || O || Die genaue Bedeutung der angegebenen Adresse, beispielsweise, dass die angegebene Adresse die Wohn-Adresse ist, z.B. HP („Home primary“"Home primary")<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_AddressUse'''“"<br/>Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als „Wohnadresse“ "Wohnadresse" („H“"H") und bei Organisationen als Büroadresse („WP“"WP").<br/>Der Hauptwohnsitz wird mit „HP“ "HP" gekennzeichnet. Weitere Adressen mit dem Kennzeichen „H“ "H" gelten dann als Zweit- oder Nebenwohnsitz.

Es wird EMPFOHLEN, den Staat im ISO 3 Ländercode (ISO-3166-1 Alpha 3) anzugeben, z.B. „AUT“ "AUT" für Österreich, „DEU“ "DEU" für Deutschland…

| || style="text-align:left" | @use|| cs|| 0..1 || O || Die genaue Bedeutung der angegebenen Adresse, beispielsweise, dass die angegebene Adresse die Wohn-Adresse ist, z.B. HP („Home primary“"Home primary")<br/>Zulässige Werte gemäß Value-Set „"'''ELGA_AddressUse'''“"<br/>Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als „Wohnadresse“ "Wohnadresse" („H“"H") und bei Organisationen als Büroadresse („WP“"WP").<br/>Der Hauptwohnsitz wird mit „HP“ "HP" gekennzeichnet. Weitere Adressen mit dem Kennzeichen „H“ "H" gelten dann als Zweit- oder Nebenwohnsitz.

Es wird EMPFOHLEN, den Staat im ISO 3 Ländercode (ISO-3166-1 Alpha 3) anzugeben, z.B. „AUT“ "AUT" für Österreich, „DEU“ "DEU" für Deutschland…

Numerische Ergebnisse werden in der Regel als „physical quantity“ "physical quantity" PQ dargestellt, was die Angabe einer Einheit in UCUM-Schreibweise erforderlich macht. Es MUSS die „case sensitive“ "case sensitive" Variante (c/s) der maschinenlesbaren Form des UCUM verwendet werden. Als Dezimaltrennzeichen MUSS im maschinenlesbaren und menschenlesbaren Teil (section.text) ein Punkt (".") verwendet werden. Die bevorzugte Einheit für jede Analyse wird in den einzelnen dazugehörigen ELGA Value Sets vorgeschlagen, jeweils in der in der maschinenlesbaren Form und in der „print“ "print" Variante für die Darstellung in section.text.

Dabei MUSS bei einer Potenz der Exponent der maschinenlesbaren Einheiten mit "*" (z.B.: 10*9 für eine Milliarde) angegeben werden (Dies resultiert aus der Reservierung des Symbols "^" als Trennzeichen in HL7 Nachrichten). Hingegen MUSS weiterhin für den Exponenten der menschenlesbaren Einheiten die „print“ "print" Variante mit "^" angegeben werden (z.B.: 10^9 für eine Milliarde).

Es wird EMPFOHLEN, anstelle von Einheitenpräfixen („Giga“"Giga", „Mega“"Mega", „Milli“"Milli", „Mikro“ "Mikro" etc.) eine Potenzschreibweise zu wählen, vor allem, wenn die Groß/Klein-Schreibung eine Rolle spielt und Verwechslungen möglich sind (z.B. „G"G/L“L"=Giga pro Liter vs. „g"g/L“L"=Gramm/Liter). Also '10^6 ' statt 'M' (Mega), '10^9 ' statt 'G ' (Giga) usw.

Die Codierung von '''textuellen Ergebnissen''' erfolgt in der Regel durch den “ST” "ST" Datentyp. Die Angabe des Ergebnisses erfolgt hier als Wert des Elementes.

Für '''Verhältnisangaben''', wie sie etwa für '''Titer''' verwendet werden (z.B. „1"1:128“128") steht der Datentyp RTO (Ratio) zur Verfügung. Ein Anwendungsbeispiel:

'''Intervalle''' können mit dem Datentyp IVL angegeben werden, z.B. „20"20-30 mg/L“L":

| style="text-align:left" | name|| PN|| 1..* || M || Name der Person<br/> Grundsätzlich sind die Vorgaben gemäß „"[[#Namen-Elemente_von_Personen_PN|Namen-Elemente von Personen PN]]“ " zu befolgen.

| style="text-align:left" | id|| II || 0..* || O || Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.<br/> Grundsätzlich sind die Vorgaben gemäß „"[[#Identifikations-Elemente|Identifikations-Elemente]]“ " zu befolgen.

| style="text-align:left" | name || PN|| 1..1 || M || Name der Organisation<br/>Grundsätzlich sind die Vorgaben gemäß „"[[#Namen-Elemente_von_Organisationen_ON|Namen-Elemente von Organisationen ON]]“ " zu befolgen.

| style="text-align:left" | telecom|| TEL || 0..* || O || Beliebig viele Kontakt-Elemente der Organisation<br/>Grundsätzlich sind die Vorgaben gemäß „"[[#Kontaktdaten-Elemente|Kontaktdaten-Element]]“ " zu befolgen.

| style="text-align:left" | addr|| AD|| 0..1 || O || Ein Adress-Elemente der Organisation<br/>Grundsätzlich sind die Vorgaben gemäß „"[[#Adress-Elemente|Adress-Elemente]]“ " zu befolgen.

Hierbei MUSS jedenfalls die „Person“ "Person" der Entität angegeben werden. Die Angabe der Organisation, der die Person angehört, ist prinzipiell optional. Diese Optionalität kann sich in Abhängigkeit vom konkreten Anwendungsfall in „verpflichtend“ "verpflichtend" ändern.

Grundsätzlich sind die Vorgaben gemäß „"[[#Identifikations-Elemente|Identifikations-Elemente]]“ " zu befolgen.

Grundsätzlich sind die Vorgaben gemäß „"[[#Adress-Elemente|Adress-Elemente]]“ " zu befolgen.

Grundsätzlich sind die Vorgaben gemäß „"[[#Kontaktdaten-Elemente|Kontaktdaten-Element]]“ " zu befolgen.

Grundsätzlich sind die Vorgaben gemäß „"[[#Personen-Element|Personen-Element]]“ " zu befolgen.

Grundsätzlich sind die Vorgaben gemäß „"[[#Organisations-Element|Organisations-Element]]“ " zu befolgen.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”"yes"?>

Um ein CDA-Dokument in einem Webbrowser anzeigen zu können, muss es nach HTML tranformiert werden. Das kann durch eine XSLT-Transformation (ein so genanntes „Stylesheet“"Stylesheet") geschehen. Ist das Stylesheet im angegebenen Pfad erreichbar, wird dieses beim Öffnen des CDA-Dokuments mit einem Browser üblicherweise automatisch auf das CDA-Dokument angewandt und die Darstellung gerendert. ELGA stellt zur einheitlichen Darstellung von CDA-Dokumenten ein „Referenz"Referenz-Stylesheet“ Stylesheet" zur Verfügung (verfügbar unter http://www.elga.gv.at/cda). Da der Zugriff auf XSLT-Programme von den meisten Browsern eingeschränkt ist, wird kein absoluter Pfad auf eine Webressource angegeben.

===Hoheitsbereich des Dokuments („realmCode“"realmCode")===

===Dokumentformat („typeId“"typeId")===

===ELGA Implementierungsleitfaden-Kennzeichnung („templateId“"templateId")===

Der Einsatz von so genannten „templateId”"templateId"-Elementen sichert zu, dass eine CDA-Instanz nicht nur CDA konform ist, sondern auch dem referenzierten Template oder Implementierungsleitfaden entspricht. Mit ''Zusicherung'' ist dabei nur eine informelle Behauptung des Verfassers gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung.

===Dokumenten-Id („id”"id")===

===Dokumentenklasse („code“"code")===Der “Code "Code des Dokuments” Dokuments" (im CDA das Element ''ClinicalDocument/code'') bezeichnet die „"'''Dokumentenklasse'''“ " bzw den präziseren „"'''Dokumententyp'''“".

**Dokumententyp: „"[[ILF:Entlassungsbrief (Ärztlich)|Entlassungsbrief aus stationärer Behandlung (Ärztlich)]]“"**Dokumententyp: „"[[ILF:Entlassungsbrief (Pflege)|Entlassungsbrief aus stationärer Behandlung (Pflege)]]“"

Für das Mapping in XDS siehe den entsprechenden Leitfaden „"[[ILF:XDS_Metadaten_2020|ELGA XDS Metadaten]]“".

===Titel des Dokuments („title“"title")===“Titel” "Titel" (im CDA das Element ''ClinicalDocument/title'') bezeichnet die verpflichtende „"'''Dokumentenüberschrift'''“ " (zusätzlich zur Dokumentenklasse).

*„Arztbrief“"Arztbrief"*„Entlassungsbrief "Entlassungsbrief der gynäkologischen Abteilung des SMZ Ost“Ost"*„Vorläufiger Entlassungsbrief“"Vorläufiger Entlassungsbrief"*„Befundbericht“"Befundbericht"

===Status des Dokuments („sdtc"sdtc:statusCode“statusCode")===

===Terminologiedatum („hl7at"hl7at:terminologyDate“terminologyDate")===Das ''Terminologiedatum'' gibt an, dass ein Dokument mit den Terminologien zum Stand eines bestimmten Datums erstellt wurde. Das Datum wird in einem eigens für die HL7-Austria Domäne geschaffenen Element „hl7at"hl7at:terminologyDate“ terminologyDate" angegeben.

===FormatCode („hl7at"hl7at:formatCode“formatCode")===

===Fachliche Zuordnung des Dokuments („hl7at"hl7at:practiceSettingCode“practiceSettingCode")===Die “fachliche "fachliche Zuordnung des Dokuments” Dokuments" wird im CDA-Element ''ClinicalDocument/hl7at:practiceSettingCode'' gespeichert.

===Erstellungsdatum des Dokuments („effectiveTime“"effectiveTime")===

===Vertraulichkeitscode („confidentialityCode“"confidentialityCode")===

===Sprachcode des Dokuments („languageCode“"languageCode")===

===Versionierung des Dokuments („setId“ "setId" und „versionNumber“"versionNumber")===

Für die direkte Referenzierung zwischen Dokumenten siehe „"[[ILF:Allgemeiner Implementierungsleitfaden#Bezug_zu_vorgehenden_Dokumenten|Bezug zu vorgehenden Dokumenten]]“".

===Patient („recordTarget"recordTarget/patientRole“patientRole")===

===Verfasser des Dokuments („author“"author")===

===Personen der Dateneingabe („dataEnterer“"dataEnterer")===

===Verwahrer des Dokuments („custodian“"custodian")===

===Beabsichtigte Empfänger des Dokuments („informationRecipient“"informationRecipient")===

===Rechtlicher Unterzeichner („legalAuthenticator“"legalAuthenticator")===

===Weitere Unterzeichner („authenticator“"authenticator")===

===Weitere Beteiligte („participant“"participant")===

====Festlegung der „Art“ "Art" des Beteiligten====Die „Art“ "Art" des Beteiligten wird über eine Kombination aus

Dieses Kapitel enthält eine detaillierte Anleitung zur Angabe der folgenden Arten von „weiteren Beteiligten“"weiteren Beteiligten":

Welche der folgenden „weiteren Beteiligten“ "weiteren Beteiligten" im Dokument angegeben werden müssen bzw. sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

Der Notfall-Kontakt entspricht in Österreich der „Auskunftsberechtigten Person“ "Auskunftsberechtigten Person" (oder auch „Vertrauensperson“"Vertrauensperson").

Als Angehörige sind in Österreich jene Personen anzusehen, welche in einem Verwandtschaftsverhältnis zum Patienten stehen, aber nicht unter die Gruppe der „Auskunftsberechtigten Personen“ "Auskunftsberechtigten Personen" fallen (siehe [[#Notfall-Kontakt.2FAuskunftsberechtigte_Person|Notfall-Kontakt/Auskunftsberechtigte Person]]).

===Auftrag („inFulfillmentOf“"inFulfillmentOf")===

===Service Events („documentationOf"documentationOf/serviceEvent“serviceEvent")===

===Autorisierung („authorization“"authorization")===

===Encounter („componentOf"componentOf/encompassingEncounter“encompassingEncounter")===

Der CDA Body eines CDA-Dokuments kann entweder „strukturiert“ "strukturiert" oder „unstrukturiert“ "unstrukturiert" angegeben werden.

Mit Level 1 ist ein XML Dokument gekennzeichnet, das vor allem auf das Lesen des Dokuments von Menschen abzielt („human readable“"human readable"), also leicht für den menschlichen Gebrauch zugänglich gemacht werden kann (z.B. durch Stylesheets). Es gibt keine Einschränkungen hinsichtlich des Inhalts, Zwecks oder Gebrauchs des Dokuments. Die technischen Anforderungen, Level 1 Dokumente zu erzeugen oder zu verarbeiten, sind verhältnismäßig niedrig. Dies ist aus Datenverarbeitungssicht das gröbste Niveau von Informationen, gewährleistet damit aber sofort die Mensch-Mensch-Interoperabilität, die aus der klassischen "Papierwelt" bekannt ist.

CDA Level 1 sind alle Dokumente mit einem CDA „nonXMLBody“ "nonXMLBody" und jene mit Sektionen ohne Codierung:

CDA-Dokumente, die auch Level 3 konform sind, beinhalten zusätzlich zu der lesbaren Text-Sektion auf dem Niveau von Einzelinformationen maschinenauswertbare Komponenten, so genannte ''entry''-Elemente (wie beispielsweise „systolischer Blutdruck“"systolischer Blutdruck").

Alle relevanten medizinischen Daten MÜSSEN im „menschenlesbaren Teil“"menschenlesbaren Teil", dem narrativen Block (title und text-Elemente der Sections) enthalten sein. Für die maschinenlesbaren Einträge (''entry'') kommen '''Entry-Level-Templates''' zum Einsatz. Dies MÜSSEN inhaltlich konsistent zum lesbaren Textbereich sein und sollen zusätzlich die entsprechenden Inhaltsstellen im Textbereich referenzieren. Zusätzliche maschinenlesbare Informationen können angegeben werden, sofern sie nicht dargestellt werden müssen und auch nicht Bestandteil des signierten Originalbefundes sind. Sind die narrativen Daten direkt von den maschinenlesbaren abgeleitet und daher inhaltlich gleich, wird das im Entry durch das Attribut typeCode="DRIV" angegeben. Hier kann ausschließlich der maschinenlesbare Teil ohne Informationsverlust zur Weiterverarbeitung verwendet werden.

CDA bietet die Möglichkeit Sektionen mit sogenannten „templateId“"templateId"-Elementen zu versehen. Mit diesen Elementen ist es möglich, analog zur ELGA Implementierungsleitfaden-Kennzeichnung für das gesamte Dokument, auch einzelne Sektionen zu kennzeichnen.

Der CDA-Standard erlaubt nur eine kleine Auswahl an Formatierungsoptionen für den section.text, damit die oben genannte einfache Lesbarkeit („human readability“"human readability") zuverlässig erhalten bleibt und die Anforderungen für die Wiedergabe einfach bleiben. Die Syntax entspricht einem vereinfachten und stark eingeschränkten HTML.

Innerhalb von Sections wird das text-Element verwendet, um den narrativen Text („plain text“"plain text") darzustellen. In vielen Fällen lassen sich die medizinischen Inhalte aber auch noch weitergehend strukturieren. Dazu stehen in CDA als Stil-Elemente Listen, Tabellen und Unterabschnitte (Paragrafen) zur Verfügung. Mit Hilfe eines einfachen Stylesheets können die Inhalte in diesen Strukturelementen für den Menschen lesbar dargestellt werden.

Das Strukturelement „Liste“ "Liste" dient zur Abbildung einer einfachen Aufzählung medizinischer Inhalte.

Eine Liste wird mit dem ''list'' Tag eingeschlossen. Das optionale Attribut @''listType'' ermöglicht die Auflistung unsortiert (@''listType''=“"''unordered''“"), die üblicherweise mit Bulletpoints • dargestellt wird, und in sortierter Form (@''listType''=“"''ordered''“"), die mit Zahlen etc. dargestellt wird. Ohne Angabe von @''listType'' ist die Liste unsortiert.

| Arabic||Sortierte Liste mit Zahlen (1, 2, 3) ||<list listType="ordered" styleCode= ”Arabic"Arabic">

| LittleRoman||Sortierte Liste mit kleingeschriebenen römischen Zahlen (i, ii, iii) ||<list listType="ordered" styleCode=”LittleRoman"LittleRoman">

| BigRoman||Sortierte Liste mit großgeschriebenen römischen Zahlen (I, II, III) ||<list listType="ordered" styleCode=”BigRoman"BigRoman">

| LittleAlpha||Sortierte Liste mit kleingeschriebenen Buchstaben (a, b, c) ||<list listType="ordered" styleCode= ”LittleAlpha"LittleAlpha">

| BigAlpha||Sortierte Liste mit großgeschriebenen Buchstaben (A, B, C)||<list listType="ordered" styleCode= ”BigAlpha"BigAlpha">

<list listType="ordered" styleCode= ”BigAlpha"BigAlpha">

Das CDA ''content''-Element wird benutzt, um Text ausdrücklich mit Tags „einzurahmen“"einzurahmen", so dass er referenziert werden kann oder bestimmte Möglichkeiten zur visuellen Darstellung genutzt werden können. Das content-Element kann rekursiv ineinander geschachtelt werden, was die Einrahmung von ganzen Texten bis hin zu kleinsten Teilen (Worte, Buchstaben etc.) erlaubt.

Im folgenden Beispiel wird das Textstück „Asthma“ "Asthma" durch das content-Element eingerahmt, so dass in einem möglichen Level 3 Entry darauf Bezug genommen werden kann (siehe „"[[#Zusammenhang_Text_und_Entry|Zusammenhang Text und Entry]]“").

Das ''br''-Element <br/> kann benutzt werden, um im laufenden Text einen „harten“ "harten" Zeilumbruch zu erzwingen. Dies unterscheidet es vom ''paragraph''-Element, da der Zeilenumbruch keinen Inhalt hat. Empfänger sind angehalten, dieses Element als Zeilenumbruch darzustellen.

Zusätzlicher Leerraum (whitespace bzw „no"no-break space“space") kann in CDA erzeugt werden durch & #160; oder & #xA0;

Es erzeugt einen Leerraum von einem Zeichen und entspricht dem in HTML verwendeten, in CDA aber NICHT ERLAUBTEN „"& nbsp;“".

| Procedure|| Prozeduren, Eingriffe, die den Patienten „verändern“"verändern"

* Observation und ObservationMedia (''entryReleationship.typeCode'' = COMP „component“"component")* Observation („Nesselsucht“"Nesselsucht") und Observation („Allergie“"Allergie"), ''entryReleationship.typeCode'' = MFST („Manifestation of“"Manifestation of")

Aus den obigen Beispielen würde das folgende Textfragment durch De-Referenzierung der Referenz „"'''''#disdiag1_diagnosis“disdiag1_diagnosis''''' " gewonnen: „"'''''M25.46, Meniskus: Empyema gen. sin.'''''“".

Hinweis zur erlaubten Größe von Multimedia-Inhalten siehe „"[[#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Größenbeschränkung von eingebetteten Objekten]]“": <br/>

Das folgende Beispiel beschreibt einen eingebetteten Befund, der in der Sektion „Beigelegte Befunde“ "Beigelegte Befunde" angegeben wurde.

Siehe „"[[#Eingebettetes_Objekt_Entry|Eingebettetes Objekt Entry]]“".

Zulässige Werte gemäß Value-Set „"'''ELGA_Medientyp'''“"

==CDA Body in EIS „Basic“"Basic"==Neben den allgemein gültigen Aussagen über den grundsätzlichen Aufbau eines CDA Body, spezifiziert dieser Allgemeine Implementierungsleitfaden auch die Vorgaben, die ein ELGA Dokument in Interoperabilitätsstufe EIS „Basic“ "Basic" erfüllen muss.

Der CDA Body kann unstrukturiert („nonXMLBody“"nonXMLBody") oder strukturiert („structuredBody“"structuredBody") angegeben werden. Die grundsätzlichen Richtlinien von CDA sind einzuhalten.

Siehe „"[[#Allgemeiner_Aufbau_des_CDA_Body|Allgemeiner Aufbau des CDA Body]]“".

Spezielle Leitfäden definieren gegebenenfalls zusätzliche Vorgaben sowohl im administrativen Bereich („CDA Header“"CDA Header") als auch im medizinischen Bereich („CDA Body“"CDA Body"), wie beispielsweise:

* '''low''' („Beginn "Beginn des Problems“Problems")

* '''high''' („Ende "Ende des Problems“Problems")** Gibt den Zeitpunkt an, seit dem die zugrunde liegende Erkrankung nicht mehr besteht ("Zustand nach" oder „status post“"status post"). Wenn es nicht angegeben ist, gilt das Problem als weiterhin bestehend. Wenn bekannt ist, dass das Problem nicht mehr auftritt, dann MUSS ein effectiveTime.high angegeben werden. Wenn das Datum der Lösung nicht bekannt ist, dann wird der nullFlavor "UNK" angegeben.

Bei den nachfolgenden Templates handelt es sich um Compilations oder auch Template-Fragmente, die mehrfach wiederkehrende Teilabschnitte von Templates abbilden. Innerhalb einer Compilation werden keine Template-Id's angegeben, der Typ des Templates ist „nicht spezifiziert“"nicht spezifiziert".

|Vertraulichkeitscode des Dokuments aus ValueSet „ELGA_Confidentiality“"ELGA_Confidentiality"

Änderungen an einem Dokument, das bereits in ELGA registriert wurde, sollen über die Registrierung einer neuen Dokumentenversion in ELGA Eingang finden. Mittels ITI-41/42 Provide and Register DocumentSet wird eine neue Version des Dokumentes geschrieben und die Metadaten der Vorversion auf den Status „deprecated“ "deprecated" gesetzt. In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp „replace“ "replace" (RPLC)).

Falls eine Korrektur des Dokumentes nicht möglich ist, kann ein Dokument auch komplett storniert werden. Dazu wird der Status des Dokumentes via ITI-57 (Metadata Update availability Status) in der Registry auf “deprecated” "deprecated" gesetzt, aber keine neue Dokumentenversion registriert. Ein storniertes Dokument wird daher nicht in der Dokumentliste enthalten sein, sofern nicht spezifische Anfragen gestellt werden, um deprecated-Versionen zu bekommen.

Das ELGA-Berechtigungssystem liefert in erster Linie immer nur jene CDA-Dokumente, die im Status „approved“ "approved" sind. Um Dokumente, die in den Status „deprecated“ "deprecated" gesetzt worden sind zu lesen, müssen spezifische Anfragen (z.B. zeige alle Versionen eines bestimmten Dokumentes) gestellt werden.

Gemäß dem XDS Document-Lifecycle sind neu veröffentlichte Dokument-Metadaten mit dem Status „approved“ "approved" zu versehen. Diese ersetzen die entsprechenden Vorversionen. Technisch wird dabei ein neues Dokument, das in Beziehung vom Typ „replace“ "replace" (RPLC) zur Vorversion steht, erstellt. Auch Ergänzungen zu einem bestehenden Dokument müssen direkt im betroffenen Dokument durchgeführt und anschließend als Folgeversion über die Dokumentenbeziehung „replace“ "replace" (RPLC) abgebildet werden.

====Schematron Assert in allen „Organization Compilation“ "Organization Compilation" Templates ====Das Schematron Assert in allen „Organization Compilation“ "Organization Compilation" Templates und dem "Author" Template ist strenger als sein narrativer Constraint ihn beschreibt. Deswegen wurden das Assert dort jeweils entfernt. Betrifft: Organization Compilation: representedOrganization/telecom