IG:Palliativdokumentation

Palliativdokumentation

Palliativdokumentation

Implementierungsleitfaden

vorgelegt von:
xxxx
xxx

Entwurf

Version:	0.01
Datum:	xxx
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2013: HL7 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 .

Ansprechpartner und Autoren

Ansprechpartner

• Salima Houta, Fraunhofer-Institut für Software- und Systemtechnik ISST, Dortmund

Autoren

• Salima Houta, Fraunhofer-Institut für Software- und Systemtechnik ISST, Dortmund
• Hasan Kadi, Fraunhofer-Institut für Software- und Systemtechnik ISST, Dortmund
• Lutz Oettershagen, Fraunhofer-Institut für Software- und Systemtechnik ISST, Dortmund

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

Die Palliativmedizin hat im Gegensatz zur heilenden Medizin das Ziel mit lindernden Maßnahmen (Symptomkontrolle, z. B. Schmerz) bei weit fortgeschrittenen unheilbaren Krankheiten, die in der Regel zum Tod führen, die Lebensqualität der Patienten zu verbessern. Die Behandlung des Patienten erfolgt in der Regel durch ein multidisziplinäres Team und in der Umgebung seiner Wahl.

Die verteilte und berufsgruppenübergreifende Versorgung erfordert eine effiziente Kommunikation zwischen allen Beteiligten. Alle für die Versorgung relevanten Informationen müssen den Leistungserbringern am Point of Care zur Verfügung stehen, um dem Patienten eine bestmögliche Behandlung zu ermöglichen. Im Rahmen des Projektes palliativcare.nrw wurde ein standardisierter Datensatz für die Kommunikation von medizinischen Daten im Rahmen der Palliativversorgung erarbeitet ([ISPC]). Dieser hält fest, welche Daten in welcher Struktur bei der Palliativdokumentation kommuniziert und ausgetauscht werden müssen.

Für die elektronische Kommunikation der Palliativdaten (z. B. über die Elektronische FallAkte ) ist eine technische Standardisierung notwendig. Ziel dieses Implementierungsleitfadens ist es ein strukturiertes Datenaustauschformat für die Palliativdokumentation zu spezifizieren. Die Grundlage der zu entwickelnden ePalliativdokumentation stellt die Clinical Document Architecture (CDA) dar.

Zielgruppe des Dokuments

Zielgruppe dieses Dokuments sind Produktmanager sowie Softwareentwickler, die an einer Umsetzung der technischen Schnittstelle ePalliativdokumentation beteiligt sind.

Aufbau dieses Implementierungsleitfadens

Der Implementierungsleitfaden ist eingeteilt in das dynamische und das statische Modell. Bestandteil des dynamischen Modells sind die Storyboards, die aufzeigen, wie die einzelnen Leistungserbringer im Kontext der Palliativdokumentation agieren. Das statische Modell beschreibt die detaillierte Struktur des Dokumentes sowie die Umsetzung in XML. Anhand von Beispieldaten wird für die einzelnen Sektionen eine XML-Darstellung als technische Umsetzung der ePalliativdokumentation dargestellt.

CDA Abschnitte und Sektionen

Ergänzend zu dieser Spezifikation wurde ein Beispiel-CDA-Dokument für die ePalliativdokumentation erstellt. Dieses CDA Dokument basiert auf die im statischen Modell beschriebene Struktur.

Beschreibung von RMIM-Klassen

Die verschiedenen genutzten RIM-Klassen (Observation, Procedure, Role…) und die Nutzung derer Attribute werden jeweils über Tabellen beschrieben.

Verwendung von Terminologien

Das statische Modell verwendet bestehende und neu definierte Terminologien zu Codierung von Sektionen bzw. weiteren Entitäten. Die Terminologien werden in der jeweiligen Sektion aufgeführt.

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 .

Dynamisches Modell

Die Palliativversorgung erfolgt in der Regel durch ein interdisziplinäres Versorgungsteam. In diesem Abschnitt wird anhand des dynamischen Modells aufgezeigt, wie die Kommunikation der Beteiligten im Kontext der ePalliativdokumentation erfolgt. Dabei werden beispielhaft zwei Anwendungsfälle (Use Cases) beschrieben, die den Austausch der ePalliativdokumentation aufzeigen:

• ePalliativdokumentation initial austauschen,
• ePalliativdokumentation aktualisieren.

Des Weiteren werden die Anwendungsfälle anhand eines Praxisbeispiels verdeutlicht. Dabei dient der folgende Prolog als Ausgangssituation für die in den nächsten Abschnitten vorgestellten Storyboards:

Die 50 jährige Martha Müller befindet sich in stationärer Behandlung. Im Rahmen einer pathologischen Untersuchung (Biopsie) wird ein Bronchialkarzinom im Stadium 2 festgestellt. Die komplette operative Entfernung des umliegenden Gewebes würde die Lungenfunktion zu sehr einschränken, weswegen der verantwortliche Onkologe Dr. Jansen eine Strahlentherapie vorsieht. Nach 6 Monaten Strahlentherapie stellen sich keine gravierenden Besserungen ein. Ein neues CT ergibt, dass sich Metastasen in der Leber von Frau Müller gebildet haben. In einem persönlichen Gespräch informiert Dr. Jansen Frau Müller darüber, dass die neuen Untersuchungsergebnisse keinen Zweifel daran lassen, dass die Aggressivität des Krebses und die starke Streuung keine kurative Behandlung ermöglichen und somit keine Aussicht auf Heilung besteht. Um die Symptome der Fünfzigjährigen zu lindern, wird ein interdisziplinäres Palliative-Care-Team (PCT) mit der Palliativversorgung von Frau Müller beauftragt.

Use Case: ePalliativdokumentation initial austauschen

Die vollständige Struktur der ePalliativdokumentation wird in Kapitel 3 im Detail vorgestellt. Grundsätzlich kann die Dokumentation jedoch in zwei Bereiche unterteilt werden:

• Basisdaten/Stammdaten
• Verlaufsdokumentation

Sowohl die Basisdaten als auch die Verlaufsdaten sind in Sektionen unterteilt. Welche dieser Sektionen beim Erstellen einer ePalliativdokumentation hinterlegt werden obliegt der Verantwortung des Autors. Die Basisdaten werden in der Regel zu Beginn der Versorgung durch einen qualifizierten Palliativmediziner (QPA) angelegt und enthalten beispielsweise die Personendaten des Patienten oder Kontaktdaten von beteiligten Personen/Institutionen (z.B. Verwandte, Hausarzt, Krankenkasse, usw.). Ein Großteil der Verlaufsdokumentation wird in der Regel im Laufe der Versorgung durch die verantwortlichen Versorger eingestellt (siehe Kapitel 2.2). Einzelne Sektionen können jedoch auch zu Beginn der Versorgung durch den QPA eingestellt werden.

Das folgende Kommunikationsdiagramm verdeutlicht die Kommunikation der Beteiligten beim initialen Austausch der ePalliativdokumentation:

Nach der Erstellung der ePalliativdokumentation und dem Einstellen einiger Sektionen durch einen Versorger (i.d.R. QPA) erfolgt eine Freigabe und Bereitstellung der Daten an die verantwortlichen Versorger (z.B. Hausärzte, Pflege- und Palliativdienste, Palliative-Care-Dienste, usw.). Diese können anschließend auf die hinterlegten Daten zugreifen. Storyboard

Zu Beginn der Palliativversorgung von Frau Müller erstellt Dr. Jansen eine neue ePalliativdokumentation und hinterlegt dort folgende Basisdaten:

• Personendaten des Patienten
• Kontaktdaten der Tochter, des Hausarztes und der Krankenkasse von Frau Müller
• Vermerk über das Vorhandensein einer Patientenverfügung, einer Vorsorgevollmacht und einer Betreuungsurkunde

Des Weiteren hinterlegt Dr. Jansen eine SAPV Verordnung und einen Aufnahmeeintrag in der Verlaufsdokumentation mit dem Hinweis, dass die Versorgung von Frau Müller durch einen Palliativpflegedienst fortgeführt wird. Anschließend erfolgt eine Freigabe und Bereitstellung der Dokumentation an das verantwortliche PCT. Bereits vor Beginn der Palliativversorgung greifen die Mitarbeiter des PCT auf die durch Dr. Jansen hinterlegten Daten zu und informieren sich über die neue Patientin.

Use Case: ePalliativdokumentation aktualisieren

Der Inhalt einer ePalliativdokumentation kann nicht mehr verändert werden; jedoch kann eine neue Version mit Bezug auf das Original erzeugt werden. Dadurch wird sichergestellt, dass der Verlauf aller Änderungen ersichtlich ist. Das folgende Kommunikationsdiagramm verdeutlicht die Kommunikation der Beteiligten bei der Aktualisierung einer ePalliativdokumentation:

Zum Aktualisieren einer bestehenden ePalliativdokumentation wird zu Beginn eine neue Dokumentation erstellt, in die alle Informationen aus der Vorgängerversion 1:1 übernommen werden. Anschließend können bestehende Sektionen bearbeitet oder neue Sektionen hinzugefügt werden. Nachdem alle Aktualisierungen vorgenommen wurden, wird die neu erstellte Dokumentation mit einem Verweis auf die Vorgängerversion versehen und als Ganzes erneut freigegeben und bereitgestellt. Da sowohl die Ursprungsversion als auch die aktualisierte Version bereitgestellt sind, können die Versorger bei Bedarf einen Abgleich der Versionen durchführen. Storyboard Bei der Versorgung von Frau Müller durch das PCT fallen versorgungsrelevante Daten an, die zum einen dem gesamten PCT und zum anderen Dr. Jansen bereitgestellt werden sollen. Zu diesem Zweck soll die bestehende ePalliativdokumentation aktualisiert werden. Ein Versorger aus dem PCT repliziert die bestehende Dokumentation und ergänzt die Verlaufsdokumentation um folgende Sektionen:

• Symptomerfassung
• Pflegedokumentation
• Medikation

Anschließend wird die aktualisierte Dokumentation mit einer Referenz auf die Vorgängerversion versehen und bereitgestellt. Die anderen Versorger des PCT und Dr. Jansen haben nun Zugriff auf die nachträglich hinzugefügten Daten.

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 .

