This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template.
This article was last edited by Foemig (talk| contribs) 11 years ago. (Purge)

Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage.
This article was last edited by Foemig (talk| contribs) 11 years ago. (Purge)

	Dieses Dokument gibt wieder: Implementierungsleitfaden Arztbrief 2012 (01). Die Teilmaterialien gehören der Kategorie cdaab2 an.

{{{Title}}}

Arztbrief 2012

Implementierungsleitfaden

vorgelegt von:
HL7-Deutschland

in Arbeit

Version:	01
Datum:	7. Februar 2013
Status:	Entwurf
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

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

Hier sind die einzelnen Kapitel noch aus dem Arztbrief 2006 als Startpunkt zu übernehmen und mit den neueren Erkenntnissen zu kombinieren.

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 .

Inhaltsverzeichnis

1 Impressum
2 Ansprechpartner
3 Disclaimer
4 Danksagung
5 Autoren
6 Mit Beiträgen von
7 Copyright-Hinweis, Nutzungshinweise
8 Einleitung
9 Transportaspekte
- 9.1 Interaktionsdiagramm
- 9.2 Dokumentenaustausch
10 Rechtssichere Übertragung
11 Struktureller Aufbau
12 Anhang
13 Referenzen

Impressum

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

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

Dr. Kai U. Heitmann, HL7 Deutschland e.V., Heitmann Consulting and Services
Dr. Frank Oemig, Agfa HealthCare GmbH, Bonn
Mathias Aschhoff, ZTG GmbH, Bochum

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 .

Disclaimer

Der Inhalt dieses Dokumentes ist öffentlich. Zu beachten ist, dass Teile dieses Dokuments auf der Normative Edition 2005 von HL7 Version 3 beruhen, für die © HL7 International gilt.
Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann HL7 Deutschland keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.

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 .

Danksagung

Wir danken besonders den folgenden Organisationen und Projekten.

Bundesverband der Hersteller von IT-Lösungen für das Gesundheitswesen, e.V. , Berlin

bvitg: www.bvitg.de

eBPG-Projekt (electronic Business Plattform im Gesundheitswesen), NRW

Konsortialprojekt eBusiness-Plattform Gesundheitswesen (Förderkennzeichen 005-GW01-038C)

Arbeitspaket AP04: Einrichtungsübergreifende elektronische Patientenakte (eEPA)

Gefördert von der EU und dem Land NRW:

Deutscher Hausärzteverband e.V., Köln

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Autoren

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

Mit Beiträgen von

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

Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

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

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

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

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

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Einleitung

Motivation

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

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

Zielgruppe

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

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

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

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

Dokumente im Gesundheitswesen

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

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

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

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

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

Abgrenzung

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

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

Hilfreich ist in diesem Zusammenhang das IHE-Cookbook^[4].

Aufbau dieses Implementierungsleitfadens

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

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

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

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

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Transportaspekte

Interaktionsdiagramm

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

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

^{[Abbildung 1]} Interaktionsdiagramm

Dokumentenaustausch

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

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

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

Rechtssichere Übertragung

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

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

Diese Aspekte Datenschutz/-sicherheit, IT-Sicherheit, Verschlüsselung und Signaturen sind nicht Bestandteil dieser Spezifikation. Es gibt dazu aber bereits entsprechende Ausarbeitungen und Vorgaben.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Struktureller Aufbau

Das statische Modell umfasst

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

Grober XML-Aufbau von CDA-Dokumenten

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

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

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

Das Dokument muss mit dem Element <ClinicalDocument> beginnen und die in obiger Abbildung genannten xmlns: Deklarationen aufweisen.

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 .

Dokumentenstruktur Arztbrief

Ein Arztbrief - wie andere Dokumente auch - setzt sich aus verschiedenen Teilen zusammen.

die Attribute der CDA-Klasse
Informationen über die verschiedenen Beteiligten an einem Dokument wie Patient, Autor, Unterzeichner etc.
Informationen über Aktivitäten, die in Zusammenhang mit dem Dokument stehen.

Attribute der CDA-Klasse

Die folgende Tabelle gibt eine Übersicht über die in diesem Leitfaden besprochenen CDA-Header-Elemente, deren Datentyp und Bedeutung. Details und weitere Erläuterungen find sich aber der Beschreibung des Dokumenten-Level-Template.

