IG:Arztbrief 2014

{{{Title}}}

Arztbrief 2012

Implementierungsleitfaden

vorgelegt von:
HL7-Deutschland

in Arbeit

Version:	01
Datum:	27. Januar 2013
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2013: HL7 Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
01	??.??.????	Entwurf	Deutschland
		noch kein download verfügbar

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Impressum

Dieser Leitfaden ist im Rahmen des Interoperabilitätsforums und den Technischen Komitees von HL7 Deutschland e. V. sowie der entsprechenden Projektgruppen zusammengestellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums und der Technischen Komitees von HL7 Deutschland e. V.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Autoren

• Dr. Kai U. Heitmann (KH), Heitmann Consulting and Services, Hürth
• Dr. Frank Oemig (FO), Agfa HealthCare GmbH, Bonn
• Daniel Hellmuth (DH), Cerner Deutschland GmbH, Berlin
• Mathias Aschhoff (MA), ZTG Gmbh, Bochum

Mit Beiträgen von

• Jürgen Brandstätter, HL7 Austria
• Dr. Rainer Fehling, Kassenärztliche Vereinigung Westfalen-Lippe
• Dr. Erich Gehlen, DURIA e.G.
• Dr. Christof Gessner, gematik
• Dr. Christian Herrmann, KRH Klinikum Region Hannover
• Michael Hofer, iSOFT Health GmbH
• Tarik Idris, InterComponentWare AG
• Dr. Stefan Sabutsch, HL7 Austria
• Dr. Norbert Sigmond, DIMDI
• Prof. Dr. Martin Staemmler, FH-Stralsund
• Prof. Dr. Sylvia Thun, HS Niederrhein
• Lars Treinat, ZTG GmbH

Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

Die erste Version dieses Dokumentes wurde 2005 vom Verband der Hersteller von IT für das Gesundheitswesen (VHitG, heute bvitg) entwickelt und ist unter dem Namen "VhitG-Arztbrief" bekannt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.
Der Inhalt dieser Spezifikation ist öffentlich.
Der VHitG-Arztbrief basiert auf den Spezifikationen der Arbeitsgemeinschaft SCIPHOX GbR mbH und dem national adaptierten HL7-Standard der „Clinical Document Architecture (CDA)".

Die hier erarbeitete Fassung ist die Weiterentwicklung davon. Sie ist u.a. auch abgeglichen mit den ELGA-Spezifikationen (http://elga.gov.at) in Österreich.

Näheres unter http://www.hl7.de und http://www.hl7.org. Für alle veröffentlichten Dateien mit einem CDA-Bezug gilt ferner: Alle abgestimmten und veröffentlichten Spezifikationen wie Implementierungsleitfäden, Stylesheets und Beispieldateien sind frei verfügbar und unterliegen keinerlei Einschränkungen, da die Autoren auf alle Rechte, die sich aus der Urheberschaft der Dokumente ableiten lassen, verzichten.

Alle auf nationale Verhältnisse angepassten und veröffentlichten CDA-Schemas können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
Aus der Nutzung ergibt sich kein weiter gehender Anspruch gegenüber dem VHitG bzw. bvitg, zum Beispiel eine Haftung bei etwaigen Schäden, die aus dem Gebrauch der Spezifikationen bzw. der zur Verfügung gestellten Dateien entstehen.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Einleitung

Motivation

Dieser Leitfaden soll als generische Grundlage für Arztbriefe aller Art dienen und damit die Ablösung der papiergebundenen Arztbriefe ermöglichen. Entsprechende Anwendungsbeispiele finden sich im Anhang dieses Leitfadens und dienten als Grundlage für die Vollständigkeit der Analyse.

Im Rahmen der Kommunikation zwischen Akteuren im Gesundheitswesen ist der Arztbrief als „Kondensat ärztlichen Handelns" von überragender Bedeutung. Das Ziel dieses Dokuments ist die Beschreibung des elektronischen Arztbriefs. Ein derartiger Arztbrief enthält die medizinisch relevanten Teile der Geschichte eines Patienten über einen bestimmten Zeitraum und ist gedacht zur Übermittlung zwischen Gesundheitsdienstleistern (primär: „Leistungserbringer"). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA-Elementen.

Zielgruppe

Der Leserkreis dieses Dokuments sind Software-Entwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld des „Arztbriefs" betraut sind.

Diese Spezifikation definiert zusätzliche Festlegungen, Einschränkungen und Bedingungen für die CDA-Elemente in „Arztbrief"-Dokumenten, die als „stationärer Entlassbrief" von Kliniken im Bereich deutscher Gesetzgebung (SGB) an Niedergelassene (auch: REHA-Einrichtungen) oder als „(Fach ) Arztbrief" vom niedergelassenen (Fach )Arzt an niedergelassene Kollegen oder Krankenhäuser versendet werden sollen.

Beispiele für konforme Dokumenten-Fragmente werden innerhalb dieses Leitfadens aufgeführt. Die Spezifikation von Infrastrukturen, Workflows, Nachrichten, Prozeduren oder Protokollen zur Übermittlung der Arztbriefe ist nicht im Fokus dieses Dokuments.

Ein elektronischer Arztbrief wird vom Gesetzgeber nach §291a ff. SGB V im Rahmen der Einführung der elektronischen Gesundheitskarte als freiwillige Anwendung betrachtet. Es ergeben sich mit Einführung einer nationalen Telematikinfrastruktur verschiedene Vorgaben für einen solchen Arztbrief, die in diesem Implementierleitfaden nicht umfänglich dokumentiert sein sollen. An den nötigen Stellen wird versucht, Hinweise auf relevante Implikationen und Überschneidungen zu geben.

Dokumente im Gesundheitswesen

Wir sind es in der medizinischen Welt gewohnt, eine Dokumentenansicht von medizinischen Beobachtungen zu verfassen, reich an Text, den Zusammenhang des Geschehens zusammenstellend und zusammenfassend. Dieser Kontext – z. B. das Ergebnis einer Laboruntersuchung im Lichte einer speziellen Medikamentenbehandlung – muss dauerhaft erhalten bleiben, da er wichtige medizinische Zusammenhänge zwischen Einzelinformationen darstellt. Die Krönung dieses „in den Kontext stellen" von Informationen über die Zeit stellt zum Beispiel der Arztbrief dar. Gleichzeitig muss der medizinische Inhalt leicht verfügbar sein und ohne große technische Barrieren sichtbar gemacht werden können. Dies ist unabdingbar für die Akzeptanz von und das Vertrauen in Technologie bei den Benutzern, den Ärzten und Pflegekräften. Mit der heutigen Papierwelt wurde dies bis zu einem gewissen Grade erreicht, es muss aber für das Einführen des elektronischen Gegenstücks ebenso gelten. „Interoperabilität" ist unter anderem gekennzeichnet durch gemeinsam verstandene Definitionen, wie zum Beispiel die des Patienten und der zu ihm bekannten (klinischen/medizinischen) Informationen, sowie deren Wiederverwendbarkeit. Hierbei kann man zwei Gegenpole beobachten. Zum einen ist da die Facette der Mensch-zu-Mensch Kommunikation. Dies wird z. B. erreicht durch das Versenden von Papier und Formularen. Jeder weiter führende elektronische Ansatz muss auch diese Art der Interoperabilität gewährleisten. Die Möglichkeit zur Signatur muss auch in elektronischer Form bestehen bleiben. Darüber hinausgehend wäre das andere Ende die Anwendungs-Interoperabilität. Dies beinhaltet die Wiederverwendbarkeit von Informationen, Kontext-abhängige Analysemöglichkeiten und angemessenes Speichern und Verwalten von klinischen Dokumenten.

Im Rahmen der bvitg-Initiative „Intersektorale Kommunikation" wird der Arztbrief als generisches Dokument beschrieben. So wird beispielhaft die Entlassung nach durchgeführter Behandlung in einem Krankenhaus o. ä. zur Weiterbehandlung durch den Niedergelassenen (Dokument „stationärer Entlassungsbrief") definiert, wie auch der ambulante Arztbrief des Facharztes zur Weiterbehandlung über den Hausarzt oder im Krankenhaus.

Im Falle der Entlassung/Ende der Behandlung werden die Behandlungsdaten übermittelt. Der Kurzbericht bei Entlassung/Behandlungsende ist als sofortige Mitteilung an den einweisenden/überweisenden Arzt am Ende der Konsultation/Krankenhausaufenthaltes konzipiert und beinhaltet neben der Patientenidentifikation einen Kurzbericht zusammen mit Diagnosen und Therapien, Befunden sowie eine Zusammenfassung. Beispiel: Termine zur Wiedervorstellung oder Nachsorgetermine.

In einer späteren Ausbaustufe kann mit überwiegend den gleichen Teilen wie im Arztbrief auch die Einweisung/Überweisung definiert werden. Das dahinterliegende Szenario: Der Patient geht vom Niedergelassenen in ein Krankenhaus zur Mitbehandlung (Dokument „Einweisung") bzw. wird von einem Niedergelassenen zum anderen überwiesen (Dokument „Überweisung").

Diese Fälle werden allgemein teilweise von den Komponenten im „Arztbrief" abgedeckt, wie zum Beispiel: Aktuelle Medikation, die auch in Ein-/Überweisungen vorkommen kann. Beim Arztbrief handelt es sich dementsprechend um ein Dokument, das in Anlehnung an die realen Gegebenheiten zwischen den Akteuren und Systemen ausgetauscht wird und das dauerhaft existiert, d.h. es wird dauerhaft gespeichert. Dies steht im Gegensatz zum Austausch von Nachrichten, bei dem der Nachrichten-Inhalt vom Empfangssystem in der Regel extrahiert, in der eigenen Datenbank gespeichert und die Nachricht als solche danach gelöscht wird.

Abgrenzung

Dieser Leitfaden deckt eine Reihe von Themen nicht ab. Dazu gehören:

• dieser Leitfaden beschreibt den Arztbrief (Discharge summarization note [physician], LOINC-Code 11490-0); andere Dokumententypen wie z. B. OP-Berichte sind hiermit nicht beschrieben (aber dem Prinzip nach gleich aufgebaut).
• digitale Signatur und andere Sicherheitsaspekte wie Verschlüsselung etc.; der geneigte Leser möge hierzu auch die Ausarbeitung zu XML-Signaturen für CDA (Elektronische Signatur von Arztbriefen) konsultieren.
• Transport von CDA-Dokumenten
• Verwendung von Stylesheets

Hilfreich ist in diesem Zusammenhang das IHE-Cookbook.

Aufbau dieses Implementierungsleitfadens

Die Spezifikation Arztbrief 2014 basiert auf dem VHitG-Arztbrief von 2006 (v1.5) und berücksichtigt hierbei die neueren Entwicklungen und Methodiken zur Erstellung von Leitfäden, beispielsweise die Nutzung von Templates oder speziellen Ausprägungen von Datentypen.

Dieser Implementierungsleitfaden verfolgt drei Ziele. Neben dem grundlegenden Konzept und dessen Begründung sollen die zugrunde liegenden Modelle ausführlich beschrieben werden, die für die Kommunikation genutzt werden. Aus ihnen leiten sich die Nachrichten/Dokumente in ihrem Aufbau und ihrer Semantik ab. Gleichzeitig können die Modelle Hinweise liefern für den Aufbau von Datenbanken oder Anwendungssystemen, die in diesem Kommunikationsszenario als Sender oder Empfänger fungieren.

Zum dritten soll dieser Leitfaden praktische Implementierungshilfen geben. Dies kann bis zu einem gewissen Detaillierungsgrad geschehen und ist in der Regel mit Beispielen angereichert, so dass ein Programmierer einer Schnittstelle das nötige Wissen erlangen kann, wie die Schnittstelle aufzubauen ist. Auf dieser Basis werden schließlich die tatsächlichen Informationsinhalte beschrieben und die Beziehung an die entsprechenden Klassen und Attribute im Modell aufgezeigt. Daraus folgen dann Dokumente und zugehörige Beispiele.

Zudem sind in diesem Leitfaden einige Anhänge aufgenommen, die als Referenzmaterial dienen können und Hinweise geben für eine erfolgreiche Implementierung.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Transportaspekte

Interaktionsdiagramm

In diesem Leitfaden geht es um die Präzisierung des Aufbaus von Dokumenten (hier: der Arztbrief), d.h. wie diese inhaltlich strukturiert sind. Die Prinzipien der Gliederung gelten aber auch für andere Arten von Dokumenten wie Ein-/Überweisungen, Befunde, etc.

Im Allgemeinen wird ein CDA-Dokument von einer Anwendung in einem bestimmten Kontext erzeugt und dann als ganzheitliches Objekt übertragen. Dies kann auf unterschiedlichen Wegen passieren (bspw. als Datei, als Binärobjekt in einer Email oder als Objekt einer Akte wie EFA, eEPA oder EGA), diese werden hier aber nicht spezifiziert. Dieses Objekt wird dann letztendlich von einer – oder mehreren – Anwendungen konsumiert:

Interaktionsdiagramm

Dokumentenaustausch

Für den Austausch der Dokumente gibt es mehrere Möglichkeiten, zu denen eine Reihe von konkreten Vorgaben existieren - insbesondere bei IHE ITI -, die hier nur kurz genannt werden sollen:

• IHE ITI
  • die Integrationsprofile XDS, XDM und XDR
• Telematikinfrastruktur (in Vorbereitung) mit KOM-LE
• KV-Connect
• Safemail
• FTP
• ...

Diese Liste ist nicht vollständig und soll nur als Beispiel dienen.

Rechtssichere Übertragung

Eine eAU kann papierbegleitend, aber auch papierersetzend umgesetzt werden. Im letzteren Fall ist diese mit einer rechtssicheren elektronischen Signatur (fortgeschritten oder QES) zu ergänzen:

• Datenschutz-/-sicherheit
• IT-Sicherheit
• Verschlüsselung
• Signaturen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Struktureller Aufbau

Das statische Modell umfasst

• Die zentrale Klasse ClinicalDocument und den Header mit einer Reihe von assozierten Header-Klassen (Patient, Autor, Empfänger, etc.) und
• den CDA-Body mit Section und Entries.

Grober XML-Aufbau von CDA-Dokumenten

Der XML-Namespace für CDA Release 2 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser muss in geeigneter Weise in jeder XML Instanz genannt werden. In diesem Leitfaden werden typischerweise keine namespace-Präfixe (z. B. "hl7:" oder "cda:") genutzt (Verwendung von default namespace), die Ausgaben der Templates aus ART-DECOR verwenden das Präfix "hl7:".

Für die Arztbrief XML-Dokumente auf der Basis von CDA Release 2 ist der Zeichensatz UTF-8 vorgeschrieben. Arztbrief XML-Dokumente beginnen mit dem Wurzelelement ClinicalDocument, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.

<?xml version="1.0"? encoding="UTF-8">
<ClinicalDocument
    xmlns="urn:hl7-org:v3"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
    <!-- CDA Header -->
              … siehe Beschreibung CDA R2 Header
    <!-- CDA Body -->
    <component>
        <structuredBody>
              … siehe Beschreibung CDA R2 Body
        </structuredBody>
    </component>
</ClinicalDocument>

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

CDA-Header-Assoziationen