Datentypen

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 .

Terminologien und OIDs

Es werden sowohl bestehende Terminologien als auch im Rahmen der ePalliativdokumentation neu definierte Terminologien aufgelistet. Um eine semantische Eindeutigkeit sicherzustellen, muss jede Terminologie eine eindeutige OID besitzen. Für alle neu definierten Terminologien werden im weiteren Verlauf des Kapitels OIDs definiert. Für die elektronische Fallakte (EFA) wurde eine Wurzel-OID bei der zentralen OID-Registratur für das Gesundheitswesen in Deutschland registriert: 1.2.276.0.76.3.1.81 . Allen Objekte, die intern in Zusammenhang mit der Fallakte Verwendung finden, werden eindeutige OID unterhalb der Wurzel-OID zugewiesen; die Vergabe neuer Objekt-Identifikatoren erfolgt dabei im Rahmen der ISO, des CEN, des DIN und der HL7-Vorgaben.

Codierung von Dokumenten und Sektionen

In der folgenden Tabelle wird den Abschnitten im Palliativdatensatz eine entsprechender LOINC Code zugeordnet. Für alle Abschnitte, für die bisher noch keine LOINC Codierung existiert, wird ein Code definiert, der im Rahmen der nächsten Interoperabilitätsforen in die Standardisierungsbemühungen von LOINC eingebracht wird. Es wird daher das CodeSystem „LOINC” benutzt .

Abschnitt im Dokument	LOINC Code	Vorläufiger Code	Beschreibung
Aufnahme	52536-0	-	Admission Information
Symptomerfassung	29547-7	-	History of disorders
Pflegedokumentation	Nicht vorhanden	Pflegedokumentation	-
Einschätzung	42800-3	-	ECOG performance status grade
Diagnose	Nicht vorhanden	-	Diagnosis
Metastasen	Nicht vorhanden	Metastasen	-
Zugänge und Katheter	Nicht vorhanden	ZugängeUndKatheter	-
Medikation	10160-0	-	History of medication use Narrative
Hilfsmittel	Nicht vorhanden	Hilfsmittel	-
Hospizdokumentation	Nicht vorhanden	Hospizdokumentation	-
SAPV Verordnung	Nicht vorhanden	SAPV	-
Pflegestufe	Nicht vorhanden	Pflegestufe	-
Einweisung stationär	Nicht vorhanden	Einweisung	-
Versorgungsunterbrechung	Nicht vorhanden	Versorgungsunterbrechung	-
Abschluss	Nicht vorhanden	Abschluss	-
Wichtige Anmerkungen zum Verlauf	34109-9	-	Note
ePalliativdokumentation	Nicht vorhanden	ePalliativdokumentation	-
Patientenverfügung	Nicht vorhanden	Patientenverfügung	-
Vorsorgevollmacht	Nicht vorhanden	Vorsorgevollmacht	-
Betreuungsurkunde	Nicht vorhanden	Betreuungsurkunde	-

Codierung von granularen Informationen

Innerhalb der Sektionen werden medizinische Informationen der ePalliativdokumentation granular über sogenannte „Observation“-Klassen u.Ä. dokumentiert. Sofern Terminologien bestehen, die für die semantische Beschreibung der Informationen genutzt werden können, werden diese verwendet. Alle weiteren Inhalte, zu denen bisher keine bestehende Terminologie bekannt ist, werden über den im Rahmen der ePalliativdokumentation definierten Terminologie „Palliativinhalte“ definiert. Dieser Katalog wird mit der eindeutigen OID 1.2.276.0.76.3.1.81.4.6.0 unterhalb der Fraunhofer Root aufgeführt.

Sektion	Information im Dokument	Katalog-OID und Code	Code im Katalog „Palliativinhalte“	Beschreibung
Alle Sektionen des CDA-Body	Eintrag Daten	-	1.0	Beschreibende Daten eines Eintrages
Wichtige Anmerkungen zum Verlauf	Anmerkung Basisdaten	-	2.0	Allgemeine wichtige Anmerkung bzgl. Basisdaten
	Anmerkung Verlaufsdokumentation	-	2.1	Allgemeine wichtige Anmerkung bzgl. Verlaufsdokumentation
Aufnahme	Aufnahme	-	3.0	-
	Mobilität	-	3.1	Mobilität des Patienten
	Prognose	-	3.2	Prognose
	Erkrankungsrelevante Behandlung	-	3.3
	Besonderer Aufwand mit	-	3.4
	Patiententherapie-Wünsche	-	3.5
	Behandlungsziel	-	3.6
Symptomerfassung	Symptom		4.0
Pflegedokumentation	Pflegedokumentation	-	5.0	Pflegedokumentation
Metastasen	Metastasen	todo	todo	todo
Einschätzung	Einschätzung	-	6.0
Zugänge und Katheter	Zugänge/Katheder	-	7.0
	Device	-	7.1	Modell des Zugangs/Katheder
Medikation	Medikation	2.16.840.1.113883.5.4, DRUG	-
	Medikament	1.2.276.0.76.4.6	-
Hilfsmittel	Hilfsmittel	-	8.0
Hospizdokumentation	Hospizdokumentation	-	9.0
	Eintrag	-	9.1
SAPV Verordnung	SAPV Verordnung	-	10.0
	Art der Verordnung	-	10.1
Pflegestufe	Pflegestufe	-	11.0
Einweisung stationär	Einweisung stationär	-	12.0
Versorgungsunterbrechung	Versorgungsunterbrechung	-	13.0
Abschluss	Abschluss	-	14.0
	Tod	(LOINC 69454-7)	14.1

Codierung der Werteausprägungen der granularen Informationen

Der Palliativdatensatz sieht vor, dass zu jedem Eintrag spezifische Metadaten erfasst werden. Dabei wird auch die Art des Kontaktes bei der Feststellung des dokumentierten med. Ereignisses erfasst. Dieser wird aus einer Liste ausgewählt. Diese Liste, die im ISPC Palliativdatensatz definiert ist, dient als Grundlage für die Aufstellung Codesystems, welches innerhalb der einzelnen Sektionen definiert wird.

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 .

Statisches Modell

Im Folgenden wird das statische Modell des ePalliativdokuments beschrieben.

CDA R2 Header

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 .

Clinical-Document Klasse

ClinicalDocument ist die zentrale Klasse des Clinical Document Architecture Modells. Die zugehörigen CDA-Header-Elemente und deren Bedeutung, so wie sie in den im Anhang beschriebenen Anwendungsszenarien zur Anwendung kommen, werden im Abschnitt zur Dokumentenstruktur und beim Dokumenten-Level-Template in diesem Leitfaden detailliert beschrieben.

Clinical Document Klasse

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 .

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 .

Textstrukturierung

Die medizinischen Informationen werden im CDA Body im Sinne von Level 1 immer in Textform wiedergegeben (verpflichtend) und wo immer möglich auch mit Section-Codes versehen, also auf Level 2 dargestellt. Dies garantiert, dass die Dokumente immer für den Menschen lesbar (und verstehbar) sind. Im Folgenden ist das Muster einer Level 1 und Level 2 Darstellung gezeigt. Level 3 ist angedeutet:

<component>
  <structuredBody>
  ... 
    <component>
      <section>
        <!-- Level 2 -->
        <code code="..." codeSystem="..." />
        <!-- Level 1 -->
        <title> ... </title>
        <text>
           ...
        </text>
        <!-- Level 3 -->
        <entry>
           ...
        </entry>
      </section>
    </component>
    ...
  </structuredBody>
</component>

Textauszeichnung