Name	DT	Beschreibung
realmCode	CS	Hoheitsangabe, d.h. wo dieser Dokumenttyp eingesetzt werden soll, hier in der Regel "DE"
templateId	II	Angabe, nach welchem Schema das Dokument erstellt wurde
typeId	II	Angabe, dass es sich um ein CDA-Dokument handelt
id	II	eindeutige Identifikation des Dokuments
code	CE	Typ des Dokuments
title	ST	Titel bzw. Bezeichnung des Dokuments
effectiveTime	TS	Erstellungszeitpunkt
confidentialityCode	CE	Vertraulichkeit
languageCode	CS	Sprache des Dokuments
setId	II	Set-Kennung
versionNumber	INT	Versionsnummer

^{[Tabelle 1]} Übersicht über die (in diesem Leitfaden besprochenen) CDA-Header-Elemente, deren Datentyp bzw. Bedeutung und deren Kardinalität

Beispiel

<?xml version="1.0"? encoding="UTF-8">
<ClinicalDocument
  xmlns="urn:hl7-org:v3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <!-- CDA Header -->
  <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
  <id extension="60878,33988" root="1.2.276.0.58"/>
  <code code="11488-4" codeSystem="2.16.840.1.113883.6.1" displayName="Consultation note"/>
  <title>Entlassbrief</title>
  <effectiveTime value="20070905"/>
  <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
  <languageCode code="de" />
  <setId extension="D1" root="2.16.840.1.113883.3.933"/>
  <versionNumber value="2"/>
  ...
</ClinicalDocument>

Informationen über die verschiedenen Beteiligten und Aktivitäten, die in Zusammenhang mit dem Dokument stehen

Die folgende Tabelle zeigt die Informationen über die verschiedenen Beteiligten und Aktivitäten, die in Zusammenhang mit dem Dokument stehen. Aufgenommen in der Tabelle sind auch Referenzen zu den Definitionen der ELGA (Österreich), die mitunter kein direktes Äquivalent haben und dann unter einem Oberbegriff geführt werden.

Abschnitt	Conf.	Kardinalität	Kommentar
Header (über Rollen)
Patient (recordTarget)	M	1..1
Autor (Person) (author)	M	1..1	das Autor Element darf nur für natürliche Personen verwendet werden, nicht für Informationssysteme oder medizin-technische Geräte
Datentypist (dataEnterer)	O	0..1
Informant (informant)	O	0..*
die das Dokument verwaltende Organisation ( custodian)	M	1..1
Empfänger (informationRecipient)	O	0..*
vor dem Gesetz verantwortliche Unterzeichner (legalAuthenticator)	O	0..1	Hier darf es nur eine juristisch verantwortliche Person geben.
Unterzeichner (authenticator)	O	0..*	Einen Brief dürfen aber mehrere Personen unterzeichnen.
einweisender Arzt	O	0..1
Hausarzt	O	0..1
Notfallkontakt	O	0..*
Angehörige	O	0..*
Kostenträger , Versicherung	O	0..*
Fachlicher Ansprechpartner	O	0..*
Betreuungsorganisation	O	0..*
Weitere Beteiligte (generisch)	-	-
Header (über Act-Relationships)
Patientenkontakt (EncompassingEncounter)	O	0..1
Einwilligung	O	0..*	wozu hat der Patient eingewilligt?
unstrukturierter Body (d.h. ohne Abschnitte)
NonXML-Body	O	0..1
strukturierter Body (d.h. Abschnitte)
Anrede	O	0..1	ELGA: Brieftext
Fragestellung	O	0..1	ELGA: Aufnahmegrund
Anamnese	O	0..1	ELGA: Anamnese (ärztlich)
Schwangerschaften	O	0..1
Familienanamnese	O	0..1
frühere Erkrankungen	O	0..1	ELGA: frühere Erkrankungen
Medizinische Untersuchung	O	0..1	klinische (körperliche) oder apparative Untersuchung
Befund	O	0..*	ELGA: Erhobene Befunde
Laborwerte	O	0..1
Diagnosen (Aufnahme/Entlassung) mit ICD Code	O	0..*
Diagnosen (Aufnahme/Entlassung)			ELGA: Diagnose bei Entlassung
besondere Hinweise (CAVE) (zu beachtende wichtige Hinweise zum Patienten)	O	0..*
besondere Hinweise	O	0..*	ELGA: Allergien, Unverträglichkeiten, Risiken
Prozeduren und Maßnahmen	O	0..*	ELGA: Weitere Maßnahmen
			ELGA: Durchgeführte Maßnahmen