Der Header umfasst neben bereits aufgelisteten einfachen Metadaten noch folgende Beziehungen, diese sind hier der Übersicht halber aufgelistet. Die Verwendung im Arztbrief wird unter Arztbriefstruktur aufgelistet und deren genauen Details später noch genauer spezifiziert.

CDA-Header-Assoziationen
Element (Sequenz)	Bedeutung
Participations
recordTarget	Patient
author	Autor / Urheber
dataEnterer	Datentypist
informant	Informant
custodian	verwaltende Organisation
informationRecipient	Empfänger
legalAuthenticator	vor dem Gesetz verantwortlicher Unterzeichner
authenticator	weitere Unterzeichner
participant	Beteiligte
Act Relationships
inFulfillmentOf	In Erfüllung von, –noch nicht verwendet–
documentationOf	Dokumentierte Gesundheitsdienstleistung, –noch nicht verwendet–
relatedDocument	Bezug zu vorhergehenden Dokumenten
authorization	Einverständniserklärung
componentOf	Informationen zum Patientenkontakt

CDA-Header-Assoziationen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Patient (recordTarget - generisch)

Id	1.2.276.0.76.10.2001	Gültigkeit	2013‑07‑10
Status	Aktiv	Versions-Label
Name	Header​Record​Target	Bezeichnung	CDA recordTarget
Beschreibung Das recordTarget repräsentiert die Person, über die dokumentiert wird. recordTarget umfasst neben der Identifikation und dem Namen, Geschlecht, Adressen etc. auch optionale Zusatzangaben wie zum Beispiel Geburtsort und Sprachfähigkeiten.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.276.0.76.10.90030 Inklusion Personenname DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.101 CDA recordTarget (DYNAMIC) ref ad1bbr-
Beispiel	Standard-Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>    <addr use="HP">       <streetName>Musterstraße</streetName>      <houseNumber>15</houseNumber>      <postalCode>50825</postalCode>      <city>Köln</city>    </addr>    <telecom use="HP" value="tel:+49(221)7812220"/>    <patient classCode="PSN" determinerCode="INSTANCE">       <name>         <given>Marie</given>        <family>Müller</family>      </name>      <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19700924"/>      <birthplace>         <place>           <addr>             <city>Köln</city>          </addr>        </place>      </birthplace>    </patient>  </patientRole></recordTarget>
Beispiel	Maximal-Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>    <id root="1.2.276.0.76.4.8" extension="8003004447"/>    <addr use="HP">       <streetName>Musterstraße</streetName>      <houseNumber>15</houseNumber>      <postalCode>50825</postalCode>      <city>Köln</city>    </addr>    <telecom use="HP" value="tel:+49(221)7812220"/>    <telecom use="HP" value="mailto:MuellerMar@gmx.de"/>    <patient classCode="PSN" determinerCode="INSTANCE">       <name>         <given>Marie</given>        <family>Müller</family>      </name>      <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19700924"/>      <!-- Familienstand des Patienten -->       <maritalStatusCode code="M" displayName="Married" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7 MaritalStatusCode"/>      <!-- Religionszugehörigkeit des Patienten-->       <religiousAffiliationCode code="1077" displayName="Protestant" codeSystem="2.16.840.1.113883.5.1076"/>      <!-- Vormund/Sachwalter des Patienten -->       <guardian>         <addr use="HP">           <streetName>Musterstraße</streetName>          <houseNumber>15</houseNumber>          <postalCode>50825</postalCode>          <city>Köln</city>        </addr>        <telecom use="HP" value="..."/>        <guardianPerson>           <name>             <given>Marius</given>            <family>Müller</family>          </name>        </guardianPerson>      </guardian>      <birthplace>         <place>           <addr>             <city>Köln</city>          </addr>        </place>      </birthplace>      <languageCommunication>         <languageCode code="EN"/>        <modeCode code="ESP"/>        <proficiencyLevelCode code="G"/>        <preferenceInd value="true"/>      </languageCommunication>    </patient>  </patientRole></recordTarget>
Beispiel	Minimal-Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>  </patientRole></recordTarget>
Item DT Kard Konf Beschreibung Label hl7:recordTarget (Hea...get) @typeCode 0 … 1 F RCT @context​Control​Code 0 … 1 F OP   Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <!-- ... -->   </patientRole></recordTarget> hl7:patientRole 1 … 1 (Hea...get) @classCode 0 … 1 F PAT   Beispiel <patientRole classCode="PAT">   <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>  <patient classCode="PSN" determinerCode="INSTANCE">     <!-- ... -->   </patient></patientRole> hl7:id II 1 … * (Hea...get)   Beispiel <id extension="6245" root="2.16.840.1.113883.3.933"/><id extension="1543627549" root="1.2.276.0.76.4.1"/> hl7:addr AD 0 … * Adresse des Patienten (Hea...get)   Beispiel <addr use="HP">   <streetName>Dorfstraße</streetName>  <houseNumber>54</houseNumber>  <postalCode>51371</postalCode>  <city>Leverkusen</city></addr> hl7:telecom TEL 0 … * Kontaktdaten des Patienten (Hea...get)   Beispiel <telecom use="H" value="tel:+4930140400"/><telecom use="MC" value="tel:+492211234567"/><telecom value="mailto:herberthannes.mustermann@provider.de"/> hl7:patient 0 … 1 (Hea...get) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE   Beispiel <patient classCode="PSN" determinerCode="INSTANCE">   <name>     <!-- ... -->   </name>  <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>  <birthTime value="19541223"/></patient> Eingefügt 1 … 1 M von 1.2.276.0.76.10.90030 Personenname (DYNAMIC) hl7:name PN 1 … 1 M Die Reihenfolge der Namensbestandteile soll der typischen Schreibweise entsprechen. Zu beachten ist, dass prefix- und suffix-Elemente mit einem Leerzeichen enden müssen, wenn sie nicht unmittelbar an den folgenden Namensbestandteil anschließen sollen. (Hea...get)   Beispiel Dr. med. Sine Johanna Gräfin von Oberberg <name>   <prefix qualifier="AC">Dr. med. </prefix>  <given>Sine Johanna</given>  <prefix qualifier="NB">Gräfin </prefix>  <prefix qualifier="VV">von </prefix>  <family>Oberberg</family></name>   Beispiel Prof. Dr. med. Dr. rer. nat. Fritz Julius Karl Freiherr von und zu Rathenburg vor der Isar, MdB <name>   <prefix qualifier="AC">Prof. Dr. med. Dr. rer. nat. </prefix>  <given>Fritz</given>  <given>Julius</given>  <given>Karl</given>  <prefix qualifier="NB">Freiherr </prefix>  <prefix qualifier="VV">von und zu </prefix>  <family>Rathenburg vor der Isar</family>  <suffix>, MdB</suffix></name> hl7:prefix ENXP 0 … * Titel (Hea...get) wo [@qualifier='AC'] @qualifier set_cs 1 … 1 F AC hl7:given ENXP 0 … * Vorname (Hea...get) hl7:prefix ENXP 0 … * Namenszusatz (Hea...get) wo [@qualifier='NB'] @qualifier set_cs 1 … 1 F NB hl7:prefix ENXP 0 … * Vorsatzwort (Hea...get) wo [@qualifier='VV'] @qualifier set_cs 1 … 1 F VV hl7:family ENXP 0 … * Nachname (Hea...get) hl7:suffix ENXP 0 … * Suffix (Hea...get) hl7:administrative​Gender​Code CE 1 … 1 R Geschlecht (administrativ) des Patienten (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.1 Administrative Gender (HL7 V3) (DYNAMIC)   Beispiel <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/> hl7:birthTime TS.​DATE.​MIN 1 … 1 R Geburtsdatum des Patienten (Hea...get)   Beispiel <birthTime value="19491224"/> hl7:marital​Status​Code CE 0 … 1 Familienstand des Patienten (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12212 Marital Status (DYNAMIC)   Beispiel <maritalStatusCode code="S" displayName="Never Married" codeSystem="2.16.840.1.113883.5.2"/> hl7:religious​Affiliation​Code CE 0 … 1 Religionszugehörigkeit des Patienten (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19185 Religious Affiliation (DYNAMIC)   Beispiel <religiousAffiliationCode code="1077" displayName="Protestant" codeSystem="2.16.840.1.113883.5.1076"/> hl7:raceCode NP darf nicht verwendet werden (Hea...get) hl7:ethnic​Group​Code NP darf nicht verwendet werden (Hea...get) hl7:guardian 0 … * Vormund/Sachwalter des Patienten (Hea...get) hl7:addr AD 0 … 1 (Hea...get) hl7:telecom TEL 0 … * (Hea...get) Auswahl 1 … 1 Elemente in der Auswahl: hl7:guardian​Person hl7:guardian​Organization hl7:guardian​Person (Hea...get) hl7:name PN 1 … 1 M (Hea...get) hl7:guardian​Organization (Hea...get) hl7:name ON 1 … 1 M (Hea...get) hl7:birthplace 0 … 1 Geburtsort des Patienten (Hea...get)   Beispiel <birthplace>   <place>     <addr>Hamburg</addr>  </place></birthplace> hl7:place 1 … 1 M (Hea...get) hl7:addr AD 1 … 1 M (Hea...get) hl7:language​Communication 0 … * (Hea...get) hl7:language​Code CS 0 … 1 (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC) hl7:modeCode CE 0 … 1 (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12249 LanguageAbilityMode (DYNAMIC) hl7:proficiency​Level​Code CE 0 … 1 (Hea...get)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12199 LanguageAbilityProficiency (DYNAMIC) hl7:preference​Ind BL 0 … 1 (Hea...get)

1. WEITERLEITUNG cdaab2:Informant (informant) (Template)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Autor (author - generisch)

Id	1.2.276.0.76.10.2002	Gültigkeit	2013‑07‑10
Status	Entwurf	Versions-Label
Name	HeaderAuthor	Bezeichnung	CDA author
Beschreibung	Die Autor-Relation gibt den Urheber der Dokumentation und den Zeitpunkt der Autorenschaft wieder. Dies sind in der Regel Personen (Gesundheitsdienstleister) oder auch Geräte, die Daten erzeugen.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 2 Templates Benutzt als Name Version 1.2.276.0.76.10.90010 Inklusion CDA Person Elements DYNAMIC 1.2.276.0.76.10.90011 Inklusion CDA Organization Elements DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.102 CDA author (DYNAMIC) ref ad1bbr-
Beispiel	Autor ist eine Person <author typeCode="AUT">   <functionCode code="DISPHYS" displayName="discharging physician" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction"/>  <time value="20130407130000+0500"/>  <assignedAuthor classCode="ASSIGNED">     <assignedPerson classCode="PSN" determinerCode="INSTANCE">       <name>         <given>Marie</given>        <family>Müller</family>      </name>    </assignedPerson>    <representedOrganization>       <id root="2.16.840.1.113883.19.5"/>      <name>Beispiel Krankenhaus</name>    </representedOrganization>  </assignedAuthor></author>
Beispiel	Autor ist ein Gerät/Maschine <author typeCode="AUT">   <assignedAuthor classCode="ASSIGNED">     <assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">       <code>...</code>    </assignedAuthoringDevice>  </assignedAuthor></author>
Item DT Kard Konf Beschreibung Label hl7:author (Hea...hor) @typeCode 0 … 1 F AUT @context​Control​Code 0 … 1 F OP   Beispiel <author typeCode="AUT" contextControlCode="OP">   <time value="201306101654"/>  <assignedAuthor classCode="ASSIGNED">     <!-- ... -->   </assignedAuthor></author> hl7:functionCode CE 0 … 1 (Hea...hor)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC) hl7:time TS.​DATE.​MIN 1 … 1 gibt den Zeitpunkt an, an dem der Autor seinen Beitrag am Dokument beendet hat; dies kommt bei einem Autoren praktisch überein mit ClinicalDocument.effectiveTime (Hea...hor) hl7:assignedAuthor 1 … 1 (Hea...hor) @classCode 0 … 1 F ASSIGNED hl7:id II 1 … * (Hea...hor) hl7:code CE 0 … 1 Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin (Hea...hor) hl7:telecom TEL 0 … * (Hea...hor) Auswahl 1 … 1 Elemente in der Auswahl: hl7:assigned​Person hl7:assigned​Authoring​Device hl7:assigned​Person  … 1 (Hea...hor) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...hor) hl7:assigned​Authoring​Device  … 1 (Hea...hor) @classCode 0 … 1 F DEV @determiner​Code 0 … 1 F INSTANCE hl7:manufacturer​Model​Name SC 1 … 1 (Hea...hor) hl7:softwareName SC 1 … 1 (Hea...hor) hl7:represented​Organization 1 … 1 M (Hea...hor)   Beispiel <representedOrganization classCode="ORG" determinerCode="INSTANCE">   <name>     <!-- ... -->   </name></representedOrganization> Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 0 … * (Hea...hor) hl7:name ON 1 … 1 M (Hea...hor) hl7:telecom TEL 0 … * (Hea...hor) hl7:addr AD 0 … 1 (Hea...hor)

1. WEITERLEITUNG cdaab2:Unterzeichner gesetzlich verantwortlich (legalAuthenticator) (Template)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Verwaltende Organisation (custodian - generisch)

Id	1.2.276.0.76.10.2004	Gültigkeit	2020‑03‑29 Andere Versionen mit dieser Id: HeaderCustodian vom 2013‑07‑17 HeaderCustodian vom 2013‑07‑07
Status	Aktiv	Versions-Label
Name	HeaderCustodian	Bezeichnung	CDA custodian
Beschreibung	Verantwortliche Organisation für ein erstelltes Dokument (die das Dokument verwaltende Organisation). In der Regel ist es die erstellende Institution des Dokumentes.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Item DT Kard Konf Beschreibung Label hl7:custodian (Hea...ian) @typeCode 0 … 1 F CST   Beispiel <custodian typeCode="CST">   <assignedCustodian classCode="ASSIGNED">     <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">       <!-- ... -->     </representedCustodianOrganization>  </assignedCustodian></custodian> hl7:assignedCustodian 1 … 1 M (Hea...ian) @classCode 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M (Hea...ian) @classCode 0 … 1 F ORG @determiner​Code 0 … 1 F INSTANCE hl7:id II 1 … 1 M (Hea...ian) hl7:name ON 1 … 1 M (Hea...ian) hl7:telecom TEL 0 … 1 (Hea...ian) hl7:addr AD 0 … 1 (Hea...ian)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

CDA R2 Body

Allgemeiner Aufbau des Body

Während im CDA Header die Akteure und mehr oder weniger administrative Inhalte wie Informationen über das Dokument selbst, den Patienten, den Autor etc. festgelegt wurden, enthält der CDA Body des hier definierten Arztbriefes die eigentliche klinische Dokumentation und stellt den „menschenlesbaren" medizinischen Teil dar.

Der hier definierte Arztbrief besteht im Body entweder aus einem nonXMLBody oder einem structuredBody Element, das wiederum section Elemente aufweist, mit denen die Information strukturiert werden kann. Falls nur die Metainformationen (Header) strukturiert übertragen werden und der Body nur aus einem Dokument (z. B. PDF) besteht, sollte man nonXMLBody verwenden (CDA Level1), das Dokumente entweder referenziert oder eingebettet wiedergeben.

Danach zeichnet sich für den Arztbrief folgende Grobstruktur ab.

Variante 1 - unstrukturierter Body

<ClinicalDocument>
  <!-- CDA Header -->
       ... siehe Beschreibung CDA R2 Header
  <!-- CDA Body -->
  <component>
    <nonXMLBody>
      <text mediaType="application/pdf" representation="B64">
        sadsfFAETQETEdfgStreTdsfgSrgregWRTERtSFGwERtwtergq45ttGw5TW%TwtR%TG
        vbnbnDJDZwrGTarGFaerewFasFaGaERgGtRzRthsYDFfGeRTertwerfFgERT3$RT34r
        dfE$R%34ReFD34T34TG§$t§4%T3ER§4t5§4TWEWRt§$t5§$t§g§$rt§$tGF$§t§$t$t
        ...
        cwER"§$wer§$65$%gTGH5643FD§$KJDU21%ZuTz$%z3vXCvSDf2EQeGFE§rwFG3$T%$
        e545REG34T%$gtrfgeg=
      </text>
      <languageCode code="de-DE"/>
    </nonXMLBody>
  </component>
</ClinicalDocument>

Variante 2 - strukturierter Body

<ClinicalDocument>
  <!-- CDA Header -->
       ... siehe Beschreibung CDA R2 Header
  <!-- CDA Body -->
    <component>
        <structuredBody>
              ... CDA R2 Body
        </structuredBody>
   </component>
</ClinicalDocument>

nonXMLBody (Variante 1)

Wie bereits angedeutet gibt es die Möglichkeit, lediglich den Header zur Übermittlung von strukturierten Metadaten zu einem Arztbrief zu nutzen:

CDA nonXMLBody

Bei dieser Variante wird der Inhalt als Ganzes übermittelt. In diesem Fall besteht der Body lediglich aus einer verkürzten XML-Struktur, in der das Dokument eingebettet ist. Dann kann es allerdings nicht weiterverarbeitet und nur zur Anzeige mit einem geeigneten Viewer gebracht werden. In diesem Fall kommt ausschließlich die nonXMLBody-Section zum Einsatz.

structuredBody (Variante 2)

In der folgenden Grafik ist wiedergegeben, dass der CDA Body für den Arztbrief aus ein bis vielen Abschnitten (section) besteht. Diese können auch ineinander geschachtelt sein, um so – ähnlich wie in einem Buch – Unterabschnitte zu reflektieren. Als Beispiel ist hier ein „Kapitel" Anamnese zu nennen, das sich wiederum untergliedern könnte in „Eigenanamnese", „Familienanamnese", „Sozialanamnese" sowie „bisherige Operationen", „bisherige Impfungen" etc. In der Regel sind die Abschnitte mit Codes versehen (siehe unten). Manche Abschnitte sind mit zusätzlichen Einträgen (Komponenten) versehen, die RIM-Klassen entsprechen und hochstrukturierte Codierungen zulassen.

Zusammenfassend sind drei Typen von Abschnitten in der hier vorliegenden Arztbrief-Definition zu finden.

• Text in Abschnitten, die nicht mit Codes identifiziert sind, innerhalb eines Abschnitts mit optionalen Unterabschnitten (Level 1, s. u.)
• Text in Abschnitten, die mit Codes identifiziert sind, innerhalb eines Abschnitts mit optionalen Unterabschnitten (Level 2, s. u.)
• Text in Abschnitten und Unterabschnitten, zusätzlich mit codierten Einträgen, die RIM-Klassen entsprechen (Level 3, s. u.).

Übersicht über den Body-Teil des CDA-Dokuments. Die medizinische Dokumentation wird als Text in Abschnitten abgelegt, die vorzugsweise mit Codes identifiziert sind. Innerhalb eines Abschnitts kann es optionale Unterabschnitte geben, die eine weiter gehende Strukturierung ermöglichen. Für Diagnosen werden neben codierten Abschnitten auch hochstrukturierte Komponenten vorgesehen, die RIM-Klassen (z. B. Observation) entsprechen. Hier ist als Beispiel der Diagnose-Code für eine Entlass-Diagnose angedeutet.

Der structuredBody eines CDA Release 2 Dokuments setzt sich aus ein oder mehreren Komponenten zusammen, wobei jede Komponente wiederum aus einer oder mehreren Sektionen und gegebenenfalls aus einem oder mehreren „Entry"-Elementen (siehe Abschnitt „Level: 1 bis 3") besteht.

Das bedeutet unter anderem, dass ein CDA-Dokument dahingehend näher bestimmt werden kann, dass es spezifische Abschnitte, Paragrafen und andere Strukturbestandteile aufweisen muss. So kann ein Entlassbrief aus der Urologie beispielsweise ganz bestimmte Abschnitte beinhalten (Anamnese, Behandlung, Medikation, weiteres Vorgehen etc.), während ein OP-Bericht oder ein Pathologie-Befund ganz andere Erfordernisse bezüglich der Abschnitte und Strukturen haben kann bzw. muss.

Attribute von strukturierten Sections

Section.title: Titel des Abschnitts

Das section Element enthält einen optionalen Titel. Näheres regeln die entsprechenden spezialisierten Templates.

Section.text: Text des Abschnitts

Das section Element enthält eine narrative Beschreibung des Inhaltes und ist verpflichtend anzugeben.

Section.code: Klassifizierung des Abschnitts

Das section Element kann ein code Element enthalten, das den Inhalt des Abschnitts klassifiziert. Als Beispiel ist 10164-2 der LOINC Code für „History of Present Illness". Im Arztbrief sind zur primären Klassifikation ausschließlich LOINC Codes zugelassen. Alternative Codes können angegeben werden. Näheres regeln die entsprechenden spezialisierten Templates.

Section.languageCode: Sprache des Abschnitts

Jeder Abschnitt kann in einer anderen Sprache geschrieben sein. Dies wird im section-Element languageCode angegeben, wenn diese von der für das ganze Dokument (mittels languageCode im Header) gewählten abweicht. Weitere Informationen finden sich bei der Beschreibung des Elements languageCode des Headers. Hiervon wird allerdings typischerweise selten Gebrauch gemacht.

Beispiele für Abschnitte in einem Dokument

Ein Dokument besteht aus einem oder mehreren Abschnitten, die bei CDA auch Sections genannt werden. Nachfolgend ein paar typische Beispiele:

• Anrede
• Fragestellung
• Anamnese
• Befund
• Diagnosen
  • Diagnoseleitfaden
  • Diagnose (Sektion)
  • ICD-Diagnose (Entry)
  • TNM-Klassifikation (Entry)
• besondere Hinweise (CAVE)
• Therapie/Behandlungsmaßnahme
• Notiz
• Epikrise
• Medikation
• Labordaten
• ..
• Schlusstext
• Anhang

Entry

Die Abschnitte/Sections enthalten den Text, der direkt zur Anzeige verwendet werden soll. Für eine Maschine ist dieser normalerweise nicht direkt auswertbar. Dafür ist ein weiterer Mechanismus vorgesehen, bei dem die dem Text zugrundeliegenden Inhalte strukturiert ausgedrückt und in XML dargestellt werden. Diese Zusatzinformationen werden Entries genannt und innerhalb der Abschnitte optional eingebettet.

So kann beispielsweise ein Abschnitt Diagnose mit einer textuellen Darstellung der Diagnose ("Patient hat Blinddarmentzündung") ein Entry Diagnose enthalten, in dem die Diagnose als ICD-Code mit allen dazugehörigen Metadaten dargestellt wird.

Levels

Die CDA Level repräsentieren die unterschiedliche Feinheit (Granularität) der wiedergegebenen klinischen Informationen und des maschinen-auswertbaren Markups (standardisierte Form der maschinenauswertbaren Auszeichnung von Text).

Level 1

Mit Level 1 ist ein XML Dokument gekennzeichnet, das vor allem auf „menschliche Interoperabilität" abzielt („human readable"), also leicht für den menschlichen Gebrauch zugänglich gemacht werden kann, zum Beispiel durch Stylesheets. Es gibt keine Einschränkungen den Gebrauch oder Zweck des Dokuments oder den Inhalt betreffend. Die technischen Anforderungen, Level 1 Dokumente zu erzeugen oder zu verarbeiten, sind verhältnismäßig niedrig. Dies ist aus Datenverarbeitungssicht das gröbste Niveau von Informationen, gewährleistet damit aber sofort die Mensch-Mensch-Interoperabilität, die aus der reinen Papierwelt bekannt ist.

