Änderungen

Wechseln zu: Navigation, Suche

ILF:Allgemeiner Implementierungsleitfaden Templates

275 Bytes hinzugefügt, 16:49, 15. Jan. 2020
Änderung 113812 von Klostermann (Diskussion) rückgängig gemacht.
Implementierungsleitfaden "Allgemeiner Implementierungsleitfaden 2020"
-->
<nowiki>{{#css:
@media screen{
.orange{</nowiki>
border: thin black solid;
background-color:#F4C789;
display: table;
padding: 7px !important;
<nowiki>}
}
}}}</nowiki>
{{Infobox Dokument
{{Infobox Contributors End}}
-->
 
=Zusammenfassung=
{{BeginYellowBox}}
</div></div>
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">==Haftungsausschluss==
<div class="mw-collapsible-content">
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die ELGA GmbH weist ausdrücklich darauf hin, dass es sich bei dem vorliegenden Leitfaden um unverbindliche Arbeitsergebnisse handelt, die zur Anwendung empfohlen werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls unerwünscht und von den Erstellern des Dokumentes nicht beabsichtigt.
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer und Frauen in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
{{ILF:Lizenzinformationen}}
==Verbindlichkeit==Die Verbindlichkeit Mit der ELGA-Verordnung 2015 (in der Fassung der ELGA-VO-Nov-2015) macht die Bundesministerin für Gesundheit und Frauen die Festlegungen für Inhalt, Struktur, Format und Codierung verbindlich, die Umsetzungsfrist dieses Leitfadens ist im Gesundheitstelematikgesetz 2012in den Implementierungsleitfäden Entlassungsbrief Ärztlich, Entlassungsbrief Pflege, Pflegesituationsbericht, Laborbefunde, Befund bildgebender Diagnostik, BGBle-Medikation sowie XDS Metadaten (jeweils in der Version 2.I Nr06) getroffen wurden.111/Die anzuwendende ELGA-Interoperabilitätsstufen ergeben sich aus §21 Abs.6 ELGA-VO. Die Leitfäden in ihrer jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind von der Gesundheitsministerin auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Dokumente für ELGA wird durch das Gesundheitstelematikgesetz 2012 (GTelG 2012 sowie in den ) und darauf fußenden ELGA-Verordnungen geregeltbasierenden Durchführungsverordnungen durch die Bundesministerin für Gesundheit und Frauen vorgegeben.
Der Leitfaden in seiner jeweils aktuell gültigen Fassung sowie Die Verbindlichkeit und 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 Umsetzungsfrist dieses Leitfadens ist im 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“ (M), „Required“ (R) und „Fixed“ (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachenBGBl. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter wwwI Nr.gesundheit.gv.at veröffentlicht werden111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.
Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit Neue Hauptversionen der Rechtsordnung der Republik Österreich Implementierungsleitfäden KÖNNEN ab dem Tag ihrer Veröffentlichung durch die Bundesministerin für Gesundheit und insbesondere mit den relevanten Materiengesetzen Frauen (zwww.Bgesundheit. Ärztegesetz 1998gv.at) verwendet werden, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012spätestens 18 Monate nach ihrer Veröffentlichung MÜSSEN sie verwendet werden. Andere Aktualisierungen (Nebenversionen) zu erfolgendürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzenat veröffentlicht werden.
Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.
==Verwendete Grundlagen und Bezug zu anderen Standards==
Grundlage dieses Implementierungsleitfadens ist Der vorliegende Leitfaden wurde unter Verwendung der internationale Standard "HL7 Clinical Document Architecture, Release 2nachstehend beschriebenen Dokumente erstellt.0" (CDA ©), für die das Copyright © von Health Level Seven International giltDas Urheberrecht an allen genannten Dokumenten wird im vollen Umfang respektiert.
CDA definiert Dieser Standard beruht auf der Spezifikation "HL7 Clinical Document Architecture, Release 2.0", für die Struktur und Semantik das Copyright &copy; von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und PatientenHealth Level Seven International gilt. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen. Das Datenmodell HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von CDA und seine Abbildung Health Level Seven International in XML folgen dem Basisstandard HL7 Version 3 mit seinem Referenzinformationsmodell Österreich bezogen werden (RIMwww.hl7.at). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
*Die Vorgaben für das Österreichische Patient Summary wurden weitgehend aus dem HL7 Leitfaden für das Internationale Patient Summary entlehnt ([http://wwwinternational-patient-summary.net HL7 IPS]).hl7 Dieser Leitfaden beruht auf Inhalten des LOINC&reg; (Logical Observation Identifiers Names and Codes, siehe http://loinc.org). Die LOINC-Codes, Tabellen, Panels und Formulare unterliegen dem Copyright &copy; 1995-2014, Regenstrief Institute, Inc. und dem LOINC Committee, sie sind unentgeltlich erhältlich. Lizenzinformationen sind unter http:/implement/standardsloinc.org/product_briefterms-of-use abrufbar. Weiters werden Inhalte des UCUM&reg; verwendet, UCUM-Codes, Tabellen und UCUM Spezifikationen beruhen auf dem Copyright &copy; 1998-2013 des Regenstrief Institute, Inc.cfm?product_id=7 HL7 Clinical Document Architecture und der Unified Codes for Units of Measures (CDAUCUM)]*[Organization. Lizenzinformationen sind unter http://www.hl7unitsofmeasure.org/implementtrac/standardswiki/product_brief.cfm?product_id=186 Version 3 Product Suite (inklTermsOfUse abrufbar. RIM)]
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (www.hl7.at). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
==Weitere unterstützende Materialien==
Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH ([http://www.elga.gv.at/CDA www.elga.gv.at/CDA]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:
 
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
 
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}
<br />
==Bedienungshinweise==
===Farbliche Hervorhebungen und Hinweise===
''<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>''
{{BeginYellowBox}}
'''<BEISPIEL>'''<br />Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''<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}}
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>
=Einleitung=
==Ausgangslage und Motivation==
'''(vorher Dokumente im Gesundheitswesen)'''
In der medizinischen Welt ist es üblich, klinische Sachverhalte und Beobachtungen mit ihrem Kontext in Dokumente zusammenstellen und 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 „[[ILF:Allgemeiner Implementierungsleitfaden#ELGA_Interoperabilit.C3.A4tsstufen|Interoperabilität]]“ ist unter anderem gekennzeichnet durch das ELGA-Gesetz berechtigten Personengemeinsam verstandene Definitionen, entsprechend ihren Rollenwie zum Beispiel die des Patienten und der zu ihm bekannten klinischen/medizinischen Informationen, den Zugriff auf relevante Gesundheitsdaten, die in bedarfsgerecht elektronisch aufbereiteter Form online zur Verfügung gestellt werdensowie deren Wiederverwendbarkeit.
Die zentrale Anwendung von ELGA ==Zweck des Dokuments==Ziel dieses Implementierungsleitfadens ist die Bereitstellung Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (e-BefundeGTelG 2012) der ELGA-Teilnehmer, die in vielen unterschiedlichen Informationssystemen der verschiedenen ELGA-Gesundheitsdiensteanbieter erstellt werden. Diese Dokumente sollen nicht nur von Benutzern gelesen, sondern aber 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 werdenmedizinische Dokumente im österreichischen Gesundheitswesen.<br/>
Die Elektronische Gesundheitsakte Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich und insbesondere mit den relevanten Materiengesetzen (ELGA) ermöglicht den durch das ELGA-Gesetz berechtigten Personenz.B. Ärztegesetz 1998, entsprechend ihren RollenApothekenbetriebsordnung 2005, den Zugriff auf relevante Gesundheitsdaten der ELGAKrankenanstalten-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 gelesenKuranstaltengesetz, sondern auch wieder in die ITGesundheits-Systeme integriert und dort weiterverwendet werden können („Semantische Interoperabilität“Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012)zu erfolgen. Beispielsweise Technische Möglichkeiten können für gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Arzt aus ELGA-Dokumenten automatisch Warnungen, Erinnerungen und Zusammenfassungen generiert und weitere Informationen berechnet sowie kontextbezogen angezeigt werdenGesetzen zu nutzen.<br/>
==(vorher unter '''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 Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 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 folgenElementen.
'''TODO: Neue Version von 2Der vorliegende „Allgemeine Implementierungsleitfaden für CDA-Dokumente“ stellt eine grundlegende Implementierungsvorschrift für alle CDA-Dokumente im österreichischen Gesundheitswesen dar.06, Hinweis auf RevisionslisteDieser Vorschrift haben alle über ELGA vermittelten CDA-Dokumente im österreichischen Gesundheitswesen zu folgen.'''
Darüber hinaus kann auf Basis des vorliegenden allgemeinen Implementierungsleitfadens ein spezieller Implementierungsleitfaden definiert sein (z.B. Entlassungsbrief, Laborbefund, etc.).
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.
 
==Ausgangslage und Motivation==
Die Elektronische Gesundheitsakte (ELGA) ermöglicht den vom 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.
 
Um dieses Ziel zu erreichen, wird für Dokumente in ELGA der internationale Standard „Clinical Document Architecture, Release 2.0“ (CDA) von HL7 eingesetzt.
 
Der [[ILF:Allgemeiner Implementierungsleitfaden#CDA_Standard|CDA-Standard]] wird 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.
=Leitfadenerstellungs- und Harmonisierungsprozess=
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.
==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
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).
===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===
Dafür gilt zudem:
 *Es muss einen eindeutig festgelegten Weg für einen Empfänger geben, den authentisierten Inhalt sichtbar zu machen<sup>2</sup>.*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.
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 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 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="text-align:left" 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="text-align:left" 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="text-align:left" 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.
|-
|}
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.
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.
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“, ...).
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==
{| 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.
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.
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}}
Sollten derartige Elemente oder Attribute im CDA-Dokument vorhanden sein, soll weiterverarbeitende Software so implementiert sein, dass dies nicht zu Fehlern in der Weiterverarbeitung der Dokumente führt.
===Umgang mit Ausnahmen bei der Konformitätsprüfung===
Nur Elemente, die im „Maximum-Set“ beschrieben sind, können zuverlässig geprüft werden. „Fremde“ Elemente oder Attribute<sup>4</sup> werden daher von den Konformitätsprüfmechanismen im Sinne der „closed templates“ grundsätzlich als falsch erkannt. Selbst die genannten Ausnahmen, v.a. zusätzliche Entries oder TemplateIds, können daher falsche Fehlermeldungen auslösen. Diese Ausnahmen sollten entsprechend nur, wenn unbedingt notwendig und mit Vorsicht eingesetzt werden.
==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]].
==Header Level Templates==
===Document Realm ===
{{:1.2.40.0.34.6.0.11.1.10/dynamic}}
===typeId===
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}}
===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.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}}
===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===
===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===
3.869
Bearbeitungen

Navigationsmenü