Ärztlicher Reha-Entlassungsbericht

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
Zeile 100: Zeile 100:
  
 
==Konformanz==
 
==Konformanz==
Ein zu diesem Leitfaden konformer eReha-Entlassungsbericht ist zunächst ein valides CDA Release 2 XML-Dokument mit Header und Body. Ein kon-former 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.
+
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).  
+
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.
 
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.
 
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.
 
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 elek¬tronischen Dokuments gemeint und nicht notwendigerweise auch eine erfolgreich durchgeführte Validierung bzw. Zertifizierung.
+
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==
 
==Zertifizierung==
Zeile 114: Zeile 114:
 
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.
 
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.
 
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.  
+
'''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.
+
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==
 
==Bezug zum HL7 Version 3 Nachrichtenaustausch==
Zeile 121: Zeile 121:
 
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.
 
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.
 
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.
 +
 +
<pre style="color:red">
 +
Tabelle 1: Mapping der Items des Ausfüll-Leitfadens ([drvALF]) nach CDA R2 Header und Body
 +
</pre>
 +
 +
==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.
 +
 +
<pre style="color:red">
 +
Tabelle 2: Übersicht über die im Kontext Reha-Entlassungsbericht benutzbaren CDA-Header-Elemente, deren Datentyp bzw. Bedeutung und deren Kardinalität
 +
</pre>
 +
 +
==typeId-Element==
 +
Nach dem Root-Element ClinicalDocument muss das folgende, zurzeit konstante XML Element in einem CDA Release 2 Dokument enthalten sein.
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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:
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || Regel TPID: Die templateID ist wie im obigen XML Fragment gezeigt anzugeben.
 +
|}
 +
 +
==Dokumenten-Id==
 +
<pre style="color:red">
 +
id Dokumenten-Id
 +
II [1..1]
 +
</pre>
 +
 +
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.
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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.''
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
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==
 +
<pre style="color:red">
 +
code Dokumententyp
 +
CE CWE [1..1]
 +
</pre>
 +
 +
Ü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.
 +
 +
<pre style="color:red">
 +
Tabelle 3: Vokabeldomäne (Auszug) für ClinicalDocument.code
 +
(OID: 2.16.840.1.113883.6.1 [LOINC]).
 +
</pre>
 +
 +
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.
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
==Zusätzliche Dokumenttyp-Bezeichnung==
 +
 +
<pre style="color:red">
 +
title zusätzliche Dokumententyp-Bezeichnung
 +
ST [0..1]
 +
</pre>
 +
 +
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.
 +
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
==Erstellungsdatum des Dokuments==
 +
<pre style="color:red">
 +
effectiveTime Erstellungsdatum des Dokuments
 +
TS [1..1]
 +
</pre>
 +
 +
Das verpflichtende Erstellungsdatum der Dokumentation (Dokument) wird in effectiveTime als Zeitpunkt wiedergegeben.
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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.''
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
==Vertraulichkeit des Dokuments==
 +
<pre style="color:red">
 +
confidentialityCode Vertraulichkeitsgrad
 +
CE CWE [1..1]
 +
</pre>
 +
 +
Hier wird der Vertraulichkeitsgrad des Dokuments codiert. Zugelassen sind folgende Codes:
 +
 +
<pre style="color:red">
 +
Tabelle 4: Vokabel Domäne (Auszug) für ClinicalDocument.confidentiali-tyCode (OID: 2.16.840.1.113883.5.25)
 +
</pre>
 +
 +
''Im folgenden Beispiel sind normale Vertraulichkeitsmaßregeln für das Dokument gültig.''
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
==Sprache des Dokuments==
 +
<pre style="color:red">
 +
languageCode Sprache des Dokuments
 +
CS CNE [0..1]
 +
</pre>
 +
 +
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.
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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).
 +
|}
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
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==
 +
<pre style="color:red">
 +
setId Set-Kennung des Dokuments
 +
II [0..1]
 +
versionNumber Versionsnummer
 +
INT [0..1]
 +
</pre>
 +
 +
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.
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
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.
 +
 +
<pre style="color:red">
 +
Abbildung 3: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungsberichts zu Rehabilitandendaten
 +
</pre>
 +
 +
{|
 +
| [[Datei:Information_icon.svg|50px]] || 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.
 +
 +
<pre style="color:red">
 +
Abbildung 4 Klassen rund um weitere Beteiligte (participants)
 +
</pre>
 +
 +
 +
<pre style="color:red">
 +
id Versicherungsnummer
 +
II [1..1]
 +
</pre>
 +
 +
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.
 +
 +
<pre style="color:red">
 +
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.
 +
</pre>
 +
 +
<pre style="color:red">
 +
code Klassifizierung der Versicherung
 +
CE CWE [0..1] <= RoleCode
 +
</pre>
 +
 +
<pre style="color:red">
 +
Tabelle 6: Vokabel Domäne for participant.associatedEntity.code
 +
</pre>
 +
 +
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.
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
'''''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.
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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.
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || Kardinalitäten und Konformanz
 +