CDA Level 1

Level 2

Im Level 2 wird der Aufbau der Abschnitte genauer festgelegt. Diese Festlegung kann sowohl die textuelle Darstellung mit <text> und <title> Elementen betreffen als auch die Vorgabe, den Abschnitt mit einem bestimmten Code kenntlich zu machen.

Die Identifikation dieser Abschnitte ist dann auch für Applikationen zugänglich, also maschinenauswertbar. Dies wird typischerweise erreicht durch die Assoziation des Abschnitts mit einem Code (oder einem Set von mehreren Codes). Hierfür werden in diesem Leitfaden ausschließlich LOINC Codes zur Dokumentenabschnittsklassifizierung verwendet. Eine andere Möglichkeit der Kenntlichmachung ist die Zuordnung einer Template-Identifikation, von der in dieser Spezifikation auch Gebrauch gemacht wird (siehe unten).

CDA Level 2

Als Folge davon können so genannte section-level Templates zur Anwendung kommen. Mit den Codes sind die Abschnitte auch maschinen-auswertbar, d. h. durch Applikationen identifizierbar. Das bedeutet unter anderem, dass ein CDA Abschnitt dahingehend näher bestimmt werden kann, dass es spezifische Textteile (Paragraphen, Listen, Tabllen, etc.) aufweisen muss. So kann für einen Abschnitt mit Labordaten bspw. genau die Tabellenstruktur vorgegeben werden, d.h. welche Spalten in welcher Reihenfolge zu erscheinen haben.

Es liegt auf der Hand, dass die Spezifikation der Abschnitte eng verbunden ist mit dem Typ des Dokuments, z.B. ein OP-Bericht. In Arztbriefen - wofür dieser Leitfaden entwickelt wurde - macht man hier relativ wenig Vorgaben, während in Formularen oder Berichten relativ genaue Vorgaben zu erwarten sind.

Die häufigste Präzisierung ist die Vorgabe einer Menge von Codes für das Attribut code.

Level 3

CDA-Dokumente, die auch Level 3 konform sind, beinhalten zusätzlich auf dem Niveau von Einzelinformationen maschinen-auswertbare Komponenten (wie beispielsweise „systolischer Blutdruck"), die RIM-Klassen entsprechen. Eine Anwendung kann damit Daten wie eine einzelne Beobachtung, Prozedur, Medikamentengabe etc. identifizieren und verarbeiten. Selbst die Anwesenheit von bestimmten Einzelinformationen kann durch Vorgaben (Templates-Konzept) verpflichtend gemacht werden.

CDA Level 3

Ingesamt spricht man bei CDA und der hier beschriebenen Architektur der Level von einer „inkrementellen bzw. variablen semantischen Interoperabilität". Das heißt schlicht, dass man sehr „bescheiden" anfangen kann und elektronische Dokumente nutzt, die im Wesentlichen Gegenstücke zum Papier sind: Mensch-Mensch-Interoperabilität. Je mehr eine Anwendung oder eine Anwendungsumgebung ermöglicht, desto mehr XML Markup kann man schrittweise zufügen: zunächst dadurch, bestimmte Abschnitte zu identifizieren oder gar zu fordern (Level 2) oder schließlich auf dem Niveau von Einzelinformationen anzugeben bzw. diese verpflichtend zu machen (Level 3). Dies bedeutet dann Anwendungsinteroperabilität.

Die folgende Grafik gibt eine Section Komponente mit ihren Bestandteilen wieder.

CDA Section Komponente mit ihren Bestandteilen

Abbildung: Eine Abschnittskomponente (section) besteht aus einem <code>, der den Abschnitt typisiert, sowie einer Überschrift im <title>. Im obligatorischen <text> Teil sind die lesbaren Informationen repräsentiert. Dies ist verknüpft mit dem Begriff Level 2. Teile des narrativen Texts können darüber hinaus maschinenauswertbar im Level 3 repräsentiert werden, den so genannten CDA Entries <entry>. Zwischen Teilen des narrativen Texts und den Entries können Verbindungen angegeben werden.

XML-technisch gesprochen validieren CDA-Dokumente unabhängig vom Level gegen das generische CDA Schema. Zusätzlich können durch Festlegung bzw. Einschränkung der Abschnitte oder Detailinformationen weitere Validierungen verfügbar gemacht und genutzt werden.

Mit diesem Konzept ist es möglich,

• narrative Befunde elektronisch strukturiert wiederzugeben, so wie sie heute in der papierbasierten Welt zu finden sind, mit oder ohne zusätzliches Markup. Gleichzeitig wird gewährleistet, dass so viele gemeinsame Informationen wie möglich den Anwendungen zur Verfügung stehen (shared semantics), wie zum Beispiel die Identifikation und andere allgemeine Daten des Patienten.
• feingranulierte und kodierte Informationen darzustellen, wie Diagnosen, Prozeduren, Medikationen etc., die in (ggf. vorgegebenen) Kodierschemas wie ICD 10 repräsentiert sind, sowie Mess- oder Laborergebnisse darzustellen.
• Dokumente abzubilden, die irgendetwas zwischen diesen beiden Extremen von grober Strukturierung von narrativem Text bis zu feingranulären Einzelinformationen repräsentieren.

Man kann dies auch als Möglichkeit ansehen, „sanft" und ohne allzu hohe Ansprüche zu beginnen, elektronische Dokumente einzuführen und mit steigenden Anforderungen und technischen Möglichkeiten zu höherer Anwendungsinteroperabilität zu migrieren.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Anrede

Id	1.2.276.0.76.10.3001	Gültigkeit	2013‑01‑10
Status	Aktiv	Versions-Label
Name	Salutation	Bezeichnung	Anrede
Beschreibung Dieser Abschnitt enthält die allgemeinen einleitenden Sätze eines Dokuments, z. B. eines Arztbriefes oder eines Befund-Dokuments. Sie werden in einem Abschnitt zusammengefasst und können Anrede (z. B. „Sehr geehrter Herr Kollege,..."), eine erste Nennung des Patienten evtl. mit der zusätzlichen Angabe des Geburtsdatums etc. enthalten.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.3001
Klassifikation	CDA Section level template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07) ref ad1bbr-
Beispiel	Anrede <section>   <templateId root="1.2.276.0.76.10.3001"/>  <code code="X-SALUT" codeSystem="2.16.840.1.113883.6.1" displayName="Salutation"/>  <text>     <paragraph>Sehr geehrter Herr Kollege Dr. Heitmann,</paragraph>    <paragraph>Vielen Dank für die freundliche Überweisung des Patienten Paul Pappel, geb. 12. Dez. 1955.</paragraph>  </text></section>
Item DT Kard Konf Beschreibung Label hl7:section (Sal...ion) hl7:templateId II 1 … 1 M (Sal...ion) @root uid 1 … 1 F 1.2.276.0.76.10.3001 hl7:code CE 1 … 1 M (Sal...ion) @code CONF 1 … 1 F X-SALUT @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC)   Beispiel <code code="X-SALUT" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> hl7:title NP Ein Titel des Abschnitts kommt in der Begrüßung nicht vor (Sal...ion) hl7:text SD.TEXT 1 … 1 M (Sal...ion)

