Bundeseinheitlicher Antrag auf Anschlussrehabilitation
| Zeile 1: | Zeile 1: | ||
{{Underconstruction}} | {{Underconstruction}} | ||
| + | |||
<!-- | <!-- | ||
Implementierungsleitfaden "Bundeseinheitlicher Antrag auf Anschlussrehabilitation" | Implementierungsleitfaden "Bundeseinheitlicher Antrag auf Anschlussrehabilitation" | ||
| Zeile 19: | Zeile 20: | ||
|Realm = Deutschland | |Realm = Deutschland | ||
}} | }} | ||
| + | <!-- | ||
{{Infobox Ballot Begin}} | {{Infobox Ballot Begin}} | ||
| − | {{Ballot | Version = | + | {{Ballot | Version = 0.91 | Date = 15.10.2014 | Status = Abstimmung | Realm = Deutschland | Othericon = x |
| − | + | | Otherdocuments = http://download.hl7.de/documents/cdar2-arztbrief/Arztbrief2014-v091.pdf | |
| − | + | | Comment = | |
| − | {{Ballot | + | }} |
| + | {{Infobox Ballot End}} | ||
--> | --> | ||
| − | |||
{{Infobox Contributors Begin}} | {{Infobox Contributors Begin}} | ||
| Zeile 31: | Zeile 33: | ||
{{Infobox Contributors End}} | {{Infobox Contributors End}} | ||
| + | =Dokumenteninformationen= | ||
| + | {{HL7transclude| cdaab2:Impressum}} | ||
| + | {{HL7transclude| cdaab2:Ansprechpartner}} | ||
| + | {{HL7transclude| cdaab2:Disclaimer}} | ||
| + | {{HL7transclude| cdaab2:Autoren}} | ||
| + | {{HL7transclude| cdaab2:Danksagung}} | ||
| + | {{HL7transclude| cdaab2:Einleitung}} | ||
| + | {{HL7transclude| cdaab2:Grundlagen}} | ||
| + | {{HL7transclude| cdaab2:Konzept-Modellbeschreibung}} | ||
| + | {{HL7transclude| cdaab2:Template-Konzept}} | ||
| + | {{HL7transclude| cdaab2:Konformität}} | ||
| + | {{HL7transclude| cdaab2:Optionalität}} | ||
| + | {{HL7transclude| cdaab2:Transportaspekte}} | ||
| + | {{HL7transclude| cdaab2:struktureller Aufbau}} | ||
| + | |||
| + | |||
| + | |||
| + | =Dokumenteninformationen= | ||
| + | ==Dokumentenhistorie== | ||
<!-- | <!-- | ||
| + | {{:Ballotbox_Arbeitsunfähigkeitsbescheinigung}} | ||
| + | --> | ||
| + | {{HL7transclude| cdaaar:Impressum}} | ||
| + | |||
| + | ==Ansprechpartner und Autoren== | ||
| + | * Ralf Franke, gevko GmbH (Projektleitung) | ||
| + | * Dr. Jens Schmidt. gevko GmbH (Projektmanagement) | ||
| + | {{HL7transclude| cdaaar:Disclaimer}} | ||
| + | |||
| + | <!-- | ||
| + | {{NoteBox| | ||
| + | Disclaimer | ||
| + | Da die GKV-SV und die KBV derzeit noch keine Vorgaben getroffen und Entscheidungen gefällt haben, wie eine digitale Umsetzung der Arbeitsunfähigkeitsbescheinigung erfolgen soll, darf dieser Implementierungsleitfaden nicht als solcher, durch die GKV-SV/KBV bestätigter Leitfaden aufgefasst werden. Die Nutzung der digitalen Umsetzung der Arbeitsunfähigkeitsbescheinigung im kollektivertraglichen ambulanten Bereich ist deshalb derzeit nicht möglich. Die im vorliegenden Leitfaden beschriebene Umsetzung der eAU ist zudem nicht interoperabel zu der von KBV und GKV-SV vorgegebenen Umsetzung bestehender digitaler Muster. Die von GKV-SV und KBV vorgegebene Umsetzung basiert auf dem ISO-Standard 19005 (PDF/A). Dieser Implementierungsleitfaden ist daher nicht geeignet, die eAU als digitales Muster gemäß BMV-Ä umsetzen. | ||
| + | |||
| + | Das primäre Ziel dieses Leitfadens ist zu demonstrieren, dass eine standardbasierte Umsetzung möglich ist. Rückmeldungen aus der Industrie legen nahe, dass diese Form einer elektronischen Fassung gegenüber einer PDF-basierten favorisiert wird. Deshalb wird der Fokus auf eine Spezifikation der fachlichen Inhalte und nicht auf begleitende Fragestellungen wie Transport oder Signatur (QES) gelegt. Für letztere werden Zusatzspezifkationen benötigt, die nicht Gegenstand dieses Leitfadens sind. | ||
| + | }} | ||
| + | --> | ||
| + | |||
{{HL7transclude| cdaaar:Einleitung}} | {{HL7transclude| cdaaar:Einleitung}} | ||
{{HL7transclude| cdaaar:Grundlagen}} | {{HL7transclude| cdaaar:Grundlagen}} | ||
| Zeile 53: | Zeile 92: | ||
== Referenzen == | == Referenzen == | ||
| − | |||
<references/> | <references/> | ||
== Abbildungen == | == Abbildungen == | ||
<references group="Abbildung"/> | <references group="Abbildung"/> | ||
| + | |||
[[Kategorie:IG]] | [[Kategorie:IG]] | ||
[[Kategorie:cdaaar|Implementierungsleitfaden]] | [[Kategorie:cdaaar|Implementierungsleitfaden]] | ||
Version vom 30. September 2019, 06:57 Uhr
 |
This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template. This article was last edited by JSchmidt (talk| contribs) 4 years ago. (Purge) Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage. This article was last edited by JSchmidt (talk| contribs) 4 years ago. (Purge) |
 |
Dieses Dokument gibt wieder:
Implementierungsleitfaden Bundeseinheitlicher Antrag auf Anschlussrehabilitation (0.1). Die Teilmaterialien gehören der Kategorie cdaaar an. |
auf Basis der HL7 Clinical Document Architecture Release 2
für das deutsche Gesundheitswesen
HL7 Deutschland e. V. und gevko GmbH
| Version: | 0.1 |
| Datum: | 19. September 2019 |
| Status: | initial |
| Verfahren: | Standard zur Probe (STU) |
| Realm: |  Deutschland
|
| Kontributoren | ||
|---|---|---|
|
gevko GmbH | Bonn |
Inhaltsverzeichnis
- 1 Dokumenteninformationen
- 2 Einleitung
- 3 Grundlagen
- 4 CDA Release 2 – Konzept und Modellbeschreibung
- 5 Transportaspekte
- 6 Rechtssichere Übertragung
- 7 Struktureller Aufbau
- 8 Dokumenteninformationen
- 9 Einleitung
- 10 Anhang
- 11 Anhang
Dokumenteninformationen
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Impressum
Dieser Leitfaden ist im Rahmen des Interoperabilitätsforums und den Technischen Komitees von HL7 Deutschland e. V. sowie der entsprechenden Projektgruppen zusammengestellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums[1] und der Technischen Komitees von HL7 Deutschland e. V. [2]
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Ansprechpartner
- Dr. Kai U. Heitmann, HL7 Deutschland e.V., Heitmann Consulting and Services
- Dr. Frank Oemig, Agfa HealthCare GmbH, Bonn
- Mathias Aschhoff, ZTG GmbH, Bochum
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Disclaimer
 |
Disclaimer
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Autoren
- Dr. Kai U. Heitmann (KH), Heitmann Consulting and Services, Hürth
- Dr. Frank Oemig (FO), Agfa HealthCare GmbH, Bonn
- Daniel Hellmuth (DH), Cerner Deutschland GmbH, Berlin
- Mathias Aschhoff (MA), ZTG Gmbh, Bochum
Mit Beiträgen von
- Jürgen Brandstätter, HL7 Austria
- Dr. Rainer Fehling, Kassenärztliche Vereinigung Westfalen-Lippe
- Dr. Erich Gehlen, DURIA e.G.
- Dr. Christof Gessner, gematik
- Dr. Christian Herrmann, KRH Klinikum Region Hannover
- Michael Hofer, iSOFT Health GmbH
- Tarik Idris, InterComponentWare AG
- Dr. Stefan Sabutsch, HL7 Austria
- Dr. Norbert Sigmond, DIMDI
- Prof. Dr. Martin Staemmler, FH-Stralsund
- Prof. Dr. Sylvia Thun, HS Niederrhein
- Lars Treinat, ZTG GmbH
Copyright-Hinweis, Nutzungshinweise
Die erste Version dieses Dokumentes wurde 2005 vom Verband der Hersteller von IT für das Gesundheitswesen (VHitG, heute bvitg) entwickelt und ist unter dem Namen "VhitG-Arztbrief" bekannt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.
Der Inhalt dieser Spezifikation ist öffentlich.
Der VHitG-Arztbrief basiert auf den Spezifikationen der Arbeitsgemeinschaft SCIPHOX GbR mbH und dem national adaptierten HL7-Standard der „Clinical Document Architecture (CDA)".
Die hier erarbeitete Fassung ist die Weiterentwicklung davon. Sie ist u.a. auch abgeglichen mit den ELGA-Spezifikationen (http://elga.gov.at) in Österreich.
Näheres unter http://www.hl7.de und http://www.hl7.org. Für alle veröffentlichten Dateien mit einem CDA-Bezug gilt ferner: Alle abgestimmten und veröffentlichten Spezifikationen wie Implementierungsleitfäden, Stylesheets und Beispieldateien sind frei verfügbar und unterliegen keinerlei Einschränkungen, da die Autoren auf alle Rechte, die sich aus der Urheberschaft der Dokumente ableiten lassen, verzichten.
Alle auf nationale Verhältnisse angepassten und veröffentlichten CDA-Schemas können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
Aus der Nutzung ergibt sich kein weiter gehender Anspruch gegenüber dem VHitG bzw. bvitg, zum Beispiel eine Haftung bei etwaigen Schäden, die aus dem Gebrauch der Spezifikationen bzw. der zur Verfügung gestellten Dateien entstehen.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Danksagung
Wir danken besonders den folgenden Organisationen und Projekten.
Bundesverband der Hersteller von IT-Lösungen für das Gesundheitswesen, e.V. , Berlin
eBPG-Projekt (electronic Business Plattform im Gesundheitswesen), NRW
Konsortialprojekt eBusiness-Plattform Gesundheitswesen (Förderkennzeichen 005-GW01-038C)
Arbeitspaket AP04: Einrichtungsübergreifende elektronische Patientenakte (eEPA)
Gefördert von der EU und dem Land NRW:
Deutscher Hausärzteverband e.V., Köln
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Einleitung
Motivation
Dieser Leitfaden soll als generische Grundlage für Arztbriefe aller Art dienen und damit die Ablösung der papiergebundenen Arztbriefe ermöglichen. Entsprechende Anwendungsbeispiele finden sich im Anhang dieses Leitfadens und dienten als Grundlage für die Vollständigkeit der Analyse.
Im Rahmen der Kommunikation zwischen Akteuren im Gesundheitswesen ist der Arztbrief als „Kondensat ärztlichen Handelns" von überragender Bedeutung. Das Ziel dieses Dokuments ist die Beschreibung des elektronischen Arztbriefs. Ein derartiger Arztbrief enthält die medizinisch relevanten Teile der Geschichte eines Patienten über einen bestimmten Zeitraum und ist gedacht zur Übermittlung zwischen Gesundheitsdienstleistern (primär: „Leistungserbringer"). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA-Elementen.
Zielgruppe
Der Leserkreis dieses Dokuments sind Software-Entwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld des „Arztbriefs" betraut sind.
Diese Spezifikation definiert zusätzliche Festlegungen, Einschränkungen und Bedingungen für die CDA-Elemente in „Arztbrief"-Dokumenten, die als „stationärer Entlassbrief" von Kliniken im Bereich deutscher Gesetzgebung (SGB) an Niedergelassene (auch: REHA-Einrichtungen) oder als „(Fach ) Arztbrief" vom niedergelassenen (Fach )Arzt an niedergelassene Kollegen oder Krankenhäuser versendet werden sollen.
Beispiele für konforme Dokumenten-Fragmente werden innerhalb dieses Leitfadens aufgeführt. Die Spezifikation von Infrastrukturen, Workflows, Nachrichten, Prozeduren oder Protokollen zur Übermittlung der Arztbriefe ist nicht im Fokus dieses Dokuments.
Ein elektronischer Arztbrief wird vom Gesetzgeber nach §291a ff. SGB V im Rahmen der Einführung der elektronischen Gesundheitskarte als freiwillige Anwendung betrachtet. Es ergeben sich mit Einführung einer nationalen Telematikinfrastruktur verschiedene Vorgaben für einen solchen Arztbrief, die in diesem Implementierleitfaden nicht umfänglich dokumentiert sein sollen. An den nötigen Stellen wird versucht, Hinweise auf relevante Implikationen und Überschneidungen zu geben.
Dokumente im Gesundheitswesen
Wir sind es in der medizinischen Welt gewohnt, eine Dokumentenansicht von medizinischen Beobachtungen zu verfassen, reich an Text, den Zusammenhang des Geschehens zusammenstellend und zusammenfassend. Dieser Kontext – z. B. das Ergebnis einer Laboruntersuchung im Lichte einer speziellen Medikamentenbehandlung – muss dauerhaft erhalten bleiben, da er wichtige medizinische Zusammenhänge zwischen Einzelinformationen darstellt. Die Krönung dieses „in den Kontext stellen" von Informationen über die Zeit stellt zum Beispiel der Arztbrief dar. 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 Benutzern, den Ärzten und Pflegekräften. Mit der heutigen Papierwelt wurde dies bis zu einem gewissen Grade erreicht, es muss aber für das Einführen des elektronischen Gegenstücks ebenso gelten. „Interoperabilität" ist unter anderem gekennzeichnet durch gemeinsam verstandene Definitionen, wie zum Beispiel die des Patienten und der zu ihm bekannten (klinischen/medizinischen) Informationen, sowie deren Wiederverwendbarkeit. Hierbei kann man zwei Gegenpole beobachten. Zum einen ist da die Facette der Mensch-zu-Mensch Kommunikation. Dies wird z. B. erreicht durch das Versenden von Papier und Formularen. Jeder weiter führende elektronische Ansatz muss auch diese Art der Interoperabilität gewährleisten. Die Möglichkeit zur Signatur muss auch in elektronischer Form bestehen bleiben. Darüber hinausgehend wäre das andere Ende die Anwendungs-Interoperabilität. Dies beinhaltet die Wiederverwendbarkeit von Informationen, Kontext-abhängige Analysemöglichkeiten und angemessenes Speichern und Verwalten von klinischen Dokumenten.
Im Rahmen der bvitg-Initiative „Intersektorale Kommunikation" wird der Arztbrief als generisches Dokument beschrieben. So wird beispielhaft die Entlassung nach durchgeführter Behandlung in einem Krankenhaus o. ä. zur Weiterbehandlung durch den Niedergelassenen (Dokument „stationärer Entlassungsbrief") definiert, wie auch der ambulante Arztbrief des Facharztes zur Weiterbehandlung über den Hausarzt oder im Krankenhaus.
Im Falle der Entlassung/Ende der Behandlung werden die Behandlungsdaten übermittelt. Der Kurzbericht bei Entlassung/Behandlungsende ist als sofortige Mitteilung an den einweisenden/überweisenden Arzt am Ende der Konsultation/Krankenhausaufenthaltes konzipiert und beinhaltet neben der Patientenidentifikation einen Kurzbericht zusammen mit Diagnosen und Therapien, Befunden sowie eine Zusammenfassung. Beispiel: Termine zur Wiedervorstellung oder Nachsorgetermine.
In einer späteren Ausbaustufe kann mit überwiegend den gleichen Teilen wie im Arztbrief auch die Einweisung/Überweisung definiert werden. Das dahinterliegende Szenario: Der Patient geht vom Niedergelassenen in ein Krankenhaus zur Mitbehandlung (Dokument „Einweisung") bzw. wird von einem Niedergelassenen zum anderen überwiesen (Dokument „Überweisung").
Diese Fälle werden allgemein teilweise von den Komponenten im „Arztbrief" abgedeckt, wie zum Beispiel: Aktuelle Medikation, die auch in Ein-/Überweisungen vorkommen kann. Beim Arztbrief handelt es sich dementsprechend um ein Dokument, das in Anlehnung an die realen Gegebenheiten zwischen den Akteuren und Systemen ausgetauscht wird und das dauerhaft existiert, d.h. es wird dauerhaft gespeichert. Dies steht im Gegensatz zum Austausch von Nachrichten, bei dem der Nachrichten-Inhalt vom Empfangssystem in der Regel extrahiert, in der eigenen Datenbank gespeichert und die Nachricht als solche danach gelöscht wird.
Abgrenzung
Dieser Leitfaden deckt eine Reihe von Themen nicht ab. Dazu gehören:
- dieser Leitfaden beschreibt den Arztbrief (Discharge summarization note [physician], LOINC-Code 11490-0); andere Dokumententypen wie z. B. OP-Berichte sind hiermit nicht beschrieben (aber dem Prinzip nach gleich aufgebaut).
- digitale Signatur und andere Sicherheitsaspekte wie Verschlüsselung etc.; der geneigte Leser möge hierzu auch die Ausarbeitung zu XML-Signaturen für CDA (Elektronische Signatur von Arztbriefen)[3] konsultieren.
- Transport von CDA-Dokumenten
- Verwendung von Stylesheets
Hilfreich ist in diesem Zusammenhang das IHE-Cookbook[4].
Aufbau dieses Implementierungsleitfadens
Die Spezifikation Arztbrief 2014 basiert auf dem VHitG-Arztbrief von 2006 (v1.5)[5] und berücksichtigt hierbei die neueren Entwicklungen und Methodiken zur Erstellung von Leitfäden, beispielsweise die Nutzung von Templates oder speziellen Ausprägungen von Datentypen.
Dieser Implementierungsleitfaden verfolgt drei Ziele. Neben dem grundlegenden Konzept und dessen Begründung sollen die zugrunde liegenden Modelle ausführlich beschrieben werden, die für die Kommunikation genutzt werden. Aus ihnen leiten sich die Nachrichten/Dokumente in ihrem Aufbau und ihrer Semantik ab. Gleichzeitig können die Modelle Hinweise liefern für den Aufbau von Datenbanken oder Anwendungssystemen, die in diesem Kommunikationsszenario als Sender oder Empfänger fungieren.
Zum dritten soll dieser Leitfaden praktische Implementierungshilfen geben. Dies kann bis zu einem gewissen Detaillierungsgrad geschehen und ist in der Regel mit Beispielen angereichert, so dass ein Programmierer einer Schnittstelle das nötige Wissen erlangen kann, wie die Schnittstelle aufzubauen ist. Auf dieser Basis werden schließlich die tatsächlichen Informationsinhalte beschrieben und die Beziehung an die entsprechenden Klassen und Attribute im Modell aufgezeigt. Daraus folgen dann Dokumente und zugehörige Beispiele.
Zudem sind in diesem Leitfaden einige Anhänge aufgenommen, die als Referenzmaterial dienen können und Hinweise geben für eine erfolgreiche Implementierung.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Grundlagen
HL7 Version 3 Referenz-Modell als Grundlage für CDA
Grundlage des Clinical Document Architecture (CDA) ist ein umfangreiches Objektmodell, das sogenannte Reference Information Model (RIM).
Allen Modellen bei HL7 Version 3 liegt das so genannte Referenz-Informations-Modell (RIM) zugrunde. Es beschreibt generisch zum Beispiel einen Behandlungsprozess. Dabei wird von einer Aktivität (Act) ausgegangen, an der Entitäten (z. B. Personen) in bestimmten Rollen (Arzt, Patient, Angehöriger) teilnehmen (Participation). Aktivitäten können miteinander in Beziehung (Kontext) stehen (Act Relationship), beispielsweise eine Laboranforderung und das daraus folgende Resultat. In der folgenden Abbildung sind die Basisklassen des RIM wiedergegeben. Darunter sind im Gesamt-RIM natürlich noch Spezialisierungen der Klassen zu finden. So ist eine Diagnose ein Sonderfall einer Beobachtung, diese wiederum eine Aktivität.
[Abbildung 1]RIM Basisklassen
Diese Basisklassen erfahren - als Beispiel - folgende Spezialisierungen, die auch in diesem Leitfaden verwendet werden:
- entity
- Person
- Organisation
- Gerät
- role
- beabsichtigter Empfänger
- verwaltende Organisation
- Pate
- ...
- participation
- Patient
- Autor
- Informant
- sonstiger Beteiligter
- Hausarzt
- ...
- act
- Beobachtung
- Diagnose
- Maßnahme
- ..
- Beobachtung
HL7 CDA basiert komplett auf HL7 Version 3, so dass dessen Verständnis hilfreich ist.
Vorgehensweise
Diese Spezifikation basiert auf den umfangreichen Diskussionen innerhalb der Arbeitsgruppe „Intersektorale Kommunikation" und wurde ergänzt durch Einschränkung bzw. Konkretisierung bestehender nationaler und internationaler Implementierungsleitfäden, namentlich
- „Sciphox Arztbrief" (gemäß WD 15)[6]
- HL7 v3 , CDA Rel. 2 „CDA Care Record Summary Implementation Guide"[7]
- Use Cases for Medical Summaries, L. McNight, IHE PCC, 2005[8]
- Der französische „Guide d’implémentation du Volet Médical au format CDA Release 2 – Niveau 3"[9]
- e-MS. Implementierungsleitfaden CDA (Level 2 und 3), Kanada[10]
- IHE Laboratory Technical Framework, Supplement „Sharing Laboratory Reports (XDS-LAB)"[11]
- CDA-Leitfäden der ELGA GmbH, Wien (Österreich)[12]
- CDA-Leitfäden von HL7 Schweiz
und schließlich als Zusatzdokument mit entsprechenden Mechanismen formal festgelegt.
Als Fernziel sei auch der Einsatz von HL7-Tools erwähnt, mit dem derartige Festlegungen auch automatisch aus formalen Ausdrücken der CDA Refined Message Information Model (R-MIM) Constraints abgeleitet werden können. Der dazu benötigte HL7-Template-Formalismus - derzeit noch als Teil von HL7v3 in Entwicklung – wird einen eindeutigen Generierungspfad vom Reference Information Model (RIM) bis zu den Validierungsausdrücken und Constraints festlegen. Damit könnten Schemata algorithmisch aus den modell-bezogenen Templates auf die gleiche Weise generiert werden, wie auch das allgemeine CDA-Schema aus seinem R-MIM generiert wurde.
Die Festlegungen in diesem Dokument werden formal durch XSD-Schemas formuliert. Die Schemas sind originaler CDA Release 2 Standard.
Zertifizierung
Die Verwendung des Implementierungsleitfadens in Softwareprodukten ist grundsätzlich frei von jeglicher Zertifizierung.
Stabilität der verwendeten Standards
Standards in der Medizin, so auch Kommunikationsstandards, entwickeln sich kontinuierlich weiter, um den ständig ändernden Anforderungen gerecht zu werden. Allerdings ist eine kontinuierliche Weiterentwicklung in Bezug auf reale Implementierungen nicht handhabbar.
Deshalb wählt man zu einem gegebenen Zeitpunkt, im Sinne einer Momentaufnahme, die zu verwendenden Standards aus und „friert" diesen für eine Zeit lang ein. Das heißt für diesen Leitfaden, dass in Bezug auf die verwendeten Standards stabile Verhältnisse für etwa zwei Jahre zu erwarten sind.
HL7 konstatiert zudem die Möglichkeit, dass Versionen, die zum Beispiel auf unterschiedlichen Implementation Technology Specifications (ITS) beruhen, durch „einfache" Transformationen (z. B. mittels XSLT) ineinander überführbar sind.
CDA Release 2 (CDA R2) ist ANSI Standard seit Mai 2005. Dieser Leitfaden fußt auf ANSI/HL7 CDA R2-2005, derweil gehen die Entwicklungen bei CDA weiter, So ist derzeit (Sommer 2014) das Release 2.1 in Vorbereitung, eine verbesserte und leicht ergänzte Version von CDA R2. Viele (insbesondere internationale) Spezifikationen basieren auf CDA (zum Beispiel IHE PCC, ELGA, CDA-CH2). Implementierungen (so auch die auf diesem Leitfaden basierten) liefern kontinuierlich Verbesserungsvorschläge. So wurde in diesem Leitfaden auch intensiv Gebrauch vom Templatemechanismus gemacht, welcher insbesondere Entwicklern zugute kommt. In Summa kann festgehalten werden, dass damit CDA R2 der erfolgreichste HL7 Version 3 Standard ist.
Die verwendeten Datentypen sind mit den Festlegungen in „XML Implementation Technology Specification - Data Types Release 1" schon länger ANSI Standard (seit der Jahreswende 2004/05). Diese sind auch im Leitfaden "HL7 Version 3 Datentypen und CMETs Leitfaden für das Deutsche Gesundheitswesen" veröffentlicht.
Bezug zum HL7 Version 3 Nachrichtenaustausch
Das CDA-Informationsmodell stellt eine Beschreibung für die Nutzinhalte von medizinischen Dokumenten zur Verfügung. Dabei wird aber explizit kein Hinweis auf den elektronischen Informationsaustausch von CDA-Dokumenten gegeben.
Von Seiten HL7 wird dieses durch die Einbeziehung in das Nachrichtenkonzept von HL7 Version 3 vollzogen, insbesondere die abstrakten Transmission Informationen (Wrapper-Konstrukte) und weitere Infrastrukturelemente (u. a. Control Acts).
Damit ist eine Use-Case abhängige Koexistenz von medizinischen Dokumenten und Nachrichten-Konzepten sowie konkrete Einbindbarkeit von CDA in Nachrichtenabläufe gegeben. Dies stellt aus HL7-Sicht einen wichtigen Eckpfeiler für einen effizienten Austauschstandard im Gesundheitswesen dar.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
CDA Release 2 – Konzept und Modellbeschreibung
CDA und XML
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 nicht begrenzten Schachtelungstiefe von Elementen.
HL7 als IT-Standard im Gesundheitswesen ist vornehmlich in Krankenhäusern verbreitet und wird zum Datenaustausch zwischen Abteilungssystemen eingesetzt. Der ursprünglich aus Amerika stammende Ansatz ist im Laufe der Zeit zu einem international einsetzbaren Standard geworden, auch dank vieler internationaler Benutzergruppen, die seit langem an der Weiterentwicklung von HL7 mitwirken. Mittlerweile wird HL7 in vielen Ländern konkret eingesetzt, ist in manchen Ländern sogar offizielle Norm. Dennoch wurde HL7 in Deutschland im niedergelassenen Bereich oder in der ambulant-stationären Kommunikation bisher nicht umgesetzt.
Zwischenzeitlich ist von der HL7-Organisation der Standard „HL7 v3" international entwickelt und anerkannt worden (bzw. abhängig von den Anwendungsdomänen noch in Verabschiedung und Anerkennung). 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
- ein festes semantisches Fundament in explizit definierten Konzept-Domänen
- ausgewählte standardisierte Terminologien, die in den Domänen semantische Interoperabilität garantieren
- die Trennung von Inhalten und Syntax (wenngleich die Verwendung bestimmter Elementnamen vor allem im Header eine gewisse Semantik suggerieren)
- eine technologie-unabhängige Entwurfsmethodik.
HL7 v3 basiert auf XML und wird genutzt für die Übermittlung von Nachrichten. HL7 stellt außerdem einen Standard zur Strukturierung, zum Inhalt und zum Austausch medizinischer Dokumente, der so genannten Clinical Document Architecture (CDA), zur Verfügung. Dabei steht der Informationsaustausch im gesamten Gesundheitswesen im Vordergrund, ist also nicht beschränkt auf Krankenhäuser. Als Grundlage für die Dokumente wurde HL7 Version 3 CDA Release 2 gewählt.
CDA Standard
Die Clinical Document Architecture[13] ist ein Standard für den Austausch und die Speicherung von klinischer Dokumentation, wie zum Beispiel ein Entlassbrief oder eine Überweisung, Behandlungsdokumentation oder OP-Berichte. Dabei wird die Extensible Markup Language XML[14] benutzt. CDA wird entwickelt von HL7 (Health Level Seven), einer bedeutenden internationalen Organisation für die Entwicklung von IT-Standards für das Gesundheitswesen.
CDA ist eine Entwicklung innerhalb der HL7-Gruppe seit 1997 und stellt einen XML-basierten Dokumenten-Markup Standard zur strukturierten klinischen Dokumentation zur Verfügung. Es definiert ein Informationsobjekt, das außerhalb einer Nachricht existieren kann und neben (strukturiertem) Text auch Bilder, Töne, Biosignale usw. enthalten bzw. referenzieren kann. CDA ist Teil der so genannten „Familie" der HL7 Version 3 Standards. Die erste Version, CDA Release 1, konnte bereits im September 2000 als offizieller Standard verabschiedet werden (CDA Level One ANSI/HL7 CDA R1.0-2000). Damit galt CDA R1 als erster offizieller XML-basierter Standard im Gesundheitswesen. Mittlerweile wird Release 1 in unzähligen Projekten rund um die Welt genutzt. Auf zwei internationalen Konferenzen 2002 und 2004 wurden die verschiedenen Projekte dargestellt (siehe Proceedings[15] [16]). Die Erfahrungen und weiter gehende Bedürfnisse sind in die Entwicklung von CDA Release 2 eingegangen.
CDA Release 2 als Fortentwicklung dieses Standards wurde, nach beinahe fünf Jahren weiterer Entwicklungsarbeit am Standard, im Juli 2005 zum ANSI Standard erhoben. In diese Entwicklungen sind zahlreiche Erfahrungen aus weltweit mehr als 15 größeren, teilweise nationenweiten Projekten eingeflossen, die sich intensiv um CDA Release 1 und der Weiterentwicklung verdient gemacht haben. Basierend auf dem HL7 Referenz-Informationsmodell (siehe oben) besteht CDA Release 2, grob gesprochen, aus Tags/Markup, die Semantik bereitstellen für Personen und Dokumenteneigenschaften (z. B. <patient>, <provider>, <authenticator>, etc.) und für die Abbildung von Dokumentenstrukturen und -hierarchien genutzt werden können (z. B. <section>, <paragraph>, <table>, etc.).
Der Name für dieses Konzept änderte sich – aus der ursprünglichen Kona-Architektur wurde die Patient Record Architecture und dann schließlich die Clinical Document Architecture – aber die Ideen dieser Architektur sind gleich geblieben.
Ein wichtiges Konzept in CDA ist das der Level, die a.a.O. weiter erläutert werden (siehe unten in diesem Leitfaden).
Eigenschaften von CDA Dokumenten
Im Standard werden sechs Kerneigenschaften definiert, die ein klinisches Dokument nach CDA kennzeichnen. Diese seien hier im Folgenden eingehender erläutert.
Persistenz
CDA Dokumente sind Persistenz, das heißt dauerhaft Existent in den sendenden oder empfangenden Systemen. Dies kennt man auch aus der Papierwelt (klinische Dokumentation hat „Dokumenten-Charakter").
Verantwortlichkeit für die Verwaltung des Dokuments
Eine Organisation ist verantwortlich für die Verwaltung eines CDA Dokuments.
Signaturfähigkeit
Ein CDA Dokument ist durch Informationen gekennzeichnet, die potentiell signiert werden können bzw. zur vor dem Gesetz gültigen Signatur benutzt werden können. (vgl. [3])
Kontext
Alle Informationen werden in Dokumenten in einen bestimmten Kontext gestellt. Ein Entlassbrief fasst z. B. alle Informationen der vorangegangenen Behandlungsepisode im Kontext der Entlassung zusammen. Diese Kontextbewahrung gilt für das ganze Dokument.
Ganzheit des Dokuments
Der Inhalt eines klinischen Dokuments bezieht sich immer auf das Dokument als Ganzes, Teilinformationen daraus können nicht ohne Bezug auf das Dokument verwendet werden.
Lesbarkeit (human readability)
Jedes CDA Dokument muss die klinischen Informationen in lesbarer Form enthalten. Diese Lesbarkeit der klinischen Inhalte für die menschlichen Kommunikationspartner ist dadurch gewährleistet, dass man diesen Anteil im XML Dokument mit sehr einfachen Mitteln (z. B. so genannte Stylesheets) sichtbar machen kann. Dies betrifft sowohl den CDA-Body als auch die strukturierten Informationen im CDA-Header. Dafür gilt zudem:
- Es muss einen deterministischen Weg für einen Empfänger geben, den authentifizierten Inhalt sichtbar, sprich für lesbar zu machen.
- Die Lesbarkeit sollte nicht beinhalten, dass ein bestimmtes Stylesheet zusammen mit dem CDA Dokument gesendet werden muss. Es muss möglich sein, den Inhalt mit einem geeigneten Stylesheet und marktüblichen Browsern darzustellen.
- Lesbarkeit bezieht sich auf den authentifizierten Inhalt. Zusätzlich kann weitere Information im Dokument vorhanden sein, die auf Auswertbarkeit durch Anwendungssysteme abzielt, die aber nicht 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 die Codes hinzugefügt hat, durch automatisierte Verarbeitung der natürliche Sprache, durch eine spezifische Software.
- Wenn narrativer Text von strukturierter Information abgeleitet ist, muss der Mechanismus beschrieben sein, wie dies bewerkstelligt wurde.
CDA Modellbeschreibung
Wie alle Spezifikationen von Nachrichten in HL7 basiert auch die Clinical Document Architecture auf dem RIM und ist als HL7 V3 Modell repräsentiert.
Grob gesprochen besteht ein CDA Dokument aus einem Header und einem Body, der wiederum Body Structures und CDA Entries aufweist. An die Entries können externe Referenzen (External References) geknüpft sein. Der folgende Überblick zeigt die Hauptkomponenten des CDA R2 Modells auf, in der Abbildung 3 ist das Ganze in XML-artiger Darstellung gezeigt.
[Abbildung 2] Vereinfachte Übersicht über einen Teil des CDA Modells mit Clinical Document Header (Informationen über das Dokument sowie deren Beteiligte, einschließlich Patient), Body Structures (Abschnitte und narrativer Text), CDA Entries (maschinenauswertbare Detailinformationen). Schließlich können auch externe Referenzen aufgeführt sein.
[Abbildung 3] Grober Aufbau eines CDA Dokuments aus XML Sicht.
CDA Header
Die Informationen zum Patienten, zum Dokument selbst, zu den weiteren beteiligten Personen und Organisationen sowie der dokumentierten Episode (Zeitereignisse) sind zum CDA Header zusammengefasst, hochstrukturiert und von der Semantik her festgelegt.
Die Informationen im Header unterstützen einen Austausch klinischer Dokumente über Institutionsgrenzen hinweg. Er trägt Informationen über das Dokument selbst (eine eineindeutige Identifikation, der Typ des Dokuments), über „Teilnehmer" am Dokument (an der Dokumentation beteiligte Heilberufler, Autoren, und natürlich den Patienten selbst), sowie über Beziehungen zu Dokumenten (zu Anforderungen und anderen Dokumenten). Mit den Informationen des Headers werden Dokumentenmanagement-Systeme unterstützt, der Header stellt dafür entsprechende Metadaten zur Verfügung. Schließlich hat man mit den im CDA Header verfügbaren Informationen die Zusammenführung einer individuellen (lebenslangen) Patientenakte vor Augen.
CDA Body
Die eigentliche klinische Dokumentation wird im so genannten CDA Body festgehalten. Im Vordergrund steht hier „lesbarer" (narrativer) Text, der verpflichtender Bestandteil von CDA R2 Dokumenten ist und die Interoperabilität zwischen den menschlichen Kommunikationspartnern garantiert.
Hier sind Möglichkeiten gegeben, diesen Text grob zu strukturieren, 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, durch das Textattribut in der section-Klasse repräsentiert, wird eingebetteter Text innerhalb eines Abschnittes angegeben. Dabei kann mit oben genanntem <content> Element bestimmter Inhalt gesondert gekennzeichnet werden. Zusammengefasst werden im Textblock (teils so auch schon in CDA Release 1 realisiert) u.a. folgende Möglichkeiten der Struktur- und Formgebung des fließenden Textes gegeben:
- Zeilenumbrüche
- Stilistische Angaben (unterstreichen, fett, kursiv etc.)
- Hoch- und Tiefstellung von Text
- Fußnoten
- Symbole
- Revisionsmarken im Text wie <delete>, <insert>
Mit den beschriebenen Body Strukturen können CDA Entries verbunden sein. Diese repräsentieren den „computerlesbaren Teil" innerhalb eines Dokumentenabschnitts. CDA 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.
[Abbildung 4] Ausschnitt aus der Auswahlliste der CDA Body Entries mit Darstellung der HL7 RIM-Klassen und deren Attributen
Diese Auswahlliste von Aktivitäten wird auch als Clinical Statement Pattern bezeichnet und findet sich in gleicher oder ähnlicher Form auch in HL7-Version 3-Nachrichten zu Anforderungen und Befunden etc. wieder. Eine konkrete Ausprägung davon wird dann als Clinical Statement bezeichnet. In dieser Auswahl sind folgende Klassen verfügbar:
- observation, eine (kodierte) 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",...).
Die folgende Abbildung zeigt das ganz CDA Release 2 Modell.
[Abbildung 5] Clinical Document Architecture Release 2.0
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Konzept der Templates
Wie aus den vorhergehenden Erläuterungen ersichtlich ist, setzt sich ein Dokument aus verschiedenen Komponenten zusammen, die flexibel miteinander kombiniert werden können. Für ein Zusammensetzen der Einzelteile auf den unterschiedlichen Ebenen gibt es detaillierte „Baupläne“, die in CDA auch Templates – oder Schablonen oder auch Muster – genannt werden.
Es werden die folgenden Template-Typen bei CDA unterscheiden.
Document Level Template
Angabe der benötigten Einzelteile für eine bestimmte Art von Dokument. So legt die Schablone für einen Arztbrief beispielsweise fest, dass ein Arzt das Dokument für einen anderen Arzt erstellt und somit sowohl eine Anrede und eine Grußformel enthalten sollte. Bei einem einfachen Meldebogen ist letzteres nicht der Fall.
Inhalt: Festlegung des Inhalts des Dokuments inklusive der Header und Section-Level-Templates sowie weiterer Header-Metadaten
Header Level Template
Angabe, wie die größeren Blöcke im Header eines Dokumentes konkret aussehen sollen, zum Beispiel welche Details zu einem Patienten hinterlegt werden können. Beispiele für Inhalt: Patient, Autor, Unterzeichner, weitere Beteiligte, ..
Section Level Template
Inhalt: Angabe, wie ein bestimmter Abschnitt konkret aussehen soll. Hier können auch Vorgaben gemacht werden, wie zum Beispiel Diagnosen in einer tabellarischen Form textuell aufbereitet werden sollen, damit sie einheitlich durch ein Stylesheet zur Anzeige gebracht werden können. Möglicherweise existieren passende Entry-Level-Templates zu der Sektion. Hier kann auf die optionale oder verpflichtende Nutzung von Entry-Level-Templates hingewiesen werden.
Beispiele für Inhalt: Anrede, Diagnose, Maßnahme, ..
Entry Level Template
Angabe, wie die Einzelinformationen in struktierter und kodierter Form hinterlegt werden sollen, damit sie durch ein Programm ausgewertet und weiter verarbeitet werden können.
Beispiele für Inhalt: ICD-Diagnosen, Maßnahmen, Scores und Assessments, Meldeanlässe, ..
Datentypen
Hier handelt es sich genau genommen nicht um Templates, sondern um sog. „Datentypen-Flavors“, jedoch beschreiben diese wie ein Datentyp in einem bestimmten Use Case genutzt werden soll. So kann es beispielsweise zwei unterschiedliche Ausprägungen für Adressen geben, die vollständige Adresse lässt Straßennamen oder Postfächer zu, der Geburtsort wird auf die Stadt inklusive Land eingeschränkt. Diese Datentypen werden in den drei vorher genannten Arten von Templates genutzt.
Inhalt: Verwendung bei Namen, Adressen, Telefonnummern, ..
Profile Components
Templates stellen somit sog. „Profile Components“ dar, sind also selber konkrete Ausprägungen allgemeiner Vorgaben für einen bestimmten Use Case. Derartige Ausprägungen können hierarchisch vorgenommen werden. Nachfolgend sei das an einem Beispiel erläutert.
| Stufe | Hierarchie / ID | Inhalt | Einschränkung |
|---|---|---|---|
| 1 | Author (HL7 International) 2.16.840.1.113883.10.12.102 |
Originäre Spezifikation aus dem CDA-Header | Keine |
| 2 | Author allgemein (HL7 Deutschland) 1.2.276.0.76.10.2002 |
Ausdifferenzierung inklusiver aller Details | Anwendung von Datentypen-Flavors |
| 3 | Author Person (HL7 Deutschland) 1.2.276.0.76.10.2007 |
Reduzierung auf eine Person als Autor | Streichung der Auswahlmöglichkeit |
| 3 | Author Gerät (HL7 Deutschland) 1.2.276.0.76.10.2008 |
Reduzierung auf ein Gerät als Autor | Streichung der Auswahlmöglichkeit |
[Tabelle 1] Beispiel für eine Template-Hierarchie
Eine weitere wichtige Eigenschaft ist die Feststellung, ob Templates „offen“ oder „geschlossen“ sind, d.h. ob nur die definierten Elemente zugelassen sind (geschlossen) oder ob auch Erweiterungen – gemäß dem zugrunde liegenden Modell – erlaubt sind (offen). Hier gibt es unterschiedliche Vorgehensweisen. So macht es für die Angaben im Header durchaus Sinn, alle notwendigen Details soweit vorzugeben, so dass in Spezialisierungen bei nicht benötigten Attributen/Klassen nur die entsprechenden Auswahlmöglichkeiten gestrichen werden müssen, während für die Angaben im Body nur bedingt möglich ist, alle Eventualitäten vorzugeben.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Konformität
Ein zu diesem Implementierungsleitfaden (engl. Implementation Guide) konformer Arztbrief ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und Body. Ein konformer "stationärer Entlassbrief" kann weiterhin fehlerfrei gegen das CDA Schema (xsd) validiert werden und erfüllt außerdem alle „Geschäftsregeln" im weiteren Text dieses Dokuments.
Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten (und Nachrichten) wieder: die Validierung in zwei Schritten. Im ersten Schritt stellt dies die Validierung gegen zugehörige W3C Schemas dar. Das zum Arztbrief gehörige Schema ist das unveränderte generische, offizielle CDA Release 2 Schema (siehe Anhang). Darüber hinaus sind eine Reihe von Schematron Skripts denkbar (und im Rahmen dieses Leitfadens auch erstellt), die für einen zweiten „Validierungsschritt" genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben sowie die Einhaltung der Geschäftsregeln sicherstellen können. Diese Schritte werden auch als Templates bezeichnet, allgemeine Arbeiten zu diesem Thema sind zurzeit in Gange, jedoch noch nicht abgeschlossen, so dass wir hier auf bewährte Techniken (W3C Schema und Schematron) zurückgreifen. 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ültiger Arztbrief im Sinne dieses Implementierungsleitfadens.
Die hier verwendeten Constraints basieren zum Teil auf extern kontrollierten Vokabularen, die sich nach Verabschiedung dieses Implementierungsleitfadens ändern könnten.
CDA ermöglicht die Identifikation der verwendeten Templates mithilfe eines eindeutigen Identifikators. Der Einsatz von so genannten „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 bzw. Zertifizierung.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Kardinalität und Konformität von Elementen
Für die einzelnen Datenelemente wird über die Spalte Card die Kardinalität und in Conf. die Konformität vorgegeben. Die verwendeten Symbole haben folgende Bedeutung:
| Conf. | Bedeutung | Erklärung | Kardinalität |
|---|---|---|---|
| M | Mandatory | Das Element muss mit einem gültigen Wert gefüllt sein. Null-Flavors sind nicht zugelassen. | mindestens 1x oder häufiger |
| R | Required | Das Element muss unterstützt werden. | 0x oder häufiger |
| O | Optional | Es steht frei, dieses Element zu unterstützen. | 0x oder häufiger |
| NP | Not Permitted | Das Element muss leer bleiben. | 0 |
[Tabelle 2] Optionalität von Elementen
Es wird empfohlen, die zugrunde liegende HL7 Version 3 Dokumentation zu Rate zu ziehen.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Transportaspekte
Interaktionsdiagramm
In diesem Leitfaden geht es um die Präzisierung des Aufbaus von Dokumenten (hier: der Arztbrief), d.h. wie diese inhaltlich strukturiert sind. Die Prinzipien der Gliederung gelten aber auch für andere Arten von Dokumenten wie Ein-/Überweisungen, Befunde, etc.
Im Allgemeinen wird ein CDA-Dokument von einer Anwendung in einem bestimmten Kontext erzeugt und dann als ganzheitliches Objekt übertragen. Dies kann auf unterschiedlichen Wegen passieren (bspw. als Datei, als Binärobjekt in einer Email oder als Objekt einer Akte wie EFA, eEPA oder EGA), diese werden hier aber nicht spezifiziert. Dieses Objekt wird dann letztendlich von einer – oder mehreren – Anwendungen konsumiert:
[Abbildung 6] Interaktionsdiagramm
Dokumentenaustausch
Für den Austausch der Dokumente gibt es mehrere Möglichkeiten, zu denen eine Reihe von konkreten Vorgaben existieren - insbesondere bei IHE ITI -, die hier nur kurz genannt werden sollen:
- IHE ITI
- die Integrationsprofile XDS, XDM und XDR
- Telematikinfrastruktur (in Vorbereitung) mit KOM-LE
- KV-Connect
- Safemail
- FTP
- ...
Diese Liste ist nicht vollständig und soll nur als Beispiel dienen.
Rechtssichere Übertragung
Eine eAU kann papierbegleitend, aber auch papierersetzend umgesetzt werden. Im letzteren Fall ist diese mit einer rechtssicheren elektronischen Signatur (fortgeschritten oder QES) zu ergänzen:
- Datenschutz-/-sicherheit
- IT-Sicherheit
- Verschlüsselung
- Signaturen
 |
Diese Aspekte Datenschutz/-sicherheit, IT-Sicherheit, Verschlüsselung und Signaturen sind nicht Bestandteil dieser Spezifikation. Es gibt dazu aber bereits entsprechende Ausarbeitungen und Vorgaben. |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Struktureller Aufbau
Das statische Modell umfasst
- Die zentrale Klasse ClinicalDocument und den Header mit einer Reihe von assozierten Header-Klassen (Patient, Autor, Empfänger, etc.) und
- den CDA-Body mit Section und Entries.
Grober XML-Aufbau von CDA-Dokumenten
Der XML-Namespace für CDA Release 2 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser muss in geeigneter Weise in jeder XML Instanz genannt werden. In diesem Leitfaden werden typischerweise keine namespace-Präfixe (z. B. "hl7:" oder "cda:") genutzt (Verwendung von default namespace), die Ausgaben der Templates aus ART-DECOR verwenden das Präfix "hl7:".
Für die Arztbrief XML-Dokumente auf der Basis von CDA Release 2 ist der Zeichensatz UTF-8 vorgeschrieben. Arztbrief XML-Dokumente beginnen mit dem Wurzelelement ClinicalDocument, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.
<?xml version="1.0"? encoding="UTF-8">
<ClinicalDocument
xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- CDA Header -->
… siehe Beschreibung CDA R2 Header
<!-- CDA Body -->
<component>
<structuredBody>
… siehe Beschreibung CDA R2 Body
</structuredBody>
</component>
</ClinicalDocument>
 |
Das Dokument muss mit dem Element <ClinicalDocument> beginnen und die in obiger Abbildung genannten xmlns: Deklarationen aufweisen. |
Dokumenteninformationen
Dokumentenhistorie
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Impressum
Dieser Leitfaden ist im Rahmen des Interoperabilitätsforums und der Technischen Komitees von HL7 Deutschland e. V. sowie der entsprechenden Projektgruppen zusammengestellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums[17] und der Technischen Komitees von HL7 Deutschland e. V. [18]
Ansprechpartner und Autoren
- Ralf Franke, gevko GmbH (Projektleitung)
- Dr. Jens Schmidt. gevko GmbH (Projektmanagement)
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Disclaimer
|
|
Disclaimer
|
|
|
Alle durch HL7 Deutschland erarbeiteten Leitfäden, die auf Standards aus der HL7-Familie beruhen und diese konform einschränken, gelten die Lizenzbestimmungen, die HL7-D einhalten muss. Hier wären primär die IP-Rechte, das Affiliate Agreement, das Governance and Operations Manual und die Bylaws zu nennen. Leitfäden, die das vorgeschriebene Ballotierungsverfahren durchlaufen haben, dürfen als gültige Affiliate Localization bezeichnet werden. |
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Einleitung
Das Gesetz zur Stärkung der Versorgung in der gesetzlichen Krankenversicherung (GKV-VSG)[19] hat mit § 39 SGB V den Anspruch gesetzlich versicherter Patienten auf ein Entlassmanagement eingefügt. Versicherte sollen damit beim Übergang von der Krankenhausbehandlung in die folgende Versorgung unterstützt werden
Der GKV-Spitzenverband, die Kassenärztliche Bundesvereinigung und die Deutsche Krankenhausgesellschaft e. V. haben einen Rahmenvertrag über ein Entlassmanagement[20] vereinbart. Der Rahmenvertrag gilt für Entlassungen von Patienten aus voll- und teilstationären Behandlungen durch das Krankenhaus.
Die beteiligten Parteien haben in Folge ein bundeseinheitliches Antragsformular (Antrag auf Anschlußrehabilitation, AR-Antrag) zur Einleitung einer Anschlussrehabilitation entwickelt und abgestimmt, welches mit der 2. Änderungsvereinbarung zum Rahmenvertrag [21] als Anlage 3a und 3b Bestandteil des Rahmenvertrages wurde und zum 1. Januar 2020 wirksam wird.
Der Formular-Vordrucksatz
Basis für die Spezifikation sind die beiden Formulare "Antrag auf Anschlußrehabilitation" und "Ärztlicher Befundbericht - Anlage zum Antrag auf Anschlußrehabilitation" die zusammen den "AR-Antrag" bilden.
Antrag auf Anschlußrehabilitation
Die folgende Tabelle zeigt eine Übersicht der Abschnitte (Sektionen) im Papierformular des Antrags auf Anschlussrehabilitation und eine kurze Beschreibung des jeweiligen Inhalts.
[Abbildung 7] Formular Antrag auf Anschlussrehabilitation
| Abschnitt | Inhalt |
|---|---|
| Pflegebedürftigkeit | Besteht Pflegebedürftigkeit nach SGB XI? (Pflegestufe, Pflegestufe beantragt) |
| Rentenbezug und Altersvorsorge | Angaben zu Leistungsbezug und Träger Altersrente bzw. Rente wegen Erwerbsminderung (Bezug, beantragt) |
| Beschäftigungsstatus und Rentenversicherungsbeiträge | Angaben zu Altersteilzeit sowie Entrichtung oder Anrechnung von Beiträgen zur gesetzlichen Rentenversicherung oder Alterssicherung der Landwirte |
| Häuslichen Situation | Angaben zu Stockwerk, Fahrstuhl, Besonderheiten (z. B. Treppen im Innen- und Außenbereich) |
| Soziale und häusliche Versorgungssituation | Angaben zur Wohnsituation (allein, betreut, Pflegeeinreichtung); Ist die häusliche Versorgung sichergestellt? |
| Behandelnde/r Hausärztin/-arzt | Kontakdaten der/s Hausärztin/-arztes |
| Spezielle Anforderungen und individuelle Wünsche an die Rehabilitationseinrichtung | z. B. Nennung einer gewünschten Rehabilitationseinrichtung mit Begründung |
| Hinweis | Textfeld ohne Daten ("Für weitere Fragen (z. B. Zuzahlungen, Wunsch- und Wahlrecht) beachten Sie bitte das beigefügte Merkblatt oder wenden Sie sich an Ihre Krankenkasse") |
| Datenschutzhinweis | Textfeld ohne Daten (Datenschutzhinweis nach § 82a Abs. 2 SGB X) |
| Einwilligung | Einwilligung zur Übermittlung persönlicher Daten an die Krankenkasse |
| Angaben zum Krankenhaus | Name/Bezeichnung des Krankenhauses; Fallnummer/Patienten-ID |
| Ansprechpartners im Krankenhaus | Kontaktdaten des Ansprechpartners im Krankenhaus (z. B. Sozialdienst/Casemanagement) |
| Kommunikation mit dem/r Patient/in | Kommunikationssprache |
| Anfrage an Rehabilitationseinrichtung | Kontaktdaten der angefragten Rehabilitationseinrichtung (falls zutreffend) |
[Tabelle 3] Abschnitte (Sections) Antrag auf Anschlussrehabilitation
Ärztlicher Befundbericht - Anlage zum Antrag auf Anschlussrehabilitation
[Abbildung 8] Formular Ärztlicher Befundbericht
Die folgende Tabelle zeigt eine Übersicht der Abschnitte (Sektionen) im Papierformular des Ärztlichen Befundberichts und eine kurze Beschreibung des jeweiligen Inhalts.
| Abschnitt | Inhalt |
|---|---|
| (Allgemeine Angaben) Personalien der/des Versicherten | Name, Geburtsdatum, Versichertennummer, Geschlecht |
| (Allgemeine Angaben) Indikation | Muskuloskeletale Erkrankungen, Kardiologie, Neurologie, Geriatrie, sonstige |
| (Allgemeine Angaben) Krankenhausbehandlung | Krankenhausbehandlung ggf. einschließlich Frühmobilisation und Wundbehandlung (Aufnahmedatum, voraussichtliches Entlassdatum) |
| (Allgemeine Angaben) Frührehabilitationsmaßnahmen | Werden derzeit neurologische, geriatrische oder fachübergreifende Frührehabilitationsmaßnahmen durchgeführt? |
| (Allgemeine Angaben) Anschlussrehabilitation | Angaben zur Anschlussrehabilitation (direkt, Datum, Grund) |
| (Rehabilitationsbedürftigkeit) Funktionsdiagnosen | Liste der antragsrelevanten Funktionsdiagnosen (in der Reihenfolge ihrer Bedeutung) |
| (Rehabilitationsbedürftigkeit) Durchgeführte Behandlungen | Angaben zu Operationen (welche, Datum, OPS); Wundstatus; andere Behandlungen (Text) |
| (Rehabilitationsbedürftigkeit) Komplikationen | Angaben zu Komplikationen im aktuellen Behandlungsverlauf (Zusammenhang mit der Anschlussrehabilitation führenden Diagnose, kardiovaskulär, sonstige); Angaben zur Besiedelung mit multiresistenten Keimen |
| (Rehabilitationsbedürftigkeit) Alltagsrelevante Beeinträchtigungen | Angaben zu drohenden oder bestehenden längerfristigen (>6 Monate) alltagsrelevanten Beeinträchtigungen |
| (Rehabilitationsfähigkeit) Belastbarkeit (körperlich, psychisch/kognitiv) | Besteht eine ausreichende körperliche und psychisch/kognitive Belastbarkeit, um an der Therapie teilzunehmen? |
| (Rehabilitationsfähigkeit) Belastbarkeit (Intervention) | Voraussichtliche Belastbarkeit im Hinblick auf die durchgeführte Intervention zum Zeitpunkt des Antritts der Anschlussrehabilitation (voll belastbar, teilbelastbar, übungsstabil); Interimsprothese; Besonderheiten (Text) |
| (Rehabilitationsfähigkeit) Unterstützungsbedarf | Ist ein besonderer Unterstützungsbedarf im Bereich der Selbstversorgung erforderlich? |
| Rehabilitationsziele/-prognose | Welches sind die realistischen, alltagsrelevanten Rehabilitationsziele unter Berücksichtigung des bisherigen Verlaufs und der individuell vorhandenen bzw. förderungsfähigen Ressourcen? |
| Zusammenfassende Bewertung | empfohlene Rehabilitationsart (ambulant, ambulant mobil, stationär) |
| (Informationen zur Durchführung) Anforderungen Rehabilitationseinrichtung | Angaben zu besonderen Anforderungen an die Rehabilitationseinrichtung |
| (Informationen zur Durchführung) Verkehrsmittel Anreise | Welches Verkehrsmittel ist für die Anreise voraussichtlich notwendig (ÖPNV, Taxi/PKW, Krankentransport); Begleitperson |
| (Informationen zur Durchführung) Krankenhausärztin/Krankenhausarzt | Kontaktdaten der/s behandelnden Krankenhausärztin/-arztes |
| Datenschutzhinweis | Textfeld ohne Daten (Datenschutzhinweis nach § 82a Abs. 2 SGB X) |
| (Anhang) Barthel-Index | Score und Einzelwerte (nur bei Indikationen Neurologie oder Geriatrie) |
| (Anhang) Frühreha-Barthel-Index | Score und Einzelwerte (nur bei Indikationen Neurologie oder Geriatrie) |
[Tabelle 4] Abschnitte (Sections) Ärztlicher Befundbericht
Akteure
Folgende Akteure kommen in Kontakt mit einem Antrag auf Anschlußrehabilitation:
- Versicherter (Antragsteller)
- Krankenhaus (Einrichtung aus der der Antragsteller in die Anschlußrehabilitation entlassen werden soll)
- Krankehausarzt (Ersteller des ärztlichen Befundberichts)
- Service-Einrichtungen des Krankenhauses wie z. B. Sozialdienste, Case Management (Unterstützung des Antragstellers)
- Krankenkasse, Rentenversicherungsträger (Empfänger des Antrags)
Zielgruppe
Zielgruppe für diesen Implementierungsleitfaden sind Software-Entwickler und Berater, die mit Implementierungen und Integrationen im Umfeld des „Entlassmanagements/Rehabilitation" betraut sind
Abgrenzung
Folgende Themen sind nicht Gegenstand dieses Implementierungsleitfadens:
- Spezifikation von Infrastrukturen, Workflows, Nachrichten, Prozeduren oder Protokollen zur Übermittlung des Antrags auf Anschlussrehabilitation
- Digitale Signaturen und andere Sicherheitsaspekte (z. B. Verschlüsselung) - mehr dazu unter [3]
- Transport von CDA-Dokumenten - mehr dazu unter [22]
- Verwendung von XSL-Stylesheets
Hinweis auf ART-DECOR®
Alle technischen Artefakte wie Templates und Value Sets sind auf der Spezifikations-Plattform ART-DECOR® einsehbar. Der direkte Link zur ART-DECOR® Live Version ist https://art-decor.org/art-decor/decor-templates--vomgt-, die HTML-Dokumentation steht auf http://hl7de.art-decor.org/index.php?prefix=cdaaar- zur Verfügung.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Anhang
cdaaar:Abkürzungsverzeichnis cdaaar:Literaturverzeichnis -->
Antrag auf Anschlussrehabilitation
Anhang
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Beispiel
XML-Materialien: Schemas, Schematron und XML-Beispieldokumente sowie zugehörige Stylesheets finden sich auf den Publikationsseiten von HL7 Deutschland unter http://hl7de.art-decor.org oder direkt unter der Materialienseite des Projekts.
Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.
|
Stylesheet
Die Arbeitsunfähigkeitsbescheinigung kann über ein Stylesheet angezeigt werden.
|
|
Zur Unterstützung der Blankformularbedruckung sind noch weitere Details notwendig:
|
[23] Blankoformularbedruckung
XML-Materialien: Schemas, Schematron und XML-Beispieldokumente sowie zugehörige Stylesheets finden sich auf den Publikationsseiten von HL7 Deutschland unter http://hl7de.art-decor.org oder direkt unter der Materialienseite des Projekts.
Referenzen
- ↑ Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)
- ↑ HL7 Deutschland e. V. http://www.hl7.de
- ↑ 3,0 3,1 3,2 Erstellung von XML-Signaturen für Dokumente nach Clinical Documents Architecture – R2 (Elektronische Signatur von Arztbriefen). Spezifikation der Bundesärztekammer, Ärztekammer Nordrhein, Ärztekammer Westfalen-Lippe. Version 1.4 vom 20. Mai 2008
- ↑ IHE Deutschland: Cookbook http://wiki.hl7.de/index.php?title=IHE_DE_Cookbook
- ↑ Arztbrief des VHitG (jetzt bvitg), http://www.bvitg.de/arztbrief.html
- ↑ SCIPHOX GbR mbH Arbeitsgruppe, alte Materialien unter sciphox.hl7.de, insbesondere „Working draft 15“
- ↑ HL7 v3 , CDA Rel. 2 „ Implementation Guide for CDA Re-lease 2 – Level 1 and 2 – Care Record Summary (US realm)“, 2005-11-17, 3rd normative ballot
- ↑ Use Cases for Medical Summaries, L. McNight, IHE PCC, 2005-09-08
- ↑ Guide d’implémentation du Volet Médical au format CDA Re-lease 2 – Niveau 3, 2005-09-01
- ↑ e-MS. Clinical Document Architecture Implementation Guide Vancouver Island Health Authority, British Columbia (Level 2 und 3), 2004-12-17
- ↑ IHE Laboratory Technical Framework, Supplement „Sharing Laboratory Reports (XDS-LAB)“ vom 14. September 2006. http:// www.ihe.net
- ↑ ELGA-Spezifikationen http://elga.gov.at, nationale Infrastruktur Österreich
- ↑ HL7 v3 Clinical Document Architecture, Release 2.0 (ANSI Standard CDA Release 2, Juli 2005), ISO/HL7 27932:2009 Data Exchange Standards -- HL7 Clinical Document Architecture, Release 2
- ↑ World Wide Web Consortium. Extensible Markup Language, 1.0, 2nd Edition. http://www.w3.org/TR/REC-xml
- ↑ First international conference on CDA, Berlin 2002. Konfe-renz-Website und Proceedings http://www.hl7.de/cda2002
- ↑ Second International conference on CDA, Acapulco 2004. Konferenz-Website und Proceedings http://www.hl7.de/iamcda2004
- ↑ Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)
- ↑ HL7 Deutschland e. V. http://www.hl7.de
- ↑ Gesetz zur Stärkung der Versorgung in der gesetzlichen Krankenversicherung (GKV-VSG) https://dejure.org/BGBl/2015/BGBl._I_S._1211
- ↑ Entlassmanagement https://www.gkv-spitzenverband.de/krankenversicherung/ambulant_stationaere_versorgung/entlassmanagement/entlassmanagement.jsp
- ↑ 2. Änderungsvereinbarung zum Rahmenvertrag Entlassmanagement https://www.dkgev.de/fileadmin/default/Mediapool/2_Themen/2.3_Versorgung-Struktur/2.3.3_Entlassmanagement/2._AEnderungsvereinbarung_zum_Rahmenvertrag_Entlassmanagement.pdf
- ↑ IHE Deutschland: Cookbook http://wiki.hl7.de/index.php?title=IHE_DE_Cookbook
- ↑ Blankoformularbedruckung: http://www.kbv.de/media/sp/02a_Blankoformularbedruckung.pdf
Abbildungen
- ↑ RIM Basisklassen
- ↑ CDA Modell mit Clinical Document Header, Body Structures und Entries
- ↑ Grober Aufbau eines CDA Dokuments
- ↑ Auswahlliste der CDA Body Entries
- ↑ Clinical Document Architecture Release 2.0 Modellübersicht
- ↑ Interaktionsdiagramm
- ↑ Formular Antrag auf Anschlussrehabilitation
- ↑ Formular Ärztlicher Befundbericht
Referenzfehler: Es sind <ref>-Tags für die Gruppe „Tabelle“ vorhanden, jedoch wurde kein dazugehöriges <references group="Tabelle" />-Tag gefunden oder ein schließendes </ref> fehlt.
