elga-cdaalf-2.06.2:Konzept und Begründung: Unterschied zwischen den Versionen
[unmarkierte Version] | [unmarkierte Version] |
(Die Seite wurde neu angelegt: „==Zweck== Das Ziel dieses Dokuments ist die Beschreibung der Struktur von medizinischen Dokumenten der Elektronischen Gesundheitsakte ELGA (entsprechend ELGA-G…“) |
(→CDA Levels) |
||
Zeile 39: | Zeile 39: | ||
Die Vereinbarungen für die Codierung in den CDA-Levels 2 und 3 werden durch Templates definiert und in Implementierungsleitfäden veröffentlicht. Die CDA-Levels können auf¬einander aufbauend verwendet werden, ein Dokument kann gleichzeitig Informationen in allen drei CDA-Levels enthalten. | Die Vereinbarungen für die Codierung in den CDA-Levels 2 und 3 werden durch Templates definiert und in Implementierungsleitfäden veröffentlicht. Die CDA-Levels können auf¬einander aufbauend verwendet werden, ein Dokument kann gleichzeitig Informationen in allen drei CDA-Levels enthalten. | ||
− | Eine detailliertere Beschreibung der CDA-Levels findet sich in | + | Eine detailliertere Beschreibung der CDA-Levels findet sich in „[[ILF:Allgemeiner Implementierungsleitfaden#CDA_Level_1_bis_3|CDA Level 1 bis 3]]“. |
===ELGA Interoperabilitätsstufen=== | ===ELGA Interoperabilitätsstufen=== |
Version vom 25. Juli 2017, 13:20 Uhr
Inhaltsverzeichnis
1 Zweck
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.
Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA-Elementen. 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):
- Entlassungsbrief (Ärztlich), [OID Root 1.2.40.0.34.7.2]
- Entlassungsbrief (Pflege), [OID Root 1.2.40.0.34.7.3]
- Pflegesituationsbericht, [OID Root 1.2.40.0.34.7.12]
- Laborbefund, [OID Root 1.2.40.0.34.7.4]
- Befund bildgebende Diagnostik, [OID Root 1.2.40.0.34.7.5]
- 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
- ELGA XDS Metadaten (XDSDocumentEntry), [OID Root 1.2.40.0.34.7.6]
2 Grundlagen
Für XML als grundsätzliches Format spricht die Flexibilität nicht nur bei der Länge einzelner darzustellender Texte sondern auch bezüglich der a priori unbegrenzten Möglichkeit, weitere Elemente beliebig tief zu verschachteln. HL7 bezeichnet eine Gruppe von Standards für den Austausch von Daten zwischen Computersystemen im Gesundheitswesen. HL7 wird als Kommunikationsprotokoll vornehmlich zum Datenaustausch zwischen Abteilungssystemen in Krankenhäusern eingesetzt. Mittlerweile wird HL7 in über 50 Ländern eingesetzt. Die ursprünglich in den USA von der Organisation „Health Level Seven International“ (HL7) (http://www.hl7.org) entwickelten Spezifikationen sind im Laufe der Zeit zu einem internationalen Standard geworden, auch dank vieler internationaler Benutzergruppen, die seit langem an der Weiterentwicklung von HL7 mitwirken. Die HL7 Standards in Version 3 sind auf die Kommunikationsbedürfnisse des gesamten Gesundheitswesens abgestimmt. HL7 V3 bietet eine konzeptuelle Grundlage in einem gemeinsamen, umfassenden „Reference Information Model“ (RIM) für alle Teile von HL7 V3. Dieses RIM ist ANSI- und ISO-Standard (ISO/HL7 21731:2006) und bietet:
- ein festes semantisches Fundament
- ausgewählte standardisierte Terminologien, die semantische Interoperabilität ermöglichen
- die Trennung von Inhalten und Syntax
HL7 Version 3 basiert auf XML und wird für die Übermittlung von Nachrichten genutzt. HL7 stellt außerdem einen Standard zur Strukturierung, zum Inhalt und zum Austausch medizinischer Dokumente, die so genannte Clinical Document Architecture (CDA), zur Verfügung. Dabei steht der Informationsaustausch im gesamten Gesundheitswesen im Vordergrund (also nicht beschränkt auf Krankenhäuser). Als Grundlage für ELGA-Dokumente wurde der Standard HL7 Clinical Document Architecture, Release 2.0 ausgewählt. Der Standard kann über die HL7 Anwendergruppe Österreich (http://www.hl7.at) bezogen werden.
3 Feststellung der Konformität
Ein zu diesem Implementierungsleitfaden konformes CDA-Dokument ist zunächst ein valides CDA Release 2.0 XML-Dokument mit Header und Body. Darüber hinaus erfüllt es alle „Geschäftsregeln“ im weiteren Text dieses Dokuments. Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten wieder: 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 modifizierte, generische, offizielle CDA Release 2.0 Schema. 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. Geschäftsregeln für Abschnitte oder Elemente werden auch technisch zu „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.
3.1 CDA Levels
CDA bietet drei verschiedene Varianten, wie Inhalte transportiert werden können; diese Varianten (die so genannten „CDA-Levels“) ermöglichen unterschiedliche Interoperabilität.
„CDA-Level 1“ ist ausschließlich auf die Lesbarkeit durch Menschen ausgelegt. Medizinische Inhalte werden als Text, Bilder oder auch nur als „eingebettetes PDF“ (als unstrukturierter „NonXMLBody“) transportiert.
„CDA-Level 2“ ermöglicht eine Strukturierung der Inhalte nach Abschnitten („Sections“) mit festgelegter Bedeutung, z.B. „Anamnese“, „Diagnosen“. Die Abschnitte sind mit einem ver¬ein-barten Code versehen, der es ermöglicht, dass EDV-Programme diese eindeutig erkennen und als Block verarbeiten können.
„CDA-Level 3“ ist eine Technik zur Anreicherung eines lesbaren Dokuments mit medizinischen Einzelinformationen (z.B. „diastolischer Blutdruck“, „ICD-10 Ent¬lass¬ungs-diagnose“, „Körpergewicht in kg“), die gemäß einer Vereinbarung maschinenlesbar codiert sind und daher automatisch in medizinische Informationssysteme integriert werden können.
Die Vereinbarungen für die Codierung in den CDA-Levels 2 und 3 werden durch Templates definiert und in Implementierungsleitfäden veröffentlicht. Die CDA-Levels können auf¬einander aufbauend verwendet werden, ein Dokument kann gleichzeitig Informationen in allen drei CDA-Levels enthalten.
Eine detailliertere Beschreibung der CDA-Levels findet sich in „CDA Level 1 bis 3“.
3.2 ELGA Interoperabilitätsstufen
Der zukünftige Nutzen von Dokumenten in ELGA hängt von ihrem Strukturierungsgrad ab: Je einheitlicher und strukturierter die Informationen vorliegen, desto besser können die Daten durch EDV-Systeme verarbeitet und ausgewertet werden. Die so genannten „ELGA Interoperabilitätsstufen“ (EIS) definieren eine bestimmte Menge von Vorgaben aus den CDA Levels 2 und 3. Die Mindeststandards für die Datenstruktur der CDA-Dokumente und die Zeitpunkte für die verbindliche Verwendung werden per bundesministerielle Verordnung festgelegt.
- EIS „Basic“ und EIS „Structured“: EIS „Basic“ beschreibt die für alle Dokumente in ELGA verpflichtende Mindeststrukturierung. Dokumente auf dieser Stufe müssen nur die Daten codiert enthalten, die unter anderem für das Dokumentenregister und das Berechtigungssystem unbedingt benötigt werden (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 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).
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.
ELGA Interoperabilitätsstufe „BASIC“ und „STRUCTURED“ | Einheitlicher CDA-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. |
ELGA Interoperabilitätsstufe „ENHANCED“ | Einheitliche Dokumentation (Strukturierung, Gliederung), barrierefreie Darstellung. Minimale Anforderungen an Level-3 Codierung, gemäß den speziellen Leitfäden. |
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. |
Die ELGA Interoperabilitätsstufen beschreiben einen ansteigenden Grad der Strukturierung und Codierung der medizinischen Inhalte unabhängig von CDA-Levels. Die Harmonisierungsgruppen legen aufgrund ihrer fachlichen Expertise fest, welche Inhalte der Dokumente in welcher Form sinnvollerweise strukturiert und codiert werden müssen. Es werden nur Daten codiert, die auch medizinisch relevant sind und die mit einem vertretbaren Umsetzungsaufwand von den IT-Systemen der Gesundheitsdiensteanbieter zur Verfügung gestellt werden können.
Um codierte und damit weiter maschinell verarbeitbare strukturierte Dokumente erzeugen zu können, müssen die IT-Systeme der meisten Gesundheitsdiensteanbieter erst umgestellt werden. Die Anpassungen können in der heterogenen IT-Landschaft der Gesundheitsdiensteanbieter unterschiedlich schnell umgesetzt werden.
Zur koordinierten stufenweisen Einführung von CDA bei den verschiedenen ELGA-Gesundheitsdiensteanbietern werden die „ELGA Interoperabilitätsstufen“ als Zwischenziele definiert.
Neben den im ELGA-Gesetz definierten Dokumentenklassen können zukünftige Dokumentenklassen mit ihrer Struktur und Format für ELGA per Verordnung festgelegt werden. Auch für diese Dokumentenklassen gilt zumindest die unterste Interoperabilitätsstufe „EIS Basic“. Wenn ein CDA Implementierungsleitfaden für die Dokumentenklasse harmonisiert wurde, ist es möglich, Dokumente in den höheren Interoperabilitätsstufen „EIS Structured“, „EIS Enhanced“ und „EIS Full Support“ auszutauschen.
4 Zertifizierung
Das Thema „Zertifizierung“ (etwa die Zertifizierung von Softwaresystemen) wird von diesem Implementierungsleitfaden nicht behandelt.