1. WEITERLEITUNG cdaab2:Grund der Überweisung-Section (Template)

[[Kategorie:{{{Namespace}}}]]

Diagnoseleitfaden

Diagnoseleitfaden

Implementierungsleitfaden

verabschiedet

Version:	1.1
Datum:	22. Juni 2011
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2011: HL7 Deutschland

HL7-Benutzergruppe in Deutschland e. V.

Darstellung von Diagnosen auf Basis der HL7 Clinical Document Architecture Rel. 2 für das deutsche Gesundheitswesen

Implementierungsleitfaden

Copyright © 2011: HL7 Benutzergruppe in Deutschland e.V.

HL7-Benutzergruppe in Deutschland e.V.
Geschäftsstelle Köln
An der Schanz 1
50735 Köln

Implementierungsleitfaden Darstellung von Diagnosen mittels HL7 Version 3 vorgelegt von:

	Gesellschaft für ein vernetztes Gesundheitswesen mbH - TeVeGe Berlin
	ID Berlin Berlin
	Duria e.G. Düren
	DIMDI Köln
	Agfa HealthCare GmbH Bonn
	FORUM Krebsregister/ADT/Krebsgesellschaft

und der Projektgruppe „Diagnosen" der HL7-Benutzergruppe in Deutschland

zur Abstimmung durch:

Mitglieder der HL7-Benutzergruppe e.V.

Ansprechpartner:

• Dr. Kai U. Heitmann, Heitmann Consulting and Services (Hürth)
• Dr. Frank Oemig, Agfa HealthCare GmbH (Bonn)

Dokumentinformation

Dokumentenhistorie

0.99c||11.03.10||KH, FO||Überarbeitung gemäß Diskussion im TC||n.a.

Version	Stand	Bearbeiter	Beschreibung	Dok.-OID
1.1	5.11.12	FO	Wikifizierung
1.1	01.06.11	ST, FO	OID-Vergabe, Vervollständigung der Terminologie, Formulierungen	1.2.276.0.76.7.4
1.0	01.03.11	FO	Freigabe	n.a.
0.99i	20.09.10	FO	OIDs (Value Sets und Codesystem für TNM-Werte), weitere Details gemäß der Anforderungen aus dem Leitfaden zur onkologischen Daten¬übermittlung	n.a.
0.99h	23.06.10	FO	Vorbereitung Publikation	n.a.
0.99g		FO		n.a.
0.99f	12.04.10	BS	Antworten auf die offenen Fragen	n.a.
0.99e	30.03.10	FO	Umsortierung + Layout	n.a.
0.99d	29.03.10	UA	Überprüfung TNM etc.	n.a.
0.99d
0.99b	07.12.09	FO	Vorbereitung Abstimmungsverfahren: Überarbeitung Qualifier gemäß TC-Sitzung vom 30.11.09 Aktualisierung der Referenzen Entfernung der ausführlichen Stadien¬gruppierung||n.a.
0.99	16.11.09	FO (MCR, BS)	Ergänzung Diagnosetypen WHO-Gradierung	n.a.
0.98	09.11.09	FO (BS)	Ergänzung der TNM-Tabellen, ausführliche Stadiengruppierung	n.a.
0.97	20.07.09	JT	Ergänzung um Bezeichnungen	n.a.
0.96	06.07.09	FO	Überarbeitung TNM Definition von Vokabulardomänen Restrukturierung	n.a.
0.95	24.10.07	KH	Kommentare des HL7-Abstimmungsverfahrens eingearbeitet	n.a.
0.9	02.07.07	KH, ST	OIDs ergänzt	n.a.
0.8	24.04.07	KH	Änderungen auf Basis der Kommentare von Herrn A. Zaiß, Freiburg	n.a
0.7	27.03.07	SG	Änderungen zum Thema Tumordiagnosen lr. Besprechung vom 01-03-2007	n.a
0.6	25.01.07	SG	Änderungen der Besprechung vom 22.1. eingearbeitet. Formulierungen und Beispiele überarbeitet Kapitel 1-4	n.a.
0.5	28.12.06	SG	Tabelle mit Diagnosetypen aufgenommen Kapitel für Tumordiagnosen eingefügt. ToDo-Liste eingefügt.	n.a
0.4	05.09.06	SG	Änderungen die im Meeting besprochen wurden eingearbeitet.	n.a
0.3	30.06.06	SG	Arbeitsversion für das Treffen der AG Diagnoseleitfaden.	n.a
0.2	22.06.06	SG	Änderung der Besprechung vom 22.5. eingearbeitet: Umstrukturierung des Dokuments Aufnahme von Feldern aus Arztbrief (Erläuterung, Ausnahmetatbestand) Abbildung ICD-Code geändert Abbildung Erstellungsdatum geändert. u.a.||n.a
0.1	21.03.06	SG	Dokument erstellt	n.a

Editor

• Sylke Grohnert, TeVeGe mbH, Berlin (SG)
• Dr. Kai U. Heitmann, HL7-Deutschland, Heitmann Consulting and Services, Hürth, (KH)

Autoren

• Dr. Kai U. Heitmann, HL7-Deutschland, Heitmann Consulting and Services (Hürth)
• Dr. Sylvia Thun, Deutsches Institut für Medizinische Dokumentation und Information DIMDI (Köln)
• Dr. Gunther Hellmann (Bamberg)
• Dr. Erich Gehlen, Duria eG (Düren)
• Dr. Frank Oemig, Agfa HealthCare GmbH (Bonn)
• Dr. Udo Altmann, Universität Gießen

Mit Beiträgen von

• Dr. Manfred Criegee-Rieck,
• Prof. Dr. Joachim Dudeck, Gießen
• Mark Neumann, ID-Berlin
• Dr. Bernd Schütze, DOC, Düsseldorf (BS)
• Dr. Sylvia Thun, DIMDI, Köln, (ST)
• Dr. Jochen Thümmler, Vivantes Netzwerk für Gesundheit, Berlin, (JT)
• Dr. Albrecht Zaiß, Freiburg

Weitere Mitglieder der Projektgruppe „Diagnosen" der HL7-Benutzergruppe:

• Hans Schüll, Siemens
• Lutz Junghanns, Cymed, Bochum
• Detlef Sievers, iSoft
• Christine Kolodzig, SBG, Berlin
• Peter Kaufmann, MCS-AG
• Ulrich Maier, Siemens
• Daniel Palzer, TeVeGe, Berlin
• Dr. Georg Heidenreich, Siemens, Erlangen

Autoren und Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

Das vorliegende Dokument wurde von der TeVeGe Berlin, und der Projektgruppe „Diagnosen" der in Kooperation mit der HL7-Benutzergruppe e.V. entwickelt. Die Nachnutzungs- bzw. Veröffentlichungs¬ansprüche sind nicht beschränkt.

Der Inhalt dieser Spezifikation ist öffentlich.

Zu beachten ist, dass Teile dieses Dokuments auf dem Abstimmungspaket 24 vom Dezember 2008 und der Normative Edition 2008 von HL7-Version 3 beruhen, für die © Health Level Seven, International gilt. Näheres unter [1] und [2].

Die Erweiterung oder Ablehnung der Spezifikation, ganz oder in Teilen, ist dem Vorstand der Benutzergruppe und den Editoren/Autoren schriftlich anzuzeigen.

Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifkationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.

Disclaimer

Auf einige der in diesem Dokument aufgeführten Tabellen besteht ein externes Copyright. Dies betrifft insbesondere die TNM-Klassifikation nach UICC, für die der Springer-Verlag die Rechte hält. Um hier keine Copyrightverletzung zu begehen, enthalten die entsprechenden Tabellen keine textuellen Beschreibungen und bleiben deshalb in der Beschreibungsspalte leer. Des Weiteren ist die Nutzung der Tabellenwerte eventuell mit Lizenzgebühren verbunden. Daher werden Implementierer gebeten, sich zu vergewissern, dass sie die ent¬spre¬chenden Lizenzen besitzen.

Disclaimer

Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann weder die HL7-Benutzergruppe in Deutschland e.V. noch die an der Erstellung beteiligten Firmen keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.

Einleitung

Einleitung

Die Dokumentation von Diagnosen ist eine elementare Aufgabe bei vielen Geschäftsprozessen im deutschen Gesundheitswesen. Dabei muss zwischen der Dokumentation zu medizinischen, statistischen, klinisch-wissenschaftlichen, rechtlichen und zu administrativen Zwecken unterschieden werden. Anwendungsbereiche für die Diagnosedokumentation sind z. B.:

• Erfassung der Diagnosen zum Zwecke der Abrechnung mit der ICD-10-GM in Verbindung mit den Vorgaben des SGB V
  • Stationär §301
  • Ambulant §295
  • IGV-MVZ §140
• die Todesursachenstatistik ICD-10 WHO (hier gibt es z.B. keine optionalen Codes)
• die Qualitätssicherung nach §137 SGB V und die Qualitätsberichte der Krankenhäuser
• Meldungen nach dem Infektionsschutz-Gesetz
• die Epidemiologie und Krebsregister (ICD-O), einschließlich weiter gehender Klassifizierungen von Tumorerkrankungen
• Gutachten von Renten- und Unfallversicherungsträger (ICF)
• die medizinische Dokumentation in der Versorgung z.B. Arztbrief, Kranken¬hauseinweisungen, Arbeitsunfähigkeitsbescheinigungen, Rezepte, stationäre EPA oder EGA
• Klinische Studien (MedDRA, WHO-Art)
• Risikostrukturausgleich (RSA)
• Produktinformationen zu Arzneimitteln, z.B. Indikationen, Kontraindikationen und unerwünschte Arzneimittelwirkungen (UAW)

Dieser Leitfaden befasst sich vornehmlich mit der Darstellung von Diagnosen für diese Anwendungen.

Die Dokumentation zu administrativen Zwecken wird im Abrechnungsbereich für die Begründung der Erbringung von Leistungen benötigt. Die ICD-10 GM wird seit dem 01.01.2000 zur Verschlüsselung von Diagnosen in der ambulanten und stationären Versorgung (§§ 295 und 301 SGB V) eingesetzt, insbesondere für die Zwecke des pauschalierenden Entgeltsystems G-DRG (German Diagnosis Related Groups).

Daneben sollen die anfallenden Primär- oder Routinedaten für weitere Zwecke als nur zur Abrech¬nung und medizinischen Dokumentation genutzt werden. Nur durch standar¬disierte Vorgaben ist die multiple Verwendbarkeit einmal erfasster Daten gewährleistet.

Statistische Auswertungen von Diagnoseinformationen werden z.B. im Rahmen der Qualitäts¬sicherung der Patientenversorgung und in der Forschung durchgeführt. Auch hier wird in der Regel die Diagnose mittels eines Codierungssystem verschlüsselt. Neben der ICD-10, sind dies z.B. die ICD-O und die ICF. Zukünftig werden sich Mehrwert¬anwendungen etablieren, die durch Verknüpfungen der medizinischen Dokumentation Entscheidungsprozesse in der Medizin unterstützen können. Hier werden weiterführende Begriffsysteme benötigt, wie z.B. das alphabetische Verzeichnis der ICD und Arzneimittelkataloge.

Zielsetzung

Ziel dieses Dokuments ist es, eine grundlegende Vereinbarung darüber zu treffen, wie Diagnosedaten in strukturierter Form mittels HL7 V3 Nachrichten und Dokumenten übermittelt werden sollen. Diagnosen sind die genaue Zuordnung von Befunden (diagnostischen Zeichen) und Symptomen zu einem Krankheitsbegriff. Grundsätzlich werden Diagnosen in HL7 als eine Beobachtung (Observation) von einem Arzt an einem Patienten betrachtet, d.h. dass die Darstellung von Diagnosedaten über die Klasse Observation erfolgt, egal in welchem HL7 V3 Modell die Klasse eingebunden ist. Das Ziel ist eine modellunabhängige Beschreibung der Abbildung von Diagnosedaten über eine Observation-Klasse.

Das Dokument ist wie folgt aufgebaut:

In Kapitel 2 werden mögliche Typen von Diagnosen vorgestellt. Damit werden schon mögliche Prozesse benannt, in denen es möglich sein muss Diagnosedaten zu versenden.

Kapitel 3 betrachtet Diagnosedaten, die von einem Arzt und/oder einem Programm zur Bewertung einer Diagnose benutzt werden.

In Kapitel 4 wird ausführlich auf die Darstellung von Diagnosedaten über die Observation–Klasse eingegangen.

Kapitel 5 beschäftigt sich mit der Darstellung von codierten Diagnosen. Dabei wird in Abschnitt 5.1 auf die Besonderheiten der ICD-10 Codierung insbesondere vor dem Hintergrund der deutschen Anforderungen eingegangen und die Darstellung von ICD-10 codierten Diagnosen aufgeführt.

Kapitel 6 beschäftigt sich mit der Darstellung der Diagnosen in der Tumordokumentation.

Das Kapitel 7 beinhaltet die Beispiele für Diagnosebeschreibungen aus verschiedenen Anwendungsbereichen.

Typisierung von Diagnosen

Begriffserläuterung

In HL7 Version 3 redet man bei der genaueren Typisierung von Beobachtungen von klassifizierenden Eigenschaften. Klassifizierung meint in diesem Kontext also Art oder Typ der Diagnose. Wegen der sprachlichen Verwirrung soll hier der Begriff „Typisierung" einer Diagnose verwendet werden.

Diagnosetypen im ambulanten Bereich

Für die Übermittlung der Abrechnungsdaten im ambulanten Bereich wurde von der Kassenärztlichen Bundesvereinigung (KBV) der KVDT-Datensatz entwickelt. Dieser ermöglicht die gebündelte Übertragung von Abrechnungsdaten (ADT), Kurärztlichen Abrechnungsdaten (KADT) und statistischen Daten (STDT) von einer Arztpraxis zu einer zuständigen Kassenärztlichen Vereinigung. Innerhalb dieser Datensatzbeschreibung erfolgt auch eine Diagnosebeschreibung, mit der die Abrechnung begründet wird. Im KVDT-Datensatz gibt es folgende Diagnosetypen:

Abrechnungsdiagnose:	aktuelle Diagnose, aufgrund derer eine Abrechnung erfolgt
Dauerdiagnosen:	Diagnosen, die schon mehr als drei Quartale gültig sind

Diagnosetypen im stationären Bereich

In § 301 SGB V wird festgelegt, welche Angaben die Krankenhäuser den Krankenkassen bei Krankenhausbehandlungen zu übermitteln haben. Auf Basis dieses Paragraphen wurde die Richtlinie zur „Datenübermittlung nach §301" von der Deutschen Kranken¬hausgesellschaft herausgegeben. In ihr wird festgelegt, wann welche Informationen an die Krankenkassen gesendet werden und in welcher Form. Diese Richtlinie beschreibt verschiedene Satzarten (z.B. Aufnahmesatz, Entlassungs¬satz). Innerhalb dieser Satzarten werden auch Diagnosen angegeben. Einen Überblick, welcher Datensatz welche Diagnose in welchem Segment übermittelt, wird in folgender Tabelle gegeben.