|-
 +
| Hier kommen noch Felder rein
 +
|}
 +
 +
{|
 +
| [[Datei:Information_icon.svg|50px]] || Hinweis: Die Rentenversicherungsträger sind in ihrer Eigenschaft als Kostenträger zur Datensparsamkeit verpflichtet. Der Geburtsort ist im Kontext des Entlassungsberichts (bisher) nicht relevant.
 +
|}
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
===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).
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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).
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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).
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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.
 +
 +
<pre style="color:red">
 +
Abbildung 5: Ausschnitt aus dem papiernen ärztlichen Reha-Entlassungs-berichts zur Rehabilitationseinrichtung
 +
</pre>
 +
 +
{|
 +
| [[Datei:Conformance.svg|50px]] || 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.
 +
 +
<pre style="color:red">
 +
Tabelle 7: Ausschnitt aus der Tabelle Anhang II „Fachabteilungssschlüssel der Rehabilitationseinrichtungen“ OID 1.2.276.0.76.5.362 (siehe [drvALF]).
 +
</pre>
 +
 +
===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.
 +
 +
<pre style="color:red">
 +
code Klassifikation des Aufenthaltes
 +
CE CWE [0..1] <= ActEncounterCode
 +
</pre>
 +
 +
Dieser Code wird benutzt, um den Aufenthalt zu klassifizieren. Hier sind momentan die folgenden Codes zu verwenden.
 +
 +
<pre style="color:red">
 +
Tabelle 8: Vokabel Domäne für EncompassingEncounter.code
 +
</pre>
 +
 +
<pre style="color:red">
 +
effectiveTime Zeitraum des Aufenthaltes
 +
IVL<TS> [1..1]
 +
</pre>
 +
 +
Die verpflichtende Aufenthaltsperiode wird im effectiveTime Attribut angegeben. Dies ist in der Regel ein Zeitintervall.
 +
 +
<pre style="color:red">
 +
dischargeDispositionCode Entlassungsform
 +
CE CWE [0..1] <= DRV-Entlassungsform
 +
</pre>
 +
 +
Die Angabe zur Entlassungsform wird codiert (DRV-Entlassungsform) im dischargeDispositionCode wiedergegeben.
 +
 +
<pre style="color:red">
 +
Tabelle 9: Vokabel Domäne for EncompassingEncounter.discharge-DispositionCode mit den Codes zur DRV-Entlassungsform (OID: 1.2.276.0.76.5.364)
 +
</pre>
 +
 +
Eine Liste der Aufenthalte wie im Blatt 1 des Formulars sind im CDA Body aufgeführt (siehe dort).
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
==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.
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
{|
 +
| [[Datei:Logo-hl7int.jpg|50px]] || 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).
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>
 +
 +
===Verwaltende Organisation===
 +
Die Organisation (custodian), die für die Verwaltung des Dokuments verantwortlich ist, muss verpflichtend in der entsprechenden Klasse wiedergegeben werden.
 +
 +
<pre style="color:red">
 +
hier kommt noch ein Code-Fragment rein
 +
</pre>

Version vom 19. April 2015, 13:46 Uhr


Abstimmungsdokument 
Version Datum Status Realm
1.10 23.11.2009 Si-confirm.svg Abgestimmt Flag de.svg Deutschland
Document PDF.svg [download]
Kontributoren 
Logo-drvbund.jpg Deutsche Rentenversicherung Bund Berlin

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.

Rehaaformular.jpg

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.

Information icon.svg Hinweise
Faq.svg häufig gestellte Fragen und Antworten (FAQs)
Issue.svg offene Punkte allgemein
Logo-hl7int.jpg offene Punkte in Bezug auf HL7 als Standard
Conformance.svg 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
Conformance.svg 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
Conformance.svg 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.

Conformance.svg 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.

Conformance.svg 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.

Conformance.svg 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
Information icon.svg 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
Conformance.svg 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.

Conformance.svg Kardinalitäten und Konformanz
Hier kommen noch Felder rein
Information icon.svg 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
Conformance.svg 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
Conformance.svg 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
Conformance.svg 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
Conformance.svg 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
Logo-hl7int.jpg 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