Der Text selber kann wiederum Strukturelemente aufweisen. Dies kann genutzt werden, um Listen, Tabellen oder auch Unterabschnitte zu definieren. Innerhalb eines Section-Tags wird in CDA Level 2 das text Tag verwendet, um den narrativen Text („plain text") darzustellen. In vielen Fällen lassen sich die medizinischen Inhalte aber auch noch weiter gehend strukturiert darstellen. Dazu stehen in CDA als Stil-Elemente Listen, Tabellen und Unterabschnitte (Paragrafen) zur Verfügung. Mit Hilfe eines einfachen Stylesheets können die Inhalte in diesen Strukturelementen für den Menschen lesbar dargestellt werden.

Listen

Das Strukturelement „Liste" dient zur Abbildung einer einfachen Aufzählung medizinischer Inhalte. Eine Liste wird mit dem list Tag eingeschlossen. Das optionale Attribut @listType ermöglicht die Auflistung unsortiert (@listType="unsorted"), die üblicherweise mit Bulletpoints • dargestellt wird, und in sortierter Form (@listType="sorted") , die mit Zahlen etc. dargestellt wird. Ohne Angabe von @listType ist die Liste unsortiert. Ein Element der Aufzählung (item) wird mit dem item Tag eingeschlossen. Eine Liste hat formal das folgende Aussehen:

<list>
  <item> 1. Element der Liste</item>
  <item> 2. Element der Liste</item>
  <item> ...</item>
  <item> n. Element der Liste</item>
</list>

Das folgende Beispiel zeigt eine mögliche Darstellung eines Befundes, strukturiert mittels Liste.

<text>
  <list>
    <item>Pulmo: Basal diskrete RGs</item>
    <item>Cor: oB</item>
    <item>Abdomen: weich, Peristaltik: +++</item>
    <item>Muskulatur: atrophisch</item>
    <item>Mundhöhle: Soor, Haarleukoplakie</item>
    <item>Haut blass, seborrhoisches Ekzem, Schleimhäute blass,
          Hautturgor herabgesetzt</item>
    <item>Neuro: herabgesetztes Vibrationsempfinden der Beine,
          distal betont, Parästesien der Beine, PSR, AST
          oB und seitengleich.</item>
  </list>
</text>

Dasselbe Beispiel in der Ansicht eines Browsers (mittels Stylesheet).

Ansicht im Browser

• Pulmo: Basal diskrete RGs
• Cor: oB
• Abdomen: weich, Peristaltik: +++
• Muskulatur: atrophisch
• Mundhöhle: Soor, Haarkoplakie
• Haut blass, seborrhoisches Ekzem, Schleimhäute blass, Hautturgor herabgesetzt
• Neuro: herabgesetztes Vibrationsempfinden der Beine, distal betont, Parästesien der Beine, PSR, AST oB und seitengleich.

Tabellen

Zur Repräsentation medizinischer Inhalte, die sich adäquat tabellarisch darstellen lassen, bietet sich die Tabellenform an. Als Beispiele seien genannt: Laborwerte, Allergiewerte, Diagnose mit ICD-Verschlüsselung etc. CDA realisiert ein vereinfachtes XHTML Table Modell, das HTML sehr ähnelt. Eine Tabelle wird angedeutet mit dem table Element. Als Attribut ist hier @border vorgesehen, das die Breite der Umrahmung angibt.

<table border="1">
  ''...Tabellen-Elemente''
</table>

Eine Tabelle besteht aus einer oder mehreren Spalten. In der ersten Zeile werden die Spaltenüberschriften aufgeführt. Die Tabellenüberschrift wird eingeschlossen in thead Tags, die Überschriftenzeile in tr Tags und die einzelnen Spalten-Items der Überschrift mit th Tag.

<table>
  <thead>
    <tr>  <!-- Überschrift-Zeile -->
      <th> Spaltenüberschrift 1</th> 
      ...
      <th> Spaltenüberschrift n</th>
    </tr>
  </thead>
  ...
</table>

Die eigentlichen Inhalte werden in tbody Tags, die Datenzeile in tr Tags und die einzelnen Spalteninhalte einer Datenzeile mit td Tag gekapselt. Insgesamt hat eine Tabelle formal das folgende Aussehen:

<table>
  <thead>
    <tr>  <!-- Überschrift-Zeile -->
      <th> Spaltenüberschrift 1</th>
      ...
      <th> Spaltenüberschrift n</th>
    </tr>
  </thead>
  <tbody>
    <tr>  <!-- 1. Zeile mit Daten -->
      <td>Inhalt Spalte 1 in Zeile 1</td>
      ...
      <td>Inhalt Spalte n in Zeile 1</td>
    </tr>
    ...
    <tr> <!-- m. Zeile mit Daten -->
      <td>Inhalt Spalte 1 in Zeile m</td>
        ...
      <td>Inhalt Spalte n in Zeile m</td>
    </tr>
  </tbody>
</table>

Das folgende Beispiel zeigt die Repräsentation einer Diagnose in Tabellenform, wobei die Spaltenüberschriften lauten: "Diagnose", "ICD Code", "Lokalisation" und "Zusatz"

<table>
  <thead>
    <tr>
      <th>Diagnose</th>
      <th>ICD Code</th>
      <th>Lokalisation</th>
      <th>Zusatz</th>
    </tr>
  </thead>
  <tbody>
   <tr>
      <td>Tuberkulose des Ohres</td>
      <td>A18.6</td>
      <td>R</td>
      <td>G</td>
    </tr>
    <tr>
      <td>Ausschluss Lungenemphysem</td>
      <td>J43.9</td>
      <td>--</td>
      <td>A</td>
    </tr>
    <tr>
      <td>V. a. Allergische Rhinopathie durch Pollen</td>
      <td>J31.1</td>
      <td>--</td>
      <td>V</td>
    </tr>
  </tbody>
</table>

Dasselbe Beispiel in der Ansicht eines Browsers (mittels Stylesheet).

Unterabschnitte

Zur Strukturierung eines längeren Textes kann das paragraph Tag verwendet werden. Beispiel:

<text>
  <paragraph> Sollten nach der empfohlenen Medikation mit Atemur die
  klinischen Zeichen weiterhin bestehen, halte ich bei dem umfangreichen
  Risikoprofil einen Kuraufenthalt für zwingend notwendig.</paragraph>
  <paragraph> Ich bitte dann um Wiedervorstellung des Patienten.
  </paragraph>
</text>

Überschriften

Mit dem caption Element kann man Paragrafen, Listen, Listenelemente, Tabellen oder Tabellenzellen mit einer Beschreibung („Überschrift") versehen. Ein caption Element enthält Text und kann Verweise (Links) oder Fußnoten enthalten.

Superskripts und Subskripts

Diese Gestaltungsmöglichkeiten sind im CDA-Standard beschrieben, werden aber in diesem Leitfaden noch nicht genutzt.

Zeilenumbrüche

Das br Element <br/> kann benutzt werden, um im laufenden Text einen „harten" Zeilumbruch zu erzwingen. Dies unterscheidet sich vom paragraph Element, da der Zeilenumbruch keinen Inhalt hat. Empfänger sind gehalten, dieses Element als Zeilenumbruch darzustellen.

Beispiel

<text>
  Patient hat Asthma seit seinem zehnten Lebensjahr.<br/>
  Patient kommt damit gut zurecht.
</text>

Fußnoten

Diese Gestaltungsmöglichkeiten sind im CDA-Standard beschrieben, werden aber in diesem Leitfaden noch nicht genutzt.

Sonstige Zeichenstile

Mittels des @styleCode Attributs im Textteil, das in content Elementen verwendet werden kann, ist es möglich, Vorschläge des Autors des Dokuments bezüglich der Visualisierung von umschlossenen Textteilen zu beschreiben. Der Empfänger ist nicht verpflichtet, den Text tatsächlich so visuell darzustellen, wie es die Vorschläge andeuten. Bisher werden im Rahmen dieses Leitfadens die folgenden Style-Codes unterstützt, die in beliebiger Reihenfolge genutzt werden können.

Font-Stil-Angaben (Änderung der Font-Charakteristik)
Code	Definition
Bold	Fettdruck
Underline	Unterstrichen
Italics	Kursivschrift
Emphasis	Betont

Stil-Codes für den narrativen Text

<text>
  Einiges vom Text wird <content styleCode="Bold">im Fettdruck</content> 
  dargestellt, anderes in <content styleCode="Bold Italics">fetter
  Kursivschrift</content>.
</text>

Referenzierter Inhalt (content)

Das CDA content Element wird benutzt, um Text ausdrücklich mit Tags „einzurahmen", so dass er referenziert werden kann oder bestimmte Möglichkeiten zur visuellen Darstellung genutzt werden können. Das content Element kann rekursiv ineinander geschachtelt werden, was die Einrahmung von ganzen Texten bis hin zu kleinsten Teilen (Worte, Buchstaben etc.) erlaubt.

Das content Element enthält ein optionales Identifikator Attribut, das als Ziel einer XML Referenz dienen kann. Alle diese IDs sind als XML IDs definiert und müssen im gesamten Dokument eindeutig sein. Die originalText Komponente einer RIM Klasse, die sich in den CDA Entries (siehe unten) wieder findet, kann sich somit explizit auf die vom content Element im Textteil umschlossene Information beziehen.

Im Beispiel wird das Textstück Asthma durch das content Element eingerahmt, so dass in einem möglichen Level 3 Entry darauf Bezug genommen werden kann (originalText.reference, siehe unten).

Beim Patienten wurde <content ID="diag-1">Asthma</content> diagnostiziert.

Das content Element wird auch zur Einrahmung von Text benutzt, der in einem, bestimmten Stil dargestellt werden soll, was mit dem @styleCode Attribut (siehe unten) näher beschrieben wird.

Referenz zu (externen) Multimedia-Inhalten

Es ist möglich, zusätzlich zu dem Text auch Referenzen auf externe Multimediaobjekte wie Bilder etc. zu spezifizieren. Dies geschieht über das renderMultiMedia Element und dient dazu aufzuzeigen, wo das Multimedia-Objekt gezeigt/dargestellt werden soll.

Das renderMultiMedia Element hat ein optionales caption Element. Es weist außerdem die Referenz (XML ID) zum erforderlichen Objekt auf, die als XML IDREF im selben Dokument definiert sein muss. XML ID und IDREF sind also korrespondierende Definitionen (einmalig) und Referenzen darauf (mehrfach möglich) eines CDA Entry ObservationMedia (oder RegionOfInterest) im selben Dokument.

Das renderMultiMedia Element trägt dabei im @referencedObject Attribut die ID.

Die Information zum eigentlichen Objekt wird in einem CDA Entry festgehalten. Für diesen Leitfaden wird ausschließlich das Element observationMedia verwendet.

Dieser Eintrag trägt im entry Element unter anderem das @ID Attribut als Zielreferenz des @referencedObject Attributs vom renderMultiMedia Element.

ObservationMedia Klasse

Die Klasse ObservationMedia selbst ist im Prinzip ein Clinical Statement, wobei die im Folgenden genannten Elemente möglich sind.

ObservationMedia CDA Entry zur Darstellung der Informationen eines Multimedia-Objektes.

Eine detaillierte Beschreibung ist beim entsprechenden Template Eingebettetes Objekt Entry angegeben.

Regel OMVL: Wenn die Klasse observationMedia genutzt wird, muss sie ein value Element mit dem eigentlichen Objekt enthalten.

Vokabular

Der Datentyp von Multimedia-Objekten ist immer ED (encapsulated data). Dabei ist auch der Medientyp (MIME) im entsprechenden @mediaType Attribut zu nennen. Zugelassen sind hier zunächst nur die folgenden Mime-Typen. Als „verpflichtend", also als zu unterstützen, werden die Typen text/plain, application/pdf sowie audio/mpeg, image/png, image/jpeg und video/mpeg eingestuft.

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.
Id	1.2.276.0.76.11.14	Gültigkeit	2014‑08‑25
Status	Entwurf	Versions-Label
Name	Mediatypes	Bezeichnung	Medientypen
Benutzung: 1 Id Name Typ Template 1.2.276.0.76.10.4014 Eingebettetes Objekt Entry DYNAMIC
Quell-Codesystem	1.2.840.10003.5.109 - FHIR: urn:oid:1.2.840.10003.5.109
Level/ Typ Code Bezeichnung Codesystem Beschreibung 0‑L text/plain Mime Type text/plain 1.2.840.10003.5.109 Für beliebige Texte. Dies ist der ’default’ Typ. In dieser Form ist er identisch mit dem ST Typ 0‑L text/html Mime Type text/html 1.2.840.10003.5.109 Bestimmt für formatierte Texte in HTML Format. HTML reicht für die meisten Anwendungen aus, bei denen Layout erwünscht ist. HTML ist Plattform-unabhängig und weit verbreitet. 0‑L text/xml Mime Type text/xml 1.2.840.10003.5.109 0‑L application/pdf Mime Type application/pdf 1.2.840.10003.5.109 Adobe Portable Document Format 0‑L image/png Mime Type image/png 1.2.840.10003.5.109 Portable Network Graphics (PNG, http://www.cdrom.com/pub/png) ist eine verlustfreie Komprimierung von Bilddateien. Wo vorher GIF benutzt wurde, muss jetzt PNG unterstützt werden. 0‑L image/jpeg Mime Type image/jpeg 1.2.840.10003.5.109 Dieses Format wird benutzt für hohe Auflösungen bei Fotos und anderen Bilddateien. Die Komprimierung verläuft nicht ohne Verluste, wodurch dieses Format nicht immer geeignet ist für diagnostische Zwecke. JPEG wird vorwiegend benutzt werden für ’thumbnails’ von großen (DICOM) Dateien. 0‑L image/gif Mime Type image/gif 1.2.840.10003.5.109 0‑L video/mpeg Mime Type video/mpeg 1.2.840.10003.5.109 MPEG ist ein internationaler Standard für Videobilder. Er ist weit verbreitet und Open-Source-Implementierungen sind verfügbar. 0‑L audio/mpeg Mime Type audio/mpeg 1.2.840.10003.5.109 MPEG-1 Audio layer-3 (auch bekannt als MP3) ist momentan der Standard für komprimierte Audiodaten.
Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

mediaType Attribut Werte (Datenarten)

Beispiel

Das in observationMedia.value befindliche reference Element enthält als Wert den Verweis auf das eigentliche Multimedia-Objekt.

Das folgende Beispiel beschreibt einen Befund am linken Zeigefinger, der zusätzlich mit einem Bild dokumentiert ist.

<section>
   <code code="8709-8" codeSystem="2.16.840.1.113883.6.1" 
    codeSystemName="LOINC"/>
   <title>Untersuchung der Haut</title>
   <text>Rötung an der Palmarfläche des linken Zeigefingers
     <renderMultiMedia referencedObject="MM1"/>
   </text>
   <entry>
      <observationMedia classCode="OBS" moodCode="EVN">
         <templateId root="1.2.276.0.76.10.4014"/>
         <value mediaType="image/jpeg">
            <reference value="lefthand.jpeg"/>
         </value>
      </observationMedia>
   </entry>
</section>

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 .

Datentypen

Die verschiedenen Templates (Header, Section und Entry) benutzen verschiedene Datentypen in speziellen Ausprägungen. Diese werden nachfolgend kurz aufgelistet. Eine detaillierte Erläuterung findet sich im Wiki unter dem Implementierungsleitfaden zu den Datentypen und den unterstützten Datentypen bei ART-DECOR.

Datentyp	DT	Ausprägung	Erläuterung, Beispiel
Adressen	AD	hier zu beachten: AD.DE Adresse in Deutschland	allgemeine Adresse, Geburtsort
boolesche Werte	BL		Ja/Nein-Informationen
kodierte Informationen	CD
kodierte Informationen	CE
kodierte Informationen	CR
kodierte Informationen	CS.LANG
kodierte Informationen	CV
Encapsulated Data	ED
Identifikation	II
Ganzzahlen	INT
nicht-negative Ganzzahlen	INT.NONNEG
Zeitintervalle	IVL_TS
Namen für Organisationen und Institutionen	ON
Namen für Personen	PN	hier zu beachten: PN.DE Namensnutzung in Deutschland
physikalische Mengenangaben	PQ
String mit Codes	SC
Text in CDA-Sections	SD.TEXT
Zeichenketten	ST
Kontaktinformationen	TEL		Telefon, Telefax und Emailadressen
Zeitpunkte	TS		Datum und Uhrzeit
Zeitpunkte	TS.DATE.MIN	mindestens YYYYMMDD
Zeitpunkte	TS.DATETIME.MIN	mindestens YYYYMMDDhhmmss
URLs	URL

CDA Datentypen

Sektionen im Body der Palliativdokumentation

Der CDA Body umfasst die klinische Dokumentation. Die nachfolgenden Abschnitte beschreiben, wie die einzelnen Strukturen der Verlaufsdokumentation in die CDA-Struktur abgebildet werden. Die Abschnitte der Verlaufsdokumentation werden auf Abschnitte/Sektionen des CDA Dokumentes abgebildet. Die semantische Bedeutung einer Section wird über deren Attribut Section/code bestimmt.

Entry: Neuer Eintrag

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Neuer Eintrag
allg. Erläuterung	Wird für neue Einträge genutzt
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Für jeden neuen Eintrag zu einer der in Tabelle 5 aufgeführten Sektionen sollen spezielle Metadaten festgehalten werden. Diese können über die HL7 Entität (z. B. zur Darstellung einer Diagnose) nicht dargestellt werden. Es werden zusätzliche Informationen zu den verschiedenen Einträgen benötigt (z. B. Art des Kontaktes, beteiligte Kooperationspartner). Die Darstellung in HL7 erfolgt mittels einer Observation-Klasse, die an den entsprechenden Eintrag annotiert wird und diese Informationen abbildet.

Alle am Kontakt beteiligten Partner werden über eine „Participation“ (siehe CDA-Header) festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	EintragDaten			M	Beinhaltet Metainformationen zu einem Eintrag
2	act	@classCode		1..1	M	OBS
2	act	@moodCode		1..1	M	EVN
2	act	code	CD CWE	1..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="1.0"
2	act	effectiveTime	TS	0..1	O	Datum des Eintrags
2	act	value	ANY CWE	0..1	O	Beschreibung durch Katalog "Art des Kontakts"
2	part	participant		0..*	O	Angabe der beteiligten Personen

Katalog "Art des Kontaks" (OID 1.2.276.0.76.3.1.81.4.6.1)

Code	Beschreibung
1	Telefonisch
2	Hausbesuch
3	Praxis

Beispiel

<observation classCode=“OBS“ moodCode=“EVN“>
..
<entryRelationship typeCode="COMP">
	<observation classCode="OBS" moodCode="EVN">
		<code xsi:type="CD" code="1.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Eintrag"/>
		<effectiveTime value="20140201" />
		<value xsi:type="CD" code="1" codeSystem="1.2.276.0.76.3.1.81.4.6.1" codeSystemName="Art des Kontakts" displayName=“telefonisch“/>
		<participant typeCode="PRF">
			<participantRole classCode="CAREGIVER">
				<id extension=“111” root=“xxx ” />
				<addr>
					<streetName>Testweg</streetName>
					<houseNumber>123</houseNumber>
					<postalCode>12345</postalCode>
					<city>Dortmund</city>
				</addr>
				<playingEntity>
					<name>
						<given>Max</given>
						<family>Mustermann</family>
					</name>
				</playingEntity>
			</participantRole>
		</participant>
	</observation>
</entryRelationship>
..
</oberservation>

Section: Aufnahme

	Template-Metadaten
Template-Typ	Section
Template ID	-
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Aufnahme
allg. Erläuterung	Sektion Aufnahme
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Alle Aufnahmen (Erstaufnahme, Notaufnahme, geplante Wiederaufnahme etc.) werden in der Sektion „Aufnahme“ festgehalten. Über den Abschnitt Aufnahme werden relevante alle relevanten Daten der Aufnahme des Patienten in ein System der palliativen Versorgung festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Aufnahme				Die für die Aufnahme eines Patienten relevanten Daten werden in dieser Sektion ferstgehalten
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	1..1	R	codeSystem="LOINC", code="52536"
1	rel	entry		0..*	O
2	rel	@typeCode	CS CNE	1..1	M
2	act	Aufnahme		0..*	O	Pro Aufnahme des Patienten wird eine solche Observation angelegt
3	act	@classCode	CS CNE	1..1	M	ENC
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.2", codeSystemName="Zuweisung als" code="[1-4]" (z. B. 1 = Geplante Erstaufnahme)
3	act	effectiveTime	TS	1..1	R	Datum der Aufnahme
3	act	id	Set<II>	0..*	O	Identifier
3	part	participant		0..1	O	Angabe des Zuweisenden Arztes/Organisation
3	rel	entry		0..*	O
4	rel	@typeCode	CS CNE	1..1	M
4	act	Mobilität		0..1	O	Angabe der Mobilität des Patienten
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="3.1"
5	act	value	ANY CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.3", codeSystemName="Mobilität", code=[1-7], z. B. code=1 --> gefähig
3	rel	entry		0..1	O
4	rel	@typeCode	CS CNE	1..1	M
4	act	Prognose		0..*	O	Prognose für den Patienten
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="3.2"
5	act	text	ED	1..1	O	Freitext zur Prognose
5	act	value	ANY CWE	0..1	R	Angabe des Codesystems für "Prognose" und Angabe der Prognose innerhalb des angegebenen Codesystems
3	rel	entry		0..1	O
4	rel	@typeCode	CS CNE	1..1	M
4	act	ErkrankungsrelevanteBehandlung		0..*	O	Beschreibt erkrankungsrelevante Behandlungen
5	act	@classCode	CS CNE	1..1	M	PROC
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="3.3"
5	act	text	ED	1..1	R	Freitext
3	rel	entry		0..1	O
4	rel	@typeCode	CS CNE	1..1	M
4	act	BesondererAufwandMit		0..*	O	Angaben über mögliche Dinge mit denen der Patient besonderen Aufwand hat
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="3.4"
5	act	text	ED	1..1	R	Freitext
5	act	value	ANY CWE	0..1	O	Angabe über Codesystem, falls vorhanden
3	rel	entry		0..1	O
4	rel	@typeCode	CS CNE	1..1	M
4	act	PatientTherapieWuensche		0..*	O	Wünsche des Patienten bzgl. der Therapie
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="3.5"
5	act	text	ED	1..1	R	Freitext
5	act	value	ANY CWE	0..1	O	Angabe über Codesystem, falls vorhanden
3	rel	entry		0..1	O
4	rel	@typeCode	CS CNE	1..1	M
4	act	Behandlungsziel		0..*	O	Angaben zum Behandlungsziel
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	GOL
5	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="3.6"
5	act	text	ED	1..1	R	Freitext
5	act	value	ANY CWE	0..1	O	Angabe über Codesystem, falls vorhanden

Katalog "Zuweisung als" (OID 1.2.276.0.76.3.1.81.4.6.2)

Code	Beschreibung
1	Geplante Erstaufnahme
2	Notaufnahme
3	Geplante Wiederaufnahme
4	Sonstige

Katalog "Mobilität" (OID 1.2.276.0.76.3.1.81.4.6.3)

Code	Beschreibung
1	Geh fähig
2	Rollator
3	Rollstuhl
4	Nachtstuhl

Beispiel

<section>
	<code code="52536-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Admission Information"/>
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="3.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Aufnahme"/>
			<effectiveTime value="20140201"/>
			<value xsi:type="CD" code="1" codeSystem="1.2.276.0.76.3.1.81.4.6.2" codeSystemName="Zuweisung als" displayName="Geplante Erstaufnahme"/>
			<participant typeCode="REF">
				<participantRole classCode="CAREGIVER">
					<id extension="123 " root="xxx " />
					<playingEntity>								
						<name>
							<given>Notarzt Dr. Max</given>
							<family>Mustermann</family>
						</name>
					</playingEntity>
				</participantRole>
			</participant>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="xxx" codeSystem="xxx" codeSystemName="xxx" displayName="Mobilität"/>
					<value xsi:type="CD" code="4" codeSystem="1.2.276.0.76.3.1.81.4.6.3" codeSystemName="Mobilitaet" displayName="Nachtstuhl"/>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="3.1" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Prognose"/>
					<text>
						Text bwz. Kommentare, falls vorhanden
					</text>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="3.4" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Besonderer Aufwand mit"/>
					<text>
						Text bzw. Kommentare, falls vorhanden
					</text>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="3.5" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="PatientenTherapieWuensche"/>
					<text>
						Text bzw. Kommentare, falls vorhanden
					</text>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="3.6" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Behandlungsziel"/>
					<text>
						Text bzw. Kommentare, falls vorhanden
					</text>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<procedure classCode="PROC" moodCode="EVN">
					<code xsi:type="CD" code="3.3" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="ErkrankungsrelevanteBehandlung"/>
					<text>
						Text bzw. Kommentare, falls vorhanden
					</text>
				</procedure>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: Symptomerfassung

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template
genutztes Templates
nutzende Templates
abgeleitete Templates
Schwester-Templates
generelle Beschreibung	Sektion für Symptomerfassung
allg. Erläuterung	Sektion für Symptomerfassung
Verhältnis zu IHE	neu
Ballotierungsstatus
Erweiterbarkeit	offen oder geschlossen

Alle Symptome werden in dieser Sektion festgehalten. Wie in der nachfolgenden Abbildung zu erkennen, umfasst die Sektion Symptomerfassung eine beliebige Anzahl Einträge eines Symptoms in Form einer Observation-Klasse

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Symptomerfassung				Beschreibt die Symptome des Patienten
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	1..1	R	codeSystem="LOINC", code="29547-7"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Symptom		0..*	O	Für jedes Symptom des Patienten wird solch eine Entität (Observation) angelegt
3	act	@classCode	CS CNE	1..1	M	OBS
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code=4.0
3	act	text	ED	0..1	O	Mögliche weitere Symptome, welche nicht codiert angegeben werden können als Freitext
3	act	effectiveTime	TS	0..1	O	Datum der Erfassung
3	act	value	ANY CWE	0..1	O	Codierte Angabe des "Symptom" und Angabe über Ausgeprägtheit des Symptoms (z.B. Skala 1 bis 10, abhängig von gewählter Codierung bei Attribut code)
3	act	id	SET<II>	0..*	O	Identifier

Katalog "Symptome"

Dieser Katalog wird unter der Fraunhofer-Root unter der OID 1.2.276.0.76.3.1.81.4.6.4 aufgeführt.

Code	Beschreibung
1	Schmerzen
2	Übelkeit
3	Erbrechen
4	Luftnot
5	Verstopfung
6	Schwäche
7	Appetitmangel
8	Müdigkeit
9	Wunden / Dekubitus
10	Hilfebedarf bei Aktivitäten des täglichen Lebens
11	Depressivität
12	Angst, Unruhe
13	Anspannung
14	Desorientiertheit, Verwirrtheit
15	Schlafstörung
16	Probleme mit der Organisation der Versorgung
17	Überforderung der Familie des Umfeldes
18	Weitere Symptome (werden dann als Freitext hinterlegt)

Beispiel

<section>
	<code code="29547-7" codeSystem="LOINC" displayName=“Anamnese“ />
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="4.0" codeSystem="Palliativinhalte" codeSystemName="1.2.276.0.76.3.1.81.4.6.0" displayName="Symptom"/>
			<effectiveTime value="20140201"/>
			<value xsi:type="CD" code="4" codeSystem="1.2.276.0.76.3.1.81.4.6.4" codeSystemName="Symptome" displayName=”Luftnot”>
				<qualifier>
					<value code="5 " />
				</qualifier>
			</value>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag! -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: Pflegedokumentation

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Pflegedokumentation
allg. Erläuterung	Sektion Pflegedokumentation
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Die Pflegedokumentation wird in der Section „Pflegedokumentation“ festgehalten. Hier können Informationen zur Patientenpflege hinterlegt werden, welche eine Relevanz für das PalliativCareTeam haben.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Pflegedokumentation				Die Sektion Pflegedokumentation umfasst eine beliebige Anzahl Einträge einer Pflegedokumentation in Form von Observation-Klassen
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	0..1	O	codeSystem="LOINC" code="Pflegedokumentation"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Pflegedokumentation		0..*	O	Je eine Observation pro Eintrag in die Pflegedokumentation
3	act	@classCode	CS CNE	1..1	M	OBS
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CW CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0" code="5.0"
3	act	text	ED	0..1	O	Biographische Aspekte als Freitext
3	act	effectiveTime	TS	0..1	O	Datum der Erfassung
3	act	value	ANY CWE	0..1	O	Codierte Angabe des Problembereichs und Angabe über die Problematik
3	act	id	Set<II>	0..*	O	Identifier

Katalog "Problembereiche" (OID 1.2.276.0.76.3.1.81.4.6.5)

Code	Beschreibung
1	Ernährung
2	Mobilität
3	Medikamenteneinnahme
4	Ausscheidung
5	Spezialisierte Pflege

Beispiel

<section>
	<code code="Pflegedokumentation" codeSystem="LOINC" />
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="5.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Pflegedokumentation"/>
			<effectiveTime value="20140201" />
			<value xsi:type="CD" code="4" codeSystem="1.2.276.0.76.3.1.81.4.6.5" codeSystemName="Problembereiche" displayName=”Ausscheidung”/>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

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>

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: Metastasen

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Metastasen
allg. Erläuterung	Sektion für Angabe von Metastasen
Verhältnis zu IHE	neu
Ballotierungsstatus
Erweiterbarkeit	offen

Beschreibung

Mögliche Metastasen des Patienten werden in dieser Sektion festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Metastasen			M	Beschreibt vorhandene Metastasen des Patienten
2	act	@classCode			M	DOCSECT
2	act	@moodCode			M	ENV
2	act	code	CD CWE	1..1	R	codeSystem="LOINC", code="Metastasen"
2	rel			0..*	O
3	rel	typeCode		0..*	O
3	act	Metastase			O	Beschreibt eine Metastase
4	act	@classCode		1..1	R	OBS
4	act	@moodCode		1..1	R	EVN
4	act	text	ED	0..1	O	Freitext für die Beschreibung der Metastase
4	act	effectiveTime	TS	0..1	O	Datum der Feststellung
4	act	value	ANY CWE	0..1	O	Angabe der Lokalisation über Katalog
4	act	targetSiteCode	DSET<CD>	0..*	O	Präzisierung der Lokalisation über Katalog

Katalog "Lokalisation" (OID 1.2.276.0.76.5.401)

Code	Description		Bedeutung
PUL	Pulmonary	Pulmonal	Lungenmetastase
OSS	Osseous	Ossär	Knochenmetastase
HEP	Hepatic	Hepatisch	Lebermetastase
BRA	Brain	Cerebral	Hirnmetastase
LYM	Lymph Nodes	Lymphonodulär	Lymphknotenmetastase
OTH	Others	Andere	Andere Metastase
MAR	Bone Marrow	Medullär	Knochenmarkmetastase
PLE	Pleura	Pleural	RippenfellMetastase
ADR	Adrenals	Adrenal	Nebennierenmetastase
SKI	Skin	dermal	Hautmetastase

Beispiel

<section>
	<templateId />
	<code code="Metastasen" codeSystem="LOINC" displayName="Metastasen"/>
	<title>...</title>
	<text>...</text>
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="xxx" codeSystem="xxx" codeSystemName="xxx" displayName="Metastase"/>
			<text>
				Metastase in der Leber
			</text>
			<effectiveTime value="20140201" />
			<value xsi:type="CD" code="HEP" codeSystem="1.2.276.0.76.5.401"/>
			<targetSiteCode xsi:type="CD" code="xxx" codeSystem="xxx"/>
			<!-- Neuer Eintrag Informationen-->
			<!--entryRelationship typeCode="COMP">
			</entryRelationship-->
		</observation>
	</entry>
</section>

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: Einschätzung

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Einschätzung
allg. Erläuterung	Sektion Einschätzung
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Die Sektion „Einschätzung von Aktivität“ umfasst medizinische Informationen zum Funktionsstatus des Patienten. Hierbei kann entweder der Karnofsky-Index oder der ECOG-Index, Ein Index zu Lebensqualität der Eastern Cooperative Oncology Group (ECOG) zum Einsatz. Im Vergleich zum Karnofsky-Index umfasst ECOG nur 5 Abstufungen. Die nachfolgende Tabelle stellt die Wertebereich im Vergleich dar. Der Karnofsky-Index definiert eine Skala, die symptombezogene Einschränkungen der Aktivität beim Patienten bewertet. Sie reicht von 100 % = keine Beschwerden bis 0 % (Tod). Die Sektion umfasst beliebig viele Einträge für den Funktionsstatus, die in der Regel vom behandelnden Arzt bzw. der pflegenden Fachkräfte auf Basis der Untersuchungsergebnisse sowie der Pflegedokumentation erfasst werden.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Einschaetzung				Sektion für die Einschätzung von Aktivität des Patienten
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	0..1	O	codeSystem="LOINC", code="Einschätzung"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Einschaetzung		0..*	O	Observation für eine Einschätzung
3	act	@classCode	CS CNE	1..1	M	OBS
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="6.0"
3	act	effectiveTime	TS	0..1	O	Datum der Erfassung
3	act	value	ANY CWE	0..1	O	Codierte Angabe des verwendeten Katalogs zur Angabe der Einschätzung (z.B. ECOG OID 1.2.276.0.76.3.1.81.4.6.6) und Wert innerhalb des verwendeten Katalogs
3	act	id	Set<II>	0..*	O	Identifier

Katalog "ECOG Index" (OID 1.2.276.0.76.3.1.81.4.6.6)

Prozent	ECOG-Wert	Code	Beschreibung
100	0	1	Keine Beschwerden, keine Zeichen der Krankheit
90	0	2	Fähig zu normaler Aktivität, kaum oder geringe Symptome
80	1	3	Normale Aktivität mit Anstrengung möglich. Deutliche Symptome
70	1	4	Selbstversorgung. Normale Aktivität oder Arbeit nicht möglich
60	2	5	Einige Hilfestellung nötig, selbstständig in den meisten Bereichen
50	2	6	Hilfe und medizinische Versorgung wird oft in Anspruch genommen
40	3	7	Behindert. Qualifizierte Hilfe benötigt
30	3	8	Schwerbehindert. Hospitalisation erforderlich
20	4	9	Schwerkrank. Intensive medizinische Maßnahmen erforderlich
10	4	10	Moribund. Unaufhaltsamer körperlicher Verfall
0	5	11	Tod

Beispiel

<section>
	<code code="Einschätzung" codeSystem="LOINC" />
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="6.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Einschaetzung"/>
			<effectiveTime value="20140201" />
			<value xsi:type="CD" code="4" codeSystem="1.2.276.0.76.3.1.81.4.6.6" codeSystemName="ECOG Index"/>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: Zugänge Katheter

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Zugänge Katheter
allg. Erläuterung	Sektion für Zugänge und Katheter
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Beschreibung

Alle Zugänge und Katheter werden in dieser Sektion festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	sesction				ZugaengeKatheter: Beschreibt Zugänge und Katheder des Patienten
1	act	@classCode	CS CNE	1..1	F	"DOCSECT"
1	act	@moodCode	CS CNE	1..1	F	"EVN"
1	act	code	CD CWE	0..1	O	codeSystem="LOINC", code="ZugängeUndKatheter"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Observation		0..1	O	ZugaengeKatheter: Eine Observation pro Zugang oder Katheder
3	act	@classCode	CS CNE	1..1	M	OBS
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="7.0"
3	act	effectiveTime	TS	0..1	O	Datum der Erfassung
3	act	text	ST	0..1	O	Anmerkung als Freitext
3	act	id	Set<II>	0..*	O	Identifier
3	part	device		0..1	R
4	part	@typeCode	CS CNE	0..1	F	"DEV"
4	rol	ManufacturedProduct		0..*	O
5	rol	@classCode	CS CNE	1..1	F	"MANU"
5	ent	Device		0..1	O	Beschreibt des Katheder oder den Zugang
6	ent	@classCode	CS CNE	1..1	M	DEV
6	ent	@determinerCode	CS CNE	1..1	M	INSTANCE
6	ent	id	SET<II>	0..*	O	Identifier des verwendeten Produkts (Produkt ID)
6	ent	code	CD CWE	0..1	O	codeSystem=codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="7.1"
6	ent	manufacturerModelName	SC CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.7" code=Angabe aus Katalog "Zugänge und Katheder"

Katalog "Zugänge und Katheder" (OID 1.2.276.0.76.3.1.81.4.6.7)

Code	Beschreibung
1	PEG
2	ZVK
3	DK
4	Port
5	Pumpe
6	Tracheostoma
7	Sonstiges (Beschreibung dann als Anmerkung)

Beispiel

<section>
	<templateID />
	<code code="ZugängeUndKatheter" codeSystem="LOINC"/>
	<title>Zugänge</title>
	<text...</text>
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="7.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="ZugängeUndKatheter"/>
			<text>
				Anmerkung
			</text>
			<effectiveTime value="20140201" />
			<participant typeCode="DEV">
				<participantRole classCode="ROL">
					<playingDevice classCode="DEV">
						<code code="7.1" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Device"/>	
						<manufacturerModelName code="2" codeSystem="1.2.276.0.76.3.1.81.4.6.7" />
					</playingDevice>
				</participantRole>
			</participant>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

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: Medikationen

In diesem Leitfaden werden folgende Templates zu Medikations-Informationen unterstützt:

Medikation bei Einweisung (Historie)

Id	1.2.276.0.76.10.3029	Gültigkeit	2013‑12‑30 Andere Versionen mit dieser Id: Admissionmedicationsection vom 2017‑02‑01
Status	Aktiv	Versions-Label
Name	Admissionmedicationsection	Bezeichnung	Medikation bei Einweisung (Historie)
Beschreibung	Erhobene Medikation bei Aufnahme des Patienten.
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.3029 hl7:code CE 1 … 1 M (Adm...ion) @code CONF 1 … 1 F 42346-7 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Adm...ion)   CONF Elementinhalt muss "Medikation bei Aufnahme" sein hl7:text SD.TEXT 1 … 1 M (Adm...ion)

Verabreichte Medikation während des Aufenthalts

Id	1.2.276.0.76.10.3030	Gültigkeit	2013‑12‑30 Andere Versionen mit dieser Id: Medicationduringstaysection vom 2017‑02‑01
Status	Aktiv	Versions-Label
Name	Medicationduringstaysection	Bezeichnung	Verabreichte Medikation während des Aufenthalts
Beschreibung	Sämtliche verabreichte Medikation während des Aufenthalts
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 0 … * (Med...ion) hl7:templateId II 1 … 1 R (Med...ion) @root 1 … 1 F 1.2.276.0.76.10.3030 hl7:code CE 1 … 1 M (Med...ion) @code CONF 1 … 1 F 29549-3 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Med...ion)   CONF Elementinhalt muss "Verabreichte Medikation während des Aufenthalts" sein hl7:text SD.TEXT 1 … 1 M (Med...ion)

Medikation bei Entlassung

Id	1.2.276.0.76.10.3031	Gültigkeit	2013‑12‑30 Andere Versionen mit dieser Id: Dischargemedicationsection vom 2017‑02‑01
Status	Aktiv	Versions-Label
Name	Dischargemedicationsection	Bezeichnung	Medikation bei Entlassung
Beschreibung	Medikation bei Entlassung
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 1 … 1 F 1.2.276.0.76.10.3031 hl7:code CE 1 … 1 M (Dis...ion) @code CONF 1 … 1 F 10183-2 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 M (Dis...ion)   CONF Elementinhalt muss "Medikation bei Entlassung" sein hl7:text SD.TEXT 1 … 1 M (Dis...ion)

Section: Hilfsmittel

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Hilfsmittel
allg. Erläuterung	Sektion für Hilfsmittel
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Alle Hilfsmittel werden in dieser Sektion festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Hilfsmittel				Diese Sektion beschreibt die vom Patienten benötigten Hilfsmittel
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	0..1	O	codeSystem="LOINC", code="Hilfsmittel"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Hilfsmittel		0..1	O	Je eine Observsation beschreibt ein benötigtes Hilfsmittel
3	act	@classCode	CS CNE	1..1	M	SPLY
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="8.0"
3	act	text	ED	0..1	O	Freitext
3	act	effectiveTime	TS	0..1	O	Datum
3	act	id	Set<II>	0..*	O	Identifier

Katalog "Hilfsmittel" (OID 1.2.276.0.76.3.1.81.4.6.8)

Code	Beschreibung
1	Krankenbett
2	Toilettenstuhl
3	Rollstuhl
4	Matratze
5	Einlegerahmen
6	O2-Konzentrator
7	Badewannenfilter
8	Rollator

Beispiel

<section>
	<code code="Hilfsmittel" codeSystem="LOINC”/>
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="8.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Hilfsmittel"/>
			<effectiveTime value="20140201" />
			<value xsi:type="CD" code="4" codeSystem="1.2.276.0.76.3.1.81.4.6.8" codeSystemName="Hilfsmittel"/>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: Hospizdokumentation

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Hospizdokumentation
allg. Erläuterung	Sektion für die Hospizdokumentation
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Die Sektion kann genau eine Observation zur Dokumentation der Versorgung durch ein Hospiz beinhalten. Diese hat verschiedene “Einträge“ als Observationen und verlinkt auf die verschiedenen relevanten Personen über „Participation“-Relationen (siehe auch Header).

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Hospizdokumentation				Beschreibt die Hospizdokumentation
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	0..1	O	codeSystem="LOINC", code="Hospizdokumentation"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Hospizdokumentation		0..1	O	Je eine Observation pro Eintrag
3	act	@classCode	CS CNE	1..1	M	OBS
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="9.0"
3	act	text	ED	0..1	O	Kommentar
3	act	id	Set<II>	0..*	O	Identifier
3	rel	entry		1..1	R
4	rel	@typeCode	CS CNE	1..1	M
4	act	Eintrag		0..*	O	Ein Eintrag beschreibt eine Informationsangabe über den Katalog "Hospizdokumentation"
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="9.1"
5	act	text	ED	0..1	O	Freitext
5	act	effectiveTime	TS	0..1	O	Datum
5	act	value	ANY CWE	0..1	O	Angabe des Codesystems für den „Eintrag" und Angabe des Wertes innerhalb des angegebenen Codesystems
5	act	id	Set<II>	0..*	O	Identifier
4	part	participant		0..*	O

Katalog "Hospizdokumentation" (OID 1.2.276.0.76.3.1.81.4.6.9)

Code	Beschreibung	Beschrieben durch
1	Datum des vereinbarten Auftrages bei Erstkontakt durch den Koordinator	effectiveTime
2	Turnus des vereinbarten Auftrages	value mit CodeSystem „Turnus“
3	Datum des wahrgenommenen Auftrags	effectiveTime
4	Turnus des wahrgenommen Auftrags	value mit CodeSystem „Turnus“
5	Unterstützung für den Sterbenden durch Gespräch und Dasein	value boolean
6	Unterstützung für den Sterbenden, dem sterbendem Menschen ein klärendes Gegenüber in der Entwicklung und Gestaltung seiner Wünsche und Bedürfnisse sein	value boolean
7	Unterstützung für den Sterbenden, Normalität im Alltag	value boolean
8	Unterstützung für den Sterbenden, Gesellschaftliche Teilhabe	value boolean
9	Unterstützung für den Sterbenden, Kleine Hilfen im Alltagsablauf	value boolean
10	Unterstützung für den Sterbenden, emotionale Unterstützung	value boolean
11	Freiraum für Dinge des Alltags ermöglichen	value boolean
12	Freiraum für Dinge des Alltags ermöglichen	value boolean
13	Emotionale Unterstützung, auch als (nächtliche) Sitzwache in der konkreten Sterbephase	value boolean
14	Kommentar zum Auftrag	text
15	Angebot der Sitzwache	value boolean
16	Datum des Abschluss	effectiveTime
17	Turnus des Abschluss	value mit CodeSystem „Turnus“

Beispiel

<section>
	<code code="Hospizdokumentation" codeSystem="LOINC" />
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="9.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Hospizdokumentation"/>
			<participant typeCode="PRF">
				<participantRole classCode="CAREGIVER">
					<id extension=“xxx” root=“xxx ” />
					<code code=“xxx” codeSystem=“xxx” />
					<addr>
						<streetName>Testweg</streetName>
						<houseNumber>123</houseNumber>
						<postalCode>12345</postalCode>
						<city>Dortmund</city>
					</addr>
					<playingEntity>
						<name>
							<given>Max</given>
							<family>Mustermann</family>
						</name>
					</playingEntity>
					<scopingEntity>
						<id extension=“xxx” root=“xxx” />
						<code code=“xxx” codeSystem=“xxx” />
					</scopingEntity>
				</participantRole>
			</participant>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="9.1" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Eintrag"/>
					<value xsi:type="CD" code="5" codeSystem="1.2.276.0.76.3.1.81.4.6.9" codeSystemName="Eintrag Hospizdokumentation" displayName="Unterstützung für den Sterbenden durch Gespräch und Dasein">
						<qualifier>
							<value code="false" />
						</qualifier>
					</value>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="9.1" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Eintrag"/>
					<effectiveTime value="20140201" />
					<value xsi:type="CD" code="1" codeSystem="1.2.276.0.76.3.1.81.4.6.9" codeSystemName="Eintrag Hospizdokumentation" displayName="Datum des vereinbarten Auftrages bei Erstkontakt durch den Koordinator"/>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="9.1" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Eintrag"/>
					<text>
						Auftrag ausgeführt...
					</text>
					<value xsi:type="CD" code="14" codeSystem="1.2.276.0.76.3.1.81.4.6.9" codeSystemName="Eintrag Hospizdokumentation" displayName="Kommentar zum Auftrag"/>
				</observation>	
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: SAPV Verordnung

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	SAPV Verordnung
allg. Erläuterung	Die SAPV Verordnung wird in dieser Sektion festgehalten.
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Die SAPV Verordnung wird in dieser Sektion festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	SAPVVerordnung				Beschreibt die SAPV Verordnung
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	0..1	O	codeSystem="LOINC", code="SAPV"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	SAPVVerordnung		0..*	O	Angabe der SAPV Verordnung
3	act	@classCode	CS CNE	1..1	M	OBS
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="10.0"
3	act	text	ED	0..1	O	Anmerkung als Freitext
3	act	statusCode	CS CNE	0..1	O	Status
3	act	effectiveTime	TS	0..1	O	Datum der Verordnung
3	rel	entry		1..1	R
4	rel	@typeCode	CS CNE	1..1	M
4	act	ArtDerVerordnung		0..*	O	Weitere Informationen zur Art der Verordnung
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="10.1"
5	act	value	ANY CWE	0..1	O	Code für entsprechenden Katalog zur Angabe der Art der Verordnung und Angabe innerhalb des Codesystems

Katalog "SAPV" (OID 1.2.276.0.76.3.1.81.4.6.11)

Code	Beschreibung
1	Beratung
2	Koordination
3	Additive Teilversorgung
4	Vollständige Versorgung

Katalog "Art der Verordnung" (OID 1.2.276.0.76.3.1.81.4.6.12)

Code	Beschreibung
1	Erstverordnung
2	Wiederverordnung

Beispiel

<section>
	<code code="SAPV" codeSystem="LOINC" />
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="10.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="SAPVVerordnung"/>
			<text>
				Anmerkung
			</text>
			<statusCode code="1"/>
			<effectiveTime value="20140201" />
			<value xsi:type="CD" code="3" codeSystem="1.2.276.0.76.3.1.81.4.6.11" codeSystemName="SAPV" displayName="Additive Teilversorgung">
				<qualifier>
					<value code="3" />
				</qualifier>
			</value>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="10.1" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Art der Verordnung"/>
					<value xsi:type="CD" code="5" codeSystem="1.2.276.0.76.3.1.81.4.6.12"
codeSystemName="Art der Verordnung" displayName="Erstverordnung">
						<qualifier>
							<value code="1" />
						</qualifier>
					</value>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: Pflegestufe

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Pflegestufe
allg. Erläuterung	Sektion für die Pflegestufe
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Die Pflegestufe wird in dieser Sektion festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Pflegestufe				Beschreibt die Pflegestufe des Patienten
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	0..1	O	codeSystem="LOINC", code="Pflegestufe"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Pflegestufe		0..1	O	Diese Observation beschreibt die Pflegestufe des Patienten
3	act	@classCode	CS CNE	1..1	M	OBS
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	0..1	O	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="11.0"
3	act	statusCode	CS CNE	0..1	O	Status
3	act	effectiveTime	TS	0..1	O	Antragsdatum
3	act	value	ANY CWE	0..1	O	Angabe der Pflegestufe über Katalog "Pflegestufe"
3	act	id	Set<II>	0..*	O	Identifier

Katalog "Einweisung" (OID 1.2.276.0.76.3.1.81.4.6.15)

Code	Beschreibung
1	Stufe 0
2	Stufe 1
3	Stufe 2
4	Stufe 3
5	Neueinstufung
6	Vorläufige Einstufung nach §3 (NRW)

Beispiel

<section>
	<code code="Pflegestufe" codeSystem="LOINC"/>
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="11.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Pflegestufe"/>
			<text>
				Anmerkung
			</text>
			<statusCode code="completed"/>
			<effectiveTime value="20140201" />
			<value xsi:type="CD" code="2" codeSystem="1.2.276.0.76.3.1.81.4.6.14" codeSystemName="Pflegestufe" displayName="Stufe 1"/>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

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: Einweisung stationär

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	hier müsste das eingebettete Entry hin
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Einweisung stationär
allg. Erläuterung	Sektion für die stationäre Einweisung
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Beschreibung

Die Informationen zur stationären Einweisung wird in dieser Sektion festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Section				EinweisungStationaer: Beschreibung einer stationären Einweisung
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	1..1	R	codeSystem="LOINC", code="Einweisung"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Act		0..*	O	EinweisungStationaer: Pro Einweisung wird solch eine Observation angelegt
3	act	@classCode	CS CNE	1..1	F	"ACT"
3	act	@moodCode	CS CNE	1..1	F	"EVN"
3	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="12.0"
3	act	effectiveTime	TS	0..1	O	Datum der Einweisung
3	rel	entry		1..1	R
4	rel	@typeCode	CS CNE	1..1	F	"RSON"
4	act	Observation		0..1	O	Grund Einweisung stationär: Pro Grund Einweisung stationär eine solche Observation
5	act	@classCode	CS CNE	1..1	F	"OBS"
5	act	@moodCode	CS CNE	1..1	F	"EVN"
5	act	code	CD CWE	1..1	M	Angabe, dass es sich hier um den Grund für die Überweisung handelt
5	act	value	CD CWE	1..1	M	Angabe des eigentlichen Grundes der Einweisung über Katalog; codeSystem="1.2.276.0.76.3.1.81.4.6.17"
3	part	participant		0..*	O	Angabe des Einweisers/der einweisenden Organisation
3	part	location		0..*	O	Ort wohin eingewiesen wird, Katalog "Einweisung"
3	part	device		0..1	R
4	part	@typeCode	CS CNE	0..1	F	"DEV"
4	rol	ManufacturedProduct		0..*	O
5	rol	@classCode	CS CNE	1..1	F	"MANU"
5	ent	Device		0..1	O	Beschreibt das Transportmittel
6	ent	@classCode	CS CNE	1..1	F	"DEV"
6	ent	@determinerCode	CS CNE	1..1	F	"INSTANCE"
6	ent	id	SET<II>	0..*	O	Identifier des verwendeten Produkts (Produkt ID)
6	ent	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="12.1"
6	ent	manufacturerModelName	SC CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.16" code=Angabe aus Katalog "Transportmittel"

Vokabular

Katalog "Einweisung"(OID 1.2.276.0.76.3.1.81.4.6.15)

Code	Beschreibung
1	Allgemeine Station
2	Onkonlogie
3	Palliativstation
4	Hospiz

Katalog "Transportmittel" (OID 1.2.276.0.76.3.1.81.4.6.16)

Code	Beschreibung
1	KTW
2	RTW mit Notarzt
3	Taxi
4	Privatwagen

Katalog "Grund der Einweisung" (OID 1.2.276.0.76.3.1.81.4.6.17)

Code	Beschreibung
1	Notfall
2	Chemotherapie / Radiation
3	Selbsteinweisung
4	Transfusion
5	Geplante medizinische Intervention

Beispiel

<section>
	<templateId root="" />
	<code code="Einweisung" codeSystem="LOINC" />
	<title>Einweisung</title>
	<text>...</text>
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="12.0" codeSystem="1.2.276.0.76.3.1.81.4.6.0"
				 codeSystemName="Palliativinhalte" displayName="EinweisungStationaer"/>
			<effectiveTime value="20140201" />
			<participant typeCode="PRF">
				<participantRole classCode="CAREGIVER">
					<id extension=“xxx” root=“xxx” />
					<code code="2" codeSystem="1.2.276.0.76.3.1.81.4.6.18" 
						codeSystemName="Einweisung durch" displayName="Notarzt"/>
					<playingEntity>
						<name>
							<given>Notarzt Dr. Max</given>
							<family>Mustermann </family>
						</name>
					</playingEntity>
					<scopingEntity>
						<id extension=“xxx” root=“xxx” />
					</scopingEntity>
				</participantRole>
			</participant>
			<participant typeCode="LOC">
				<participantRole classCode="SDLOC">
					<id extension=“xxx” root=“xxx” />
					<code code="1" codeSystem="1.2.276.0.76.3.1.81.4.6.15" 
						codeSystemName="Einweisung" displayName="Allgemeine Station"/>
				</participantRole>
			</participant>
			<participant typeCode="DEV">
				<participantRole classCode="MANU">
					<playingEntity classCode="DEV">
						<code code="2" codeSystem="1.2.276.0.76.3.1.81.4.6.16" 
							codeSystemName="Transportmittel" 
							displayName="RTW mit Notarzt"/>	
					</playingEntity>
				</participantRole>
			</participant>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="4" codeSystem="1.2.276.0.76.3.1.81.4.6.17" 
						codeSystemName="Grund der Einweisung" displayName="Transfusion"/>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: Versorgungsunterbrechung

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Versorgungsunterbrechung
allg. Erläuterung	Sektion für Versorgungsunterbrechung
Verhältnis zu IHE	neu
Ballotierungsstatus
Erweiterbarkeit	offen

Versorgungsunterbrechungen werden dieser Sektion festgehalten.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Versorgungsunterbrechung				Beschreibt Versorgungsunterbrechungen
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	1..1	R	codeSystem="LOINC", code="Versorgungsunterbrechung"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Versorgungsunterbrechung		0..1	O	Pro Versorgungsunterbrechung eine solche Observation
3	act	@classCode	CS CNE	1..1	M	ACT
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="13.0"
3	act	text	ED	0..1	O	Anmerkung als Freitext
3	act	effectiveTime	TS	0..1	O	Datum, Beginn der Unterbrechung
3	act	id	Set<II>	0..*	O	Identifier
3	rel	entry		1..1	R
4	rel	@typeCode	CS CNE	1..1	M	RSON
4	act	Grund Versorgungsunerbrechung		0..1	O	Pro Grund Versorgungsunterbrechung eine solche Observation
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	1..1	R	Code für entsprechenden Katalog zur Angabe des Grunds für die Unterbrechung und Angabe innerhalb des Codesystems; codeSystem="1.2.276.0.76.3.1.81.4.6.19"

Katalog "Grund der Versorgungsunterbrechung" (OID 1.2.276.0.76.3.1.81.4.6.19)

Code	Beschreibung
1	Stabilisierung des Allgemeinzustands
2	Wunsch des Patienten
3	Überleitung in stationäre Behandlung
4	Sonstiges

Beispiel

<section>
	<code code="Versorgungsunterbrechung" codeSystem="LOINC" />
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="13" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Versorgungsunterbrechung"/>
			<text>
				Anmerkung
			</text>
			<effectiveTime>
				<low value="20140201" />
			</effectiveTime>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="4" codeSystem="1.2.276.0.76.3.1.81.4.6.19" codeSystemName="Grund der Versorgungsunterbrechung" displayName="Sonstiges"/>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: Abschluss

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Abschluss
allg. Erläuterung	Sektion für den Abschluss
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Abschlussdaten werden in dieser Sektion festgehalten. Die Sektion enthält genau eine Observation falls ein Abschluss festgehalten werden soll. Es kann keine zwei Abschlüsse geben, da im Unterschied zur Versorgungsunterbrechung nicht von einer Wiederaufnahme der Behandlung ausgegangen wird. Mit einer weiteren Observation (Tod) kann der Tod eines Patienten, samt Todeszeitpunkt und Todesort, festgehalten werden.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	Abschluss				Beschreibt den Abschluss der Palliativbehandlung
1	act	@classCode	CS CNE	1..1	M	DOCSECT
1	act	@moodCode	CS CNE	1..1	M	EVN
1	act	code	CD CWE	0..1	O	codeSystem="LOINC", code="Abschluss"
1	rel	entry		1..1	R
2	rel	@typeCode	CS CNE	1..1	M
2	act	Abschluss		0..1	O	Beschreibt einen Abschluss der Palliativbehandlung
3	act	@classCode	CS CNE	1..1	M	ACT
3	act	@moodCode	CS CNE	1..1	M	EVN
3	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="14.0"
3	act	id	Set<II>	0..*	O	Identifier
3	rel	entry		1..1	R
4	rel	@typeCode	CS CNE	1..1	M	RSON
4	act	Abschlussgrund		0..1	O	Pro Abschlussgrund eine solche Observation
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	1..1	O	Code für den Abschlussgrund; codeSystem="1.2.276.0.76.3.1.81.4.6.20
3	rel	entry		1..1	R
4	rel	@typeCode	CS CNE	1..1	M
4	act	Tod		0..1	O	Falls der Patient verstorben ist wird diese Observation genutzt
5	act	@classCode	CS CNE	1..1	M	OBS
5	act	@moodCode	CS CNE	1..1	M	EVN
5	act	code	CD CWE	1..1	R	codeSystem="1.2.276.0.76.3.1.81.4.6.0", code="14.1"
5	act	effectiveTime	TS	0..1	O	Sterbedatum
5	part	location		0..*	O	Angabe des Sterbeorts

Katalog "Grund des Abschluss" (OID 1.2.276.0.76.3.1.81.4.6.20)

Code	Beschreibung
1	Tod
2	Verzogen
3	Remission
4	Wunsch des Patienten
5	Entlassung in Weiterbehandlung

Beispiel

<section>
	<code code="Abschluss" codeSystem="LOINC"/>
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">

			<code xsi:type="CD" code="xxx" codeSystem="xxx" codeSystemName="xxx" displayName="Abschluss"/>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="1" codeSystem="1.2.276.0.76.3.1.81.4.6.20" codeSystemName="Grund der Abschluss" displayName="Tod"/>
				</observation>
			</entryRelationship>
			<entryRelationship typeCode="COMP">
				<observation classCode="OBS" moodCode="EVN">
					<code xsi:type="CD" code="5" codeSystem="1.2.276.0.76.3.1.81.4.6.0" codeSystemName="Palliativinhalte" displayName="Tod"/>
					<effectiveTime value="201402011000"/>
				</observation>
			</entryRelationship>
			<participant typeCode="LOC">
				<participantRole classCode="SDLOC">
					<id extension="xxx" root="xxx" />
					<code code="1" codeSystem="1.2.276.0.76.3.1.81.4.6.21" codeSystemName="Sterbeort" displayName="Zuhause"/>
				</participantRole>
			</participant>
			<entryRelationship typeCode="COMP">
				<!-- Neuer Eintrag -->
			</entryRelationship>
		</observation>
	</entry>
</section>

Section: Wichtige Anmerkungen

	Template-Metadaten
Template-Typ	Section
Template ID	keine
generischeres Template	-
genutztes Templates	-
nutzende Templates	-
abgeleitete Templates	-
Schwester-Templates	-
generelle Beschreibung	Wichtige Anmerkungen
allg. Erläuterung	Sektion für wichtige Anmerkungen
Verhältnis zu IHE	neu
Ballotierungsstatus	in Abstimmung
Erweiterbarkeit	offen

Beschreibung

Im Folgenden werden die Angaben der Basisdaten welche nicht direkt über den CDA-Header abgebildet werden können spezifiziert. Diese Angaben können innerhalb des CDA Body in der Sektion „Wichtige Anmerkungen“ hinterlegt werden. Es können wichtige Anmerkungen zum einen für die Basisdaten und zum anderen für die Verlaufsdokumentation hinterlegt werden. Diesem wird durch die entsprechenden Kodierungen der Sektion Rechnung getragen. D.h. es kann je eine Sektion für die Dokumentation von weiteren Angaben der Basisdokumentation und eine Sektion für wichtige Anmerkungen der Verlaufsdokumentation existieren.

Modell

Attribute

Lvl	RIM	Name	DT	Kard	Conf	Beschreibung
1	act	WichtigeAnmerkungen		0..*	O
2	act	@classCode	CS CNE	1..1	M	DOCSECT
2	act	@moodCode	CS CNE	1..1	M	EVN
2	act	code	CD CWE	0..1	O	Kodierte Bedeutung der Sektion
2	rel	entry		0..*	O
3	rel	@typeCode	CS CNE	1..1	R
3	act	Anmerkung		0..*	O
4	act	@classCode	CS CNE	1..1	M	OBS
4	act	@moodCode	CS CNE	1..1	R	EVN
4	act	code	CD CWE	0..1	O
4	act	text	ED	0..1	O
4	act	effectiveTime	TS	0..1	O
4	rel	entry		0..1	O
5	rel	@typeCode	CS CNE	1..1	M
5	act	EintragDaten		0..1	O
6	act	@classCode	CS CNE	1..1	M	OBS
6	act	@moodCode	CS CNE	1..1	M	EVN
6	act	code	CD CWE	0..1	O
6	act	effectiveTime	TS	0..1	O
6	act	value	ANY CWE	0..1	O
6	part	participant		0..*	O

Beispiel

<section>
	<templateID />
	<code code="WAB" codeSystem="2.16.840.1.113883.6.1" 
		codeSystemName="LOINC" displayName="Wichtige Anmerkungen Basisdaten"/>
	<title>...</title>
	<text>...</tetxt>
	<entry typeCode="DRIV">
		<observation classCode="OBS" moodCode="EVN">
			<code xsi:type="CD" code="ANM" 
				codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" 
				displayName="Anmerkung"/>
			<text>
				Hier steht der Text zur Anmerkung

			</text>
			<effectiveTime value="20140201" />
			<entryRelationship typeCode="COMP">
				<!-- Eintrag für d. strukturierte Darstellung d. Anmerkung, falls vorhanden -->
			</entryRelationship>
		</observation>
	</entry>
</section>