Satzart	Segment: Bezeichnung	Diagnosen
Aufnahmesatz	EAD: Einweisungs- und Aufnahmediagnose	Aufnahmediagnose Einweisungsdiagnose
Verlängerungsanzeige	DAU: Dauer	Nachfolgediagnose als Arbeitsunfähigkeitsbegründung
	FAB: Fachabteilung	Fachabteilungsdiagnose
Entlassungsanzeige	DAU: Dauer	Nachfolgediagnose als Arbeitsunfähigkeitsbegründung
	ETL: Entlassung/Verlegung	Entlassungsdiagnose
	NDG: Nebendiagnose	Nebendiagnose
	FAB: Fachabteilung	Fachabteilungsdiagnose Zusatzdiagnose
Rechnungssatz Ambulante OP	RZA: Rechnungszusatz ambulantes Operieren	Überweisungsdiagnose
	BDG: Behandlungsdiagnose	Behandlungsdiagnose

Tabelle 1: Satzarten gemäß §301 SGB V

Aus dieser Richtlinie ergeben sich folgende Diagnosetypen für die Datenübermittlung nach §301 SGB V:

• Aufnahmediagnose
• Einweisungsdiagnose
• Fachabteilungsdiagnose
• Nachfolgediagnose (mit anschließender Arbeitsunfähigkeit)
• Entlassungsdiagnose
• Fachabteilungszusatzdiagnose
• Überweisungsdiagnose
• Behandlungsdiagnose

Haupt- und Nebendiagnosen (im Wesentlichen medizinisch definiert) sowie Primär- und Sekundär¬diagnose werden über zusätzliche Attribute abgebildet.

Zu weiteren Diagnosentypen siehe Anhang 10.

Allgemeine Diagnosebeschreibung

Einleitung

Zur intellektuellen wie auch zur automatisierten Verarbeitung von Diagnoseinformationen werden verschiedene Merkmale einer Diagnose benötigt. Allgemein wird eine Diagnose durch folgende Attribute beschrieben.

Freitextbeschreibung der Diagnose

Bei dieser Art der Darstellung wird die Diagnose im Klartext beschrieben, welche z.B. von einem Arzt über ein Textfeld eingegeben werden kann. Im Bereich der medizinischen Dokumentation sollte die Textbeschreibung obligatorisch sein.

Beispiel: Allergisches Asthma

Die freitextliche Beschreibung entspricht nicht notwendiger Weise dem mit dem Diagnosecode assoziierten Text, z.B. dem Text aus dem systematischen Verzeichnis des ICD-10.

Diagnosecode

Im Bereich der administrativen und statistischen Auswertung wird die Diagnose mit Hilfe von Codiersystemen verschlüsselt. So wird z.B. bei der Abrechnung nach §301 und §295 SGB V die Codierung von Diagnosen mittels ICD-10 GM gesetzlich vorgeschrieben. Weitere Codiersysteme sind z.B. die „Alpha-ID", SNOMED CT und ID MACS. z.B. J45.0 Allergisches Asthma

Diagnosecode – Katalogtext

Zu einem Diagnosecode kann der assoziierte Text im Codiersystem (Klassentext, Displaytext/-name, Preferred Name, etc.) angegeben werden. Dieser Text entspricht nicht der freitextlichen Beschreibung einer Diagnose und kann automatisch von einem System anhand des Codes angegeben werden. z.B. Vorwiegend allergisches Asthma bronchiale

Diagnosetyp

Über den Diagnosetyp wird angegeben, um welche Art von Diagnose es sich handelt. Der Diagnosetyp wird codiert angegeben. Bei der Angabe des Diagnosetyps ist darauf zu achten, dass dieser auch im richtigen Kontext verwendet wird. Zum Beispiel wird es bei der Beschreibung einer Diagnose im Rahmen einer Überweisung nicht den Diagnosetyp „Entlassungsdiagnose" geben.

Feststellungsdatum der Diagnose

Das Datum ist der Zeitpunkt, an dem eine Krankheit z. B. durch einen Arzt festgestellt wurde. Dies wird im Folgenden mit Diagnosedatum bezeichnet.

Dokumentationsdatum der Diagnose

Das Datum ist der Zeitpunkt, an dem eine Krankheit z. B. durch einen Arzt dokumentiert wurde. Hinweis: Wenn zwischen Feststellung der Diagnose und Dokumentationsdatum nicht unterschieden werden muss, ist das Datum der Feststellung der Diagnose (Diagnose¬datum) anzugeben.

Angaben zur klinisch relevanten Zeitraum von Diagnosen

Der Zeitraum wird durch zwei Datumsangaben beschrieben, das heißt, von wann bis wann ein Patient an der diagnostizierten Krankheit litt. Über den Zeitraum kann auch ausgedrückt werden, seit wann ein Patient an einer Krankheit leidet, indem nur das Startdatum des Zeitraums angegeben wird. Das Startdatum des Zeitraums kann abweichen von dem Diagnose¬datum. Datumsangaben zu Diagnosen können in unterschiedlicher Präzision vorhanden sein.

Beispiel: Diabetes seit 2006 oder Oberschenkelfraktur am 12. März 2007

Diagnosesicherheit

Die Diagnosesicherheit, d.h. wie sicher die Diagnose im Einzelfall zu werten ist, kann unterschiedlich angegeben werden. Für Abrechnungszwecke in der ambulanten Versorgung muss obligatorisch ein Zusatz¬kennzeichen für die Diagnosesicherheit (A, G, V oder Z) angegeben werden, d. h. die Angabe ist obligatorisch. In der stationären Versorgung sind diese Zusatzkennzeichen für die Angabe der Diagnosesicherheit für Abrechnungszwecke dagegen nicht zulässig.

Lokalisation

Über die Lokalisation kann angegeben werden, in welchem Bereich des Körpers eine Krankheit diagnostiziert wurde (Topographische Information). Die Beschreibung der Lokalisation kann sowohl im Klartext erfolgen, als auch über einen Codierungs¬schlüssel. Hier ist z.B. der in der Tumordokumentation benutzte Lokalisations¬schlüssel, abgeleitet aus der ICD-O, zu nennen. Eine Zusatzangabe kann je nach Organ die Angabe der Körperseite (Seitenlokalisation) sein.

Diagnoseerläuterung

Damit soll dem Arzt die Möglichkeit gegeben werden evt. nähere Angaben zu einer Diagnose in Form von Freitext zu machen.

Begründung von Ausnahmen

Unter bestimmten Umständen ist es erforderlich, das Auftreten einer Diagnose zu Abrechnungszwecken zu begründen, z.B. für geschlechtsspezifische Plausibilitäts–prüfungen. Eine Codierung für Ausnahmebegründungen gibt es zurzeit nicht, d.h. diese erfolgt in Freitext.

Darstellung des Diagnosemodells in HL7 V3

Die ICD-Diagnosen werden auf Entry-Level wie folgt dargestellt:

ICD-Diagnosen-Entry (Template)

Darstellung von Diagnosen in bestimmten Codesystemen

ICD-10 GM codierte Diagnosen

verschoben: cdaab2:ICD-Diagnosen_(Entry)#ICD-10_GM_codierte_Diagnosen

Beschreibung einer Diagnose durch einen Thesaurus – Index

Eine weitere Möglichkeit der Diagnosebeschreibung ist die Angabe eines Indexes, durch den auf einen Eintrag in einem Thesaurus verwiesen wird.

Beispiel: Abbildung einer Alpha-ID codierten Diagnose

Der in Deutschland verwendete Diagnosethesaurus ist das „Alphabetische Verzeichnis zur ICD-10 GM". Über dieses Verzeichnis ist es möglich, über die wörtliche Beschreibung einer Diagnose den entsprechenden ICD-10 GM Code zu ermitteln.

Die Alpha-ID wurde entwickelt, um die Einträge aus diesem Thesaurus elektronisch weiterverarbeitbar zu machen.

Die Alpha-ID ist eine Identifikationsnummer für jeden einzelnen Eintrag im „Alphabetischen Verzeichnis des ICD-10 GM". Um die ID eines Eintrages ermitteln zu können, wird eine Zuordnungsdatei vom DIMDI zur Verfügung gestellt. Die Notwendigkeit für die Entwicklung der Alpha-ID ergab sich, da die Beschreibung einer Diagnose aus der Code-Beschreibung laut ICD-10 für die medizinische Dokumentation häufig nicht ausreichend differenziert. Durch den Einsatz der Alpha-ID kann ein wesentlich höherer Feinheitsgrad in der Diagnosebeschreibung erzielt werden. \[DIMDI, Alpha_Id\].

Z.B. ist der ICD-10 Code "A01.0 Typhus durch Salmonella typhi" ein Verschlüsselung für die Diagnosen „Lebertyphus", „Lungentyphus" u.a. Durch die Angabe der Alpha-ID ist es möglich die genaue Typhusausprägung anzugeben. „Lebertyphus" hat die Alpha-ID „I18721" und „Lungentyphus" die Alpha-ID „I21312" (Siehe auch Abb. 4)

Beispiel Alpha-IDs aus 2009

1;I22457;A01.0;;;Darmtyphus
1;I75303;A01.0;;;Eberth-Krankheit
1;I71406;A01.0;;;Enteritisches Fieber
1;I22466;A01.0;;;Enterotyphus
1;I22467;A01.0;;;Febris enterica
1;I17704;A01.0;;;Gallenblasentyphus
1;I71415;A01.0;;;Gastroenteritisches Fieber
0;I78350;A01.0;;;Gastrointestinale Perforation bei Typhus
1;I17794;A01.0;;;Gehirntyphus
1;I21313;A01.0;;;Hauttyphus
1;I22455;A01.0;;;Ileotyphus
1;I94981;A01.0;;;Infektion durch Bacterium typhosum
1;I73671;A01.0;;;Infektion durch Eberthella typhosa
1;I22458;A01.0;;;Infektion durch Salmonella typhi
1;I18721;A01.0;;;Lebertyphus
1;I21312;A01.0;;;Lungentyphus
1;I96251;A01.0;;;Lymphadenitis mesenterialis durch Salmonella typhi
1;I66509;A01.0;;;Posttyphoider Abszess
1;I22456;A01.0;;;Status typhoides
1;I22463;A01.0;;;Typhoenteritis
1;I71447;A01.0;;;Typhogastrisches Fieber
1;I22462;A01.0;;;Typhoides Fieber
1;I31416;A01.0;;;Typhomanie
1;I22464;A01.0;;;Typhoperitonitis
1;I22454;A01.0;;;Typhus
1;I22461;A01.0;;;Typhus abdominalis
1;I73926;A01.0;;;Typhusinfektion

Abbildung 3: Auszug aus der Zuordnungsdatei „icd10gm2009_alphaid_edv_ascii20081006.txt"

Der in Abbildung 4 dargestellte Auszug aus der dazugehörenden Beschreibungsdatei erklärt kurz die Felder, aus denen sich ein Alpha-ID Datensatz zusammensetzt.

Jeder Datensatz besteht aus 6 Feldern, die jeweils durch ein Semikolon getrennt sind. Die Felder enthalten folgende Daten:

• Feld 1: Gültigkeit (0-nicht gültig, 1-gültig)
• Feld 2: stabile Identifikationsnummer mit Präfix I oder T ("Alpha-Identifikationsnummer")
• Feld 3: Primärschlüsselnummer (ggf. mit Kreuz)
• Feld 4: Sternschlüsselnummer (mit Stern)
• Feld 5: Zusatzschlüsselnummer (ggf. mit Ausrufezeichen)
• Feld 6: zugehöriger Text, ohne eventuelle Verweise

Abbildung 4: Auszug aus der Alpha-ID Beschreibungsdatei „icd10gm_alphaid_edv_ascii_liesmich.txt"

Die Darstellung eines Thesaurus – Indexes oder eines Nomenklaturkennzeichens erfolgt über das Attribut @value der Klasse Observation. Die strukturierte Darstellung sieht wie folgt aus.

<!-- Strukturierte Darstellung der Diagnose-->
<observation moodCode="EVN" classCode="OBS">
	…
	<value xsi:type="CD" code="I2173" codeSystem="1.2.276.0.76.5.309" 
				codeSystemName="alphaid2006"/>
	...
</observation>

Lvl	RIM	Name	Desc	DT	Kard	Conf	Beschreibung
1	act	value
2	act	@code	Alpha-Id	ST	1..1	M	Das XML-Attribut @code enthält den Index, mit dem auf ein Eintrag im „Alphabetischen Verzeichnis" verwiesen wird.
2	act	@codeSystem	OID der Alpha-ID	UID	1..1	M	Das XML-Attribut @codeSystem enthält die OID der verwendeten Alpah-ID Version.
2	act	@displayName	Alpha-Id Text	ST	0..1	optional	Im XML-Attribute @displayName kann, der zur Alpha-Id gehörende Text angegeben werden.
2	act	@codeSystemName	Name der Alpha-ID Version	ST	0..1	optional	Im XML-Attribut @codeSystemName kann der Name des Codierungssystems angegeben werden. In diesem Fall wäre der Wert alphaid2006. Die OID und die Bezeichnung der ICD-10 Version können von der Internetseite des DIMDI bezogen werden.

Beschreibung mittels Nomenklatur- Identifikationskennzeichen

Eine weitere Beschreibungsmöglichkeit für Diagnosen wird durch die Angabe eines Diagnosecodes aus einer medizinischen Nomenklatur möglich. Die wohl bekannteste für den medizinischen Bereich ist die „Systematisierte Nomenklatur der Medizin" (SNOMED). Gegenüber dem ICD-10 Code wird zwischen verschiedenen Diagnosen deutlich mehr differenziert und meist nicht klassifiziert. Die Angabe eines Diagnosekennzeichens aus einer Nomenklatur ist demzufolge häufig aussagekräftiger als die Angabe des ICD-10 Codes. D.h. im Rahmen einer medizinischen Dokumentation einer Diagnose wäre die Verschlüsselung der Diagnose mittels Alpha-ID bzw. Nomenklatur-Identifikationskennzeichen der Codierung mittels ICD-10 Code vorzuziehen, wenn der Detaillierungsgrad der ICD-10-codierten Diagnose nicht ausreicht. Eine kurze Gegenüberstellung verschiedener Codes soll die Ungenauigkeit bzw. die Unklarheiten, welche bei der ICD-10 Codierung aufkommen, verdeutlichen. Es sind verschiedene Diagnosen gezeigt, die allesamt auf den selben ICD-10 Code Q92.8 „Sonstige näher bezeichnete Trisomien und partielle Trisomien der Autosomen" zeigen, aber in anderen Codesystemen feiner differenzierbar sind.

Diagnose	ICD-10 Code	Alpha-ID	Snomed CT	ID MACS
Unbalancierte Insertion	Q92.8	I87548	254262003	M002405-D62839-58
Trisomie 22	Q92.8	I81282	205655003	M001897-D55549-58
Trisomie 20	Q92.8	I81283	53346000	M002406-D55530-58
Partielle Trisomie a.n.k.	Q92.8	I81284	133849008	M001D1C-C78409-58

Tabelle 6: Diagnosen in versch. Codiersystemen

Präkoordinierte und postkoordinierte Konzepte einer Nomenklatur

Für die Beschreibung einer Diagnose durch eine Terminologie gibt es zwei unterschiedliche Ansätze. Die präkoordinierte Beschreibung vergibt einen festen Code für eine Diagnose, die postkoordinierte Beschreibung zerlegt die Diagnose in ihre Bestandteile, in dem mehrere Codes zum Ausdrücken desselben Sachverhaltes kombiniert werden.

