IG:Ärztlicher Reha-Entlassungsbericht

Der Ärztliche eReha-Entlassungsbericht
Einheitlicher Entlassungsbericht in der medizinischen Rehabilitation der gesetzlichen Rentenversicherung
auf der Basis der HL7 Clinical Document Architecture Release 2

Ärztlicher Reha-Entlassungsbericht

Implementierungsleitfaden

vorgelegt von:
HL7 Deutschland, DRV-Bund

Abgestimmt

Version:	1.10
Datum:	23. November 2009
Status:	Abgestimmt
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2009-2014: HL7 Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
1.10	23.11.2009	Abgestimmt	Deutschland
		[download]

Kontributoren
	Deutsche Rentenversicherung Bund	Berlin

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 Konformanz-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
	Konformanz-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.

Regel CDLC: Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben).

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