Ärztlicher Reha-Entlassungsbericht
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 Wikiadmin (talk| contribs) 9 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 Wikiadmin (talk| contribs) 9 years ago. (Purge) |
Dieses Dokument gibt wieder:
Implementierungsleitfaden Ärztlicher Reha-Entlassungsbericht (1.10). Die Teilmaterialien gehören der Kategorie cdarehaa an. |
Einheitlicher Entlassungsbericht in der medizinischen Rehabilitation der gesetzlichen Rentenversicherung
auf der Basis der HL7 Clinical Document Architecture Release 2
HL7 Deutschland, DRV-Bund
Version: | 1.10 |
Datum: | 23. November 2009 |
Status: | Abgestimmt |
Verfahren: | {{{Verfahren}}} |
Realm: | Deutschland |
Abstimmungsdokument | |||
---|---|---|---|
Version | Datum | Status | Realm |
1.10 | 23.11.2009 | Abgestimmt | Deutschland |
[download] |
Kontributoren | ||
---|---|---|
Deutsche Rentenversicherung Bund | Berlin |
Inhaltsverzeichnis
- 1 Dokumenteninformationen
- 2 Einleitung
- 3 Konzept und Begründung
- 4 Dynamisches Modell
- 5 CDA R2 Dokument und Header
- 5.1 Mapping der Items des DRV-Leitfadens nach CDA
- 5.2 Dokumentenstruktur
- 5.3 typeId-Element
- 5.4 templateID
- 5.5 Dokumenten-Id
- 5.6 Typisierung des Dokuments
- 5.7 Zusätzliche Dokumenttyp-Bezeichnung
- 5.8 Erstellungsdatum des Dokuments
- 5.9 Vertraulichkeit des Dokuments
- 5.10 Sprache des Dokuments
- 5.11 Versionierung des Dokuments
- 5.12 Rehabilitandendaten
- 5.13 Rehabilitationseinrichtung
- 5.14 Unterschriftsdatum und Unterzeichner
- 5.15 Weitere teilnehmende Parteien (Participants)
- 6 CDA R2 Body
- 6.1 Abschnitte im Reha-Entlassungsbericht
- 6.2 Beschreibung der Abschnitte
- 6.2.1 Aufnahme, Entlassung, Entlassungsform und Arbeitsfähigkeit
- 6.2.2 Diagnosen
- 6.2.3 Gewicht, Größe, Ursache der Erkrankung und Arbeitsunfähigkeitszeiten
- 6.2.4 Empfehlungen
- 6.2.5 Sozialmedizinische Beurteilung der Leistungsfähigkeit (Blatt 1a)
- 6.2.6 Dokumentation therapeutischer Leistungen (Blatt 1b)
- 6.2.7 Arztbericht (Blatt 2 ff.)
- 6.2.7.1 Allgemeine und klinische Anamnese
- 6.2.7.2 Jetzige Beschwerden und Beeinträchtigungen in Beruf und Alltag
- 6.2.7.3 Gegenwärtige Therapie
- 6.2.7.4 Allgemeine Sozialanamnese
- 6.2.7.5 Arbeits- und Berufsanamnese
- 6.2.7.6 Aufnahmebefund, Vorbefunde, ergänzende Diagnostik
- 6.2.7.7 Therapieziele in der Rehabilitation
- 6.2.7.8 Rehabilitationsverlauf
- 6.2.7.9 Rehabilitationsergebnis
- 6.2.7.10 Sozialmedizinische Epikrise
- 6.2.7.11 Nachsorgeempfehlungen
- 6.2.7.12 Beispielfragment
Dokumenteninformationen
Einleitung
Einführung
Bereits im Vorfeld der Einführung der elektronischen Gesundheitskarte gibt es im Gesundheitswesen die vielfältigsten Aktivitäten, die sich der Digitalisierung von Dokumenten, der Speicherung von Daten in elektronischen Akten oder einer internen und sektorenübergreifenden elektronischen Kommunikation widmen. Es ist deshalb besonders wichtig schon heute Wege zu beschreiten, um eine einheitliche Kommunikationsbasis zwischen den verschiedenen Institutionen im Gesundheitswesen zu schaffen.
Der elektronische Arztbrief stellt hierbei für die Ärzteschaft das wichtigste Dokument dar, das mit ihren Kollegen innerhalb der eigenen Einrichtung oder über Einrichtungsgrenzen hinaus elektronisch ausgetauscht wird.
Der Verband der Hersteller von IT für das Gesundheitswesen e.V. (VHitG) leistet für die Umsetzung des elektronischen Arztbriefs seinen Beitrag und hat im Rahmen der Initiative „Intersektorale Kommunikation“ im April 2006 mit dem „Implementierungsleitfaden Arztbrief“ (siehe [eArztbrief]) einen entscheidenden ersten Schritt gemacht. Unter Nutzung von HL7 Version 3 und insbesondere der so genannten Clinical Document Architecture (Release 2) wurde für das deutsche Gesundheitswesen eine Basis zur Abbildung des papierbasierten Arztbriefs in eine elektronische Repräsentanz geschaffen. Die XML-basierte Abbildung ermöglicht die standardisierte Übernahme strukturierter Dateninhalte für die Weiterbehandlung des Patienten. Somit entfallen Neueingaben durch den weiterbehandelnden Arzt und die Datenqualität wird nachhaltig gesteigert. Auf dieser Grundlage sind weitere Leitfäden entstanden wie der Labor-, Medikamenten-, und Diagnosen-Leitfaden, die die entsprechende Abbildung dieser Daten im Arztbrief beschreiben.
Mit ihrer Zuständigkeit für die Rehabilitation und den Betrieb von eigenen Rehabilitations-Einrichtungen ist auch die Deutsche Rentenversicherung im Gesundheitswesen eingebunden. Auf dem Weg zu einer papierlosen Verarbeitung gibt es bei der Deutschen Rentenversicherung derzeit verschiedene entsprechende Projekte. Im Zusammenhang mit diesen Aufgaben wird die Abstimmung einer Kommunikationsbasis auf der Grundlage von strukturierten, maschinell auswertbaren Dokumenten, im Hinblick auf den Datenaustausch mit anderen Partnern im Gesundheitswesen, als ein sehr wichtiges Ziel angesehen. Sie wird auch als eine ausgezeichnete Vorbereitung auf die Anforderungen der kommenden fakultativen Anwendungen der elektronischen Gesundheitskarte betrachtet.
Zu diesem Zweck hatte die Deutsche Rentenversicherung Bund gemeinsam mit dem VHitG zunächst den „Implementierungsleitfaden eReha-Kurzbrief“ entwickelt ([rehaKB]). Der ärztliche Reha-Kurzbrief ist eine sehr komprimierte Kurzform des ausführlichen Reha-Entlassungsberichtes und wird dem Patienten bei seiner Entlassung für den Hausarzt mitgegeben. Er ist recht übersichtlich und beinhaltet u. a. die entscheidenden zusammengefassten Informationen zur durchgeführten Reha-Maßnahme und Hinweise zur Weiterbehandlung im Hausarztbereich. Schon mit der Einbeziehung des Kurzbriefs laut eArztbrief-Spezifikation erreicht man einen schnellen Einstieg in die weit komplexere Spezifikation des umfassenden Entlassungsberichts. Gleichzeitig bietet sich die Möglichkeit, die ersten Arbeitsergebnisse kurzfristig praktisch umzusetzen.
Ein erster Prototyp des eReha-Kurzbriefes wurde auf der ITeG 2007 in Berlin präsentiert.
Reha-Entlassungsbericht
Beim ärztlichen Reha-Entlassungsbericht handelt es sich um ein einheitliches standardisiertes Dokument in der medizinischen Rehabilitation der gesetzlichen Rentenversicherung, welches seit 1977 zur Unterstützung der medizinischen Dokumentation der Rehabilitations- und Rentenverfahren besteht und regelmäßig fortentwickelt wird. Der Entlassungsbericht ist sehr ausführlich, anspruchsvoll und gut strukturiert.
Abbildung 1: Blatt 1 des Formulars zum ärztlichen Reha-Entlassungsberichts.
Der Reha-Entlassungsbericht ist angesichts der jährlich etwa 800.000 von der Deutschen Rentenversicherung durchgeführten Leistungen zur medizinischen Rehabilitation eines der wichtigsten Dokumente, die im Reha-Verlauf erstellt werden. Die hier dokumentierten Daten dienen nicht nur als Grundlage der Qualitätssicherung und der Leitlinienentwicklung im Rehabilitationsprozess, sondern vor allem auch der sozialmedizinischen Transparenz zum Beispiel bei Entscheidungen über Renten wegen Erwerbsminderung oder im Zuge von Anschlussheilbehandlungen.
Der diesem Implementierungsleitfaden zugrunde liegende Leitfaden zum Ausfüllen des papiernen Dokuments ([drvALF]) wurde in seiner dritten überarbeiteten Fassung von einer Projektgruppe des Ärztegremiums der Deutschen Rentenversicherung zusammengestellt und von den zuständigen Gremien im Frühjahr 2007 zustimmend zur Kenntnis genommen.
Abbildung 2: Leitfaden zum Ausfüllen des papiernen ärztlichen Reha-Entlassungsberichts (siehe [drvALF]).
Die Ärztinnen und Ärzte der Rehabilitationseinrichtungen werden auch weiterhin in ihrer Doppelrolle als Behandler und Gutachter gefordert. Für die Abfassung eines „guten“ Reha-Entlassungsberichtes gilt nach wie vor, möglichst alle in der Gliederung aufgeführten Bereiche abzuhandeln und den Schwerpunkt auf jene Informationen zu legen, die von klinischer und vor allem sozialmedizinischer Bedeutung sind. Dieses wurde bei der Konzipierung des Implementierungsleitfaden für den eReha-Entlassungsbericht berücksichtigt.
Basisdokumente
Zusammenfassend seien im Folgenden die Dokumente genannt, die die Basis für diesen Implementierungsleitfaden darstellen:
- Implementierungsleitfaden Arztbrief ([eArztbrief])
- Leitfaden zum Ausfüllen des ärztlichen Reha-Entlassungsberichts ([drvALF])
- Implementierungsleitfaden eReha-Kurzbrief ([rehaKB])
Hinweise zum Leitfaden
Hinweise, häufig gestellte Fragen und Antworten (FAQs), offene Punkte allgemein, offene Punkte in Bezug auf HL7 als Standard und Konformitäts-Regeln können im Text besonders hervorgehoben werden.
Hinweise | |
häufig gestellte Fragen und Antworten (FAQs) | |
offene Punkte allgemein | |
offene Punkte in Bezug auf HL7 als Standard | |
Konformitäts-Regeln |
Konzept und Begründung
Zweck
In diesem Implementierungsleitfaden werden primär die Ergänzungen zum bzw. Spezialisierungen vom bestehenden Implementierungsleitfaden „eArztbrief“ beschrieben. Eine ausführliche Behandlung aller möglichen und nötigen Definitionen bei der Verwendung von CDA Release 2 im Arzt-briefkontext sind im Implementierungsleitfaden „eArztbrief“ zu finden (siehe [eArztbrief]). Für die Entwicklung oder Implementierung des eReha-Entlassungsberichts sind somit beide Dokumente notwendig.
Beteiligte Organisationen
Der VHitG repräsentiert 90% der Krankenhaus-Informationssystem-Her-steller sowie Hersteller des ambulanten und des Apothekenbereichs. Dem VHitG fällt die fachlich-technische Unterstützung bei der Entwicklung des Leitfadens zu. Darüber hinaus setzen die relevanten Mitglieder des VHitGs im freien Markt den elektronischen Reha-Entlassbericht in den Reha-Einrichtungen und den stationären und ambulanten Einrichtungen ein. Die Deutsche Rentenversicherung Bund betreibt als Leistungserbringer 22 Reha-Zentren mit insgesamt 27 Kliniken für unterschiedliche medizinische Indikationen. Die Deutsche Rentenversicherung Bund unterstützt auch weiterhin die Ini-tiative „Intersektorale Kommunikation“. Im Rahmen der gemeinsamen Kooperation wurde die Erstellung des Implementierungsleitfadens für den eReha-Entlassungsberichtes auf Basis der Standards HL7 Version 3 CDA Release 2.0 beschlossen. Neben ihrem fachlichen Wissen bringt die Deut-sche Rentenversicherung Bund die Erfahrungen in die Kooperation ein, die in den vergangenen Jahren bei der aktiven Mitarbeit im Aktionsforum Telematik im Gesundheitswesen (ATG) bei der Erstellung von Manage-mentpapieren zum eArztbrief und zur ePatientenakte erworben wurden. Gleichzeitig beabsichtigt die Deutsche Rentenversicherung Bund die Resultate der Zusammenarbeit im Zuge der Einführung des DRV-einheitlichen Entlassungsberichtes in seiner Auflage 2008 in ihren Kliniken über das KLInet-Verfahren (DRV-Bund Klinik-Informations-System) praktisch umzusetzen.
Fokus
Der vorliegende Implementierungsleitfaden richtet sich an Software-Entwickler, Projektbetreuer und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld des „Arztbriefes“ vertraut sind. Der Leitfaden beschreibt die Spezialisierung und Erweiterungen des bestehenden Implementierungsleitfadens „Arztbrief auf Basis HL7 Clinical Docu-ment Architecture Release 2“ im Kontext des allgemeinen Ausfüll-Leitfadens zur Erstellung des DRV-einheitlichen Entlassungsberichtes in seiner Auflage von 2007 ([drvALF]).
Grundlagen
Grundlagen und allgemeine Beschreibungen zu HL7 Version 3 und der Clinical Document Architecture sind im [eArztbrief] zu finden. Ergänzend sei hier angemerkt, dass ein Verständnis des DRV-Ausfüll-Leitfadens ([drvALF]) vorausgesetzt wird.
Konformanz
Ein zu diesem Leitfaden konformer eReha-Entlassungsbericht ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und Body. Ein konformer eReha-Entlassungsbericht kann weiterhin fehlerfrei gegen das CDA Schema (xsd) validiert werden und erfüllt außerdem alle „Geschäfts-regeln“ 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 XML-Schemas dar. Das zum eReha-Entlassungsbericht gehörige Schema ist das unveränderte generische, offizielle CDA Release 2 Schema (siehe Anhang 7.1). Darüber hinaus sind eine Reihe von Schematron Skripts denkbar, die für einen zweiten „Validierungsschritt“ genutzt werden und letztlich die Detail-regelungen in diesem Leitfaden wiedergeben sowie die Einhaltung der Ge-schäftsregeln sicherstellen können. Diese Schritte werden auch als Temp-lates bezeichnet, allgemeine Arbeiten zu diesem Thema sind zurzeit in Gange, jedoch noch nicht abgeschlossen, so dass wir hier auf bewährte Techniken (XML-Schema und Schematron) zurückgreifen. Eine XML-Instanz, die kein valides CDA-Dokument ist oder sich nicht ge-gen das XSD-Schema validieren lässt, oder im Widerspruch zu den ange-gebenen Geschäftsregeln steht, ist kein gültiger eReha-Entlassungsbericht im Sinne dieses Implementierungsleitfadens. Die hier verwendeten Constraints basieren zum Teil auf extern kontrollierten Vokabularen, die sich nach Verabschiedung dieses Implementierungsleitfadens ändern könnten. Solange der HL7-Template-Formalismus noch in Arbeit ist, ermöglicht CDA die Identifikation der verwendeten Templates bzw Implementation Guides vom CDA-Dokument aus mittels 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 Erzeugers des jeweiligen elektronischen Dokuments gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung bzw. Zertifizierung.
Zertifizierung
Derzeit ist nicht beabsichtigt, eine Zertifizierung auf Grundlage dieses Leitfadens durchzuführen.
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 mehrere Jahre zu erwarten sind. HL7 konstatiert zudem die Möglichkeit, dass Versionen, die zum Beispiel auf unterschiedlichen Implementation Technology Specifications (ITS) beruhen, durch Transformationen (z. B. mittels XSLT) ineinander überführbar sind. CDA Release 2 ist ANSI Standard seit Mai 2005 ([ansicdar2]). Dieser Leitfaden fußt auf ANSI/HL7 CDA R2-2005, derweil gehen die Entwicklun-gen bei CDA weiter und Implementierungen (so auch die auf diesem Leit-faden basierten) liefern Verbesserungsvorschläge. 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" [dtcmetv3-hl7de] 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 Trans-mission Informationen (Wrapper-Konstrukte) und weitere Infrastruktur-elemente (u. a. Control Acts). Zur Steuerung von Prozessen im Sinne von Dokumentenaustausch und –management sind in der HL7-Domäne „Medical Records“ alle notwenigen Interaktionen beschrieben. Damit ist eine Use-Case abhängige Koexitstenz von medizinischen Dokumenten und Nachrichten-Konzepten sowie konkrete Einbindbarkeit von CDA-Dokumenten in Nachrichtenabläufe gegeben. Dies stellt aus HL7-Sicht einen wichtigen Eckpfeiler für einen effizienten Austauschstandard im Gesundheitswesen dar.
Dynamisches Modell
Beschreibung der Use Cases und Storyboards
Im Folgenden wird ein so genanntes Storyboard als Basis für den Aufbau des Reha-Entlassungsberichts und die Beispielfragmente beschrieben. Die ausführlichen Entlassberichte als Beispiel sind im Anhang aufgeführt.
Storyboard 1: Reha-Entlassungsbericht (POCD_SN000040DE)
Herr Thomas Müller, geboren am 06.08.1952 in Leipzig, wohnhaft in Beerenstraße 12 in 04103 Leipzig befand sich in der Zeit von 24.09.2007 bis 15.10.2007 in einer stationären Reha-Maßnahme (Versicherungs-Nummer 49060852M002, Maßnahmen-Nummer 11A5 der DRV-Bund, bearbeitet unter Kennzeichen 8374) im Reha-Zentrum Bayerisch Gmain, Klinik Hochstaufen (Insitutionskennzeichen 123456789, Abteilung 0100). Nach Abreise des Patienten und Aushändigung des eReha-Kurzbriefes am Tag der Entlassung wird der eReha-Entlassungsbericht über das KIS zeitnah fertig gestellt und letztlich zur Un-terzeichnung an den leitenden Arzt gegeben. Durch dessen Freigabe wird unter anderem die Versendung an den RV-Träger und den behandelnden Arzt veranlasst.
Der elektronische Entlass-Bericht enhält Informationen, die im Anhang im Detail wiedergegeben sind (siehe Abschnitt 8.4).
Storyboard 2: Reha-Entlassungsbericht (POCD_SN000041DE)
Herr Frank Muster, geboren am 10.03.1950 in Flensburg wohnhaft in 10704 Berlin befand sich in der Zeit von 14.01.08 bis zum 23.02.08 in einer vollstationären Reha-Maßnahme (VSNR: 66100350M008, Maßnahmen-Nummer 10A5 der DRV-Bund, bearbeitet unter Kenn-zeichen 4567) im Reha-Zentrum Teltow, Klinik Seehof (Insitutionskennzeichen 223456789, Abteilung 3100). Nach Abreise des Patienten und Aushändigung des eReha-Kurzbriefes am Tag der Entlassung wird der eReha-Entlassungsbericht über das KIS zeitnah fertig gestellt und zur Endabnahme / Endzeichnung an den Leitenden Arzt gegeben. Durch dessen Freigabe wird u.a. die Versen-dung an den RV-Träger und den behandelnden Arzt veranlasst.
Der elektronische Entlass-Bericht enhält Informationen, die im Anhang im Detail wiedergegeben sind (siehe Abschnitt 8.5).
CDA R2 Dokument und Header
Mapping der Items des DRV-Leitfadens nach CDA
Die folgende Tabelle gibt eine Übersicht über die Items aus dem Leitfaden der DRV-Bund (mit entsprechender Kapitelangabe aus dem Leitfaden, [drvALF]) und das Mapping nach CDA R2 Header und Body, ggf. mit Angabe der zugehörigen Klasse(n) und Attribute.
Tabelle 1: Mapping der Items des Ausfüll-Leitfadens ([drvALF]) nach CDA R2 Header und Body
Dokumentenstruktur
Die folgende Tabelle gibt eine Übersicht über die für den eReha-Entlassungsbericht relevanten CDA-Header-Elemente, deren Datentyp bzw. Bedeutung und deren Kardinalität.
Tabelle 2: Übersicht über die im Kontext Reha-Entlassungsbericht benutzbaren CDA-Header-Elemente, deren Datentyp bzw. Bedeutung und deren Kardinalität
typeId-Element
Nach dem Root-Element ClinicalDocument muss das folgende, zurzeit konstante XML Element in einem CDA Release 2 Dokument enthalten sein.
hier kommt noch ein Code-Fragment rein
Regel TYID: Die typeID ist wie im obigen XML Fragment gezeigt anzugeben. |
templateID
Die Nutzung von templateID, einem XML Element, das an vielen Stellen im CDA Arztbrief vorkommen kann, ist hier verpflichtend. Dies stellt zunächst einen Platzhalter dar, zu einem späteren Zeitpunkt werden hier die Regeln genannt werden können, denen das ganze CDA Dokument oder Teile davon unterliegen müssen. Dies sind in der Regel Kardinalitäts- und Strukturforderungen oder auch zu erfüllende Erfordernisse in Bezug auf den Inhalt, Vokabularien etc. Vorübergehend werden im Rahmen dieses Leitfadens die Konformanz-Anforderungen wie folgt verpflichtend spezifiziert:
hier kommt noch ein Code-Fragment rein
Regel TPID: Die templateID ist wie im obigen XML Fragment gezeigt anzugeben. |
Dokumenten-Id
id Dokumenten-Id II [1..1]
Die Dokumenten-Id eines Arztbriefs ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit eindeutig und für alle Zeit identifiziert. Ein CDA-Dokument hat genau eine Id. Identifikationen sind vom Typ Instance Identifier (siehe Datentypen). Das XML-Element id weist die XML Attribute @extension und @root auf.
Regel IIRT: Das @root Attribut ist bei Instanzidentifikatoren verpflichtend an-zugeben. |
Im @root Attribut wird das Dokument-erzeugende Anwendungssystem identifiziert. Üblicherweise wird an diese Id noch eine Kennung des An-wendungssystems für Dokument-Ids angehängt.
Im @extension Attribut wird die Dokumentennummer des Anwendungssystems angegeben.
Im folgenden Beispiel hat das ein Dokument erzeugende Anwendungssystem die OID 2.16.840.1.113883.2.6.15.3.427. Dokumenten-Ids sind dadurch gekennzeichnet, dass eine .1 angehängt wird. Das System erzeugt eine interne Nummer für ein Dokument (13234453645), die im @extension Attribut zu finden ist. Zusammen mit dem @root Attribut entsteht so jeweils ein weltweit eindeutiger Instanzidentifikator.
hier kommt noch ein Code-Fragment rein
Für die Kommunikation nach außen muss eine OID gewählt werden, die eindeutig für die Instanz des Anwendersystems ist. In der Regel werden diese OIDs vom Hersteller des jeweiligen Anwendersystems kommen, der seine tatsächlichen Installationen (Applikations-Instanzen) mit entspre-chenden eindeutigen OIDs zu versehen hat. Das heißt, dass jede Installa-tion eines Anbieters eine eindeutige OID besitzt und verwendet. Mandantenfähige Systeme können für jeden Mandanten eine eigene OID haben.
Für weitere Informationen zur Vergabe und Verwendung von OIDs siehe auch die Ausführungen im Anhang Seite 82.
Typisierung des Dokuments
code Dokumententyp CE CWE [1..1]
Über das code Modellattribut der ClinicalDocument Klasse wird eine Typi-sierung des Dokuments vorgenommen. In den hier vorliegenden Fällen ist eines der in der folgenden Tabelle aufgeführten „Discharge Summarization Notes“ zu wählen.
Tabelle 3: Vokabeldomäne (Auszug) für ClinicalDocument.code (OID: 2.16.840.1.113883.6.1 [LOINC]).
Dass es sich bei der entlassenden Einrichtung um eine Reha-Einrichtung handelt, ergibt sich aus der Angabe bei encompassingEncounter (s.u.). Zur eindeutigen Identifikation der Typisierung wird das Codesystem LOINC (Logical Observation Identifiers Names and Codes [LOINC]) verwendet.
Im XML @code Attribute steht der eigentliche Code, @codeSystem ist die OID des LOINC Systems (2.16.840.1.113883.6.1). Der optionale @displayName kann die klartextliche Bedeutung wiedergeben, darf aber von der empfangenden Anwendung selbst nicht ausgewertet werden.
hier kommt noch ein Code-Fragment rein
Zusätzliche Dokumenttyp-Bezeichnung
title zusätzliche Dokumententyp-Bezeichnung ST [0..1]
Beim optionalen title können klartextlich zusätzliche Dokumententypbe-zeichnungen aufgenommen werden. Dabei kann der „Titel“ auch den Dokumententyp, Autoren und das Datum enthalten. Der Name des Patienten darf nicht verwendet werden.
hier kommt noch ein Code-Fragment rein
Erstellungsdatum des Dokuments
effectiveTime Erstellungsdatum des Dokuments TS [1..1]
Das verpflichtende Erstellungsdatum der Dokumentation (Dokument) wird in effectiveTime als Zeitpunkt wiedergegeben.
Regel CDET: Das Erstellungsdatum ClinicalDocument.effectiveTime muss min-destens tagesgenau sein, d. h. es muss mindestens ein Datum mit Jahr, Monat und Tag angegeben sein. |
Die Angabe einer Zeitzone ist optional. Wenn möglich sollte auch Stunde und Minute mit angegeben werden, wenn diese für die Erstellung der medizinischen Dokumentation bekannt ist.
Im Beispiel wurde das Dokument am 24.9.2005 um 16:34 Uhr erzeugt.
hier kommt noch ein Code-Fragment rein
Vertraulichkeit des Dokuments
confidentialityCode Vertraulichkeitsgrad CE CWE [1..1]
Hier wird der Vertraulichkeitsgrad des Dokuments codiert. Zugelassen sind folgende Codes:
Tabelle 4: Vokabel Domäne (Auszug) für ClinicalDocument.confidentiali-tyCode (OID: 2.16.840.1.113883.5.25)
Im folgenden Beispiel sind normale Vertraulichkeitsmaßregeln für das Dokument gültig.
hier kommt noch ein Code-Fragment rein
Sprache des Dokuments
languageCode Sprache des Dokuments CS CNE [0..1]
Die Sprache des Dokuments wird in diesem Attribut gemäß IETF (Internet Engineering Task Force), RFC 1766: Tags for the Identification of Languages nach ISO-639-1 (zweibuchstabige Codes für Sprachen, Klein-buchstaben) und ISO 3166 (hier: zweibuchstabige Ländercodes, Groß-buchstaben) festgelegt.
hier kommt noch ein Code-Fragment rein
Der languageCode ist ein Element des CDA-Headers, das den Sprachenkontext für das gesamte Dokument bestimmt, es sei denn, dies wird für bestimmte Inhalte, z. B. für einen anderssprachig verfassten Abschnitt, anders definiert.
Versionierung des Dokuments
setId Set-Kennung des Dokuments II [0..1] versionNumber Versionsnummer INT [0..1]
Der CDA-Header repräsentiert ebenfalls die Beziehungen zu anderen Do-kumenten mit Referenz auf die oben genannte Dokumenten-Identifikation.
Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden. Entweder können beide Attribute fehlen, oder beide müssen anwesend sein.
Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten). Die versionNumber ist eine natürliche Zahl für die fortlaufende Versionszählung. Mit einer neuen Version wird diese Zahl hochgezählt, die setId bleibt gleich.
hier kommt noch ein Code-Fragment rein
Während ein Originalbericht neue eindeutige Werte für Clinical-Document.id (verpflichtend) und setId sowie eine versionNumber von 1 aufweist (letztere beide optional im Orginalbericht), müssen Anhänge oder Ersetzungen von Vordokumenten in jedem Fall diese zusätzlichen Angaben enthalten. Der Zusammenhang zwischen diesen Attributen ist in der Spezifikation zum Arztbrief (siehe [eArztbrief]) erläutert.
Die übrigen Attribute der Klasse ClinicalDocument werden nicht benutzt.
Rehabilitandendaten
Die Art der Daten des Rehabilitanden mit der Fallidentifikation der Rentenversicherung ist im Ausfüllleitfaden beschrieben. Diese werden im Folgenden einzeln aufgeführt.
Abbildung 3: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungsberichts zu Rehabilitandendaten
Hinweis: im eReha-Entlassungsbericht auf CDA-Basis wird das Geburtsdatum des Rehabilitanden/Patienten immer genannt. |
Versicherungsnummer (VSNR)
Die persönliche Versicherungsnummer wird von der Rentenversicherung zur Identifizierung genutzt. Sie wird als id über die participant Beziehung angegeben.
Abbildung 4 Klassen rund um weitere Beteiligte (participants)
id Versicherungsnummer II [1..1]
Die Angabe der Versicherungsnummer erfolgt im extension Attribut, die root OID für Versicherungsnummern der Deutschen Rentenversicherung (DRV) ist 1.2.276.0.76.3.1.100.4.1. Der @typeCode der participation Klasse ist entweder HLD (Holder) oder COV (Covered Party), der @classCode der Klasse associatedEntity ist ent-weder POLHOLD (Policy Holder) oder COVPTY (Covered Party). Näheres dazu ist weiter unten erläutert.
Tabelle 5: Codes für die Klassen participation und AssociatedEntity Wenn bekannt ist, ob der Patient/Rehabilitand der Versicherte ist oder nicht (siehe auch Bemerkungen weiter unten), wird dies in der Klasse associatedEntity im Attribut code spezifiziert.
code Klassifizierung der Versicherung CE CWE [0..1] <= RoleCode
Tabelle 6: Vokabel Domäne for participant.associatedEntity.code
Der Gebrauch der Versicherungsnummer im Zusammenhang mit Versi-chertem oder Angehörigen ist zurzeit (noch) nicht einheitlich geregelt. Im Idealfall hat jeder Patient/Rehabilitand eine eigene Versicherungsnummer. Wegen der Nichteinheitlichkeit sind die unterschiedlichen Fälle wie folgt deutlich zu machen:
Patient/Rehabilitand ist Versicherter Es wird eine participant Beziehung mit seiner Versicherungsnummer angegeben. In der Klasse associatedEntity wird als code = SELF eingetragen (siehe oben). Damit wird angedeutet, dass es sich um die Versicherungsnummer des Patienten selbst handelt. Der @typeCode der participation Klasse ist HLD (Holder), der @classCode der Klasse associatedEntity ist POLHOLD (Policy Holder). Die Angabe eines Namens (über associatedPerson) kann entfallen.
hier kommt noch ein Code-Fragment rein
Patient/Rehabilitand ist Angehöriger Dies ist zu erkennen an der Tatsache, dass ein Name bei „Versichter“ (siehe Abbildung 3) eingetragen ist. In diesem Falle werden zwei participant Beziehung angegeben. Die erste Angabe enthält die Versicherungsnummer (laut Bescheid). Sie ist dann nicht notwendigerweise die Versicherungsnummer des Patienten oder des Versicherten, sondern ist lediglich die Angabe, unter welcher Nummer die Versicherungsleistungen abgehandelt werden. Der @typeCode dieser participation Klasse ist COV (Covered Party), der @classCode der Klasse associatedEntity ist COVPTY (Covered Party).
Die Angabe in der zweiten participant Beziehung gibt nur den Namen des Versicherten an, hierbei ist die id der associatedEntity in der Regel nicht bekannt und ist daher als fehlend zu markieren (nullFlavor=UNK). Sollte die Versicherungsnummer des Versicherten dennoch bekannt sein, ist es zugestanden, dass diese angegeben wird. Der @typeCode der participation Klasse ist HLD (Holder), der @classCode der Klasse associatedEntity ist POLHOLD (Policy Holder). Diese Vorgehensweise ist notwendig, weil ein Zusammenhang zwischen Versicherungsnummer und Name nicht garantiert ist.
hier kommt noch ein Code-Fragment rein
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Patient/Rehabilitand (Name, Wohnort, Geschlecht, Geburtsdatum)
Mittels der recordTarget Beziehung werden in der Klasse patientRole die Angaben zum Patienten/Rehabilitanden gemacht.
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Hinweis: Die Rentenversicherungsträger sind in ihrer Eigenschaft als Kostenträger zur Datensparsamkeit verpflichtet. Der Geburtsort ist im Kontext des Entlassungsberichts (bisher) nicht relevant. |
hier kommt noch ein Code-Fragment rein
Kennzeichen (Sachbearbeitungstelle)
Das Kennzeichen („Team-Kennzeichner“) bezeichnet die für den Einzelfall zuständige Stelle in der Sachbearbeitung des Rentenversicherungsträgers und ist, wenn bekannt, anzugeben. Es ist eine Identifikation einer Zuständigkeit beim jeweiligen Rentenversicherungsträger.
Diese Angabe wird in einer weiteren participation Klasse untergebracht, die den Rentenversicherungsträger identifiziert.
Die id der associatedEntity trägt dabei die Identifikation des Rentenversicherungsträgers. Der @typeCode der participation Klasse ist GUAR (Guarantor), der @classCode der Klasse associatedEntity ist GUAR (Guarantor). Die Angabe der Sachbearbeitungsstelle als Teilorganisation des Trägers wird in scopingOrganization.asOrganizationPartOf.id spezifiziert. Dabei trägt die extension das Kennzeichen, das root Attribut ist auf-gebaut aus der OID des jeweiligen Rentenversicherungsträgers mit dem Suffix 4.19 (zur Spezifizierung, dass es sich um ein Kennzeichen bzw. Sachbearbeitungsstelle innerhalb des Trägers handelt).
hier kommt noch ein Code-Fragment rein
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Ein weiteres Merkmal kann die Maßnahmennummer beim Versicherungsträger sein (siehe hierzu folgenden Abschnitt).
Maßnahme-Nummer (MSNR)
Für jeden Versicherten wird bei jeder Antragsstellung auf eine (medizini-sche) Rehabilitationsleistung eine neue MSNR im Konto vergeben. Durch die MSNR in Verbindung mit der VSNR erfolgt eine Identifikation aller von ihm beantragten und ggf. erhaltenen Rehabilitationsleistungen im Sinne einer „Durchnummerierung“.
Diese Angabe wird ebenfalls in der AssignedEntity Klasse im Attribut id untergebracht, die den Rentenversicherungsträger identifiziert (siehe auch vorigen Abschnitt zu Kennzeichen (Sachbearbeitungstelle)).
Die Angabe der Maßnahmennummer erfolgt nur in Zusammenhang mit der zugehörigen Versicherungsnummer und wird daher damit kombiniert spezifiziert. Dazu wird die Versicherungsnummer mit der Maßnahmennummer und einem Schrägstrich „/“ als Trennzeichen zusammengefügt und als weitere AssignedEntity.id aufgeführt. Zu beachten ist, dass das root Attribut die OID des Rentenversicherungsträgers darstellt, ergänzt um das Suffix .4.20 (= Identifikation Versicherungsnummer + Maßnahmennummer).
hier kommt noch ein Code-Fragment rein
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Berechtigten-Nummer (BNR)
Die BNR wird trägerspezifisch dokumentiert und geht aus den Bewilligungsunterlagen hervor (Ergänzungs-Identifikation).
Diese Angabe wird ebenfalls in der AssignedEntity Klasse im Attribut id untergebracht, die den Rentenversicherungsträger identifiziert (siehe auch vorigen Abschnitt zu Kennzeichen (Sachbearbeitungstelle)). Die Angabe der Berechtigtennummer erfolgt nur in Zusammenhang mit der zugehörigen Versicherungsnummer und wird daher damit kombiniert spezifiziert. Dazu wird die Versicherungsnummer mit der Berechtigtennummer und einem Schrägstrich „/“ als Trennzeichen zu-sammengefügt und als weitere AssignedEntity.id aufgeführt. Zu beachten ist, dass das root Attribut die OID des Rentenversicherungsträgers dar-stellt, ergänzt um das Suffix .4.21 (= Identifikation Versicherungsnummer + Berechtigtennummer).
hier kommt noch ein Code-Fragment rein
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Rehabilitationseinrichtung
Die Angaben zur Rehabilitationseinrichtung mit IK-Nummer, Anschrift und ggf. Abteilung werden bei den Angaben zum Patientenkontakt in der encompassingEncounter Klasse aufgeführt.
Abbildung 5: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungs-berichts zur Rehabilitationseinrichtung
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Adresse der Rehabilitationseinrichtung
Name und Anschrift der Reha-Einrichtung werden in den Attributen name bzw. addr innerhalb der Klasse location.healthCareFacility.location wiedergegeben. Die Art der Einrichtung wird im Attribut code der Klasse location.healthCareFacility angegeben und ist in der Regel RH (Rehabilitationseinrichtung).
Institutionskennzeichen (IK)
Das Institutionskennzeichen (IK-Nummer) der Rehabilitationseinrichtung wird im Attribut id innerhalb der Klasse location.healthCareFacility wiedergegeben. Die OID für Institutionskennzeichen-Nummern ist 1.2.276.0.76.4.5 (root Attribut der id).
Abteilungscode (-nummer) innerhalb der Einrichtung
Die Abteilung innerhalb der Rehabilitationseinrichtung wird in der Klasse serviceProviderOrganization.asOrganizationPartOf angegeben. Dabei wird die Art der Fachabteilung (Abteilungscode) laut Tabelle Anhang II „Fach-abteilungssschlüssel der Rehabilitationseinrichtungen“ des Ausfüllleitfadens und im @displayName der Name der Abteilung spezifiziert. Die OID für diese Tabelle ist 1.2.276.0.76.5.362.
Tabelle 7: Ausschnitt aus der Tabelle Anhang II „Fachabteilungssschlüssel der Rehabilitationseinrichtungen“ OID 1.2.276.0.76.5.362 (siehe [drvALF]).
Zusätzliche Angaben
Zusätzlich zu den oben genannten Angaben muss der dokumentierte (Haupt-)Aufenthalt in code typisiert (ambulant, stationär etc.), der Aufenthaltszeitraum in effectiveTime als Intervall angegeben und die Entlassungsform in dischargeDispositionCode spezifiziert werden.
code Klassifikation des Aufenthaltes CE CWE [0..1] <= ActEncounterCode
Dieser Code wird benutzt, um den Aufenthalt zu klassifizieren. Hier sind momentan die folgenden Codes zu verwenden.
Tabelle 8: Vokabel Domäne für EncompassingEncounter.code
effectiveTime Zeitraum des Aufenthaltes IVL<TS> [1..1]
Die verpflichtende Aufenthaltsperiode wird im effectiveTime Attribut angegeben. Dies ist in der Regel ein Zeitintervall.
dischargeDispositionCode Entlassungsform CE CWE [0..1] <= DRV-Entlassungsform
Die Angabe zur Entlassungsform wird codiert (DRV-Entlassungsform) im dischargeDispositionCode wiedergegeben.
Tabelle 9: Vokabel Domäne for EncompassingEncounter.discharge-DispositionCode mit den Codes zur DRV-Entlassungsform (OID: 1.2.276.0.76.5.364)
Eine Liste der Aufenthalte wie im Blatt 1 des Formulars sind im CDA Body aufgeführt (siehe dort).
hier kommt noch ein Code-Fragment rein
Unterschriftsdatum und Unterzeichner
Dokumente beinhalten Unterzeichner. Dabei gibt es höchstens einen Unterzeichner, der vor dem Gesetz verantwortlich ist (legalAuthenticator) und optional mehrere andere unterzeichnende Personen (authenticator).
Das Datum der Unterschrift sowie der vor dem Gesetz verantwortliche Heilberufler und weitere Unterzeichner sind allesamt Angaben in der Klasse legalAuthenticator bzw. authenticator. Dabei ist das Datum der Unterschrift im Attribut time, der Heilberufler in assignedEntity und die zugehörige Einrichtung in representedOrganization spezifiziert.
hier kommt noch ein Code-Fragment rein
Die Kardinalität des Elements legalAuthenticator ist im Standard 0..1 und sollte 0..* sein (deutscher Use Case). Dies ist als Anpassung für CDA Release 3 eingebracht. |
Weitere teilnehmende Parteien (Participants)
Weitere so genannte „Teilnehmer“ (Participants) sind ebenfalls im Header eines CDA Release 2 Dokuments spezifiziert und müssen angegeben wer-den. Diese sind im Kontext dieses Leitfadens
- der Autor der Dokumentation (author)
- die das Dokument erstellende Organisation (custodian)
Dies sind Beziehungen (relationships), die von der ClinicalDocument Klasse ausgehen.
Autor
Die Autor-Relation gibt den Urheber der Dokumentation und den Zeit-punkt der Autorenschaft wieder. Dies sind in der Regel Personen (Heilberufler).
hier kommt noch ein Code-Fragment rein
Verwaltende Organisation
Die Organisation (custodian), die für die Verwaltung des Dokuments verantwortlich ist, muss verpflichtend in der entsprechenden Klasse wiedergegeben werden.
hier kommt noch ein Code-Fragment rein
CDA R2 Body
Abschnitte im Reha-Entlassungsbericht
Nachfolgend den Rehabilitandendaten und den Angaben zur Rehabilitati-onseinrichtung (Blatt 1) folgen weitere Daten zu Aufenthalten, Arbeitsfä-higkeit, Diagnosen, Entlassbefunde, Empfehlungen sowie (ab Blatt 1a) die sozialmedizinische Beurteilung der Leistungsfähigkeit, Dokumentation the-rapeutischer Leistungen und der Arztbericht (Blatt 2). Diese Informationen werden im Body des CDA-Entlassungsberichts unter-gebracht und im Folgenden beschrieben. Die Informationen werden im CDA Body im Sinne von Level 1 immer in Textform wiedergegeben (verpflichtend) und wo immer möglich auch mit Section-Codes versehen, also auf Level 2 dargestellt. Dies garantiert, dass die Dokumente immer für den Menschen lesbar (und verstehbar) sind. Die Section-Codes, die in diesem Kontext verwendet werden, sind in der folgenden Tabelle zusammengefasst:
Tabelle 10: Section-Codes für die Formularabschnitte (Codesystem-OIDs “DRV-365” = DRV-Formularabschnitte OID 1.2.276.0.76.5.365, “LOINC” = 2.16.840.1.113883.6.1)
Teilweise sind einige Informationen auch in maschinenlesbarer Form (Le-vel 3) anzugeben. Details dazu sind in der Mapping-Tabelle 2: Übersicht über die im Kontext Reha-Entlassungsbericht benutzbaren CDA-Header-Elemente, deren Datentyp bzw. Bedeutung und deren Kardinalität aufge-führt.
Beschreibung der Abschnitte
Aufnahme, Entlassung, Entlassungsform und Arbeitsfähigkeit
Die folgende Tabelle fasst die hier anzugebenden Informationen zusammen. Der Section-Code für diesen Abschnitt ist AEFA (DRV-Formularabschnitte).
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Aufnahme, Entlassung
Die Anwesenheiten des Rehabilitanden in der Einrichtung werden in die-sem Abschnitt dokumentiert. Auf Level 1 wird hier in Form einer Tabelle die Angabe zum Beginn und Ende des Aufenthaltes gemacht.
CODEFRAGMENT
Die Angaben werden zusätzlich in Level 3 in der Encounter-Klasse ange-geben. Hierbei wird der Aufenthalt in effectiveTime als Zeitinterval und die Art des Aufenthalts in codiert in code angegeben. Es können bis zu drei Aufenthalte dokumentiert werden, aber dann nur jeweils ein Aufenthalt pro Art des Aufenthaltes.
code Klassifikation des Aufenthaltes CE CWE [0..1] <= ActEncounterCode
Dieser Code wird benutzt, um den Aufenthalt zu klassifizieren. Hier sind momentan die folgenden Codes zu verwenden.
Tabelle 11: Vokabel Domäne für EncompassingEncounter.code
effectiveTime Zeitraum des Aufenthaltes IVL<TS> [1..1]
Abbildung 6: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungs-berichts zu den Aufenthalten
CODEFRAGMENT
Entlassungsform
Die Entlassungsform (genau eine muss pro Entlassungsbericht angegeben werden) wird ausschließlich über den dischargeDispositionCode der EncompassingEncounter Klasse spezifiziert (siehe Abschnitt 4.13.4 „Zusätzliche Angaben“).
Arbeitsfähigkeit
Die Arbeitsfähigkeit bei Entlassung wird in derselben Section in Level 2 als Text und als separate Observation in Level 3 dargestellt. Hierbei ist im Attribut code eines der folgenden Codes anzugeben.
Tabelle 12: Codes für DRV-Arbeitsfähigkeit (OID: 1.2.276.0.76.5.366)
CODEFRAGMENT
Diagnosen
Die folgende Tabelle fasst die hier anzugebenden Informationen zusam-men. Der Section-Code für diesen Abschnitt ist 29308-4 (LOINC).
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Die Informationen werden in Tabellenform in Level 1 dargestellt. Zusätzlich sind die Diagnosen auch als Observation in Level 3 anzugeben (siehe [eArztbrief] und [Diagnoseleitfaden]).
Diagnosetext
Der Freitext der Diagnose wird in Level 1 in der ersten Spalte der Tabelle der Diagnosen angegeben.
Diagnoseschlüssel
Diagnosen sind nach dem jeweils aktuellen ICD-10-Katalog deutsche Fas-sung (z. B. ICD-10 GM 2007) zu codieren. Der Schlüssel wird in der zwei-ten Spalte der Tabelle der Diagnosen angegeben.
Zusatzkennzeichen Seitenlokalisation
Für die Angabe der Seitenlokalisation, also links, rechts oder beidseitig etc. wird in Level 1 „links“, „rechts“ etc. oder die übliche abkürzende Schreibweise L, R etc. benutzt. Hierfür ist die zweite Spalte der Diagnosentabelle vorgesehen.
In Level 3 wird die Seitenlokalisation im qualifier unterhalb des code Element wiedergegeben. Hierzu ist folgende Codetabelle zu verwenden.
Tabelle 13: Vocabulary Domain für Seitenlokalisation Codesystem: Sciphox (OID: 2.16.840.1.113883.3.7.1.7)
Zusatzkennzeichen Diagnosesicherheit
Als Angaben der Sicherheit/Verlässlichkeit der Diagnose ist in der dritten Spalte in Level 1 der Text anzugeben: „Gesichert“, „Verdacht auf“, „Zu-stand nach“, „Ausschluss von“.
Auf Level 3 werden die verschiedenen Zustände unterschiedlich gehandhabt. Zum value Element des Codes kommt hier ein zusätzliches qualifier Element, dass die Sicherheit der Diagnose angibt.
Tabelle 14: Vocabulary Domain für Sicherheit/Verlässlichkeit Codesystem: Sciphox (OID: 2.16.840.1.113883.3.7.1.8)
Behandlungsergebnis
Das Behandlungsergebnis wird in der vierten Spalte der Tabelle der Diagnosen angegeben. Die folgenden Codes sind dabei zu verwenden:
Tabelle 15: Vocabulary Domain für DRV-Behandlungsergebnis (OID 1.2.276.0.76.5.367)
Das Behandlungsergebnis wird in der Level 3 Darstellung an die gegebene Diagnose gekoppelt mittels einer über entryRelationship (@typeCode = COMP) assoziierten Observation.
Da der Originaltext immer mitgegeben wird (Level 1) und in der Regel von Bedeutung ist, wird dieser in Level 1 markiert (<content> Elemente) und in Level 3 über originalText referenziert.
originalText Bezug zum Originaltext in Level 1
CODEFRAGMENT
Beispielfragment
CODEFRAGMENT
Gewicht, Größe, Ursache der Erkrankung und Arbeitsunfähigkeitszeiten
Die folgende Tabelle fasst die hier anzugebenden Informationen zusammen. Der Section-Code für diesen Abschnitt ist GGUA (DRV-Formular-abschnitte).
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Die Informationen werden in Listenform in Level 2 dargestellt. Zusätzlich sind die Informationen auch als Observation in Level 3 anzugeben.
Aufnahmegewicht
Dieses Item wird auch auf Level 3 als Observation dargestellt. Der observation.code ist X_ADMBW (LOINC), als Einheit ist „kg“ anzugeben.
Entlassungsgewicht
Dieses Item wird auch auf Level 3 als Observation dargestellt. Der observation.code ist X_DISBW (LOINC), als Einheit ist „kg“ anzugeben.
Körpergröße
Dieses Item wird auch auf Level 3 als Observation dargestellt. Der observation.code ist 8302-2 (LOINC), als Einheit ist „cm“ anzugeben.
Ursache der Erkrankung
Die Ursache der Erkrankung (1. Diagnose) wird auf Level 3 wie folgt codiert wiedergegeben.
Tabelle 16: Codes für DRV-Krankheitsursache (OID 1.2.276.0.76.5.368)
Arbeitsunfähigkeitszeiten
Die Arbeitsunfähigkeitszeiten innerhalb der letzten 12 Monate vor Aufnahme werden auf Level 3 wie folgt codiert wiedergegeben.
Tabelle 17: Codes für DRV-Arbeitsunfähigkeitszeiten (OID 1.2.276.0.76.5.369)
DMP-Patient
Die Angabe, ob der Patient an einem DMP Programm teilnimmt, wird auf Level 3 wie folgt codiert wiedergegeben.
Tabelle 18: Codes für DRV-DMP-Patient (OID: 1.2.276.0.76.5.370)
Beispielfragment
CODEFRAGMENT
Empfehlungen
Die Empfehlungen sind einerseits als Ankreuzfelder (Empfehlungskategorien) auf dem Ausfüllformular wiedergegeben, andererseits können Erläuterungen und weitere Empfehlungen klartextlich ergänzt werden.
Abbildung 7: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungsberichts zu Empfehlungen
Auf Level 2 werden diese in Listenform wiedergegeben. Der Section-Code ist EMPF (DRV-Formularabschnitte).
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Die Empfehlungskategorien werden auf Level 3 als Observation dargestellt, für jede gewählte Empfehlungskategorie eine. Die Kategorien sind wie folgt codiert.
Tabelle 19: Codes für DRV-Empfehlungskategorien (OID: 1.2.276.0.76.5.371)
CODEFRAGMENT
Sozialmedizinische Beurteilung der Leistungsfähigkeit (Blatt 1a)
Die folgende Tabelle fasst die hier anzugebenden Informationen zusammen. Die Informationen werden in einer Section mit zwei geschachtelten Unterabschnitten angegeben. Der Section-Code für den Hauptabschnitt ist SMBU (DRV-Formularabschnitte), der Abschnitt über die letzte berufliche Tätigkeit hat den Code 21847-9 (LOINC), der Abschnitt zu positivem und negativem Leistungsvermögen erhält den Code SMLV (DRV-Formular-abschnitte).
Die Informationen werden in Listenform in Level 2 dargestellt. Zusätzlich sind die Informationen auch als Observation in Level 3 anzugeben.
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Letzte berufliche Tätigkeit
Dies umfasst die letzte berufliche Tätigkeit im Klartext sowie eine kategorisierte Beurteilung des zeitlichen Umfangs, in dem die letzte berufliche Tätigkeit ausgeübt werden kann.
Abbildung 8: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungsbericht zur letzten beruflichen Tätigkeit
Die Kategorien können der folgenden Tabelle entnommen werden.
Tabelle 20: Codes für DRV-Zeitumfang (OID: 1.2.276.0.76.5.372)
Auf Level 3 wird dieser Sachverhalt als eine Observation dargestellt, die die letzte berufliche Tätigkeit im value Attribut (Datentyp ST) angibt. Der Code dieser Beobachtung ist 21847-9 (LOINC). Daran ist über eine entryRelationship der Zeitumfang assoziiert.
CODEFRAGMENT
Positives und negatives Leistungsvermögen, Beschreibung des Leistungsvermögen, Zeitumfang
Positives und negatives Leistungsvermögen wird in Level 1 in der Form von Listen angegeben. Jedes ausgewählte Item wird zudem in Level 3 als Observation dargestellt.
Abbildung 9: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungsbericht zum Leistungsvermögen
Tabelle 21: Codes für DRV-Leistungsvermögen (OID: 1.2.276.0.76.5.373)
Zudem sind die Beschreibung des Leistungsvermögens und der Zeitumfang (Codes für DRV-Zeitumfang siehe Tabelle 20) anzugeben.
Abbildung 10: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungsbericht zum Zeitumfang
CODEFRAGMENT
Dokumentation therapeutischer Leistungen (Blatt 1b)
Die folgende Tabelle fasst die hier anzugebenden Informationen zusammen. Der Section-Code für diesen Abschnitt ist KTLS (DRV-Formularabschnitte).
Kardinalitäten und Konformanz | |
Hier kommen noch Felder rein |
Die Informationen werden in Tabellenform in Level 1 dargestellt. Zusätz-lich sind die KTL-Angaben auch als Procedure in Level 3 anzugeben. Diese enthält den eigentlichen KTL-Schlüssel im code Attribut, Dauer und Anzahl sind als qualifier anzugeben. Falls Erläuterungen gegeben werden sollen, können diese an das Ende der Tabelle gestellt werden. Hierzu wird ein entsprechender Text mit <paragraph> gekennzeichnet.
code KTL-Schlüssel CD CWE [1..1]
Hiermit wird der Typ der Leistung spezifiziert. Für die Codierung der Pro-zeduren muss der jeweils aktuelle KTL-Schlüssel in der deutschen Fassung, z. B. KTL 2007, benutzt werden. Dauer und Anzahl werden mittels Kindelemente zum Code als qualifier angegeben.
qualifier Dauer bzw. Anzahl nach KTL CE CWE [1..1]
Für die Kategorien der Dauer der Leistung ist folgende Codetabelle verbindlich.
Tabelle 22: Codes für DRV-KTLDauer (OID: 1.2.276.0.76.5.360)
Die Anzahl der Leistungen wird ebenfalls als Code übermittelt, d.h. „01“ steht für 1x, „07“ für 7x, „14“ steht für 14x usw. Die OID für die codierte Anzahl ist 1.2.276.0.76.5.361.
Tabelle 23: Codes für DRV-KTLAnzahl (OID: 1.2.276.0.76.5.361). Es handelt sich hier um einen Code, daher sind führende Nullen Bestandteil des Codes und deren Angabe erforderlich.
Abbildung 11: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungsbericht zur Leistungsdokumentation
CODEFRAGMENT
Da der Originaltext immer mitgegeben wird (Level 1) und bei der Einstufung von Bedeutung ist, wird dieser in Level 1 markiert (<content> Elemente) und in Level 3 über originalText referenziert.
originalText Bezug zum Originaltext in Level 1
CODEFRAGMENT
Beispielfragment
CODEFRAGMENT
Arztbericht (Blatt 2 ff.)
Für den nicht standardisierten Teil des Ärztlichen Entlassungsberichts haben sich die Rentenversicherungsträger auf eine einheitliche Gliederung verständigt. Sie umfasst folgende elf Punkte:
- Allgemeine und klinische Anamnese
- Jetzige Beschwerden und Beeinträchtigungen in Beruf und Alltag
- Gegenwärtige Therapie
- Allgemeine Sozialanamnese
- Arbeits- und Berufsanamnese
- Aufnahmebefund, Vorbefunde, ergänzende Diagnostik
- Therapieziele in der Rehabilitation
- Rehabilitationsverlauf
- Rehabilitationsergebnis
- Sozialmedizinische Epikrise
- Nachsorgeempfehlungen
Die einzelnen Abschnitte sind in CDA jeweils als Sections wiedergegeben und jede Section ist über den section.code maschinenlesbar gekennzeichnet (siehe Tabelle 10). In diesen Abschnitten sind auch entries (Level 3) zulässig, aber zurzeit nicht erforderlich.
Allgemeine und klinische Anamnese
Dieser Abschnitt wird bei section.code durch den Code 11329-0 (LOINC) gekennzeichnet.
Jetzige Beschwerden und Beeinträchtigungen in Beruf und Alltag
Dieser Abschnitt wird bei section.code durch den Code RJBB gekennzeichnet.
Gegenwärtige Therapie
Dieser Abschnitt wird bei section.code durch den Code 29554-3 (LOINC) gekennzeichnet.
Allgemeine Sozialanamnese
Dieser Abschnitt wird bei section.code durch den Code 29762-2 (LOINC) gekennzeichnet.
Arbeits- und Berufsanamnese
Dieser Abschnitt wird bei section.code durch den Code 11340-7 (LOINC) gekennzeichnet.
Aufnahmebefund, Vorbefunde, ergänzende Diagnostik
Dieser Abschnitt wird bei section.code durch den Code RAAD gekennzeichnet.
Therapieziele in der Rehabilitation
Dieser Abschnitt wird bei section.code durch den Code RTHZ gekennzeichnet.
Rehabilitationsverlauf
Dieser Abschnitt wird bei section.code durch den Code RRVL gekennzeichnet.
Rehabilitationsergebnis
Dieser Abschnitt wird bei section.code durch den Code RRER gekennzeichnet.
Sozialmedizinische Epikrise
Dieser Abschnitt wird bei section.code durch den Code RSME gekennzeichnet.
Nachsorgeempfehlungen
Dieser Abschnitt wird bei section.code durch den Code RNSE gekennzeichnet.
Beispielfragment
Beispiel-Dokumente sind in den Supporting Documents (siehe Kapitel 7 „Unterstützende Dokumente“ unter Beispieldokumente).