Beispiel für präkoordinierte Konzepte

• Offene Keilfraktur mit Biegungskeil der mittleren Humerusdiaphyse S42.3
• Akute Histoplasmose der Lunge durch Histoplasma capsulatum B39.0

Postkoordinierte Konzepte werden hier, außer bei ICD-10 (Kreuz-Stern, im Prinzip auch ein postkoordiniertes Konzept) nicht näher beschrieben. Weitere Informationen sind im Terminfo-Projekt \[Terminfo\] von HL7 International zu finden.

Thesaurus-Index oder Nomenklaturkennzeichen der Diagnose

Die Darstellung eines Nomenklaturkennzeichens erfolgt über das Attribut @value der Klasse Observation. Die strukturierte Darstellung sieht wie folgt aus.

<observation moodCode="EVN" classCode="OBS">
	...
	<value xsi:type="CD" code="314888007" codeSystem="2.16.840.1.113883.6.96" 
			codeSystemName="SNOMED CT" 
			displayName="Typ-II-Diabetes mit diabetischer Katarakt"/>
	...
</observation>

Lvl	RIM	Name	Desc	DT	Kard	Conf	Beschreibung
1	act	value
2	act	@code	Nomenklaturindex	CD CWE	1..1	M	Das XML-Attribut @code enthält den Index, mit dem auf einen Eintrag in einem Nomenklaturverzeichnis verwiesen wird.
2	act	@codeSystem	OID der Nomenklatur	UID	1..1	M	Das XML-Attribut @codeSystem enthält die OID der verwendeten Nomenklatur.
2	act	@displayName	Text	ST	0..1	optional	Im XML-Attribute @displayName kann, der zum Nomenklaturindex gehörende Text angegeben werden.
2	act	@codeSystemName	Nomenklaturname		0..1	optional	Im XML-Attribut @codeSystemName kann der Name der Nomenklatur angegeben werden.

Darstellung von Diagnosen und Klassifikationen in der Tumordokumentation

Einleitung

An dieser Stelle werden die diagnostischen Aspekte in der Dokumentation von Tumorerkrankungen dargestellt. Die verschiedenen Aspekte der diagnostischen Beschreibung von Tumorerkrankungen werden durch die ICD-O (Onkologie) und verschiedene Klassifikationen zur Festlegung der Ausbreitung bzw. des Krankheitsstadiums beschrieben. Letztere ist in den allermeisten Fällen das TNM Klassifikationssystem. Speziell für hämatoonkologische Erkrankungen (Lymphome und Leukämien) kommen andere Systeme (z.B. Ann-Arbor Klassifikation) zum Einsatz. Das TNM System beschreibt

• die Ausbreitung des Primärtumors (Größe bzw. Ausbreitung in andere Organe)
• den Befall von Lymphknoten im Lymphabflußgebiet und
• das Vorhandensein von Fernmetastasen.

Für nicht durch das TNM-System klassifizierbare Erkrankungen oder zusätzlich dazu existiert eine Reihe weiterer Klassifikationen. Die häufigsten verwendeten sind:

• Ann Arbor
• Rai
• Binet
• CML-Phasen
• FAB
• Durie und Salmon
• Gleason-Score

Beschreibungen finden sich unter [3] [4]

Es ist damit zu rechnen, dass diese Liste wegen des medizinischen Fortschritts jedoch prinzipiell immer unvollständig ist.

ICD-O

Aktuell ist die 3. Auflage der ICD-O \[DIMDI, WHO\]. Die ICD-O besteht aus einer Topographie- und einer Morphologie-Achse. Mit der ICD-O werden

• Lokalisation,
• Gewebestruktur (Histologie)
• biologisches Verhalten (Dignität) und
• Gewebe-Differenzierungsgrad (meist zwei- oder vierstufig) des Tumors

klassifiziert. Hierbei sind die Gewebestruktur und der Gewebe-Differenzierungsgrad redundant. Genauer: Die ersten 4 Stellen des Morphologie-Codes beschreiben den Zelltyp.

Die 5. Stelle das biologisches Verhalten (Dignitätscodes):

Code	Beschreibung
0	benigne
1	Neoplasie unsicheren oder unbekannten Verhaltens
2	Carcinoma in situ
3	maligne, Primärtumor
6	maligne, Metastase (wird in Krebsregistern nicht verwendet)
9	maligne, unbestimmt ob Primärtumor oder Metastase

Die 6. Stelle beschreibt das Grading, Differenzierung oder Phänotyp (Histologie / Pathologie):

Code	Beschreibung
1	Grad I, gut differenziert, differenziert o.n.A.
2	Grad II, mäßig differenziert, mäßig gut differenziert, mittelgradig differenziert
3	Grad III, schlecht differenziert
4	Grad IV, undifferenziert, anaplastisch
9	Grading nicht durchgeführt, nicht angegeben oder entfällt

Bei Leukämien und Lymphomen dient die 6. Stelle zur Bezeichnung des Immunphänotyps:

Code	Beschreibung
5	T-Zell
6	B-Zell, prä-B-Zell, B-Vorläufer-Zell
7	Null-Zell, Nicht-T-Zell-nicht-B-Zell
8	NK-Zell, Natürliche Killerzell
9	Bestimmung des Zelltyps nicht durchgeführt, nicht angegeben oder entfällt

Das TNM System beschreibt

• die Ausbreitung des Primärtumors (Größe bzw. Ausbreitung in andere Organe)
• den Befall von Lymphknoten im Lymphabflußgebiet und

das Vorhandensein von Fernmetastasen.

Für die Topographieachse gibt es eine (hierarchische) Erweiterung, den Lokalisationsschlüssel (Wagner, G. (Hrsg.): Tumorlokalisationsschlüssel. 5. Auflage, Springer Verlag, Berlin, Heidelberg, New York, Tokyo 1993), der an einigen Stellen klinisch relevante Unterscheidungen liefern kann. Die Morphologieachse setzt sich zusammen aus einem vierstelligen Code für die Grundstruktur des Gewebes, einer Dignitätskennzahl und einem Grading-Zusatz. Der Schlüssel selbst enthält nicht alle möglichen Kombinationen aus Histologie und Dignität, sondern hebt vor allem die hervor, bei denen es besondere Bezeichnungen gibt. Umgekehrt sind nicht alle Kombinationen aus Grundstruktur und Dignität möglich (so gibt es keine gutartige Leukämie). Auch ist nicht für alle Tumoren ein Gradingsystem verfügbar. Bei manchen wird an der entsprechenden Stelle eine andere Zusatz¬information (z.B. Zelllinie) verwendet.

Lokalisation des Tumors

Bei der Codierung von Tumorerkrankungen steht zunächst die Lokalisation des Tumors im Vordergrund, die nach der Lokalisationsachse der ICD-O klassifiziert wird. Die Lokalisationscodes der ICD-O basieren auf dem Kapitel II (Neubildungen – C 00 – C 97) der ICD-10. Allerdings werden in der ICD-O eine Reihe von topographischen Codes der ICD-10 (Codes) nicht verwendet, da deren Inhalte in der ICD-O über Histologie und Dignitätscodes (s.u.) dargestellt werden (z.B. Unterscheidung in situ / infiltrierend, Hautmelanom vs. Hautkarzinom).

Histologie und Dignität des Tumors

In der ICD-O werden darüber hinaus die Morphologie des Tumors, d.h. die Gewebestruktur (Histologie) und das biologische Verhalten, die Dignität des Tumors in gesonderten Codes erfasst. Die Histologie des Tumors wird über eine vierstellige Zahl codiert, die aus der Morphologie Achse der Standardized Nomenclature of Pathology (SNOP) übernommen wurde. Mit dem Morphologiecode ist verbunden – getrennt durch / der Dignitätscode.

Beispiele:

• 8060/0 Plattenepithel-Papillomatose
• 8070/2 Plattenepithel-Carcinoma in situ o.n.A.
• 8070/3 Plattenepithelkarzinom o.n.A.
• 8070/6 Plattenepithelkarzinom Metastase o.n.A.

Differenzierungsgrad

Der Differenzierungsgrad wird von einem Vergleich zum ursprünglichen Gewebe abgeleitet aus dem die Neubildung entstanden ist . Man unterscheidet 5 Grading-Stufen (s.o.), sowie weitere 3 Stufen für maligne Lymphome. Die Erfassung des Differenzierungsgrads ist auch in TNM vorgesehen.

Qualifier der Tumorformel

Die ICD-O-Codes können noch über folgende Qualifier präzisiert werden:

Qualifier	Bedeutung	Erlaubte Werte (Darstellung)	OID
DF	Differenzierungsgrad (Grading)	1, 2, 3, 4, 5, 6, 7, 8, 9	1.2.276.0.76.5.336
DN	Dignität	0, 1, 2, 3, 6, 9	1.2.276.0.76.5.335

Tabelle 7: Komponenten der ICD-O-Tumorformel

An dieser Stelle sieht die ICD-O bei Lymphomen zusätzlich folgende Codes vor, die die Zelllinie kennzeichnen: B-Zell, T-Zell, Null-Zell-Lymphom. Die ICD-O-3 verwendet die Kodes 1-9. Ein detaillierteres System wird in diesem Leitfaden unter 9.5.2 und 9.5.3 beschrieben.

Beispiel

<observation classCode="OBS" moodCode="EVN">
	...
	<value xsi:type="CD" code="8070" codeSystem="2.16.840.1.113883.6.43.1" 
			displayName="Plattenepithelkarzinom">
			codeSystemName="icd-o-3">
		<originalText>
			Plattenepithelkarzinom mit adenomatösen Anteilen …
		</originalText>
		<qualifier>
			<name code="335" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="3" codeSystem="1.2.276.0.76.5.335"/>
		</qualifier>
		<qualifier>
			<name code="336" codeSystem="2.16.840.1.113883.3.7.1.0"/>
			<value code="1" codeSystem="1.2.276.0.76.5.336"/>
		</qualifier>
	</value>
</observation>

Der Displayname ist nur in Zusammenhang mit den Qualifiern gültig. Laut Bildungsregel der ICD-O-3 sind weit mehr Benennungen zulässig, als es der Katalog ICD-O-3 vorgibt.

TNM Klassifikation (Tumor, Noduli, Metastasen)

Die TNM Klassifikation beschreibt die Ausbreitung des Tumors, d.h. Stadium und Prognose der Erkrankung. Die TNM Klassifikation hat als Besonderheit, dass die Bezeichnungsweise (Notation) bei allen Tumoren gleich ist, die Inhalte aber getrennt für unterschiedliche Tumorentitäten definiert werden, d.h. z.B. hat ein T3 für das Mammakarzinom eine andere Interpretation als für das Magenkarzinom. Aktuell ist die 7. Auflage. Da diese jedoch erst seit 1.Januar 2010 gilt, ist auch mit einer Reihe TNM-6-Klassifikationen zu rechnen. Grundsätzlich sollte jede TNM-Angabe mit einer entsprechenden Versionsangabe versehen werden, da es hier nicht konvertierbare Unterschiede zwischen Auflagen geben kann. Einen einführenden Überblick gibt [5].

Die T-Kategorie wird zur Klassifikation des Primärtumorsitzes verwendet, wobei es meist die Stufen T0, Tis, T1-T4 und TX gibt. Je höher die Zahl, desto fortgeschrittener ist die Erkrankung und desto ungünstiger die Prognose. T0 besagt, dass kein Primärtumor nachweisbar ist (z.B. weil dieser durch eine Therapie zum Verschwinden gebracht wurde). Tis, dass der Tumor sich noch in einem sehr frühen, nicht infiltrativem Stadium (Tumor in situ) befindet und TX kommt zur Anwendung, wenn auf Grund fehlender Daten das Stadium des Tumors nicht verlässlich beurteilt werden kann. Bei einigen Tumoren werden Subkategorien wie T2a, T2b definiert. Die N-Kategorie klassifiziert den Befall von Lymphknoten mit N0, N1-N3, NX, wobei N0 zugeordnet wird, wenn kein Lymphknotenbefall nachweisbar ist. Bei einigen Tumoren wird für den Ausschluss des Befalls von Lymphknoten die Untersuchung einer Mindestzahl von Knoten vorgeschrieben. Die Zahl der untersuchten Knoten wird an einigen Stellen erfasst. Je höher die N Kategorie, desto ausgedehnter ist der Lymphknotenbefall. Wenn die Daten nicht ausreichend sind, wird NX vergeben. Die M-Kategorie beschreibt das Vorhandensein von Fernmetastasen, wobei nur zwischen M0 (keine Metastasen nachweisbar), M1 (Metastasen nachweisbar) und MX (für die Beurteilung nicht ausreichende Daten) unterschieden wird.

Bei der TNM Klassifikation wird zwischen der Beurteilung nach klinischen Kriterien (präoperativ - cTNM) und nach dem pathologischen Befund (pTNM) unterschieden. Bei vielen Patienten wird nur ein TNM Befund erhoben, d.h. entweder cTNM oder pTNM. Die Art des TNM Befundes muss erfassbar sein. Das Präfix "c" (gleichbedeutend mit Fehlen eines Präfixes) und "p" muss für jede Kategorie getrennt erfasst werden d.h. der häufig klinisch verwendete Begriff pTNM entspricht meist – aber nicht immer - pTpNcM. So kann die Ausbreitung des Primärtumors exakt durch eine Operation bestimmt sein, nicht jedoch der Lymphknotenbefall. Mit dem Präfix "r" wird die TNM Klassifikation eines Rezidivtumors (nach krankheitsfreiem Intervall) gekennzeichnet, mit "y" wenn die Klassifikation nach Vorbehandlung mit systemischer oder mit Strahlentherapie erfolgt (ycTNM, ypTNM etc.).

Bei multiplen Primärtumoren wird nach der T Klassifikation als Suffix in Klammern "m" bzw. die Zahl der Primärtumoren eingefügt (T2(m), T2(5)). Eine komplette TNM-Formel ist folgendermaßen aufgebaut: nicht jede Komponente ist zwingend, so z.B. der Certainty-Faktor (C-Faktor). Manche sind auch nur nach pathohistologischer Untersuchung möglich (L-, V- oder Pn-Kategorie)