Medikation (abstrakte Spezifikation)	-	-	Dies ist die vollständige Beschreibung, die für die nachfolgend beschriebenen Abschnitte weiter eingeschränkt wird.
jetzige Medikation	O	0..1	ELGA: Letzte Medikation
empfohlene Medikation			ELGA: Empfohlene Medikation
Medikation bei Aufnahme	O	0..1	ELGA: Medikation bei Einweisung
Medikation bei Entlassung	O	ELGA: "Verabreichte Medikation während des Aufenthalts\|
Impfung	O	0..1
Notiz	O	0..*
Epikrise Zusammenfassender Rückblick Empfehlung Prognose	O	0..1	ELGA: Zusammenfassung des Aufenthalts; Epikrise streichen und durch die Details ersetzen; Plan of Care
Schlusstext	O	0..1	ELGA: Abschließende Bemerkungen
Anhänge: Referenzen auf externe Dokumente oder direkt inkludierte Objekte	O	0..*	ELGA: Beilagen Das Entry-Level-Template für externe Referenzen ist dafür gedacht, einzelne Aktivitäten (bspw. Befunde oder Maßnahmen) mit Dokumenten zu belegen. Beilagen gemäß ELGA-Spezifikation müssen in das Dokument eingebettet sein und dürfen nicht referenziert werden.
			ELGA: Patientenverfügung (als Referenz auf die Patienteneinwilligung)

^{[Tabelle 2]}Informationen über die verschiedenen Beteiligten und Aktivitäten

Der Ersteller des Dokuments muss festlegen, ob er einen nicht XML-basierten Body (NonXMLBody) oder auf XML-basierende Abschnitte (section) benutzen möchte.

Ein Arztbrief kann somit entweder in einem Binärformat als PDF o.ä. Dokument oder XML-formatiert übermittelt werden, und sich entweder ohne Strukturvorgabe oder aus strukturierten Abschnitten zusammensetzen.

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

^{[Tabelle 3]} CDA-Header-Assoziationen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Patient (recordTarget - generisch)

Id

1.2.276.0.76.10.2001

Gültigkeit

2013‑07‑10

Status

Aktiv

Versions-Label

Name

HeaderRecordTarget

Bezeichnung

CDA recordTarget

Beschreibung

Das recordTarget repräsentiert die Person, über die dokumentiert wird. recordTarget umfasst neben der Identifikation und dem Namen, Geschlecht, Adressen etc. auch optionale Zusatzangaben wie zum Beispiel Geburtsort und Sprachfähigkeiten.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.276.0.76.10.90030	Inklusion	Personenname	DYNAMIC

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.101 CDA recordTarget (DYNAMIC)

ref

ad1bbr-

Beispiel

Standard-Beispiel

<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>    <addr use="HP">
      <streetName>Musterstraße</streetName>      <houseNumber>15</houseNumber>      <postalCode>50825</postalCode>      <city>Köln</city>    </addr>    <telecom use="HP" value="tel:+49(221)7812220"/>    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>      <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19700924"/>      <birthplace>
        <place>
          <addr>
            <city>Köln</city>          </addr>        </place>      </birthplace>    </patient>  </patientRole></recordTarget>

Beispiel

Maximal-Beispiel

<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="2.16.840.1.113883.3.37.6.2.23.3" extension="12345"/>    <id root="1.2.276.0.76.4.8" extension="8003004447"/>    <addr use="HP">
      <streetName>Musterstraße</streetName>      <houseNumber>15</houseNumber>      <postalCode>50825</postalCode>      <city>Köln</city>    </addr>    <telecom use="HP" value="tel:+49(221)7812220"/>    <telecom use="HP" value="mailto:MuellerMar@gmx.de"/>    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>      <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>      <birthTime value="19700924"/>      
      <maritalStatusCode code="M" displayName="Married" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7 MaritalStatusCode"/>      
      <religiousAffiliationCode code="1077" displayName="Protestant" codeSystem="2.16.840.1.113883.5.1076"/>      
      <guardian>
        <addr use="HP">
          <streetName>Musterstraße</streetName>          <houseNumber>15</houseNumber>          <postalCode>50825</postalCode>          <city>Köln</city>        </addr>        <telecom use="HP" value="..."/>        <guardianPerson>
          <name>
            <given>Marius</given>            <family>Müller</family>          </name>        </guardianPerson>      </guardian>      <birthplace>
        <place>
          <addr>
            <city>Köln</city>          </addr>        </place>      </birthplace>      <languageCommunication>
        <languageCode code="EN"/>        <modeCode code="ESP"/>        <proficiencyLevelCode code="G"/>        <preferenceInd value="true"/>      </languageCommunication>    </patient>  </patientRole></recordTarget>

Beispiel

Minimal-Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:recordTarget

(Hea...get)

@typeCode

0 … 1

F

RCT

@contextControlCode

0 … 1

F

OP

Beispiel

hl7:patientRole

1 … 1

(Hea...get)

@classCode

0 … 1

F

PAT

Beispiel

hl7:id

II

1 … *

(Hea...get)

Beispiel

hl7:addr

AD

0 … *

Adresse des Patienten

(Hea...get)

Beispiel

<addr use="HP">
<streetName>Dorfstraße</streetName> <houseNumber>54</houseNumber> <postalCode>51371</postalCode> <city>Leverkusen</city></addr>

hl7:telecom

TEL

0 … *

Kontaktdaten des Patienten

(Hea...get)

Beispiel

hl7:patient

0 … 1

(Hea...get)

@classCode

0 … 1

F

PSN

@determinerCode

0 … 1

F

INSTANCE

Beispiel

Eingefügt

1 … 1

M

von 1.2.276.0.76.10.90030 Personenname (DYNAMIC)

hl7:name

PN

1 … 1

M

Die Reihenfolge der Namensbestandteile soll der typischen Schreibweise entsprechen. Zu beachten ist, dass prefix- und suffix-Elemente mit einem Leerzeichen enden müssen, wenn sie nicht unmittelbar an den folgenden Namensbestandteil anschließen sollen.

(Hea...get)

Beispiel

Dr. med. Sine Johanna Gräfin von Oberberg

<name>
<prefix qualifier="AC">Dr. med. </prefix> <given>Sine Johanna</given> <prefix qualifier="NB">Gräfin </prefix> <prefix qualifier="VV">von </prefix> <family>Oberberg</family></name>

Beispiel

Prof. Dr. med. Dr. rer. nat. Fritz Julius Karl Freiherr von und zu Rathenburg vor der Isar, MdB

<name>
<prefix qualifier="AC">Prof. Dr. med. Dr. rer. nat. </prefix> <given>Fritz</given> <given>Julius</given> <given>Karl</given> <prefix qualifier="NB">Freiherr </prefix> <prefix qualifier="VV">von und zu </prefix> <family>Rathenburg vor der
Isar</family> <suffix>, MdB</suffix></name>

hl7:prefix

ENXP

0 … *

Titel

(Hea...get)

wo [@qualifier='AC']

@qualifier

set_cs

1 … 1

F

AC

hl7:given

ENXP

0 … *

Vorname

(Hea...get)

hl7:prefix

ENXP

0 … *

Namenszusatz

(Hea...get)

wo [@qualifier='NB']

@qualifier

set_cs

1 … 1

F

NB

hl7:prefix

ENXP

0 … *

Vorsatzwort

(Hea...get)

wo [@qualifier='VV']

@qualifier

set_cs

1 … 1

F

VV

hl7:family

ENXP

0 … *

Nachname

(Hea...get)

hl7:suffix

ENXP

0 … *

Suffix

(Hea...get)

hl7:administrativeGenderCode

CE

1 … 1

R

Geschlecht (administrativ) des Patienten

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.1 Administrative Gender (HL7 V3) (DYNAMIC)

Beispiel

hl7:birthTime

TS.DATE.MIN

1 … 1

R

Geburtsdatum des Patienten

(Hea...get)

Beispiel

hl7:maritalStatusCode

CE

0 … 1

Familienstand des Patienten

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12212 Marital Status (DYNAMIC)

Beispiel

hl7:religiousAffiliationCode

CE

0 … 1

Religionszugehörigkeit des Patienten

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.19185 Religious Affiliation (DYNAMIC)

Beispiel

hl7:raceCode

NP

darf nicht verwendet werden

(Hea...get)

hl7:ethnicGroupCode

NP

darf nicht verwendet werden

(Hea...get)

hl7:guardian

0 … *

Vormund/Sachwalter des Patienten

(Hea...get)

hl7:addr

AD

0 … 1

(Hea...get)

hl7:telecom

TEL

0 … *

(Hea...get)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:guardianPerson
hl7:guardianOrganization

hl7:guardianPerson

(Hea...get)

hl7:name

PN

1 … 1

M

(Hea...get)

hl7:guardianOrganization

(Hea...get)

hl7:name

ON

1 … 1

M

(Hea...get)

hl7:birthplace

0 … 1

Geburtsort des Patienten

(Hea...get)

Beispiel

<birthplace>
<place>
<addr>Hamburg</addr> </place></birthplace>

hl7:place

1 … 1

M

(Hea...get)

hl7:addr

AD

1 … 1

M

(Hea...get)

hl7:languageCommunication

0 … *

(Hea...get)

hl7:languageCode

CS

0 … 1

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.11526 HumanLanguage (DYNAMIC)

hl7:modeCode

CE

0 … 1

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12249 LanguageAbilityMode (DYNAMIC)

hl7:proficiencyLevelCode

CE

0 … 1

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.12199 LanguageAbilityProficiency (DYNAMIC)

hl7:preferenceInd

BL

0 … 1

(Hea...get)

WEITERLEITUNG cdaab2:Informant (informant) (Template)

cdaab2:Empfänger (informationRecipient) (headertemplate) cdaab2:Datentypist (dataEnterer) (headertemplate)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Autor (author - generisch)

Id

1.2.276.0.76.10.2002

Gültigkeit

2013‑07‑10

Status

Entwurf

Versions-Label

Name

HeaderAuthor

Bezeichnung

CDA author

Beschreibung

Die Autor-Relation gibt den Urheber der Dokumentation und den Zeitpunkt der Autorenschaft wieder. Dies sind in der Regel Personen (Gesundheitsdienstleister) oder auch Geräte, die Daten erzeugen.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.276.0.76.10.90010	Inklusion	CDA Person Elements	DYNAMIC
1.2.276.0.76.10.90011	Inklusion	CDA Organization Elements	DYNAMIC

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.102 CDA author (DYNAMIC)

ref

ad1bbr-

Beispiel

Autor ist eine Person

<author typeCode="AUT">
  <functionCode code="DISPHYS" displayName="discharging physician" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction"/>  <time value="20130407130000+0500"/>  <assignedAuthor classCode="ASSIGNED">
    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Marie</given>        <family>Müller</family>      </name>    </assignedPerson>    <representedOrganization>
      <id root="2.16.840.1.113883.19.5"/>      <name>Beispiel Krankenhaus</name>    </representedOrganization>  </assignedAuthor></author>

Beispiel

Autor ist ein Gerät/Maschine

Item

DT

Kard

Konf

Beschreibung

Label

hl7:author

(Hea...hor)

@typeCode

0 … 1

F

AUT

@contextControlCode

0 … 1

F

OP

Beispiel

hl7:functionCode

CE

0 … 1

(Hea...hor)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC)

hl7:time

TS.DATE.MIN

1 … 1

gibt den Zeitpunkt an, an dem der Autor seinen Beitrag am Dokument beendet hat; dies kommt bei einem Autoren praktisch überein mit ClinicalDocument.effectiveTime

(Hea...hor)

hl7:assignedAuthor

1 … 1

(Hea...hor)

@classCode

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

(Hea...hor)

hl7:code

CE

0 … 1

Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin

(Hea...hor)

hl7:telecom

TEL

0 … *

(Hea...hor)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

… 1

(Hea...hor)

Eingefügt

von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)

@classCode

0 … 1

F

PSN

@determinerCode

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

(Hea...hor)

hl7:assignedAuthoringDevice

… 1

(Hea...hor)

@classCode

0 … 1

F

DEV

@determinerCode

0 … 1

F

INSTANCE

hl7:manufacturerModelName

SC

1 … 1

(Hea...hor)

hl7:softwareName

SC

1 … 1

(Hea...hor)

hl7:representedOrganization

1 … 1

M

(Hea...hor)

Beispiel

Eingefügt

von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...hor)

hl7:name

ON

1 … 1

M

(Hea...hor)

hl7:telecom

TEL

0 … *

(Hea...hor)

hl7:addr

AD

0 … 1

(Hea...hor)

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

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Verwaltende Organisation (custodian - generisch)

Id

1.2.276.0.76.10.2004

Gültigkeit

2020‑03‑29

Andere Versionen mit dieser Id:

HeaderCustodian vom 2013‑07‑17
HeaderCustodian vom 2013‑07‑07

Status

Aktiv

Versions-Label

Name

HeaderCustodian

Bezeichnung

CDA custodian

Beschreibung

Verantwortliche Organisation für ein erstelltes Dokument (die das Dokument verwaltende Organisation). In der Regel ist es die erstellende Institution des Dokumentes.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Item

DT

Kard

Konf

Beschreibung

Label

hl7:custodian

(Hea...ian)

@typeCode

0 … 1

F

CST

Beispiel

hl7:assignedCustodian

1 … 1

M

(Hea...ian)

@classCode

0 … 1

F

ASSIGNED

hl7:representedCustodianOrganization

1 … 1

M

(Hea...ian)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

1 … 1

M

(Hea...ian)

hl7:name

ON

1 … 1

M

(Hea...ian)

hl7:telecom

TEL

0 … 1

(Hea...ian)

hl7:addr

AD

0 … 1

(Hea...ian)

cdaab2:Beteiligte (participant) (headertemplate)

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:

^{[Abbildung 2]} 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.).

^{[Abbildung 3]} Ü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.

Für strukturierte CDA-Dokumente (structuredBody) gilt, dass ein Clinical Document mindestens ein „section"-Element enthalten muss. Jede Sektion muss genau ein „Text"-Element enthalten, das nicht leer sein darf.

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.

Der Text in den Abschnitten kann mit bestimmten Elementen strukturiert werden, die im Abschnitt Textstrukturierung genauer beschrieben sind.

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.

^{[Abbildung 4]} 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).

^{[Abbildung 5]} 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.

^{[Abbildung 6]} 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.

^{[Abbildung 7]} 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.

Die Reihenfolge der Darstellung richtet sich nach der Reihenfolge im CDA Dokument.

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>

^{[Abbildung 8]} 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

^{[Tabelle 4]} 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.

^{[Abbildung 9]} 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.

^{[Tabelle 5]} 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 .

Section: Anrede

Id

1.2.276.0.76.10.3001

Gültigkeit

2013‑01‑10

Status

Aktiv

Versions-Label

Name

Salutation

Bezeichnung

Anrede

Beschreibung

Dieser Abschnitt enthält die allgemeinen einleitenden Sätze eines Dokuments, z. B. eines Arztbriefes oder eines Befund-Dokuments. Sie werden in einem Abschnitt zusammengefasst und können Anrede (z. B. „Sehr geehrter Herr Kollege,..."), eine erste Nennung des Patienten evtl. mit der zusätzlichen Angabe des Geburtsdatums etc. enthalten.

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.3001

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)

ref

ad1bbr-

Beispiel

Anrede

<section>
<templateId root="1.2.276.0.76.10.3001"/> <code code="X-SALUT" codeSystem="2.16.840.1.113883.6.1" displayName="Salutation"/> <text>
<paragraph>Sehr geehrter Herr Kollege Dr. Heitmann,</paragraph> <paragraph>Vielen Dank für die freundliche Überweisung des Patienten Paul Pappel, geb. 12. Dez. 1955.</paragraph> </text></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

(Sal...ion)

hl7:templateId

II

1 … 1

M

(Sal...ion)

@root

uid

1 … 1

F

1.2.276.0.76.10.3001

hl7:code

CE

1 … 1

M

(Sal...ion)

@code

CONF

1 … 1

F

X-SALUT

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

Beispiel

hl7:title

NP

Ein Titel des Abschnitts kommt in der Begrüßung nicht vor

(Sal...ion)

hl7:text

SD.TEXT

1 … 1

M

(Sal...ion)

Anmerkung: LOINC Codes mit einem vorangestellten X, wie hier X-SALUT, werden kurzfristig durch tatsächliche numerische LOINC Codes ersetzt.

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

cdaab2:Anamnese (Sektion) cdaab2:Befunde (Sektion)

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>

WEITERLEITUNG cdaab2:ICD-Diagnose Entry (Template)

WEITERLEITUNG cdaab2:TNM-Diagnose Entry (Template)

cdaab2:Besondere Hinweise (CAVE) (Sektion) cdaab2:Maßnahmen (Sektion) cdaab2:Notizen (Sektion) cdaab2:Epikrise (Sektion) cdaab2:Medikation (Sektion) cdaab2:Labordaten (Sektion)

WEITERLEITUNG cdaab2:Anam-Section (Template)

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden.

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

Anhang

Referenzen

↑ Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)
↑ HL7 Deutschland e. V. http://www.hl7.de
↑ Erstellung von XML-Signaturen für Dokumente nach Clinical Documents Architecture – R2 (Elektronische Signatur von Arztbriefen). Spezifikation der Bundesärztekammer, Ärztekammer Nordrhein, Ärztekammer Westfalen-Lippe. Version 1.4 vom 20. Mai 2008
↑ IHE Deutschland: Cookbook http://wiki.hl7.de/index.php?title=IHE_DE_Cookbook
↑ Arztbrief des VHitG (jetzt bvitg), http://www.bvitg.de/arztbrief.html

Referenzfehler: Es sind <ref>-Tags für die Gruppe „Abbildung“ vorhanden, jedoch wurde kein dazugehöriges <references group="Abbildung" />-Tag gefunden oder ein schließendes </ref> fehlt.
Referenzfehler: Es sind <ref>-Tags für die Gruppe „Tabelle“ vorhanden, jedoch wurde kein dazugehöriges <references group="Tabelle" />-Tag gefunden oder ein schließendes </ref> fehlt.

[1] Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)

[2] HL7 Deutschland e. V. http://www.hl7.de

[cdasign-3] Erstellung von XML-Signaturen für Dokumente nach Clinical Documents Architecture – R2 (Elektronische Signatur von Arztbriefen). Spezifikation der Bundesärztekammer, Ärztekammer Nordrhein, Ärztekammer Westfalen-Lippe. Version 1.4 vom 20. Mai 2008

[4] IHE Deutschland: Cookbook http://wiki.hl7.de/index.php?title=IHE_DE_Cookbook

[5] Arztbrief des VHitG (jetzt bvitg), http://www.bvitg.de/arztbrief.html

[1]

[2]

[3]

[4]

[5]

[Abbildung 1]

[Tabelle 1]

[Tabelle 2]

[Tabelle 3]

[Abbildung 2]

[Abbildung 3]

[Abbildung 4]

[Abbildung 5]

[Abbildung 6]

[Abbildung 7]

[Abbildung 8]

[Tabelle 4]

[Abbildung 9]

[Tabelle 5]

Arztbrief 2012

Inhaltsverzeichnis

Impressum

Ansprechpartner

Disclaimer

Danksagung

Autoren

Mit Beiträgen von

Copyright-Hinweis, Nutzungshinweise

Einleitung

Motivation

Zielgruppe

Dokumente im Gesundheitswesen

Abgrenzung

Aufbau dieses Implementierungsleitfadens

Transportaspekte

Interaktionsdiagramm

Dokumentenaustausch

Rechtssichere Übertragung

Struktureller Aufbau

Grober XML-Aufbau von CDA-Dokumenten

Dokumentenstruktur Arztbrief

Attribute der CDA-Klasse

Beispiel

Informationen über die verschiedenen Beteiligten und Aktivitäten, die in Zusammenhang mit dem Dokument stehen

CDA-Header-Assoziationen

Patient (recordTarget - generisch)

Autor (author - generisch)

Verwaltende Organisation (custodian - generisch)

CDA R2 Body

Allgemeiner Aufbau des Body

nonXMLBody (Variante 1)

structuredBody (Variante 2)

Attribute von strukturierten Sections

Section.title: Titel des Abschnitts

Section.text: Text des Abschnitts

Section.code: Klassifizierung des Abschnitts

Section.languageCode: Sprache des Abschnitts

Beispiele für Abschnitte in einem Dokument

Entry

Levels

Level 1

Level 2

Level 3

Textstrukturierung

Textauszeichnung

Listen

Tabellen

Unterabschnitte

Überschriften

Superskripts und Subskripts

Zeilenumbrüche

Fußnoten

Sonstige Zeichenstile

Referenzierter Inhalt (content)

Referenz zu (externen) Multimedia-Inhalten

ObservationMedia Klasse

Vokabular

Beispiel

Section: Anrede

Section: Diagnosen

Aufnahmediagnose

Entlassungsdiagnose

Textformatierung für Diagnosen (auf Level 1)

Beispiel

Anhang

Referenzen

Navigationsmenü

Suche