• y-Symbol (y oder nichts)
• r-Symbol (r oder nichts)
• p/c/a-Symbol für pT-Kategorie
• T-Kategorie
• (m) für multiple Lokalisation oder Anzahl der Tumoren
• C-Faktor für T-Kategorie
• L-Kategorie
• V-Katgorie
• Pn-Kategorie
• p/c/a-Symbol für pN-Kategorie
• N-Kategorie
• C-Faktor für N-Kategorie
• p/c/a-Symbol für pM-Kategorie
• M-Kategorie
• C-Faktor für M-Kategorie
• S-Kategorie (serologische Werte  nur bei Hodentumoren)
• UICC-Stadium (Einstufungen in UICC 0 und I-IV in Verbindung mit den Buchstaben A, B und C zur weiteren Unterteilung

Bei bestimmten Tumoren ist zur Kategorie noch die Angabe bestimmter Modifikatoren üblich, die meist in runden Klammern der Angabe nachgestellt werden (sn), (mol-), (mol+). Darüber hinaus gibt es mitunter testweise Erweiterungen oder Neuerungen, die im sogenannten TNM-Supplement dargestellt werden. Das lässt fraglich erscheinen, ob eine komplette Kontrolle der Einträge möglich ist.

Die bekannten T-Kategorien (ohne Darstellung möglicher Zusätze) sind in Kapitel 9.6.1. aufgelistet. Die bekannten N-Kategorien (ohne mögliche Zusätze) sind in Kapitel 9.6.2. Nodes aufgelistet. Die bekannten M-Kategorien (ohne mögliche Zusätze) sind in Kapitel 9.6.3. Metastasen aufgelistet.

Qualifier der Tumorformel

Die Tumorformel kann neben den drei Werten für T, N, und M noch eine Reihe von Qualifiern enthalten. Die nachfolgende Tabelle gibt eine Übersicht, welche Qualifier bei welchen Informationen verwendet werden können. Außerdem ist angegeben, wo in einer textuellen Darstellung diese Informationen stehen. Die kodierte Information:

Das ist die offizielle Nomenklatur und Schreibweise der Symbole. Groß/Kleinschreibung ist relevant!

a	Autoptisch
c	Klinisch
C	C-Faktor (Diagnosesicherheit)
G	histopathologisches Grading
L	Lymphgefäßinvasion
m	multiple Tumoren
M	Fernmetastasen
N	Regionäre Lymphknotenmetastasen
p	pathologisch
Pn	perineurale Invasion
r	Rezidivtumor
R	Residualtumor nach Behandlung
sn	Sentinel-Lymphknoten
Stage	Anatomische Stadiengruppierung
T	Ausdehnung des Primärtumors
V	Veneninvasion
y	Klassifikation nach initialer multimodaler Therapie

Code	Qualifier	Bedeutung	Werte (in der Darstellung)	Beispiel	Anwendung/ Bezug	Position der Qualifier
	a	Autopsie	a	aTNM	TNM	davor
	c	Clinical	c	cTNM	TNM	davor
	C	Certainty Factor	C1 – C5	T3C2 N2C1 M0C2	TNM	dahinter
G		histopathologisches Grading	GX, G1-G4
L		Lymphgefä߬invasion	LX, L0, L1
	m	Multiplizität (Multiple Tumore)	(m) (<Zahl>) <leer>		T	dahinter (in Klammern)
M		Fernmetastasen	MX, M0, M1		M
N		regionäre Lymph¬knoten¬metastasen	NX, N0, N1-3
	p	postoperativ/patho¬logisch	pT, pN, pM in allen Unterkategorien	pT2b pN2a pM0	TNM	davor
Pn		perineurale Invasion	Pn0, Pn1
	r	rezidiv	r <leer>		TNM	davor
R		Residualtumor nach Behandlung	RX, R0-R2		R
	sn	sentinel Lymphknoten	(sn)	N0(sn)	N	dahinter
Stage		anatomische Stadiengruppierung
T		Ausdehnung des Primärtumors			T
V		Veneninvasion	VX, V0-V2
	y	Klassifikation nach initialer multi¬modaler Therapie	y		TNM	Davor
	i+	Nachweis von isolierten Tumorzellen	(i+)	N0(i+)	NM	Dahinter
	i-	Kein Nachweis von isolierten Tumorzellen	(i-)	N0(i-)	NM	dahinter
	mol+	Molekularer Nachweis von Tumorzellen	(mol+)	N0(mol+)	NM	dahinter
	mol-	Kein molekularer Nach¬weis von Tumor¬zellen	(mol-)	N0(mol-)	NM	dahinter
	DCIS LCIS Paget	Ductal Carcinoma in situ Lobular Carcinoma in situ Morbus Paget	(DCIS) (LCIS) (Paget)		Tis	dahinter (inkl. Leerzeichen)
	pd	Carcinoma in situ, involvement of prostatic ducts	pd		T	dahinter
	pu	Carcinoma in situ, involvement of prostatic urethra	pu		T	dahinter
		Lokalisation von Metastasen	PUL OSS HEP BRA LYM OTH MAR PLE ADR SKI		M1	dahinter (inkl. Leerzeichen)

Tabelle 8: Komponenten der TNM-Tumorformel

Certainty Faktor

Zusätzlich zu dem jeweiligen T, N oder M Wert wird in der Regel noch der Faktor zur Diagnosesicherheit (Certainty Factor) registriert. Der C-Faktor drückt die von den verwendeten diagnostischen Methoden abhängige Zuverlässigkeit der Klassifikation aus. Seine Verwendung ist fakultativ. Er hat die Ausprägungen C1 – C5, die jeweils hinter die Kategorien T, N und M gesetzt werden. Diese werden nachfolgend definiert.

Der T, N oder M Befund beruht auf der Anwendung von

• C1 - Aussage aufgrund von diagnostischen Standardmethoden (Inspektion, Palpation, einfache Röntgenaufnahmen)
• C2 - Aussage aufgrund spezieller diagnostischer Maßnahmen z.B. Computer¬tomogramm, Magnet-Resonanz-Tomographie
• C3 - Aussage aufgrund chirurgischer Exploration (Biopsie, Zytologie etc.)
• C4 - Aussage nach definitiver chirurgischer Behandlung und pathologischer Untersuchung der entnommenen Gewebeteile
• C5 - Aussage aufgrund einer Autopsie

Ein in diesem Sinne vollständiger TNM Befund sieht somit folgendermaßen aus

cT2 C3 cN1 C3 cM0 C1

(Klinischer Befund, Primärtumor Stadium 2 mit differenzierteren Untersuchungsverfahren festgestellt, Lymphknotenausbreitung Stadium 1, ebenfalls durch differenziertere diagnostische Verfahren festgestellt, keine Metastasen, mit einfacheren klinischen Verfahren untersucht).

Der cTNM entspricht den Certainty Faktoren C1 – C3, der pTNM dem Faktor C4. Diese präzisere Bezeichnungsweise hat sich nicht flächendeckend durchgesetzt, obwohl T, N und M durchaus unterschiedliche C Faktoren haben können. So kann der T Befund durchaus C4 sein, während die Beurteilung der Metastasen nur über einfache klinische Methoden erfolgt und daher nur C1 ist.

Residualtumor

Der pathologische TNM (pTNM) kann durch die Klassifikation des bei einem Eingriff hinterlassenen restlichen Tumorgewebes – des Residualtumors – ergänzt werden. Unterschieden werden

• R0: kein Residualtumor,
• R1: mikroskopischer Residualtumor,
• R2: makroskopischer Residualtumor und
  • R2a: - mikroskopisch nicht bestätigt
  • R2b: - mikroskopisch bestätigt
• RX: Vorhandensein von Residualtumor kann nicht beurteilt werden

Grading - Differenzierungsgrad

Das Grading gibt den Grad der Tumordifferenzierung an. Das Grading gibt den Umfang der Veränderung des Tumorgewebes im Vergleich zu normalen Gewebe an und gibt Hinweise auf die biologischen Eigenschaften und die Aggressivität des Tumors. Angegeben wird das Grading mit den Kürzeln G1 (gut differenziert) bis G3 und G4 (wenig oder undifferenziert). GX bedeutet, dass der Differenzierungsgrad nicht bestimmt werden kann.

Lymphgefäßinvasion

Die Lymphgefäßinvasion gibt zusätzlich zur Angabe für die Lymphknoten an, ob sich auch in Lymphbahnen der Tumorregion Tumorzellen befinden (L1) oder nicht (L0). Der Wert LX wird angegeben, wenn die Lymphgefäßinvasion nicht beurteilbar ist.

Veneninvasion

Die Veneninvasion gibt an, ob und in welcher Stärke der Tumor in eine Vene eingebrochen ist.

• V0: nicht nachweisbar
• V1: mikroskopisch
• V2: makroskopisch erkennbar
• VX: nicht beurteilbar

Stadiengruppierung

Die TNM Klassifikation erlaubt eine sehr fein granulierte Beschreibung der Ausbreitung eines Tumors. Für viele Anwendungen reicht eine gröbere Einteilung, die UICC-Stadieneinteilung, aus. In der Regel werden fünf Stadien, Stadium 0 und die Stadien I-IV unterschieden, wobei bei verschiedenen Tumoren einzelne Stadien durch A, B und teilweise auch C noch weiter unterteilt werden. Die bekannten Stadien sind in Kapitel 9.6.5. Stadiengruppierung aufgeführt.

Bei jedem Tumor gibt es Tabellen, in denen die TNM Klassen den jeweils gültigen Stadien zugeordnet werden. Die Stadiengruppierung muss bei jedem Tumor mit erfassbar sein.

Ann-Arbor Klassifikation

verschoben: cdaab2:Assessment_Scales_(Entry)#Ann-Arbor

FIGO-Stages

verschoben: cdaab2:Assessment_Scales_(Entry)#Papanikolaou-Kodierung

Gleason-Score

verschoben: cdaab2:Assessment_Scales_(Entry)#Gleason

Papanikolaou-Kodierung

verschoben: cdaab2:Assessment_Scales_(Entry)#Papanikolaou-Kodierung

WHO-Gradierung (von Hirntumoren)

verschoben: cdaab2:Assessment_Scales_(Entry)#WHO-Stadium_.28Gehirntumoren.29

Zusammenfassung

Bei malignen Tumoren ist die Darstellung folgender Daten vorzusehen, die dann als Werte bzw. als Qualifier übermittelt werden:

Tumorlokalisation	ICD-O
Morphologie + Dignität	ICD-O
Differenzierungsgrad	ICD-O / TNM
Typ des Stadien Codes (c,p,r,y)	TNM /Ann-Arbor
T Code + C Faktor, Multiplizität	TNM
N Code + C Faktor	TNM
M Code + C Faktor	TNM
Residualtumor	TNM
Stadiengruppierung	TNM/Ann-Arbor/Durie&Salmon/SWOG

Tumordiagnosen in HL7 V3

TNM-Diagnose-Entry

Darstellung von Diagnosen in bestimmten Anwendungs¬bereichen

Einleitung

In den folgenden Abschnitten werden beispielhaft strukturierte Diagnosedarstellung für verschiedene Anwendungsbereiche vorgestellt.

Abrechnungsdiagnose nach §295 – KVDT – Diagnose

Diagnosefelder im aktuellen KVDT – Datensatz:

FK	Vorkommen	Feldbezeichnung	Feldart	Bedingungen	Erläuterung
6001	n	ICD-Code	m	Regel 486 Regel 488 Regel 489 Regel 490 Regel 492	vgl. Kapitel 7
6003	1	Diagnosensicherheit	m	Regel 484	vgl. Kapitel 7
6004	1	Seitenlokalisation	k		vgl. Kapitel 7
6006	n	Diagnosenerläuterung	k		vgl. Kapitel 7
6008	n	Diagnosenausnahmetatbestand	m	Regel 491
3673	n	Dauerdiagnose (ICD-Code)	m	Regel 486 Regel 488 Regel 489 Regel 490 Regel 492
3674	1	Diagnosensicherheit Dauerdiagnose	m
3675	1	Seitenlokalisation Dauerdiagnose	k
3676	n	Diagnosenerläuterung Dauerdiagnose	k
3677	n	Diagnosenausnahmetatbestand Dauerdiagnosen	m	Regel 491

Tabelle 11: Diagnosen in §295 SGB V

Es können mehrere ICD-Codes angegeben werden. Dabei wird nicht überprüft (‚m\'uss), ob die Codierung einen medizinischen Sinn macht, sondern es wird nur überprüft, ob mindestens ein Primärcode angegeben wurde. Zu jedem Code kann ein Seiten¬lokalisation, muss eine Diagnosesicherheit, können mehrere Diagnose¬erläuterungen und mehrere Diagnoseausnahmetatbestände angeben werden. Über das Feld 6001 werden Abrechnungsdiagnosen, über das Feld 3673 Dauerdiagnosen abgebildet.

Beispieldarstellung in HL7-V3:

<!-- Diagnose (Abrechnungsdiagnose) 6001-->
<!-- :A17.0+;G01\*;;Tuberkulöse Meningitis Gesichert Rechts-->
<!-- Diagnose 1 *************************************************************************-->
…
<observation classCode="OBS" moodCode="EVN">
        <!-- Code für Abbrechungsdiagnose 6001-->
	<code code="XXX_DX" codeSystem="2.16.840.1.113883.5.4"/>
        <!-- Diagnoseerläuterung 6006*************************************************************************-->
	<text/>
        <!-- Primärcode 6001*************************************************************************-->
	<value xsi:type="CD" code="A17.0" codeSystem="1.2.276.0.76.5.311" 
						codeSystemName="icd10gm2006">
	<!-- Diagnosesicherheit 6003-->
		<qualifier>
			<name code="DSH" codeSystem="111.111.1.1.1"/>
			<value code="G" codeSystem="1.2.276.0.76.3.1.1.5.1.21"/>
		</qualifier>
	<!-- Seitenlokalisation 6004-->
		<qualifier>
			<name code="SL" codeSystem="111.111.1.1.1"/>
			<value code="R" codeSystem="1.2.276.0.76.3.1.1.5.1.22"/>
		</qualifier>
	</value>
        <!-- Ausnahmetatbestand zu Primärcode******************************************************************-->
	<entryRelationship typeCode="RSON">
		<observation classCode="OBS" moodCode="EVN">
			<code nullFlavor="NI"/>
			<value xsi:type="ST">…</value>
		</observation>
	</entryRelationship>
	<entryRelationship typeCode="MFST">
	<!-- Sekundärcode 6001*******************************************************************************-->
		<observation classCode="OBS" moodCode="EVN">
			<code code="XXX_DX" codeSystem="2.16.840.1.113883.5.4"/>
		<!-- Diagnoseerläuterung 6006***********************************************************************-->
			<text>Diagnoseerläuterung</text>
			<value xsi:type="CD" code="G01" codeSystem="1.2.276.0.76.5.311" 
						codeSystemName="icd10gm2006">
			<!-- Diagnosesicherheit 6003-->
				<qualifier>
					<name code="DSH" codeSystem="2.16.840.1.113883.3.7.1.0"/>
					<value code="G" codeSystem="1.2.276.0.76.3.1.1.5.1.21"/>
				</qualifier>
			<!-- Seitenlokalisation 6004-->
				<qualifier>
					<name code="SL" codeSystem="2.16.840.1.113883.3.7.1.0"/>
					<value code="R" codeSystem="1.2.276.0.76.3.1.1.5.1.22"/>
				</qualifier>
					</value>
		<!-- Ausnahmebegründung zum Sekundärcode 6008********************************************-->
			<entryRelationship typeCode="RSON">
				<observation classCode="OBS" moodCode="EVN">
					<code nullFlavor="NI"/>
					<value xsi:type="ST">…</value>
				</observation>
			</entryRelationship>
		</observation>
	</entryRelationship>
</observation>
...

Diagnose im Arztbrief/medizinische Dokumentation

Im Leitfaden „Arztbrief" sowie den zugehörigen Beispieldokumenten sind verschiedene Beispiele für die Darstellung von Diagnosen mittels HL7 V3/CDA Release 2 enthalten (siehe \[CDAr2Arztbrief\]).

Terminologie

Einleitung

Dieser Abschnitt dient der Trennung von verwendeten Codes und der normativen Spezifikation. Damit lassen sich die Codes aktualisieren, ohne dass die Spezifikation überarbeitet werden muss.

Dieser Abschnitt ist deshalb nur informativ. Die jeweils aktuellen Codes sind deshalb zu erfragen.

Überblick über die Value Sets

Value Sets	OID	Kurz¬bezeichnung
Tumordiagnosen			deutsch	Englisch
Tumore	1.2.276.0.76.11.1	uicc-tumor	ValueSet für Tumore in der Tumordokumentation	ValueSet for tumors in the cancer documentation
Nodes (Knoten)	1.2.276.0.76.11.2	uicc-nodes	ValueSet für Knoten in der Tumordokumentation	ValueSet for nodes in the cancer documentation
Metastasen	1.2.276.0.76.11.3	uicc-metastasen	ValueSet für Metastasen in der Tumordokumentation	ValueSet for metastases in the cancer documentation
Residualtumor	1.2.276.0.76.11.4	uicc-residualtumor	ValueSet für Residualtumor in der Tumordokumentation	ValueSet for residual tumor in the cancer documetation
Stadiengruppierung	1.2.276.0.76.11.5	uicc-stages	ValueSet für die Stadiengruppierung in der Tumordokumentation	ValueSet for stages in the cancer documetation
Veneninvasion	1.2.276.0.76.11.6	uicc-veneninvasion	ValueSet für die Veneninvasion in der Tumordokumentation	ValueSet for vene invasion in the cancer documentation
Lymphsysteminvasion	1.2.276.0.76.11.7	uicc-lymph¬system-invasion	ValueSet für die Lymphsysteminvasion in der Tumordokumentation	ValueSet for the lymphsystem invasion in the cancer documentation
Neural-scheiden¬invasion	1.2.276.0.76.11.8	uicc-neural¬scheiden¬invasion	ValueSet für die Neuralscheiden¬invasion in der Tumordokumentation	ValueSet for the neuralscheiden invasion in the cancer documentation
TNM-Qualifier	1.2.276.0.76.11.9	uicc-tnm-qualifier	ValueSet für die TNM-Qualifier in der Tumordokumentation	ValueSet for tnm qualifier in the cancer documen¬tation
Seitenlokalisation für Tumordokumentation	1.2.276.0.76.11.10	uicc-localisation	ValueSet für die TNM-Seitenlokalisation in der Tumordokumentation	ValueSet for tnm localisation in the cancer documentation

Tabelle 12: Value Sets

Überblick über die Codierschemata

verschoben: Kodesysteme

Diagnosetypen in Deutschland

Die folgenden Codes werden zur Typisierung von Diagnosen eingesetzt. Diese Tabelle ist eine pragmatische Sammlung der IST-Situation in den Systemen in Deutschland. Eine (internationale) Klassifikation steht derzeit nicht zur Verfügung.

Code	Bedeutung
DX	Diagnose, nicht näher spezifiziert
RFFDX	Überweisungsdiagnose
ENTDX	Einweisungsdiagnose
TRFDX	Verlegungsdiagnose
ADMDX	Aufnahmediagnose
CDDX	Fachabteilungsdiagnose
CDXDX	Fachabteilungszusatzdiagnose
CDTDX	Fachabteilung Behandlungsdiagnose
CDDISDX	Fachabteilung Entlassdiagnose
CDADMDX	Fachabteilung Aufnahmediagnose
SUCCDX	Nachfolgediagnose (mit anschließender Arbeitsunfähigkeit)
DISDX	Entlassdiagnose
TDX	Behandlungsdiagnose
PERMDX	Dauerdiagnose
APERMDX	Anamnestische Dauerdiagnose
BPERMDX	Behandlungsrelevante Dauerdiagnose
EMERDX	Notfalldiagnose, besondere Bedeutung im Falle eines Notfalls
REIMDX	Abrechnungsdiagnose
POSTOPDX	Postoperative Diagnose
PREOPDX	Präoperativ Diagnose
ADR	UAW - Beobachtete Unerwünschte Nebenwirkung
ADRPD	UAW - Grunderkrankung
ADRCCD	UAW - Begleiterkrankung
IFSGDX	If–G - Diagnosen
IFSGSUSPDX	If–G - Verdachtsdiagnosen
IFSGDD	If–G - Differentialdiagnosen
COD	Todesursache (unmittelbar zum Tode führende Krankheit)
CCCOND	Begleitkrankheiten
EXTCS	Äußere Ursache
NEO	Neubildung
UAE	unerwünschtes Arzneimittelereignis
UAW	unerwünschte Arzneimittelwirkung
CAREDX	Pflegediagnose
SYMDX	Symptom
OTHDX	sonstige Diagnose

Tabelle 14: Diagnose-Typen (OID 1.2.276.0.76.5.342)

ICD-O-Codes

verschoben: cdaab2:TNM-Diagnosen_(Entry)#Terminologie:_ICD-O

TNM-Klassfikation

veschoben: cdaab2:TNM-Diagnosen_(Entry)#Terminologie:_TNM-Klassfikation

Gleason-Score

verschoben: cdaab2:Assessment_Scales_(Entry)#Gleason

Ann-Arbor-Codes

verschoben:

Papanikolaou-Kodierung

verschoben: cdaab2:Assessment_Scales_(Entry)#Papanikolaou-Kodierung

Anhang A: Diverses

Offene Punkte

• Die Liste der Diagnosetypen in Deutschland stellt eine Mischung dar, die überarbeitet werden muss/sollte! Diese stammt aus den Systemen der Hersteller, die zu dieser Spezifikation beigetragen haben, und ist somit nicht konsentiert.

Referenzen/Literatur

\[Ann-Arbor\]	[6]
\[BMGS, 2004\]	ICD-10-Bekanntmachung des BMGS
\[CDAr2Arztbrief\]	Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen, Version 1.50 vom 12.05.2006, herausgegeben vom VHitG, HL7 Deutschland und der Arbeitsgemeinschaft Sciphox, www.hl7.de (Publikationen)
\[Deutsche Gesellschaft für Urologie e.V.\]	Miller, K./Weißbach, L. (Hrsg.), Leitlinien zur Diagnostik von Prostatakarzinomen, 1999, http://www.prostatakrebse.de/informationen/pdf/DGU-DIPK.PDF
\[DIMDI, Alpha_Id\]||Alpha-ID - Die Identifikationsnummer [7]
\[DIMDI, Basis\]	Basiswissen Kodieren, DIMDI 2004
\[DIMDI, ICD-10-GM\]	Zusatzinformationen zur ICD-10-GM Version 2011 http://www.dimdi.de/static/de/klassi/diagnosen/icd10/htmlgm2011/zusatz-morphologie-neubildungen.htm
\[DIMDI, Verschl\]	Anleitung zur Verschlüsselung [http://www.dimdi.de/static/de/klassi/diagnosen/icd10/ icdsgbv20.htm-http://www.dimdi.de/static/de/klassi/diagnosen/icd10/icdsgbv20.htm]
\[DKFZ\]	Deutsches Krebsforschungszentrum
\[DUDECK et al, 1999\]	Basisdokumentation für Tumorkranke, 5. Auflage, 1999
\[FIGO\]	http://www.ekr.med.uni-erlangen.de/GEKID/Doc/GEKID%20Mindestdatensatz%202008-04.xls
\[Helpap 1985\]	Helpap B, Böcking A, Dhom G, Kastendieck H, Leistenschneider W, Müller HA (1985) Klassifikation, histologisches und zytologisches Grading sowie Regressionsgrading des Prostatakarzinoms. Eine Empfehlung des pathologisch-urologischen Arbeitskreises "Prostatakarzinom". Urologe \[A\] 24:156-159
\[Helpap, 2002\]	Helpap, B., et al. Diagnostische Maßnahmen zur Therapieplanung des Prostatakarzinoms, Urologe B 2002 42:121-127
\[Helpap, 2007\]	Helpap, B., et al. Die Wertigkeit des 2005 modifizierten Gleason-Gradings in der urologischen Diagnostik von Prostatakarzinomen, Urologe A 2007 46:59-62
\[HL7 Datentypen\]	HL7 Version 3 Datentypen und CMETs für das Deutsche Gesundheitswesen, www.hl7.de (Publikationen)
\[InEK, Kodierrichtlinien\]	Deutsche Codierrichtlinien – Version 2005, Institut für Entgeltsystem im Krankenhaus (InEK gGmbH) 2004 [http://www.g-drg.de/service/download/ veroeff_2005/DKR2005_Endversion_PDF30_040916_1500.pdf-http://www.g-drg.de/service/download/veroeff_2005/DKR2005_Endversion_PDF30_040916_1500.pdf]
\[Louis, 2007\]	Louis et al. (2007) The 2007 WHO Classification of Tumours of the Central Nervous System. Acta Neuropathol 114(2):97–110
\[Pap\]	http://www.krebsgesellschaft.de/re_pap_test,13315.html
\[Schmoll, H.-J.\]	Kompendium Internistische Onkologie Standards in Diagnostik und Therapie, 4. Auflage, 2006
\[Technisches Komitee der HL7 Benutzergruppe Deutschland\]	Beschluss des TC vom 2005-09-01. Protokoll Abs. 1.3.2m 01.05.2005
\[Wikipedia\]	[8], März 2011
\[Wiley, 2009\]	TNM Classification of Malignant Tumours, 7th Edition Editors: Sobin L, Gospodaarowicz M, Wittekind C Wiley-Blackwell, ISBN: 978-1-4443-3241-4, Dez. 2009

Evaluierung der genutzten Diagnosetypen

Die folgende Tabelle ist im Rahmen der Evaluation von Diagnosetypen in Deutschland entstanden und hier lediglich zur Vollständigkeit als Referenz beigefügt.

	Siemens (ICD-10-GM)	Agfa Healthcare (ICD-10-GM)	§301 (ICD-10-GM)	§295 (ICD-10-GM)	UAW (MedDRA o. ICD-10-GM)	IfSG (MedDRA o.ICD)	CT (MedDRA o.ICD)	Toten- be- scheinigung (ICD-WHO)	Krebs- register (ICD, ICD-O)	Psychosoziale Diagnostik (ICF)
Einweisungsdiagnose	x	Einw	x
Aufnahmediagnose	x	Aufn	x
Fachabteilungsdiagnose			x
Nachfolgediagnose (mit anschließender Arbeitsunfähigkeit)			x
Entlassungshauptdiagnose			x
Entlassungsnebendiagnose			x
Fachabteilungszusatzdiagnose			x
Überweisungsdiagnose			x
Behandlungsdiagnose		Beh	x
Entlassdiagnose	x	Entl
sonstige Diagnose	x
Verlegungsdiagnose	x
Dauerdiagnose	x			x
Abrechnungsdiagnose	x	Abr		x
Postoperativ		Post
Präoperativ		Pra¬op
DRG-Diagnose		DRG
Fachabteilung Behandlungsdiagnose		FA Be
Fachabteilung Entlassdiagnose		Fa En
Fachabteilung Aufnahmediagnose		Fa Au
UAW - Grunderkrankung					x
UAW - Begleiterkrankung					x
UAW - Beobachtete Unerwünschte Nebenwirkung					x
IfSG - Diagnosen						x
IfSG - Verdachtsdiagnosen						x
IfsG - Differentialdiagnosen						x
Medizinischer Zustand oder Erkrankung							x
Todesursache (unmittelbar zum Tode führende Krankheit)								x
Begleitkrankheiten								x
Äußere Ursache								x
Neubildung									x
Erkrankung

Tabelle 37: Nutzung der Diagnosetypen in Deutschland

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Section: Diagnosen

Die Diagnosen werden im Arztbrief im Idealfall

• in Level 1 zur direkten Ausgabe formatiert,
• in Level 2 als Diagnose markiert und
• in Level 3 codiert angegeben (im jetzigen Leitfaden nicht beschrieben, sondern alleinig in den nicht-normativen Einzelabschnitten zu den Diagnosen wiedergegeben):
  • ICD-Diagnosen
  • TNM-Klassifikation

Die folgenden Typen von Diagnosen werden in den entsprechenden Sektionen wiedergegeben.

Aufnahmediagnose

Id	1.2.276.0.76.10.3026	Gültigkeit	2013‑12‑30 Andere Versionen mit dieser Id: Admissiondiagnosissection vom 2017‑02‑01
Status	Aktiv	Versions-Label
Name	Admissiondiagnosissection	Bezeichnung	Aufnahmediagnose
Beschreibung	Speziell gekennzeichnete Diagnose, die im Verlauf der Aufnahmeuntersuchung gestellt wird.
Klassifikation	CDA Section level template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:section (Adm...ion) hl7:templateId II 1 … 1 (Adm...ion) @root uid 1 … 1 F 1.2.276.0.76.10.3026 hl7:code CE 1 … 1 M (Adm...ion) @code CONF 1 … 1 F 46241-6 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Adm...ion)   CONF Elementinhalt muss "Aufnahmediagnosen" sein hl7:text SD.TEXT 1 … 1 M (Adm...ion)

Entlassungsdiagnose

Id	1.2.276.0.76.10.3027	Gültigkeit	2013‑12‑30 Andere Versionen mit dieser Id: Dischargediagnosissection vom 2017‑02‑01
Status	Aktiv	Versions-Label
Name	Dischargediagnosissection	Bezeichnung	Entlassungsdiagnose
Beschreibung	Diagnose, mit der der Patient entlassen wurde
Klassifikation	CDA Section level template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:section (Dis...ion) hl7:templateId II 1 … 1 (Dis...ion) @root uid 1 … 1 F 1.2.276.0.76.10.3027 hl7:code CE 1 … 1 M (Dis...ion) @code CONF 1 … 1 F 11535-2 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Dis...ion)   CONF Elementinhalt muss "Entlassungsdiagnosen" sein hl7:text SD.TEXT 1 … 1 M (Dis...ion)

Textformatierung für Diagnosen (auf Level 1)

Das nachfolgende Beispiel zur Textformatierung zeigt die Nutzung von Tabellen am Beispiel der Diagnosen.

Beispiel

<component>                     
  <!-- Diagnose mit ICD Komponente auf CDA Level 2--> 
  <section>
    <code code="29548-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
    <title>29.08.2005: Diagnosen mit ICD 10</title>
    <text>
      <table border="1">
        <thead>
          <tr>
          <th>Diagnose</th>
          <th>ICD Code</th>
          <th>Lokalisation</th>
          <th>Zusatz</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td><content ID ="DIAG200508291">Allergisches Asthma</content></td>
            <td>J45.0</td>
            <td>--</td>
            <td>G</td>
          </tr>
          <tr>
            <td><content ID ="DIAG200508292">Ausschluss Lungenemphysem</content></td>
            <td>J43.9</td>
            <td>--</td>
            <td>A</td>
          </tr>
          <tr>
            <td><content ID ="DIAG200508293">V.a. Allergische Rhinopathie durch Pollen</content></td>
            <td>J31.1</td>
            <td>--</td>
            <td>V</td>
          </tr>
        </tbody>
      </table>
    </text>
  </section>
</component>

1. WEITERLEITUNG cdaab2:ICD-Diagnose Entry (Template)

1. WEITERLEITUNG cdaab2:TNM-Diagnose Entry (Template)

1. WEITERLEITUNG cdaab2:Anam-Section (Template)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .